[00:08] <zorglu_> 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] <RAOF> zorglu_: Also, yes.  They're options to dpkg-deb, I believe.
[00:09] <zorglu_> RAOF: it is. but .tar.7z takes more than .7z itself
[00:10] <zorglu_> RAOF: aka .tar got a lot of overhead
[00:10] <zorglu_> RA
[00:10] <zorglu_> ok thanks will look
[00:10] <StevenK> .tar has very overhead.
[00:10] <RAOF> In particular, -Zlzma
[00:10] <StevenK> Er, very little
[00:10] <lifeless> its got a 512 byte block size
[00:11] <schierbeck> i've got a problem building a package, is there some here willing to help me out?
[00:11] <StevenK> lifeless: Point. The tar header is quite small, though.
[00:11] <lifeless> sure; but stuff 100K 5-byte files in tar :)
[00:12] <schierbeck> lifeless: oh, hi!
[00:12] <lifeless> schierbeck: hi
[00:12] <schierbeck> i'm trying hard to learn packaging, but i'm completely stuck
[00:13] <schierbeck> 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] <schierbeck> i can do ./configure and make just fine
[00:13] <schierbeck> is that a common problem?
[00:14] <zorglu_> pure7z=1705165, tar.gz=3170879(with gzip -9), tar.7z=2294475(top 7z compression)
[00:15] <zorglu_> notice that pure7z is 1.7mbyte, while tar+lzma=2.3mbyte
[00:15] <zorglu_> StevenK: this is the overhead im talking about
[00:15] <lifeless> zorglu_: debs are not targs
[00:15] <lifeless> zorglu_: they are ar's.
[00:16] <zorglu_> of the same package. a normal .deb is 3.2mbyte :)
[00:17] <lifeless> zorglu_: yes, we know, have you tried the -Zlzma option yet ?
[00:17] <lifeless> schierbeck: no not a common problem
[00:17] <zorglu_> lifeless: where should i put this option ?
[00:17] <schierbeck> lifeless: i've been googling around for ages, and i can't fint a pattern
[00:17] <lifeless> do you have a clean rule that removes it perhaps?
[00:18] <schierbeck> lifeless: could be, i'll go check it out!
[00:19] <RAOF> 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 <packagedir>'
[00:20] <zorglu_> RAOF: worst i use epm :)
[00:20] <schierbeck> lifeless: nope, it doesn't get deleted
[00:29] <mok0> Is would be nice to have the newest lintian installed on REVU...
[00:30] <zorglu_> RAOF: ok thanks for your help. now i know it is possible at least
[00:30] <mok0> s/Is/It
[00:30] <zorglu_> RAOF: doing it with epm seems non trivial as it hardcode the gzip :)
[00:30] <zorglu_> snprintf(command, sizeof(command), EPM_GZIP " > %s", filename); <- bla :)
[00:34] <zorglu_> https://wiki.ubuntu.com/dpkg-lzma <- already working on the matter, hey :)
[00:49] <bddebian> Heya gang
[01:13] <mok0> booring
[01:14]  * bddebian dances around mok0
[01:14] <mok0> yay
[01:15] <mok0> bddebian, feel like reviewing?
[01:17] <bddebian> mok0: What's the package?
[01:17] <mok0> http://revu.ubuntuwire.com/details.py?package=gpp4
[01:17] <mok0> bddebian: it's a library
[01:17] <bddebian> Ugh :-)
[01:23] <jdong> bluekuja: what do you think about the upgrade request for transmission? should we service it ourselves or wait for Debian?
[01:23] <bddebian> mok0: Looking
[01:24] <mok0> bddebian: cool
[01:28] <jdong> 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] <bddebian> mok0: Just out of curiosity, why do you call clean and distclean?
[01:31] <mok0> bddebian: hmm, it's been a while since I wrote it, it may be redundant
[01:31] <jdong> oh I am an idiot, it's in main.
[01:56] <StevenK> imbrandon: Gah! apt-mirror is a compassionate parent and doesn't kill its children.
[01:56] <imbrandon> heh
[01:57] <StevenK> imbrandon: It ought to.
[01:57] <imbrandon> 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] <StevenK> imbrandon: I have a patch already.
[01:57] <imbrandon> ahh killer
[01:57] <slicer> 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] <StevenK> imbrandon: Anyway, it also doesn't lock.
[01:57] <imbrandon> StevenK: what would it lock ?
[01:58] <StevenK> 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] <imbrandon> ahhh
[01:58] <imbrandon> yea bad mojo
[01:58] <imbrandon> never thought about that
[01:58] <StevenK> imbrandon: Example: You have one running, and then cron fires off another -> Badness
[01:58] <imbrandon> right
[01:58] <StevenK> imbrandon: I'm investigating a patch for that, too.
[01:59] <imbrandon> hrm it would have to lock per mirror
[01:59] <imbrandon> because really it could be run with a diffrent config
[01:59] <imbrandon> at the same time
[01:59] <StevenK> imbrandon: Nah, don't do that, it's too hard.
[01:59] <imbrandon> err per config, not per mirror
[01:59] <imbrandon> hrm
[01:59] <StevenK> A global "I'm running" lock.
[01:59] <imbrandon> yea just check for a pid
[02:01] <imbrandon> cool, i'm heading to bed, if you want email them to me, if not i'll be arround fairly early tomarrow
[02:03] <minghua> Debian is finally starting to remove GNOME 1.x stuff.
[02:04] <StevenK> \o/ Finally
[02:05] <minghua> ... and obviously, the first reply is objection (to the procedure).
[02:05] <minghua> :-/
[02:05] <imbrandon> http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/bca2c92496161015
[02:07] <slangasek> Debian has been working on removing GNOME 1.x stuff for some time
[02:07] <slangasek> we're just now getting to the bottom of the stack, is all
[02:08] <bddebian> Ugh level 1 deps are even ugly :-(
[02:09] <ion_> imbrandon: Haha
[02:09] <pochu> Good night folks
[02:09] <mok0> bddebian: what do you mean?
[02:14] <mok0> bddebian: thx for advocating. Without doubt you are right on the clean/distclean target, in fact I think distclean depends on clean
[02:15] <mok0> Well 03:16am here, gotta go to bed
[02:15] <mok0> g'night
[03:34] <alex_mayorga> hi
[03:34] <alex_mayorga> anyone knows if netbeans 6 is planned to be packaged?
[03:34] <alex_mayorga> is it late already?
[03:35] <LucidFox> We haven't hit feature freeze yet, so it's not late to have it packaged
[03:36] <alex_mayorga> it's on debian already http://packages.debian.org/sid/contrib/netbeans-ide
[03:36] <alex_mayorga> but I've never done a ubuntu package myself :S
[03:37] <alex_mayorga> LucidFox, what should be the right way to go?
[03:38] <LucidFox> first, check if a needs-packaging bug has been filed for it on Launchpad
[03:38] <LucidFox> if it hasn't been, file it yourself
[03:39] <LucidFox> "Current plan for NB 6.0 packaging"...
[03:39] <LucidFox> It's underway.
[03:40] <LucidFox> https://launchpad.net/~mslama-email <-- ask this person about the progress
[03:41] <alex_mayorga> is there a bug files already?
[03:43] <crimsun> 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] <crimsun> it's also a good idea to ask in #ubuntu-java
[03:44] <alex_mayorga> I'll look around
[03:44] <LucidFox> Oh, so it's in Debian
[03:44] <LucidFox> alex_mayorga> http://packages.qa.debian.org/n/netbeans-ide.html
[03:44] <alex_mayorga> yup
[03:44] <alex_mayorga> and sun-java6 is on hardy already if I'm not mistaken
[03:45] <LucidFox> then all we'll need is to merge it from there
[03:45] <LucidFox> yes, but there's the Dreaded Chroot Build Issue
[03:45] <alex_mayorga> ???:-(
[03:46] <LucidFox> 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] <crimsun> correct
[03:47] <LucidFox> 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] <alex_mayorga> nothing lost on asking I guess
[03:48] <alex_mayorga> just wondering given feisty had netbeans 5.5 and canonical and sun did the whole press release thingie for the previous release
[03:49] <alex_mayorga> probably someone at canonical is already into it, dunno
[03:50] <alex_mayorga> there's even https://edge.launchpad.net/netbeans6
[03:52] <alex_mayorga> please forgive me if I'm babbling in the wrong channel or anything
[03:55] <mwolson> it might be possible to build using icedtea-java7 instead of sun-java6
[03:58] <LucidFox> alex_mayorga> That's the upstream page for netbeans6, not the Ubuntu package
[04:00] <RAOF> LucidFox: But, IIRC, you can work around the Dreaded Chroot Build issue by writing a magic value somewhere in /etc.
[04:00] <alex_mayorga> LucidFox, thanks
[04:02] <bddebian> OK dumb question, how can I force a build with gcc-4.3?  Can't I use CC=gcc-4.3 ?
[04:03] <RAOF> That *should* work, assuming autotools.  I think.
[04:03] <crimsun> using what gcc-4.3 package in hardy?  :)
[04:03] <RAOF> Ok, and assuming a gcc-4.3 binary :)
[04:04] <bddebian> crimsun: OK you caught me, this is in sid :)
[04:04] <crimsun> ;)
[04:05] <bddebian> I have a patch for vodovod but I need to test it :(
[04:19] <ScottK> bddebian: This Universe.  We don't actually test stuff here.
[04:19] <ScottK> ;-)
[04:20] <bddebian> heh, touche ;-P
[04:21] <ScottK> slangasek: Thanks for the quick processing of NEW stuff today.
[04:33]  * TheMuso grumbles at late mailing list email arrivals
[04:35] <slangasek> ScottK: n/p, it was the day for it :)
[04:37] <ScottK> 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] <TheMuso> 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] <ubotu> Launchpad bug 182700 in sysinfo "Please sponsor sysinfo 0.7ubuntu3 (universe) into Hardy" [Wishlist,New] https://launchpad.net/bugs/182700
[04:53] <TheMuso> I told him to not use cdbs just for patches, and look into something like dpatch
[04:53] <TheMuso> this time, he seems to ahve probably gotten the code from simple-patchsys, but I haven't checked.
[04:53] <TheMuso> 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] <TheMuso> 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] <bddebian> Grr, what is the g++ equivalent of CC=gcc-x.x ?
[05:05] <TheMuso> bddebian: Run configure --help and that should tell you at the bottom of the output
[05:05] <TheMuso> ./configure even
[05:06] <TheMuso> From what I can remember, its CX
[05:06] <TheMuso> CXX even
[05:06] <StevenK> It's either CXX or CPP
[05:08] <bddebian> CPP is C preprocessor isn't it?
[05:10] <StevenK> Hrm, it could be.
[05:10] <bddebian> Thank btw :-)
[05:10] <bddebian> +s
[05:12] <ScottK> TheMuso: I'd make him do it again with dpatch (dunno about quilt, I've managed to avoid it so far).
[05:14] <StevenK> quilt is kinda fun, once you managed to get yourself in the right mindset
[05:14] <StevenK> s/ged/ge/
[05:17] <TheMuso> 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] <TheMuso> ScottK: I didn't see your message until after I posted to the bug, but thanks for your thoughts.
[05:18] <TheMuso> THis contributor is, well, I think, a little over eager.
[05:22] <somerville32> He has almost as many uploads as me, lol
[05:22] <somerville32> I guess I should stop slacking, lol
[05:22] <TheMuso> somerville32: heh.
[05:26] <ion_> Anyone feel like uploading http://revu.tauware.de/details.py?package=hardware-connected (it has been advocated twice)? Thanks :-)
[05:30] <bddebian> Ugh, how the hell am I going to conditionally include auto_ptr.h if building with gcc-4.3?
[05:33] <LucidFox> #if (__GNUC__ == 4) && (__GNUC_MINOR__ >= 3)
[05:33] <StevenK> Eww
[05:34] <TheMuso> heh
[05:34] <ion_> That ignores the case where __GNUC__ > 4 ;-)
[05:34] <LucidFox> #if (GNUC > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 3))
[05:35] <LucidFox> s/(GNUC/(__GNUC__
[05:35]  * StevenK quietly sobs
[05:35] <TheMuso> Even more eww
[05:35] <bddebian> Actually that's backward compatibility anyway isn't it?  I.E. the code should be updated?
[05:35] <RAOF> 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] <RAOF> Then you could have all sorts of fun with #if HAVE_AUTOPTR_H #include <auto_ptr.h> #endif
[05:37] <LucidFox> Makes sense.
[05:38] <somerville32> You could also pass the version to gcc with the -D flag :P
[05:38] <RAOF> And there's some voodoo like AC_CHECK_HEADER(auto_ptr.h, bleargh)
[05:42] <bddebian> Yuck to all :-)
[05:43] <RAOF> 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] <bddebian> Aye, but in this case afaict, auto_ptr.h only comes with gcc-4.3 for backwards compatibility
[05:45] <StevenK> You can't fix the code to work with both 4.2 and 4.3?
[05:46] <bddebian> 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] <bddebian> yes
[05:46] <somerville32> soren, can you please take a look at bug #182445 - it is blocked pending your ACK
[05:46] <RAOF> So it doesn't exist in < 4.3?
[05:47] <ubotu> Launchpad bug 182445 in ebox-network "Sponsor ebox-network_0.9.3-0ubuntu4" [Wishlist,Confirmed] https://launchpad.net/bugs/182445
[05:47] <bddebian> bdefreese@bddebian1:~/games_team/moagg/moagg-0.18$ find /usr/include/ -name auto_ptr.h
[05:47] <bddebian> /usr/include/c++/4.3/backward/auto_ptr.h
[05:47] <RAOF> Or you don't need it < 4.3?  Or it breaks stuff if you include it in < 4.3?
[05:47] <bddebian> Well < 4.3 would FTBFS because the file doesn't exist :-)
[05:48] <lifeless> RAOF: auto_ptr IIRC is one of the new TR-2 features
[05:48] <RAOF> Right, so it only exists on 4.3, so you can AC_CHECK_HEADER(foo, blar)
[05:48] <lifeless> RAOF: in boost you had to include a header to get it
[05:48] <lifeless> RAOF: in TR-2 its part of another existing STL header, so you don't need the header.
[05:48] <RAOF> Aaaaah.-
[05:48] <RAOF> So auto_ptr.h is going to be essentially empty?
[05:49] <RAOF> So that code that #include <auto_ptr.h> will still work?
[05:49] <lifeless> 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] <bddebian> On 4.3 is where I'm HAVING to include it
[05:50] <RAOF> bddebian: Or else it fails to build with an error (pastebin)?
[05:50] <bddebian> auto_prt is undefined
[05:50] <bddebian> Err auto_ptr
[05:51] <bddebian> Well that's not totally true
[05:51] <RAOF> Right.  So it's in some other random STL header.
[05:51] <bddebian> It actually barfs about being in std::auto_ptr()
[05:52] <RAOF> Possible to pastebin the (probably huge) error?
[05:52] <LucidFox> bddebian> Can't you add "using std::auto_ptr"?
[05:52] <bddebian> There are several and I've been fixing them incrementally
[05:53] <bddebian> LucidFox: Dunno, I don't do C++
[05:53] <LucidFox> and #include <memory>
[05:53] <bddebian> Well I don't do C either but that's a different story
[05:53] <RAOF> LucidFox: That's where auto_ptr is?
[05:53] <LucidFox> yes
 is not a standard header anyway, unlike <memory>
[05:54] <RAOF> Right.  So, what you'd want to do is check for the presence of auto_ptr in libstdc++, and if it exists then #include <memory> and using std::auto_ptr
[05:54] <bddebian> So just change: std::auto_ptr<Tiles> tiles(new Tiles());  to:  using std::auto_ptr<Tiles> tiles(new Tiles());  ??
[05:54] <RAOF> Oh, no.
[05:54] <LucidFox> eh, no
[05:55] <LucidFox> leave that as is
[05:55] <RAOF> Does #include <memory> appear, or help?
[05:56] <bddebian> checking
[05:57] <bddebian> Yep, just #including <memory> seems to work also.  Will that cause any issues on < 4.3?
[05:57] <LucidFox> No.
[05:57] <bddebian> sweet, thanks!
[05:57] <LucidFox> It's a header from the C++ standard, so should work everywhere.
[06:00] <RAOF> LucidFox: Yeah, but which standard? :P  I'm pretty sure some (really ancient) compilers will barf on it.
[06:01] <LucidFox> Maybe, but Ubuntu doesn't include them. :)
[06:02] <RAOF> And they probably don't support templates, either, which'll introduce other problems for that code :)
[06:02] <bddebian> Anyway, bed time for this old man.  Thanks again gents!
[06:04] <ScottK> 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] <ScottK> Now that bddebian's gone to bed, I get to be the old and incompetent one.
[06:05] <ScottK> For the 5 minutes longer than him that I can manage to stay awake...
[06:05] <ScottK> Good night all.
[06:22] <somerville32> Hi Hobbsee
[06:24] <LaserJock> quick question, how long does it usually take for a bug reported via email to show up on LP?
[06:24] <StevenK> 5-10 minutes?
[06:24] <LaserJock> hmm, ok
[06:25] <LaserJock> I just tried my first one and it still hasn't shown up
[06:25] <LaserJock> so I just wondered
[06:25] <Hobbsee> hi somerville32
[06:25] <Hobbsee> LaserJock: it probably died again
[06:25] <LaserJock> the first time I tried it the email didn't seem to send
[06:26] <LaserJock> but the second time it seemed like it sent it
[06:26] <somerville32> LaserJock, Did you sign the e-mail? :P
[06:26] <LaserJock> not sure
[06:26] <LaserJock> do I have to?
[06:26] <somerville32> yes
[06:26] <LaserJock> hmm
[06:26] <LaserJock> I think I did
[06:26] <LaserJock> I just copy-n-pasted the output from requestsync
[06:27] <LaserJock> I think that's enough
[06:27] <TheMuso> Heya Hobbsee!
[06:27] <Hobbsee> hey TheMuso!
[06:27] <Hobbsee> LaserJock: you need to sign the mail.  requestsync stuff is usually signed, iirc.
[06:27] <TheMuso> It is.
[06:27] <LaserJock> it had the GPG garbage
[06:28] <LaserJock> I've only ever signed email a couple times so I'm wasn't positive
[06:28] <LaserJock> s/I'm/I/
[06:29] <LaserJock> bah, that's why I so much prefer the web UI
[06:29] <Hobbsee> heh
[06:29] <LaserJock> and dislike BTS
[06:31] <LaserJock> 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] <LaserJock> s/received/sent/
[06:33]  * StevenK sighs.
[06:34] <StevenK> Everytime LaserJock files a bug against Debian, must we also listen to another rant about how crap (apparently) the Debian BTS is?
[06:34] <LaserJock> hehe
[06:34] <LaserJock> I don't think it's crap
[06:34] <LaserJock> in fact I think it's very nice
[06:34] <StevenK> It isn't funny, I'm serious.
[06:34] <LaserJock> it just needs to grow a web ui
[06:35] <StevenK> It hasn't needed one before.
[06:35] <Hobbsee> StevenK: just don't mention the launchpad.
[06:36] <StevenK> PONI ... Oh, wait
[06:36] <LaserJock> StevenK: well, sorry for the rant, it wasn't meant as one
[06:40] <LaserJock> hmm, so 25 min without anything, should I assume it died?
[06:41] <Hobbsee> LaserJock: er, are you sending a bug to the debian BTS, or launchpad via the web?
[06:42] <LaserJock> launchpad via email
[06:42] <Hobbsee> er, by email
[06:42] <Hobbsee> then you probably should.
[06:42] <Hobbsee> LaserJock: what was the request for?  i can just put it thru here
[06:42] <somerville32> Should I add lintian ignores for warnings or just errors? (when appropriate)
[06:42] <LaserJock> I can do it, I just thought I'd try out the email interface
[06:43] <LaserJock> it's nice to not add any ignores, but I would think just errors if you have to
[06:43] <somerville32> W: pysdm: desktop-command-not-in-package /usr/share/applications/pysdm.desktop gksudo
[06:44] <somerville32> W: pysdm: script-not-executable ./usr/share/pysdm/pysdm.py
[06:45] <LaserJock> hmm, I may have found the problem
[06:46] <LaserJock> when I go to the email in my Sent folder evo says it doesn't have a valid signature
[06:46] <LaserJock> so maybe my copy-n-paste signing was not a good idea
[06:46] <somerville32> If I can remove a build-dep and it builds fine, it should be safe to remove it right?
[06:47] <Hobbsee> LaserJock: i don't see why you need to c&p at all anyway
[06:47] <Hobbsee> somerville32: er, yes, i think so, but does it need the corresponding package to run, which then neesd adding?
[06:48] <LaserJock> Hobbsee: I'll just try it from requestsync directly next time
[06:48] <somerville32> hmm
[06:51] <SWAT> 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] <somerville32> It is  intltool
[06:52] <somerville32> pysdm seems to build fine w/o it
[06:52] <LaserJock> well, what does intltool do ...
[06:53] <Hobbsee> oh, interesting, i didn't think it did that
[06:54] <Hobbsee> LaserJock: openmpi just worked
[06:54] <LaserJock> Hobbsee: I did that web ui
[06:54] <LaserJock> finding another
[06:54]  * Hobbsee dies at all the mail from u-a
[06:55] <SWAT> Inbox zero
[06:55] <somerville32> SWAT, hmm... it seems to automatically extracts translatable strings from oaf, glade, bonobo
[06:55] <somerville32>  ui, nautilus theme and other XML files into the po files.
[06:56] <somerville32> I think I need it
[06:56] <somerville32> :)
[06:56] <somerville32> po/Makefile.in calls it
[06:56] <LaserJock> somerville32: good boy
[06:56] <LaserJock> :-)
[06:57] <LaserJock> hmm, seems lintian could use a sync
[08:00] <dholbach> good morning
[08:20] <man-di> does someone know when slytherin is normally here? Whats his timezone?
[08:21] <huats> morning everyone
[08:24] <ToyKeeper> ... if only it were morning here.  :)  I'm finally awake and it's time to sleep.
[08:32] <\sh> moins
[09:00] <slytherin> 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] <slytherin> for me the connection times out.
[09:04] <\sh> well, the servers are up and running
[09:04] <man-di> slytherin: hello
[09:05] <slytherin> man-di: hi
[09:05] <man-di> slytherin: did you got a response from Vincent about batik?
[09:05] <slytherin> 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] <man-di> ah
[09:06] <man-di> I thought you already mailed him
[09:06] <man-di> sorry for that misunderstanding
[09:06] <slytherin> man-di: I will do it today.
[09:06] <man-di> cool
[09:07] <man-di> would be nice to be able to move batik to main/universe
[09:07] <man-di> as some documentation people want to have a working free toolchain
[09:19] <geser> good morning
[09:20] <pochu> hey geser
[09:20] <geser> 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 :-)
[09:29]  * Hobbsee ponders upgrading the lintian/linda on revu
[09:30] <pochu> Hobbsee: please :)
[09:30] <Hobbsee> mabye the linda too
[09:31] <mok0> Hobbsee: Yes!!
[09:31] <Hobbsee> er, why are backports enabled on this machine?
[09:32] <Hobbsee> chug, chug, chug
[09:32]  * Hobbsee actually applies the security updates, etc
[09:34] <Hobbsee> StevenK: is there any reason why linda shouldn't be backported too?
[09:34] <StevenK> Um
[09:34] <Hobbsee> seeing as it's listed on revu, etc?
[09:34]  * StevenK shrugs
[09:34] <Hobbsee> StevenK: looks like there are some patches too that you might want
[09:39] <Hobbsee> uh oh....
[09:39]  * rzr updated http://revu.tauware.de/details.py?package=jaaa
[09:42] <DaveMorris> I'm looking for a second revu of my package, available at - http://revu.tauware.de/details.py?package=libserial
[09:43] <Hobbsee> right, so it appears that you can all view revu
[09:49] <Hobbsee> siretart: ping
[09:52] <\sh> StevenK, are you working on a new virtualbox upload to match kernel 2.6.24-X ?
[09:57] <pochu> \sh: bug 156210
[09:58] <ubotu> 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] <Hobbsee> siretart: don't worry
[10:13] <siretart> what's up?
[10:14] <Hobbsee> nothing, now
[10:14] <siretart> k
[10:16] <\sh> alleeHol, pingeling fai
[10:28] <persia> ScottK-confused: Could you expand a little on which part of libmilter causes your condition?  Is it the pulling out, or the building separately?
[10:42] <alleeHol> \sh: ah, right, yes.  My Dell Optiplex 755 are waiting too :(
[10:45] <slytherin> 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] <persia> 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] <ubotu> 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] <Seveas> alleeHol, optiplex 755 is nice
[10:48] <Seveas> alleeHol, too bad the network card driver for it is missing from initramfs by default :)
[10:49] <slytherin> hi all, if there is a connection issue which is causing FTBFS for lucene2, whom should I contact?
[10:49] <Hobbsee> slytherin: is it trying to connect to the internet during build?
[10:50] <slytherin> Hobbsee: yes, for validating an xml
[10:50] <persia> 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] <Hobbsee> slytherin: you fix the package so it doesn't require net access to build.
[10:51] <slytherin> Hobbsee: I guess that will need patch to source
[10:51] <Hobbsee> probably
[10:51] <Hobbsee> or forbid it from autosyncing
[10:51] <slytherin> persia: the dtd is xhtml1-transitional.dtd, do you have any idea where I can find it?
[10:53] <persia> slytherin: I think it's in w3-recs, but you'd want to check that.
[10:54] <Ng> it's presumably also at the url in the xml file that's being validated?
[10:54] <persia> 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] <Ng> fair point :)
[10:55] <slytherin> persia: it is in w3c-dtd-xhtml. I will create a patch accordingly
[10:55] <persia> slytherin: And yes, this unfortunately keeps the package in multiverse, but at least it builds :)
[10:56] <persia> slytherin: And thanks a lot for all your FTBFS efforts.  It's nice to see so many Java libraries becoming installable again.
[10:57] <slytherin> persia: You are welcome. Java is my favourite. And I am happy I am able to contribute to Ubuntu. :-)
[11:04] <man-di> hmm, still not Java related group on http://qa.ubuntuwire.com for multidistrotools...
[11:07] <persia> 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] <man-di> persia: thanks for the info
[11:23] <emgent> \sh, ping
[11:24] <\sh> emgent, yepp
[11:43] <pochu> 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] <persia> 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] <pochu> persia: since you already reviewed it, are you happy with it? 'cos I am :)
[11:46] <persia> 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] <pochu> Sure. Thank you.
[11:48] <Ng> 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] <pochu> 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] <Hobbsee> persia: it's still 2 acks for MOTU's too, isn't it?
[11:48] <persia> Hobbsee: Best practice, yes.  One can be the packager, of course.
[11:48] <Hobbsee> persia: of course
[11:49] <Hobbsee> persia: makes me wonder why falcon managed to get uploaded, though
[11:49] <pochu> Hobbsee: one ACK is enough
[11:49] <pochu> Hobbsee: https://wiki.ubuntu.com/MOTU/Council/Meetings/2007-02-23
[11:49] <persia> Hobbsee: Raise it to the MOTU Meeting if you want to adjust it again.
[11:50] <Hobbsee> persia: i don't really care sufficiently, as our MOTU's should be fine.
[11:52] <Hobbsee> just its' a small lack of transparency
[11:52] <persia> Hobbsee: I think that's the general point.  Sometimes there's a reason to just push, but I do see a lot of MOTU candidates on REVU early in the cycle, so I think the process works (although people might get jumpy as feature freeze approaches)
[11:53] <persia> Hobbsee: Anyway, the archive admins get to review again, so even if someone makes a big mistake, there should be another pair of eyes.
[11:53] <Hobbsee> true
[11:56] <TheMuso> But the less work for the archive admins, the better IMO.
[11:56] <persia> Yep.  We've already gotten two emalis from the archive-admins complaining about MOTU Reviews.  More would not be ideal.
[12:00] <Ng> is it possible for a source package to produce binary packages in different components? (ie main and universe)
[12:00] <Ng> I'm looking at rhythmbox and its uPnP plugin needs two python packages from universe, but it doesn't say that, it just fails to load the plugin
[12:00] <geser> Ng: yes, and it happens already sometimes
[12:01] <Ng> aha. I'm wondering if the plugin might be better off in universe so it can Depends on the right things and maybe be Recommends by rhythmbox itself
[12:01] <geser> Ng: but the source package needs to be in main to produce debs for main (and also it's build-depends must be in main)
[12:02] <Ng> which, fortunately, rhythmbox is :)
[12:02] <sladen> Ng: if Rhythmbox doesn't *require* it for operation, it shouldn't be *Depends*
[12:02] <Ng> sladen: I'm saying the plugin should Depends on the two python packages it requires. Whether or not rhythmbox should Recommends that plugin is a different matter (arguably it shouldn't)
[12:02] <sladen> but Recommends is good, as it'll get installed if it's available, but not break horribly otherwise
[12:03] <persia> Ng: If you think the plugins are useful enough to a large enough proportion of users, you might look into what would be required for MIRs for the build-dependencies.  It may be that whatever buggy, unsupported, security-problem-prone, or otherwise unsupportable issue has been addressed since the last review.
[12:03] <sladen> Ng: yup
[12:03] <Ng> persia: yeah I wondered about that too. I suspect that uPnP is going to become more and more useful. In the last 6 months I've acquired two consumer devices (ps3, n95) which now support it
[12:04] <Ng> hmm, and after you follow the chain down, at least 4 python packages would need promoting to main :/
[12:05] <Ng> configobj, ctypes, louie and coherence
[12:06] <Ng> would anyone happen to know of a source package which puts binaries into main and universe, so I can poke around it?
[12:06] <geser> Ng: ctypes? doesn't python2.5 already include it?
[12:07] <persia> python2.5 does include ctypes.
[12:07] <Ng> hmm
[12:07]  * persia remembers a whole heap of FTBFS issues when that happened
[12:07] <Hobbsee> Ng: kdenetwork
[12:07] <Hobbsee> iirc
[12:07] <Ng> Hobbsee: cool, thanks
[12:07] <Hobbsee> Ng: kdepim also should
[12:07] <siretart> Ng: xine-lib does so
[12:08] <Hobbsee> Ng: what did you want to know?
[12:08] <geser> Ng: gnupg2, the gnupg2 package is in universe while gpgsm and gnupg-agent are in main
[12:08] <Ng> Hobbsee: how one would do such a thing :)
[12:08] <Hobbsee> Ng: you don't.  the archive admins do.  as for how to get stuff into main, you file main inclusino reports
[12:08] <Hobbsee> Ng: they have overrides there
[12:08] <Hobbsee> it's not at the packaging level
[12:09] <Ng> Hobbsee: ah. in this case it would be the other way around, it'd be part of rhythmbox (in main already) going into a separate package in universe
[12:09] <pkern> dholbach: I need a gobby upload to be sponsored later.
[12:09] <dholbach> pkern: you can attach the diff to the bug you filed about it and i'll be in the sponsoring queue
[12:09] <mruiz> hi all
[12:09] <Hobbsee> Ng: right, so then you're looking to split the package, of which there are many examples, and then asking an archive admin to send a package to universe.
[12:09] <dholbach> pkern: I'll take a look at it then
[12:09] <dholbach> hey mruiz
[12:09] <Hobbsee> Ng: usually via a bug
[12:10] <mruiz> hey dholbach ! :-)
[12:10] <Ng> Hobbsee: thanks :)
[12:10] <Hobbsee> Ng: you're welcome.
[12:10] <pkern> dholbach: Thanks, will submit a diff in an hour, when I ate s.th. and booted my lappy.  Forgot to sync the branch to git.d.o. *narf*
[12:10] <dholbach> pkern: great
[12:11] <mruiz> What does mean the number after the responsible on http://people.ubuntu.com/~dholbach/sponsoring/ ?
[12:11] <persia> mruiz: Number of days since it entered the sponsors queue.
[12:11] <dholbach> number of days the subscription is old
[12:11] <mruiz> persia: useful!
[12:12] <mruiz> and the nickname with bold font?
[12:12] <dholbach> mruiz: core-dev
[12:13] <dholbach> in italics it's a team
[12:13] <mruiz> :-)
[12:13]  * persia notes that "Responsible" is really more "Interested" in the case of Needs-Packaging
[12:18] <slytherin> persia: found an ugly bug in w3c-dtd-xhtml while trying to fix lucene2 build.
[12:18] <pochu> dholbach: you should comment all that at the top of the page ;)
[12:18] <persia> slytherin: Excellent
[12:20] <dholbach> persia: should be fixed in one of the next runs
[12:20] <persia> dholbach: Really?  Cool!
[12:22] <dholbach> pochu: should be fixed in one of the next runs
[12:22] <pochu> Great. I wondered the same thing the other day (what the numbers meant)
[12:23] <slytherin> persia: The DTD has wrong paths for entity sets. it simply specifies file names, but files are in different directory. I will file a bug. But this also means that I can not use package w3c-dtd-xhtml (main) and I have to use w3-recs (multiverse). What do you suggest?
[12:24] <persia> slytherin: I suggest you submit a patch to w3c-dtd-xhtml that allows you to build against it.
[12:25] <slytherin> persia: hmm. that is tough task. and the package is in main. let's see.
[12:26] <persia> slytherin: Is it not just changing some directory references?  Also, there are a number of main sponsors, and if your patch to fix the FTBFS has a note in the bug indicating that the w3c-dtd-xhtml package needs a patch first, it oughtn't be too long before it gets uploaded.
[12:27] <slytherin> persia: Either change directory references or create symlinks. I will file a bug right away. So if someone picks it up before I start, well and good.
[12:28]  * persia suspects this bug is less difficult than the others that have been being addressed with such regularity
[12:29] <slytherin> persia: But is not difficult. There are various ways to fix it. SO I am a bit confused.
[12:30] <persia> slytherin: How are you confused.  As to whether it would be better to move things, or to symlink?
[12:31] <slytherin> persia: yes, move by changing rules or symlink.
[12:32] <ScottK> Good morning all.
[12:32] <ScottK> persia: The pulling out is easy, it's making a new set of rules to just build libmilter and friends that's got me confused.
[12:32] <mruiz> good morning ScottK
[12:33] <persia> ScottK: and friends?  I thought you just wanted ./libmilter/
[12:33] <ScottK> persia: libmilter, libmilter-dev, and libmilter-dbg.
[12:33] <ScottK> Heya mruiz.
[12:34] <persia> Ah.  Right.  So, first you want an orig.tar.gz.  I'd recommend undoing the tarball-in-tarball approach, and using the upstream sendmail tarball.
[12:34] <geser> ScottK: do you need a -dbg package? doesn't -dbgsym suffice?
[12:34] <slytherin> ScottK: FYI ... I files a bug in debian for kdissert for use of dh_icons. The maintainer says he won't do it.
[12:35] <ScottK> geser: The existing Sendmail package has one, so it'd be a regression not to provide it.
[12:35] <persia> Then, you need a build system.  I'd recommend just replacing the upstream build system with something smaller, using pkg-create-dbgsym and dh_strip for -dbg, and splitting -dev with dh_install.
[12:35] <ScottK> slytherin: That's all we can do.  It's not required in Debian.  Thanks for doing it.
[12:36] <geser> slytherin: there was a "discussion" about inclusion of dh_icons into packages on the debian-devel-ML
[12:36]  * persia downloads sendmail again to dig into generating -dbg
[12:36] <ScottK> persia: Thanks.
[12:36]  * ScottK wonders off to push children out the door to school.
[12:38]  * persia grumbles that the point of using CDBS is for short debian/rules files that are easy to read, and not using CDBS might be better when that goal cannot be achieved.
[12:40] <slytherin> persia: filed bug 183164
[12:40] <ubotu> Launchpad bug 183164 in w3c-dtd-xhtml "Wrong path for entity sets" [Undecided,New] https://launchpad.net/bugs/183164
[12:40]  * txwikinger2 is amused about the statement of easy to read and short rules files
[12:42] <persia> ScottK: Looks like you just need to define DEB_DBG_PACKAGES = libmilter$(sm_libmilter_version)-dbg and DEB_DBG_PACKAGE_libmilter$(sm_libmilter_version) = libmilter$(sm_libmilter_version)-dbg if you want to keep using CDBS, or use `dh_strip -X libmilter-dbg` otherwise.
[12:43] <persia> txwikinger2: If CDBS allows debian/rules to fit in less than 24 lines, it makes it really easy to read as that is a standard screen.  Even 48 isn't too bad.  A 595-line CDBS-based debian-rules file is just plain unreadable.
[12:43] <txwikinger2> :)
[12:44] <txwikinger2> Sounds like one of my fever dreams
[12:46] <persia> slytherin: Is there a way to set a default search path for DTD validation, or does that have to be encoded in each DTD individually?
[12:47] <slytherin> persia: I don't think it is possible.
[12:48] <persia> slytherin: In that case, I suggest it makes sense to patch the DTD to use the correct relative path references to where the files are installed by the package (assuming the license permits this).
[12:49] <geser> how does the syntax checker tool know where to find the dtd?
[12:49]  * persia thinks there's some registration process, but isn't that familiar with the Ubuntu XML environment
[12:49] <slytherin> geser: doctype includes path to DTD
[12:51] <geser> slytherin: that's usually a url and not a path
[12:51] <geser> and I doubt that we patch all files needing a dtd to find it on the harddisk
[12:52] <slytherin> geser: One can give path of a local file.
[12:52] <broonie> persia: there's catalogs in /etc/xml, see dh_installxmlcatalogs if you're using debhelper
[12:52] <txwikinger2> This doctype url thing is stupid... doesn't work offline
[12:53] <persia> broonie: Thanks for the explanation.
[12:53] <slytherin> geser: I have no idea if any other package is failing for same reason. Ideally it shouldn't fail at all.
[12:53] <persia> txwikinger2: That's why the DTDs are packaged :)
[12:53] <txwikinger2> :)
[12:55] <slytherin> persia: the copyright file of this package says that the license is GPL compatible.
[12:56] <persia> slytherin: In that case, patch it...
[13:02]  * persia tries to find problems with pochu's advocation
[13:02] <pochu> That'll be hard, I hope :)
[13:04] <persia> Ng.  Why does the revu orig tarball differ from the upstream tarball?
[13:08] <persia> pochu: Can you tell me about pycompat please?  Why might it be needed or not needed?
[13:11] <pochu> persia: it's generated by debian/rules clean. So you don't need to include it in the tarball, since it will be generated. But there's no harm in having it.
[13:12] <persia> pochu: OK.  That's not enough then.  Now just waiting for a tarball explanantion...
[13:12] <pkern> dholbach: How would you like it?  interdiff?  dsc?  http://dpaste.com/31122/
[13:13] <Ng> persia: hmm, I'll check
[13:13] <persia> pkern: It's just a normal update.  Submit a debdiff to a bug.
[13:13]  * pochu didnt look at that
[13:14] <pkern> persia: *cough*
[13:14]  * pkern hates it that he cannot update his packages himself.
[13:14] <persia> Ng: If they are basically the same, I can rebuild and retest with the upstream tarball, I just want to check.
[13:14] <pkern> dholbach: diffed against the current Debian version that is.
[13:14] <persia> pkern: Still a merge: just a debdiff.
[13:14] <Ng> persia: they ought to be very very similar at least. I've not quite got my release workflow sorted ;)
[13:15] <persia> Ng: Mind checking them?
[13:15] <Ng> persia: not at all :)
[13:15] <pkern> persia: debdiff of what?  last ubuntu vs. new?
[13:15] <pkern> persia: And I really need to file a bug?
[13:15] <persia> pkern: Debdiff against Debian, noting any Ubuntu variance.  Bugs are nice for tracking.
[13:16] <pkern> persia: That was a diff against Debian.
[13:16] <persia> pkern: Right.  Perfect format.  Just needs a bug (unless Daniel happens to want to grab it from dpaste)
[13:17]  * pkern cheers git.
[13:17] <\sh> moins pkern
[13:18] <pkern> Hey \sh (:
[13:21] <Hobbsee> pkern: what do you want updated?
[13:23] <pkern> Hobbsee: gobby
[13:24] <pkern> I'll merge the Ubuntu change back into Debian on the next upload, but don't know when that happens.  I first back Gobby to migrate to Lenny.
[13:24] <Hobbsee> pkern: OK to drop all ubuntu changes?
[13:24] <pkern> Hobbsee: http://dpaste.com/31122/ -- the only change left
[13:25] <Hobbsee> pkern: got it. is there a bug open about it btw?
[13:27] <pkern> Hobbsee: Just an invalid sync bug because I did not see the Ubuntu changes first (got not mail about that back then).
[13:28] <Hobbsee> pkern: fair enough
[13:29] <slytherin> persia: ran out of time for today. Will do it tomorrow. :-)
[13:31] <Hobbsee> oh, sod.
[13:31] <Hobbsee> it would help if i actually ran patch *without* --dry-run when i was finished testing it.
[13:32] <amarillion> Do I have to send an email to the ubuntu motu list when I upload a package to REVU for the first time?
[13:32] <Hobbsee> pkern: uploaded, thanks
[13:32] <pkern> Hobbsee: Thanks a lot!
[13:32] <Hobbsee> pkern: munged the maintainer while i was at it
[13:33] <Hobbsee> whoops, uploaded the wrong one
[13:33]  * Hobbsee uploads again
[13:34] <Hobbsee> er, drat
[13:34] <Hobbsee> third time lucky!
[13:34]  * Hobbsee uploads the correct changes file with the original tarball too, for bonus points!
[13:36] <persia> amarillion: No.  A MOTU does that when they upload to the archive.
[13:36]  * persia gives Hobbsee a lucky bat
[13:36] <pkern> Hobbsee: That was not really needed@munging.
[13:37] <Hobbsee> pkern: this is true.  however, the way my build scripts work is they mangle by default, if it's not already mangled :)
[13:37] <pkern> Hobbsee: I am the Debian maintainer and I care about the package in Ubuntu, albeit I cannot care directly because I'm just a MOTU and MOTUs are not responsible \-:
[13:37] <Hobbsee> pkern: core, actually.
[13:37] <Hobbsee> pkern: i'll try to remember next time to build your packages by hand.
[13:38] <Ng> persia: oh, right. The difference is that I noticed some extra tab characters in the upstream ChangeLog file and removed them from the version in REVU. Would you prefer another upload of exactly the same as upstream?
[13:39] <pkern> Hobbsee: Yeah.
[13:39] <Ng> hmm, I did add a couple of words to the changelog too, but that is definitely the only file that changed
[13:40]  * Ng makes a note not to fiddle with things once released
[13:40] <persia> Ng: No point.  You happy with the upstream tarball?
[13:40] <Ng> persia: yep :)
[13:41]  * persia rebuilds with upstream tarball, and tests again
[13:45] <persia> Ng: Did the Italian and Romanian translations get dropped, or is changelog just odd?
[13:47] <Ng> persia: those were the couple of words that got added to the ChangeLog, I dropped those in right before I rolled the tarball because I noticed someone had done them with Launchpad, but didn't update the changelog. i then updated it and only then did a revu upload, but I obviously did it from my trunk branch instead of the 0.7 branch, which is why the two tarballs were different
[13:48] <Ng> I'm happy to re-roll the upstream tarball, but I'm not sure if it's worth it - the important thing is that the translations are in it even if the changelog doesn't say so ;)
[13:48] <\sh> brb
[13:48] <persia> Ng: Ah.  That makes sense.  So Italian and Romanian will be in 0.8, and the changelog is now correct?
[13:48] <persia> OK.  Silent translation addition is fine.  Let's stick with upstream: I was just confused by the change.
[13:49] <Ng> ok :)
[13:49]  * Ng will be more careful about using the right branch next time
[13:51] <persia> pochu: Do you want to check again with the upstream tarball, or are you good?  Diff is: http://paste.ubuntu.com/3577/
[14:09] <persia> pochu: You've lost your chance.
[14:16] <\sh> emgent, looks ok...now the feisty one ;)
[14:16] <Ng> persia: (and everyone else who checked it and helped me) thanks very very much!
[14:17] <pkern> Hobbsee: Ubuntu Core Developers does not use Launchpad. This page was created on 2007-01-18  when the openoffice.org package was uploaded to Ubuntu. <-- /me giggles.
[14:18] <persia> Ng: Now for complaints: 1) No easy way to reset the terminal when it's full of junk, 2) bad child handling when attempting to generate a 3x3 grid, 3) No documented means of opening a new instance.
[14:18] <emgent> \sh, sure
[14:21] <Ng> persia: 1 is certainly true. 3 I think is somewhat discoverable with the context menu, but maybe we need a toolbar or something. what do you mean with 2?
[14:22] <Hobbsee> pkern: yeah.  iz bug.  :(
[14:22] <Hobbsee> apparently forwards are hard to do, when the email keeps getting used.
[14:23] <LucidFox> Gah... and everything went out of NEW _except_ for mpeg4ip. So ironic.
[14:46] <pochu> Ng: congrats :)
[14:47]  * Ng very pleased :D
[15:04] <ScottK> Adri2000 or Lutin: Would one of you have a moment to discuss a DaD feature request?
[15:06] <Lutin> ScottK: sure
[15:06] <\sh> what about "insert into X rows the bug numbers and enter return to save, to see that X-1 bug numbers are not saved. please fix asap, kthxbye"  Those DaD Featues? ,-)
[15:07] <ScottK> Lutin: I'm currently working on splitting the Debian sendmail package into two packages so that libmilter (without the rest of sendmail) can get promoted to Main.
[15:07] <ScottK> Lutin: Would it be possible to customize DaD's treatment of my new libmilter package to look to sendmail in Debian for does it need to be merged, since that's where it actually comes from?
[15:11] <ScottK> Lutin: Assuming I actually manage to get this into Hardy (haven't done it yet).
[15:19] <Adri2000> ScottK: do you want DaD to just display it on the web page? or do you also want that DaD tries to actually do the merge? as they are different packages (even if parts are the same), I'm afraid of what the result would be
[15:19] <bddebian> Heya gang
[15:20] <Adri2000> \sh: please file a bug for that, bugs.launchpad.net/dad/+file-bug
[15:20] <Adri2000> heya bddebian
[15:20] <bddebian> Hi Adri2000
[15:20] <Adri2000> \sh: https://bugs.launchpad.net/dad/+filebug even
[15:23] <geser> Hi bddebian
[15:27] <bddebian> Heya geser
[15:47] <dholbach> Packaging 101 Session in #ubuntu-classroom in 12 minutes
[15:47]  * Hobbsee ponders going there to play devil's advocate or something
[15:48] <zul> evil
[15:48] <Hobbsee> yes.  and?
[15:48] <zul> no ands..
[15:48] <pkern> Hobbsee: Advocate yada, please.
[15:49] <pkern> Hobbsee: *eg*
[15:49] <Hobbsee> dream on.
[15:49] <pkern> !OP ABUSE
[15:49] <ubotu> Sorry, I don't know anything about op abuse - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[15:49] <pkern> Hobbsee: http://sinfest.net/comikaze/comics/2008-01-14.gif
[15:49] <Hobbsee> !obabuse
[15:49] <ubotu> Sorry, I don't know anything about obabuse - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[15:49] <Hobbsee> !opabuse
[15:49] <ubotu> leave the ops alone ktnxbye
[15:50] <Hobbsee> heh :)
[15:50] <nxvl> dholbach: did you know when will be the next CC meeting?
[15:50] <dholbach> nxvl: no, I'm sorry, there's no agreement on a date yet
[15:51] <nxvl> dholbach: mmm ok thnx
[15:51] <DaveMorris> Can someone please provide a 2nd review of http://revu.tauware.de/details.py?package=libserial
[15:54] <ScottK> Adri2000: It depends on how much of the original packaging I end up preserving.  If it's a total fork, then just display, but if my current approach works, then a merge ought to actually work.
[16:34] <Mindfulgeek> Hello
[16:34] <LucidFox> Mindfulgeek> Welcome
[16:34] <Mindfulgeek> Thank you LucidFox
[16:34] <Mindfulgeek> Did I miss the session?
[16:35] <LucidFox> Mindfulgeek> What session?
[16:35] <LucidFox> Packaging 101?
[16:35] <Mindfulgeek> yeah
[16:35] <LucidFox> It's underway on #ubuntu-classroom
[16:35] <Mindfulgeek> ah.. thanks
[16:36] <LucidFox> and here's the log so far: http://lucidfox.org/stuff/packaging101.txt
[16:36] <Mindfulgeek> Thank you LucidFox
[16:38] <ToyKeeper> LucidFox: thanks, I was just starting to look for a log.  :)
[17:09] <jdong> aww poor vorian
[17:09] <vorian> jdong: what?
[17:09] <vorian> :P
[17:09] <jdong> his watchfile for supertux is no longer good :)
[17:09] <jdong> the SF mirror is not kept up to date
[17:09] <vorian> bull crap
[17:09] <jdong> and they added letters to the version
[17:09] <jdong> 0.3.1d is the latest
[17:09]  * vorian cries
[17:09]  * jdong pats vorian 
[17:10] <vorian> :)
[17:10] <jdong> now to figure out how to get directory listings on berlios
[17:10] <vorian> tried that, and passed them up after a while
[17:10] <jdong> also, supertux 0.3.1 uses binary name supertux2
[17:11] <jdong> who here cares a lot about supertux?
[17:11] <jdong> I think supertux should not replace supertux-stable now that 0.3.1 can install side by side
[17:11] <jdong> we should allow both to be installed
[17:11] <jdong> there's a note on upstream's site too discouraging packagers from adopting supertux as the default one.
[17:12] <vorian> hmmm
[17:14] <jdong> I think we can scrape links from http://developer.berlios.de/project/showfiles.php?group_id=3467
[17:22] <jdong> Newest version on remote site is 0.3.1d, local version is 0.3.0
[17:22] <jdong> VICTORY IS MINE ;-)
[17:24] <vorian> what was the regex jdong?
[17:24] <jdong> opts=downloadurlmangle=s/prdownload/download/ \ http://developer.berlios.de/project/showfiles.php?group_id=3467 \ http://prdownload.berlios.de/supertux/supertux-([0-9].*)\.tar\.bz2 \ debian uupdate
[17:24] <jdong> yeah berlios ain't pretty
[17:25] <tkamppeter> Hi, I am Till Kamppeter, "Till Kamppeter" on Launchpad) and I have joined the "Contributors of packages for ubuntu universe" team, can someone resync the the REVU uploaders keyring, so that I can upload a new package? Thanks.
[17:25] <vorian> demagler eh?
[17:25] <vorian> mangler*
[17:25] <jdong> vorian: yep.
[17:25] <jdong> vorian: because of their nasty redirect thing for mirror selection
[17:25] <vorian> nice jorb
[17:25] <jdong> vorian: but it won't be that easy....
[17:26] <jdong> vorian:need a lot of s/supertux/supertux2/
[17:26] <jdong> GRUMBLE there's patches too
[17:26] <jdong> globbed in the diff.gz
[17:28] <\sh> damn...I'm working on merges, but we have a debianimportfreeze...still time to catch up with merges?
[17:29] <ScottK> \sh: Absolutely.  DIF just means no more autosyncs and in theory everything should have been merged once this cycle by now.
[17:29] <ScottK> \sh: You should feel absolutely feel to upload any merge you feel is worthwhile.
[17:29] <\sh> ScottK, ok...so I'm still in time ;)
[17:31] <\sh> hmm..whois  Marco Rodrigues <gothicx@sapo.pt> ?
[17:31] <bddebian> Kmos
[17:31] <\sh> oh damn
[17:31] <\sh> Kmos, please don't mark sync bugs of mine....
[17:32] <\sh> Kmos, it's not wishlist, it's needed for maemo (bug #182920 e.g.)
[17:32] <ubotu> Launchpad bug 182920 in galculator "[MoM Sync] please sync galculator" [Wishlist,Confirmed] https://launchpad.net/bugs/182920
[17:32] <geser> \sh: was told it often enough already to not touch (sync) bugs from MOTUs
[17:33]  * DaveMorris forgot about classroom
[17:33] <\sh> man...that spams my inbox for nothing
[17:33] <ToyKeeper> DaveMorris: log is here: http://irclogs.ubuntu.com/2008/01/15/%23ubuntu-classroom.txt
[17:33] <DaveMorris> thanks ToyKeeper
[17:33] <DaveMorris> was busy working anyway today
[17:35] <ToyKeeper> Hmm, the log is still missing the last half hour.
[17:35] <ScottK> geser: You should know by now that telling him stuff has no long term effect.
[17:35] <tkamppeter> Anyone here who can resync the the REVU uploaders keyring?
[17:36] <geser> ScottK: unfortunately it's true and I'm already losing hope that he remembers it longer
[17:37] <ScottK> geser: Which is fundamentally why I made the request I did.  If I had hope of progress, I'd have waited for the progress.
[17:37] <jdong> vorian: mmmkay, now to test-build supertux and make sure I didn't make anything explode by removing the conflicts.
[17:38] <vorian> you can do it :)
[17:38] <jdong> vorian: pfft :P
[17:38] <vorian> jdong: I was trying to be encouraging :)
[17:38] <jdong> vorian: alright fine, if you're gonna FORCE me to play supertux....
[17:39] <vorian> ha!
[17:39] <jdong> "The My Little Sister Wants Newest Supertux NOW Release"
[17:41] <geser> does somebody have an idea where I can find the last sync bug for libgcr410?
[17:41] <dholbach> Ng, persia: seems that the tarball contained no license file? (infinity just told me)
[17:41] <\sh> geser, hmm...under "closed bugs"?
[17:41] <Ng> yeah, it had a symlink
[17:42] <Ng> dholbach: I'll fix it and reupload when I get home
[17:42] <\sh> geser, but there is nothing...
[17:42] <geser> \sh: https://bugs.edge.launchpad.net/ubuntu/+source/libgcr410/ reports " All bugs ever reported   0"
[17:43] <\sh> geser, yeah, because it was autosynced
[17:43] <geser> that's why I wonder why it got synced (and it still FTBFS)
[17:43] <geser> \sh: one hour ago?
[17:43] <geser> 2.4.0-8 Published in hardy-release 1 hour ago
[17:43] <\sh> geser, libgcr410 (2.4.0-8) unstable; urgency=low
[17:43] <\sh>   * remove busy waiting timeout.
[17:43] <\sh>   * remove useless ifdhandler.h (Closes: #420046)
[17:43] <\sh>   * update pt_BR.po (Closes: #417251)
[17:43] <\sh>  -- Marco Rodrigues < gothicx@sapo.pt>   Tue,  15 Jan 2008 15:27:54 +0000
[17:43] <\sh> so yes
[17:44] <geser> isn't the autosync off and any sync request should have a paper trail aka sync bug now?
[17:45] <ScottK> SHould
[17:45] <\sh> geser, yupp
[17:45] <pochu> \should? :)
[17:45] <\sh> -ESTRANGE
[17:45] <\sh> geser, I asked on #u-d
[17:46] <highvoltage> if I'd like to work on https://bugs.launchpad.net/ubuntu/+source/pyro/+bug/178948 , should I comment so on the bug report?
[17:46] <ubotu> Launchpad bug 178948 in pyro "No init scripts for Pyro Event Server" [Wishlist,New]
[17:46] <highvoltage> or can I just get going?
[17:46] <jdong> cp: cannot stat `supertux.desktop': No such file or directory
[17:47] <jdong> oh FFS the last step of a 10-minute build!
[17:47] <geser> highvoltage: assign it to you
[17:47] <highvoltage> geser: ok
[17:48] <\sh> looks like Riddell was on sync tour..reading -changes
[17:49] <geser> \sh: no harm was done with this sync but I'd like to know in this case why it got synced without testing that it builds by the submitter
[17:49] <\sh> geser, yeah, but it would informational why it was synced in the first place without a paper
[17:50] <geser> that too
[17:52] <ScottK> Obviously it came from somewhere and got Kmos' name attached to it.
[17:52] <\sh> cool...buddy is coming over to my place with a freecom nas to push openwrt on it ;)
[17:53] <\sh> ScottK, but it is in debian, so that's ok...but coincidence ;)
[17:53] <ScottK> \sh: No.  It's not.  That's who got assigned the sync in LP. debian/changelog in Debian has the maintainer
[17:54] <ScottK> Riddell wouldn't have just randomly assigned it to him.
[17:54] <\sh> ScottK, where did you find the sync bug  for this libfoo?
[17:54] <ScottK2> I haven't yet
[17:54] <ScottK2> But this is debian/changelog in Debian: http://packages.debian.org/changelogs/pool/main/libg/libgcr410/current/changelog
[17:55] <ScottK2> For a sync, in LP, the name listed is who asked for the sync.
[17:55] <ScottK2> !logs
[17:55] <ubotu> Channel logs can be found at http://irclogs.ubuntu.com/ - Logs for LoCo channels are at http://logs.ubuntu-eu.org/freenode/ - See also « /msg ubotu ircstats »
[17:55] <\sh> ScottK, you mean that changed by
[17:55] <Ng> what happens if I dput something that's already archived in REVU?
[17:55] <Ng> (with the same version number)
[17:55] <nxvl_work> finally the packaging guide is browseable
[17:56] <ScottK2> Yes.
[17:56] <\sh> ScottK, ah...silly silly LP...I was sure it shows the original changelog
[17:56] <nxvl_work> ScottK2: i mean that i have just putted "Next" and "Prev" links on the bottom of the pages
[17:57] <LucidFox> By the way, is Riddell here?
[17:57] <ScottK2> nxvl_work: Sorry,  I was talking to \sh.
[17:57] <ScottK2> \sh: There's an LP bug open about that or something similar
[17:59] <nxvl_work> ScottK2: oh! ok ok, sorry, i misunderstood it
[17:59] <ScottK2> nxvl_work: Sorry,  I wasn't clear.
[18:00] <ScottK2> \sh: I'm wget'ing this month's IRC logs right now to see if he asked for it on IRC.
[18:00] <\sh> ScottK, thx
[18:00]  * ScottK2 also notices that Kmos has filed a silly bug on the package in Debian.
[18:00] <nxvl_work> ScottK2: really it was clear, i was lazy to read up :D
[18:02] <mok0> Why is no debtags work carried out on our packages?
[18:04] <geser> ScottK2: I couldn't find libgcr410 in my irc logs before this discussion right now
[18:05]  * ScottK2 neither
[18:05] <ScottK2> geser: I think the MC should make part of their Kmos work getting to the bottom of this.
[18:07] <ScottK2> mok0: I don't think Ubuntu uses debtags.
[18:07] <ScottK2> But I'm not sure.
[18:08] <mok0> ScottK2: the debtags command is there, and seems to work
[18:08] <ScottK> Kmos: How did your libgcr410 sync get initiated?  There is not bug for it.
[18:08] <mok0> ScottK2: It's a really cool orthogonal way to index packages
[18:09] <ScottK2> Dunno then mok0.  I haven't seen any use of it in Ubuntu and IIRC it's still pretty new for Debian.
[18:10] <mok0> ScottK2: yes, I think so too, but if the system is to be useful, it is easier to tag packages when they enter the archive than at some later time. That's what I was thinking...
[18:10] <LucidFox> Hmm, I thought Kmos was a MOTU...
[18:11] <ScottK> !language | LucidFox
[18:11] <ubotu> LucidFox: Please watch your language and topic to help keep this channel family friendly.
[18:11] <ScottK> ;-)
[18:11] <mok0> ScottK2: "debtags tagcat"
[18:16] <ScottK> geser and \sh: Found it: https://bugs.launchpad.net/ubuntu/+source/pcsc-lite/+bug/182963
[18:16] <ubotu> Launchpad bug 182963 in pcsc-lite "Please sync pcsc-lite 1.4.99-1 (universe) from Debian unstable (main)" [Wishlist,Fix released]
[18:17] <\sh> grmpf
[18:20] <geser> ScottK: I guessed already it was mentioned in some other bug, but couldn't find it just by looking at the bug title which was a good candidate. Did you check all bugs?
[18:20] <ScottK> geser: No, I searched for the package name in his "Fix Released" bugs.
[18:21] <geser> ScottK: I tried the same for ~ubuntu-archive but I wasn't successful
[18:21] <ScottK> I just added a task for libgcr410 to that bug so it'll show up in the future.
[18:22] <geser> thanks
[18:25] <tjaalton> RAOF: ping
[18:26] <ScottK> geser: Also, libgcr410 FTBFS in my hardy pbuilder.  Clearly he didn't even test it before asking.
[18:27] <tjaalton> RAOF: hmm, bad timezone it seems :) I was just wondering how nouveau is doing, but I'll just download and try it
[18:28] <geser> ScottK: with the new pcsc-lite packages?
[18:29] <geser> ScottK: as libgcr410 is on the FTBFS page I looked at the new libgcr410 version and it FTBFS for me so I got curious as I've seen it synced
[18:29] <ScottK> geser: It's also FTBFS in Debian too.
[18:30] <ScottK2> http://buildd.debian.org/fetch.cgi?pkg=libgcr410;ver=2.4.0-8;arch=amd64;stamp=1200188459
[18:30] <ScottK2> So this is typical Kmos work.  Completely hopeless, without value, and distracting from getting something done.
[18:30] <geser> and that one used the new pcsc-lite packages
[18:31] <Kmos> ScottK2: I talk with debian maintainer about that.. he told me that it will be fixed if pcsc-lite was updated too..
[18:31] <Kmos> debian bug 420046
[18:31] <ubotu> Debian bug 420046 in libgcr410 "libgcr410: FTBFS: ./ifdhandler.h:115: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'IFDHCreateChannel'" [Serious,Open] http://bugs.debian.org/420046
[18:31] <Kmos> i also reopened the bug, because i test it in pbuilder
[18:31] <Kmos> check the conversation.
[18:31] <ScottK2> Kmos: You're supposed to actually test stuff.
[18:31] <geser> Kmos: pcsc-lite 1.4.99-1 or newer?
[18:32] <ScottK2> The conversation is irrelevant.
[18:32] <Kmos> geser: that one
[18:32] <Kmos> geser: that was synced
[18:32] <geser> Kmos: the debian build uses already libpcsclite1 (1.4.99-1) and still FTBFS
[18:33] <geser> Kmos: who did you managed to get it build successfully?
[18:33] <Kmos> geser: so that's a motive to re-open the bug, because debian maintainer closed it again after I reopen it, telling me that
[18:33] <ScottK2> Kmos: How does any of this relate to you thinking a sync would fix things?
[18:34] <Kmos> ScottK2: http://bugs.debian.org/420046 -> it's supposed to be fixed
[18:34] <ScottK2> Kmos: So what.  You're supposed to test stuff before you ask for a sync.  What Debian BTS says is irrelevant.
[18:35] <ScottK2> Kmos: It didn't even build in Debian.
[18:35] <greg-g> where should I go to tell debian that we have an updated version of a lib in Hardy?  I submitted bugs about an issue, links to the updated upstream version (which fixes the bug), and just now a link to the new deb in Ubuntu.  The maintainer has not responded to any of them (I have not directly sent an email to him)
[18:35] <Kmos> ScottK2: isn't debian BTS, i talk with the debian maintainer, it's supposed to be fixed, he told in bug report that's now working
[18:35] <ScottK2> greg-g: That's about all you can do.
[18:35] <geser> Kmos: and have you checked that?
[18:36] <geser> that it builds now?
[18:36] <ScottK2> Kmos: I say again: YOU are supposed to test stuff and clearly you didn't.
[18:36] <ScottK2> What the Maintainer said or what's in BTS doesn't excuse you didn't test.
[18:36] <greg-g> Thanks ScottK2, I just didn't want to be accused of not being good at debian/ubuntu relationships
[18:36] <Kmos> ScottK2: I test.. check bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=420046
[18:36] <ubotu> Debian bug 420046 in libgcr410 "libgcr410: FTBFS: ./ifdhandler.h:115: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'IFDHCreateChannel'" [Serious,Open]
[18:36] <Kmos> and see what debian maintainer said
[18:37] <ScottK2> greg-g: You're welcome.  Going beyond that is being pushy, IMO.
[18:37] <greg-g> ScottK2: got it, thanks
[18:37] <ScottK2> Kmos: Yet you still asked for it synced.
[18:37] <Kmos> ScottK2: after he told me in private mail, that it's because of pcsc-lite
[18:37] <Kmos> not updated in hardy
[18:38] <Kmos> so i ask for pcsc-lite sync and it should be working as he said..
[18:38] <ScottK2> Kmos: Which is still irrelevant.
[18:38] <Kmos> ScottK2: but ok, it's my fault to trust debian maintainer
[18:38] <geser> Kmos: and have you checked in a pbuilder that it builds with an updated pcsc-lite?
[18:38] <ScottK2> Kmos: Yes.
[18:39] <Kmos> geser: nop, i trusted debian maintainer word.. because he tested it severall times
[18:39] <ScottK2> Kmos: Ubuntu is a different environment than Debian.  Even if it had worked in Debian, it would still need testing in Ubuntu.
[18:39] <ScottK2> Which is typical crap and excuses.
[18:40] <Kmos> I already re-open the bug on debian to see what debian maintainer says about that
[18:40] <geser> Kmos: see the many packages which fail in ubuntu but build in Debian because debian has bash as /bin/sh
[18:40] <geser> because it works in debian, it must also work in Ubuntu (different lib, gcc, python, etc.)
[18:40] <ScottK2> Kmos: You have a huge amount of energy to get stuff done.  I really wish you could find an area you can be productive in.  This isn't it.
[18:40] <geser> s/must/hasn't/
[18:41] <Kmos> geser: exactly.. but this one is a different problem.
[18:41] <Kmos> ScottK2: maybe I'll take my time with fishing
[18:42] <the_belgain> hi there - pbuilder is failing for me on a package after upgrading to hardy.  it's complaining that it can't satisfy build dependenvies because some of the dependencies are virtual packages (libfaad-dev, liblame-dev, and libtwolame-dev)
[18:42] <jdong> ok, done and done, merry christmas everyone, new supertux and now supertux + supertux-stable can be installed together.
[18:42] <jdong> vorian: ^^
[18:43] <the_belgain> why would it complain about this?  this seemed to be working in my pbuilder on gutsy
[18:43] <jdong> the_belgain: it's a known problem
[18:43] <mok0> the_belgain: make sure you do a pbuilder update
[18:43] <jdong> the_belgain: faad/faac and anything that depends on libmp4v2 are currently broken on Hardy
[18:43] <jdong> the_belgain: there's two MOTU's, myself and superm1, working to rectify the situation
[18:44] <the_belgain> ok, fine thanks - it doesn't look like there's anything wrong with my package then
[18:44] <the_belgain> while i'm here, are there any known issues with pbuilder-dist on hardy at the moment? it ain't working for me
[18:45] <the_belgain> looks like it picks up a corrupted /etc/apt/sources.list
[18:47] <tsmithe> would there possibly be a debian developer around in here? i've got a package on mentors which is looking for some love.  mscore was recently uploaded to ubuntu, and i want to contribute back to debian. the version on mentors is an updated one, which includes usage of pasuspender to run the binary when pulseaudio is running.
[18:47] <LucidFox> tsmithe> Same problem here
[18:47] <tsmithe> problem?
[18:47] <geser> the_belgain: corrupted /etc/apt/sources.list? how?
[18:48] <LucidFox> I also have a package from Ubuntu on mentors... actually two, but the other one has problems
[18:48] <tsmithe> ah :)
[18:48] <ScottK> LucidFox and tsmithe: Are any of these packages written in Python?
[18:48] <tsmithe> ScottK, sorry no
[18:48] <LucidFox> no
[18:48] <ScottK> OK.  There are Debian teams for Python stuff that are easy to get sponsoring in, that's why I asked.
[18:49] <bddebian> They are?? ;-)
[18:49] <nxvl_work> DD are evil
[18:50] <ScottK> nxvl_work: Be nice.
[18:50] <ScottK> Many/most of the senior Ubuntu developers are also DDs.
[18:53] <LucidFox> ScottK> I looked at the Utnubu team, but judging by the state of their mailing lists, it's dead
[18:54] <ScottK> Yes.
[18:54] <bddebian> Yeah, that hasn't really taken off :(
[18:54] <ScottK> Actually, I think it's work is largely done.
[18:54] <ScottK> I think their main purpose was to get the Ubuntu patches pushed back into p.q.d.o.
[18:55] <nxvl_work> scottK: those are nice
[18:56] <ScottK> You might ask bddebian.  He's had a little luck getting stuff sponsored.
[19:00] <bddebian> heh
[19:00] <the_belgain> if any of the people who've taken a look at the fuppes package i uploaded a couple of days ago are interested, i've just uploaded an updated version with a few more markups
[19:01] <geser> ScottK: perhaps we should all include debian in our nick :)
[19:02] <ScottK> ;-)
[19:04] <LucidFox> bddebian> So, please tell me about your luck getting stuff sponsored :)
[19:05] <geser> LucidFox: try /nick LucidFoxDebian :) perhaps that helps
[19:05] <LucidFox> lol
[19:05] <geser> it seems to work for bddebian
[19:07] <AndyP> easiest way to get sponsored in debian these days seems to be through teams, my experiences of debian python {modules,apps} team has been great
[19:08] <ScottK2> Actually bddebian uses a different nick on Debian channels because he got sh!t about it there.
[19:10] <LucidFox> I'll try the debian-multimedia team for smplayer, then
[19:11] <bddebian> Well the python team seems helpful.  The Games Team, well....
[19:11] <_MMA_> LucidFox: TheMuso might be a good person to chat with as he has contact with those guys.
[19:14] <LucidFox> _MMA_> Thanks
[19:26] <LucidFox> How do I unsubscribe u-u-s from a bug I filed?
[19:27] <geser> LucidFox: ask an u-u-s member to do it
[19:34] <LucidFox> DarkSun88> Fixed debdiff for qtemu
[19:47] <mruiz> mathiaz, I read your comment about adtool and I uploaded a new debdiff
[19:55] <rulus> .mo files should not be in the source package, but build when creating the binary package, right?
[19:58] <slangasek> rulus: normally, yes; but it's usually not worth repacking the tarball over
[19:59] <rulus> slangasek: what do you mean with repacking the tarball?
[20:11] <slangasek> rulus: I mean that if upstream shipped .mo files in the tarball, you can address this in the ./debian/rules clean target without having to worry about repacking the tarball
[20:11] <slangasek> rulus: if upstream didn't ship .mo files in the tarball, then any .mo files in your source package would end up in the .diff.gz, and .mo files aren't text so you'll get an error building the source package anyway :)
[20:17] <rulus> slangasek: I'm the upstream developer, so ideally I put only the .po files in the tarball and create the .mo files with setup.py (it's a Python program)?
[20:17] <slangasek> rulus: in that case, yes
[20:18] <rulus> ok, thanks
[20:18] <slangasek> but this channel is for Ubuntu development, not upstream development, so I assumed your question referred to the former :)
[20:19] <rulus> I understand :-)
[20:25] <subterrific> i'm trying to follow the instructions from https://wiki.ubuntu.com/SponsorshipProcess/ppaput but the bug doesn't seem to be getting updated after i run ppaput my-ppa -sa. so i'm not sure how i get the bug on the sponsorship list?
[20:26] <ScottK> Uploading to PPA isn't an approved method of getting sponsored.
[20:26] <ScottK> What kind of update do you have?
[20:26] <ScottK> (that wiki page is experimental).
[20:31] <subterrific> oh, well i tried the other process too, but it is marked as out of date
[20:32] <ScottK> subterrific: Which?
[20:32] <ScottK> What kind of update do you have (process is a bit different depending).
[20:32] <subterrific> my update is a patch to the bash package that i found in launchpad to fix a bug i ran into while doing the motu class this morning
[20:33] <subterrific> ScottK: https://wiki.ubuntu.com/SponsorshipProcess says to use http://people.ubuntu.com/~pitti/scripts/requestsponsor which is marked as out-of-date
[20:33]  * ScottK looks
[20:34] <subterrific> ScottK: basically there are these two tools that are supposed to automate the process, but neither work and i haven't been able to find any documentation on what exactly they do so i can just do it manually :)
[20:35] <ScottK> subterrific: Make your new package, debdiff the old package to the new package, attach the debdiff to the bug, and subscribe ubuntu-main-sponsors (or ubuntu-universe-sponsors for Universe packages).
[20:35] <subterrific> ScottK: thanks
[20:45] <josesanch> If there is any MOTU bored. I offer my package for a review. http://revu.tauware.de/details.py?package=gnomecatalog
[20:47] <nxvl_work> wow
[20:47] <nxvl_work> http://www.chris-lamb.co.uk/2008/01/14/gnome-applet-for-monitoring-debian-bugs/
[20:47] <nxvl_work> wouldn't it be nice to have such a thing for LP
[20:57] <somerville32> nxvl_work, Probably wouldn't be hard to do now that there are atom feeds
[20:59] <nxvl_work> somerville32: yep, i think that too, i will try it, check the code and try to adapt it
[21:21] <TheMuso> ember: Yes re sysinfo, thats fine.
[21:23]  * DaveMorri1 plugs his package for a revu - http://revu.tauware.de/details.py?package=opensg
[21:30] <somerville32> mok0, Nice e-mail to -motu :)
[21:30] <mok0> ;-)
[21:32] <pochu> TheMuso: are you looking to bug 92939, or can I take care of it? You assigned it to you on December 12.
[21:32] <ubotu> Launchpad bug 92939 in libowfat "Please sync libowfat 0.27-1 from Debian unstable (main)" [Unknown,Fix released] https://launchpad.net/bugs/92939
[21:37] <mtp_> 5~
[21:39] <_KeenEars_> hello anyone. can someone say, what`s happening in gutsy-backports now? i mean, kde4 miss some dependencies, although the files are in the pool, but it`s just not in relevant packages list
[21:42] <_KeenEars_> maybe the update wasn`t finished yet?
[21:43] <ScottK> _KeenEars_: For KDE, ask in #kubuntu-devel
[21:43] <_KeenEars_> ok,thanx
[21:51] <TheMuso> pochu: all yours
[21:52] <subterrific> if i wanted to add a .pam_environment file to /etc/skel/ which package would i add that to? libpam-modules, bash, ???
[22:10] <somerville32> interdiffs or .diff.gz for new upstream releases now?
[22:11] <persia> somerville32: interdiffs.  The transition is under discussion, but not adopted.
[22:12] <somerville32> I'm a little confused by the output of my interdiff
[22:12] <persia> somerville32: The blob attached for sponsoring isn't human readable :)
[22:12] <somerville32> persia, I'm looking at the human readable version
[22:12] <persia> somerville32: Pastebin it.  What's confusing?
[22:13] <somerville32> http://pastebin.com/d610ec953
[22:13] <persia> tkamppeter: Resyncing keyring.
[22:13] <nxvl_work> somerville32: what's the confusing part of that?
[22:14] <somerville32> An interdiff is the the diff of the diff, right?
[22:14] <nxvl_work> yep
[22:14] <persia> somerville32: Right.  This one shows that the only packaging that changed was the .desktop file, which makes me suspect you forgot to add a changelog entry.
[22:14] <somerville32> persia, It is just an excerpt
[22:15] <slangasek> subterrific: I hope you're asking about this for local use, not for inclusion in Ubuntu?
[22:15] <somerville32> In the orig, you modified the .desktop file in the package (you didn't use a packaging system) persia
[22:15] <somerville32> In the new release, he incorporated your changes
[22:15] <somerville32> This interdiff looks like it'll remove your changes persia and apply the old way to the new fixed one
[22:16]  * persia is having difficulties parsing
[22:16] <slangasek> subterrific: and if it's for local use, I'm not sure it matters which package you put it in, though conceptually I guess libpam-modules or libpam-runtime is probably as good as any
[22:16] <nxvl_work> somerville32: what are you doing? a merge?
[22:16] <somerville32> No, new upstream release
[22:16] <nxvl_work> ok
[22:18] <persia> somerville32: If I understand your issue correctly, it is correct for the diff to drop any patch that was adopted by upstream.
[22:18] <somerville32> persia, correct
[22:18] <somerville32> But it looks like the new diff is being modified so that it applies the old way from the first version unpatched
[22:19] <persia> somerville32: I'd have to look at the whole thing, but I think that the "reverted" at the top indicates that that patch is being dropped.  If you want to be absolutely sure, follow the interdiff sponsoring process locally, and look at the results.
[22:20] <somerville32> persia, awesome, thanks.
[22:30] <\sh> guys, does anybody has a freecom fsg-3 w/o wlan appliance?
[22:38] <RAOF> tjaalton: Bad timezone indeed.  Nouveau is going pretty well, at least for me.  My laptop screen now works with the randr12 code :)
[22:38] <RAOF> tjaalton: Oh, and the drivers are quite snappy.
[22:39] <tjaalton> RAOF: yeah I got it working on my desktop, once I linked the drm.ko in place
[22:39] <tjaalton> too bad that the virtual console doesn't work yet
[22:39] <RAOF> tjaalton: What exactly did you have to do?  I've only ever had to install it, and it Just Work.
[22:40] <RAOF> s/./s./
[22:40] <RAOF> It did for me (last time I tried) with the non-randr12 code.
[22:40] <tjaalton> there was two drm.ko's installed, so I had to move the older one out of the way
[22:40] <RAOF> tjaalton: Right.  You should have one in modules/extra, and one in somewhere else.
[22:41] <tjaalton> the "official" one and the one in extra/
[22:41] <tjaalton> yep
[22:41] <RAOF> But I was under the impression that modprobe should be able to determine the correct one to load.  It does for me.
[22:41] <tjaalton> btw, there's going to be a libdrm release soon
[22:41] <tjaalton> hm, doesn't do that here
[22:42] <RAOF> Maybe x86-64's modprobe is smarter?
[22:42] <tjaalton> maybe, mine is i686
[22:44] <tjaalton> RAOF: would you like to maintain it on git.debian.org?-)
[22:45] <tjaalton> seems that the packaging is much like the rest of the drivers
[22:48] <subterrific> slangasek: i'm actually working on a bug in launchpad
[22:48] <subterrific> slangasek: which is asking for ~/bin to be added by default to PATH
[22:49] <subterrific> slangasek: and according to the bug, that should be done inside ~/.pam_environment
[22:49] <RAOF> tjaalton: Someone's asked whether I'd like to help get it into experimental.  I need to get back to them.  Yeah, I'll help maintain it on git.debian.org.
[22:50] <subterrific> slangasek: so it would seem there needs to be a .pam_environent in /etc/skel/ no?
[22:50] <RAOF> tjaalton: The packaging is taken very nearly verbatim from the nv driver :)
[22:50] <tjaalton> RAOF: cool, then it would be a breeze to push it there
[22:52] <_KeenEars_> got anothe question... will be main gutsy repo updated in future ? or it`s freezed for any additions ?
[22:52] <RAOF> jdong: The think I wasn't sure about with pushing to experimental is the need for git snapshots of libdrm.
[22:52] <slangasek> subterrific: uhm, that doesn't sound like the correct approach to me. what's the bug #?
[22:52] <persia> !sru | _KeenEars_
[22:52] <ubotu> _KeenEars_: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
[22:52] <persia> In summary, it's frozen except for critical bugfixes
[22:53] <RAOF> Sorry, tjaalton ^^^
[22:53] <subterrific> slangasek: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/64064
[22:53] <ubotu> Launchpad bug 64064 in pam "would be nice to add ~/bin to the default PATH" [Wishlist,Confirmed]
[22:54] <RAOF> tjaalton: But if libdrm is releasing soon, that'd be nice.
[22:54] <tjaalton> RAOF: right, airlied said "in a few weeks" :P
[22:54] <slangasek> subterrific: ok, I'll look that over
[22:55] <\sh> bah...don't add it by default ;)
[22:55] <_KeenEars_> well, ty. but thu updates will go to ubuntu-updates after all? not gutsy
[22:55] <\sh> someone hacks into your box, which is obviously not root but some other user...and this guy can't overcome sudo
[22:56] <\sh> he installs something into ~/bin and voila...
[22:56] <\sh> other user == first user of the system who is sudo su - compatible
[22:57] <slangasek> subterrific: ok, it says that it's *doable* on a per-user basis by editing ~/.pam_environment; not that the correct way to configure it as a system-wide default is to set it in ~/.pam_environment by default
[22:57] <_KeenEars_> at least what i`ve get from that document
[22:58] <slangasek> subterrific: and indeed, ~/.pam_environment is not the place to do it if this is to be made a system-wide default; if it's agreed that the change should be made, it ought to go to /etc/environment instead, I think
[22:58] <persia> _KeenEars_: They go into the gutsy-updates repository, but the rules are still very strict.  You might be interested in backports
[22:59] <subterrific> slangasek: well i've already attempted to solve the do-able part by fixing https://bugs.launchpad.net/ubuntu/+source/pam/+bug/145380
[22:59] <ubotu> Launchpad bug 145380 in pam "pam_env should document per-user environment file ~/.pam_environment" [Wishlist,Confirmed]
[22:59] <_KeenEars_> actually, i`m mirroring -backports, -proposed, -updates and - security at all
[22:59] <_KeenEars_> but left base gutsy unchanged
[22:59] <TheMuso> pochu: re accerciser, that sounds like an upstream problem.
[22:59] <TheMuso> bug 183191
[22:59] <ubotu> Launchpad bug 183191 in accerciser "Please sponsor accerciser 1.1.5 (universe) into Hardy" [Wishlist,Confirmed] https://launchpad.net/bugs/183191
[22:59] <subterrific> slangasek: and i don't think you can make the change in /etc/environment because $HOME might not be set yet
[23:00] <subterrific> slangasek: and ~/bin is already in the default path, look at /etc/profile
[23:00] <persia> TheMuso: Maybe upstream, but it would be a regression, no?
[23:00] <TheMuso> persia: I don't know, as I hadn't seen what has happened with it previously.
[23:00] <nxvl_work> is there any way to check what package generated a file?
[23:01] <pochu> TheMuso: yeah, but I'm not comfortable uploading a broken application :)
[23:01] <persia> nxvl_work: No, but which package installed a file is available from dpkg -S
[23:01] <TheMuso> pochu: Fair enough.
[23:01] <pochu> ember: you might want to forward that bug if you can reproduce it.
[23:02] <\sh> subterrific, where is it set? on hardy is nothing to see about ~/bin in /etc/profile...
[23:03] <subterrific> \sh: sry, i meant /etc/skel/.profile
[23:03] <\sh> subterrific, but it's not set by default...because ~/bin doesn't exist by default in ~/
[23:03] <\sh> subterrific, only if ~/bin is created then it's been appended to $PATH
[23:05] <subterrific> \sh: seems default to me, checking if it exists first is an optimization only
[23:07] <\sh> subterrific, no it's an important difference :) most users don't need ~/bin...there were several discussions about this and most of the sysadmins are saying "it's evil"
[23:08] <persia> pochu: TheMuso: just tested.  Definitely a regression.
[23:09] <Devourer> What is Masters of the Universe?
[23:09] <pochu> persia: thanks. ember, could you forward it upstream?
[23:09] <pochu> Devourer: us.
[23:09] <pochu> !motu | Devourer
[23:09] <subterrific> \sh: i agree it helps prevent people from shooting themselves in the foot, but as far as security i see little difference in having it in the PATH vs. added to the PATH only if it exists
[23:09] <ubotu> Devourer: motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See  http://wiki.ubuntu.com/MOTU
[23:10]  * persia notes that accerciser as currently distributing can be trivially frozen, but at least doesn't break from choosing "No".
[23:10] <Devourer> Oh. Brave souls. :)
[23:10] <nxvl_work> persia: thanx i found it :D
[23:10]  * nxvl_work HUGS persia
[23:11] <subterrific> \sh: the difference being: ~/.profile needs to be executed after your box is "hacked"
[23:11] <\sh> subterrific, well, the good thing is, most people won't create ~/bin but I agree it should be removed from ~/.profile
[23:11] <\sh> subterrific, well, that is easy....profile is there and user foo (1st user) is logging in..and executes e.g. sudo ,-)
[23:12] <ScottK> Anyone want to do a merge to fix a CVE?  dspam could use a little merging love.
[23:12] <\sh> hacker installs ~/bin/sudo which is the hacker tool now, and user foo is fcked :)
[23:13] <subterrific> \sh: the reason i don't see it as a security concern is that once your account is compromised, a hacker can change your .profile anyway and add ~/.myhackbin/sudo to your path
[23:14] <persia> (or just execute /tmp/superhacktool in the .profile directly
[23:14] <subterrific> \sh: plus is it possible to override a /sbin with a /bin, i don't think it is
[23:15] <subterrific> persia: i think the point was that the hacker needed some user input to complete the hack, like pretending to be sudo and logging your password
[23:17] <Riddell> ScottK: assigned which to whom?
[23:17] <Riddell> I may well have got the assignee wrong during a sync, it's easily enough done
[23:18] <ScottK> Riddell: There was some confusion about a sync you processed.  It was Kmos.
[23:18] <\sh> subterrific, this is all possible...but having ~/bin and the user foo knows about it, but doesn't look inside for some time, it's much more unsecure...
[23:18] <ScottK> Riddell: The bug in question was Bug 182963
[23:18] <ubotu> Launchpad bug 182963 in pcsc-lite "Please sync pcsc-lite 1.4.99-1 (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/182963
[23:19] <ScottK> It turns out the libgcr410 part of that request was untested and FTBFS after the sync.
[23:19] <\sh> subterrific, but anyways...it's the job of the sysadmin to get rid of those things, agree :)
[23:19] <Riddell> ScottK: meh fooey, he did ask me for it
[23:19] <\sh> Riddell, no sync without a paper ,-)
[23:19] <ScottK> Riddell: Yes.  Our collective finger is pointed straight at him.
[23:20] <ScottK> \sh: We found the paper, it just wastn't completely filled out.
[23:20] <\sh> ScottK, I know :)
[23:20] <ScottK> K
[23:20] <ScottK> Riddell: It's unfortunately typical of the quality level of a large fraction of his work.
[23:21] <ScottK> Adri2000 and Lutin: I see that the MoM code is up on LP: https://code.launchpad.net/merge-o-matic (and GPL).  Any thought to contributing patches for a U/I overhaul?
[23:27] <subterrific> \sh: so i just commented on the bug to try to get more feedback and i'll leave it at that for now
[23:30] <Adri2000> ScottK: yes, this is planned
[23:30] <ScottK> Adri2000: Great.
[23:30] <ScottK> Adri2000: Any schedule?
[23:33] <Adri2000> ScottK: nothing specific, but the sooner the best. also, when this is done, we will shutdown DaD
[23:35] <Adri2000> ScottK: actually, we were waiting for the official announcement of MoM's code release, but seems you were quicker to find it than Keybuk to make the announcement :p
[23:36] <ScottK> Heh.  He mentioned it on #ubuntu-devel, so I guess that's an announcement then.
[23:36] <ScottK> ;-)
[23:38] <Adri2000> ah, indeed :)
[23:43] <\sh> ScottK, question, we have on mom a merge for claws-mail-extra-plugins 3.2.0 ... it needs claws-mail 3.2.0 should we try to include it into hardy?
[23:43] <ScottK> \sh: I'd say yes.
[23:43] <ScottK> But I don't use it, so ....
[23:44] <\sh> ScottK, I#m just asking you, because you were the last one who touched it ,)
[23:44] <\sh> ScottK, I use it so no problem testing it :)
[23:44] <ScottK> Ah.
[23:45] <ScottK> \sh: I just touched it to rebuild the clamav plugin for libclamav2/3 transition, so I've no strong opinion.  I'd love some testing with the new clamav though.
[23:45] <\sh> ScottK, cool..I'll build the new claws stuff and do a functional test for myself...if it's ok I'll file a sync req for claws mail...
[23:46] <ScottK> Great.
[23:49] <emgent> hello there
[23:57] <ScottK> Anyone looking for security experience might want to look at syslog-ng.
[23:58] <somerville32> ScottK, Okay.
[23:59] <ScottK> somerville32: The version in Hardy has a CVE fix that needs to be put in any of the released versions it's applicable to.