[12:08] <thierry> any MOTU could review my packages? I need them to build more packages, I don't want to always do the same errors, only one package would be appreciated (http://revu.tauware.de/details.py?upid=1245 or http://revu.tauware.de/details.py?upid=1246) . ajmitch maybe?
[12:09] <sistpoty> thierry: I'll take a look at it
[12:10] <thierry> systpoty : thanks a lot!
[12:31] <sistpoty> thierry: I just looked at libfxscintilla
[12:31] <sistpoty> thierry: I posted some comments on it... if s.th. is not clear, just ask
[12:33] <lfittl> sistpoty: do you have some time to review an audacity update? (http://revu.tauware.de/details.py?upid=1237)
[12:34] <sistpoty> lfittl: in a few minutes
[12:34] <lfittl> sistpoty: :)
[12:35] <seth_k|lappy> sistpoty is always so willing... we appreciate it a lot, sir ;)
[12:36] <sistpoty> hehe... well if I have the time, why not doing some reviews while waiting for the next merge to compile
[01:28] <ajmitch> well not until jan or so
[01:29] <sistpoty> hehe
[01:42] <lfittl> sistpoty: do you have time now to review my package?
[01:47] <sistpoty> lfittl: I'm just building it
[01:48] <lfittl> sistpoty: k
[01:51] <sistpoty> lfittl: looks good... just wondering: why did you go for a new upstream version?
[01:53] <lfittl> sistpoty: just saw that a new version was out, and since most updates are fast to do, I did it ;)
[01:53] <sistpoty> lfittl: problem is, that we'll go out of sync with debian... i.e. we need to do at least one more merge in the future
[01:54] <sistpoty> lfittl: so I'd rather tend not to go out of sync unless new upstream version has cool new stuff or fixes bugs
[01:55] <sistpoty> lfittl: did you test the new version? (install it, play around with it...)?
[01:55] <lfittl> sistpoty: sure ;)
[01:56] <sistpoty> lfittl: ok, then I'll upload it... but it would be cool if you would file a wishlist bug in BTS stating that a new upstream version is available
[01:56] <lfittl> sistpoty: will do that tomorrow
[01:56] <sistpoty> :)
[01:57] <lfittl> do you have some time left for other packages? :)
[01:58] <sistpoty> lfittl: I'll do one merge and then I'll look at another package ;)
[01:59] <lfittl> sistpoty: k :)
[02:03] <hub> can I poke some MOTUs to review some packages?
[02:04] <sistpoty> argl... now everyone wants his package reviewed *g*
[02:04] <lfittl> hehe
[02:05] <lfittl> ajmitch did the right thing to not review anything until january ;)
[02:06] <hub> sistpoty: well mine had been around for sometime
[02:06] <hub> but so be it
[02:07] <hub> :-)
[02:07] <hub> I'll just make more
[02:07] <lfittl> :)
[02:07] <sistpoty> hub: if I'm not too tired after merging and reviewing lfittl's next one... I'll give a look
[02:07] <hub> ok thanks
[02:07] <sistpoty> but then I won't accept reviews for tonight ;)
[02:15] <ajmitch> lfittl: well I'm going away tomorrow afternoon, and I need tonight to get my own stuff ready for upload :)
[02:16] <lfittl> ajmitch: that makes sense, when do you come back? :)
[02:16] <ajmitch> dec 30
[02:18] <sistpoty> oh, that reminds me of s.th.... got a new version of "my" package here as well
[02:18] <lfittl> whats "your" package?
[02:18] <sistpoty> min12xxw... I can't print w.o. it ;)
[02:20] <sistpoty> lfittl: any specific package I should look at?
[02:20] <lfittl> sistpoty: well the easiest one to review would be http://revu.tauware.de/details.py?upid=1165
[02:21] <hub> sistpoty: http://revu.tauware.de/details.py?upid=873
[02:21] <hub> http://revu.tauware.de/details.py?upid=1238
[02:21] <hub> http://revu.tauware.de/details.py?upid=840
[02:22] <Kyral> slomo_: Ping
[02:22] <sistpoty> hub I'll look at the first one... after doing these reviews, I need some sleep after all ;)
[02:22] <hub> sistpoty: sure
[02:23] <Kyral> okay sistpoty can you save slomo_ some work and just put the vote he has given EasyChem before onto the new version seeing as all I did was change email addresses?
[02:23] <Kyral> please?
[02:23] <Kyral> (Head is clouded by the steak he had for dinner)
[02:28] <sistpoty> Kyral: this change is trivial so it's not much work for slomo_ to review the debdiff...
[02:28] <Kyral> sistpoty: thats what I mean, can you just put the vote there
[02:28] <sistpoty> Kyral: and I don't want to just give away votes in the name of other ppl
[02:28] <Kyral> so he has to go back and do it
[02:28] <Kyral> again lol
[02:29] <sistpoty> Kyral: not exactly... you'd still need another vote, and seeing that slomo already gave his vote for a trivial change only, this will count as well
[02:29] <Kyral> ah
[02:29] <Kyral> okay thanks for explaining
[02:29] <sistpoty> Kyral: but I really don't want to act as slomo here, though I'd have the technical means ;)
[02:29] <Kyral> hehehe
[02:30] <Kyral> sokay
[02:50] <sistpoty> lfittl: cafix looks nice with only one minor exception: you should call dh_strip on the binaries
[02:51] <lfittl> sistpoty: i am calling install -s in the Makefile
[02:52] <sistpoty> hm... strange
[02:52] <lfittl> I know, I tried to get these lintian errors away, even with dh_strip, but nothing worked
[03:00] <sistpoty> lfittl: that's really strange... at least dh_strip *is* called during build
[03:01] <lfittl> sistpoty: k, what do you want to do?
[03:01] <sistpoty> lfittl: just another small thing: please stick to <= 80 cols in copyright
[03:02] <sistpoty> lfittl: maybe s.o. else has a good idea bout that section-issue
[03:02] <lfittl> sistpoty: k, will fix that copyright thing tomorrow, I need some sleep now
[03:02] <sistpoty> ok, gn8 lfittl
[03:02] <lfittl> gn8
[03:18] <sistpoty> hub: autopano-sift has a new upstream version available
[03:18] <hub> I must admit I didn't check upstream. I'll see about updating it
[03:19] <hub> hugin has beenm fixing the ftbs
[03:19] <sistpoty> hub: would be good to update it, since I didn't find old orig-tarball
[03:19] <hub> yep I will
[03:21] <sistpoty> hub: and fsf-address is outdated... but apart from that it looks fine
[03:22] <hub> oh
[03:22] <hub> okay. thanks
[03:24] <ajmitch> hi hub
[03:24] <hub> hey ajmitch
[03:25] <ajmitch> how's the new job?
[03:26] <hub> it is ok
[03:27] <hub> it pays
[03:27] <hub> that is probably the first reason
[03:28] <ajmitch> heh
[03:29] <hub> and I work on linux
[03:29] <hub> and everyday I understand why I prefer GNOME and why people hate GNOME
[03:31] <ajmitch> plenty of people hate GNOME
[03:31] <ajmitch> I've been using KDE for the last week, and it's quite a surprising change to see so many configuration options
[03:31] <Kyral> KDE uses too much memory for my taste
[03:32] <hub> KDE is a big mess
[03:32] <hub> KMail has a bunch of interesting feature
[03:32] <Kyral> I'm addicted to Fluxbox
[03:32] <hub> but of lot of annoyance
[03:32] <hub> dug in various secret dialogs
[03:33] <sistpoty> maybe I'm old already... I used kde 1, kde 2 and now kde 3... and I'm used to it
[03:33] <sistpoty> though I can't say I know all these dialogs and stuff
[03:34] <ajmitch> but after using GNOME for awhile, you notice the differences
[03:34] <Kyral> I hate the flamewar
[03:34] <hub> the thing is that KDE have a good architecture
[03:34] <Kyral> just let people use what they want
[03:35] <hub> and does not use brain-damage GObject
[03:35] <ajmitch> Kyral: flames more often seem to come from users who are passionate & stubborn
[03:35] <Kyral> good point
[03:36] <hub> actually I have this small notebook on my back on which I put ideas of what is good in KDE
[03:36] <hub> to put in GNOME
[03:39] <SEJeff> I hope gparts takes off and is integrated into gnome sometime in the future
[03:40] <SEJeff> http://gparts.blogspot.com/
[03:41] <Amaranth> SEJeff: it's just KParts embedded using the common mainloop, isn't it?
[03:41] <SEJeff> It's basicly a gnome port of kparts. But the two will interoperate
[03:42] <SEJeff> And it wraps bonobo
[03:42] <SEJeff> Which is a bloody nightmare
[03:42] <Amaranth> ah
[03:43] <Amaranth> i hope, even if trolltech doesn't want it, that ubuntu applies the glib mainloop patch to qt
[03:43] <Amaranth> i think it's only available for qt 4 though
[03:43] <ajmitch> sounds painful
[03:44] <SEJeff> KDE has a leg up on us with kparts... it's really nice from a developers standpoint
[03:44] <SEJeff> And the KDE devs make sure that we know that. Multiple times over and over again
[03:45] <ajmitch> heh
[03:56] <hub> SEJeff: that is one of the good things of KDE
[03:56] <hub> gnome deprecated orbit and bonobo without replacement
[03:56] <SEJeff> hub: My point exactly
[03:57] <SEJeff> If gparts becomes stable and is accepted into gnome. It means that *parts will work in kde and gnome. Thats a win for both sides
[03:57] <Amaranth> "At first, GParts may be viewed just as a direct mapping of KParts into GNOME's development environment, so that GNOME developers don't need to care if they are interoperating with KDE and embedding a Qt-based component or are reusing GNOME's native Gtk+ code."
[03:57] <Amaranth> that means it needs the common mainloop
[03:58] <Amaranth> apparently trolltech is willing to use glib in Qt/X11 but they want the mainloop seperated from the rest of glib, or something
[04:00] <SEJeff> Amaranth: I'm not following
[04:01] <Amaranth> SEJeff: GParts will probably work standalone but the major feature is supposed to be using KParts in GTK and GParts in Qt
[04:01] <Amaranth> which needs the common mainloop
[04:02] <Amaranth> so the two don't block each other
[04:02] <SEJeff> oh
[04:04] <sistpoty> hub: hugin lacks some manpages and has old fsf-address as well... but apart from that it's good
[04:04] <hub> sistpoty: I'll check manpages too
[04:04] <hub> sistpoty: already upgraded upstream
[04:04] <sistpoty> and now I'm off to bed
[04:04] <sistpoty> gn8 everyone
[04:24] <hub> crap
[04:24] <hub> I mistakenly uploaded a "binary" package
[04:40] <Burglaptop> been out of the loop a while. How do I request a multiverse sync again? file a malone bug?
[04:41] <hub> Burglaptop: elmo?
[04:42] <Burglaptop> ugh, I don't have the time to check it myself, sadly
[04:43] <hub> last time it was elmo
[04:43] <hub> to be asked
[04:43] <hub> you can file a malone bug
[04:45] <Burglaptop> sweet, I just filed bug 6000
[04:45] <Ubugtu> Malone bug #6000: Sync newer upstream In: vice (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: New https://launchpad.net/bugs/6000
[05:12] <hub> night all
[05:19] <Pupeno> Hello.
[05:19] <Pupeno> Should all Ubuntu packages have ubuntu on their versions ?
[05:20] <StevenK> No.
[05:21] <Pupeno> what's the policy ?
[05:22] <StevenK> If a package doesn't need any changes from Debian, it can be 'synced' - the version from Debian is just blatted into the archive. However, if changes are needed, they are done and ubuntuX is appended to the version, and that is uploaded. That is refered to as a 'merge'.
[05:24] <Pupeno> What about packages that doesn't exist on Debian ?
[05:25] <womble> Pupeno: -0ubuntu1, AFAIK
[05:25] <Pupeno> Thanks.
[05:26] <StevenK> Well, that's either packages not in Debian, or packages that are newer in Ubuntu.
[05:26] <womble> StevenK: Hence correctly answering pupeno's question.  <grin>
[06:08] <prabu^> Hello
[07:42] <Yagisan> G'day all, I've noticed a few missing dependency bugs in some universe packages. Would you rather I file a bug + patch in launchpad
[07:42] <Yagisan> or just upload a fixed package to revu
[07:42] <crimsun> yes, the former would be most helpful
[07:42] <crimsun> (debdiff)
[07:54] <Yagisan> crimsum: ok. should I ping you to let you know when I submit the patches ?
[07:56] <crimsun> Yagisan: and/or paste the urls here, thanks
[07:57] <Yagisan> crimsun: no worries.
[08:17] <Yagisan> crimsum: https://launchpad.net/distros/ubuntu/+source/transcode/+bug/6002
[08:17] <Ubugtu> Malone bug #6002: Missing depencency on libxvidcore4 In: transcode (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: New https://launchpad.net/bugs/6002
[08:19] <Yagisan> crimsum: Should I file a separate bug with suggested changes to CFLAGS as well ?
[08:20] <crimsun> Yagisan: err...
[08:21] <crimsun> it should not have to explicitly depend on libxvidcore4 since we build-dep on libxvidcore4-dev
[08:22] <crimsun> Make sure that it's not missing in the ./configure flags
[08:22] <Yagisan> crimsun: oh, well, it didn't pull in libxvidcore4 on my headless nodes, and I fixed it by manually installing it
[08:25] <crimsun> Yagisan: ok, if it's enabled in the ./configure flags in debian/rules, then it's a shlibdeps issue
[08:26] <Yagisan> crimsun: I can't see a ./configure flag for enabling/disabling xvid. I only see a setting that sets xvid4 as default
[08:27] <crimsun> erg, sounds like a shlibdeps issue then.
[08:27] <crimsun> I'll look in a bit
[08:28] <Yagisan> crimsun: thanks. the rules file looked ok to me, but I still consider myself a newbie packager, so I very likely did miss something
[08:33] <Yagisan> crimsun: Anyway re:cflags, I measured a few fps increase changing from "-O2" to "-O2 -fweb -ffast-math -funswitch-loops -fgcse-after-reload -fomit-frame-pointer" on both amd64 and k7 systems. Shall I submit bug + patch for that, for both libxvidcore and transcode ?
[08:35] <crimsun> Yagisan: oh my, what effect do those have on i386?
[08:35] <StevenK> crimsun: Can I bug you to upload somethings for me? :-)
[08:35] <crimsun> StevenK: sure, I'm busy for another 20 minutes or so, but I'll churn through 'em
[08:36] <StevenK> crimsun: xemacs21, bug 5745
[08:36] <Ubugtu> Malone bug #5745: xemacs21: merge new debian version In: xemacs21 (Ubuntu), Severity: Normal, Assigned to: MOTU Merge Team, Status: New https://launchpad.net/bugs/5745
[08:37] <Yagisan> crimsun: All they do is make gcc spend more time tuning the instructions, if you had an i486 system, they would still work.
[08:38] <Yagisan> crimsun: I'll be testing a p2 300Mhz soon
[08:38] <StevenK> Oh this machine is fun when it's hot.
[08:38] <StevenK> Not.
[08:39] <Yagisan> as that is the slowest pc I can find, but on the slower systems I don't expect any improvement, nor any decrease in performance
[08:39] <Yagisan> StevenK: your boxes overheating too ?
[08:42] <crimsun> Yagisan: ok, if they show no regressions on i386, I see no reason not to enable them, but please run it past slomo/siretart
[08:44] <Yagisan> crimsun: no problems. I'll prepare debdiffs. For transcode should I base it on my flawed patch for libxvidcore4, or the existing dapper package ?
[08:44] <minghua> I don't know much about GCC options, but I know -ffast-math generates instructions that give out different float point results (from my numeric computation experience), not sure that matters for multimedia code though
[08:45] <crimsun> Yagisan: existing dapper, please
[08:48] <Yagisan> minghua: doesn't really matter much on a something like xvid that doesn't really need exact precision, but for scientific apps
[08:49] <Yagisan> I wouldn't use it - games and most lossy encoders/decoders work fine
[08:49] <siretart> morning
[08:49] <crimsun> hi siretart
[08:50] <Yagisan> then you look at x87 compared to sse, they also generate different results, as x87 has higher precession then sse/sse2
[08:51] <siretart> Yagisan: do you also have a malone bug for your cflags patch for xvidcore?
[08:51] <Yagisan> siretart: not yet, waiting for current xvidcore source to download
[08:52] <Yagisan> siretart: those cflags ok - they are i386 compatible
[08:52] <Yagisan> even though ubuntu can't run on an i386 box
[08:52] <garbage> hi all
[08:54] <siretart> i386 is the architecture name, it does not really refer to true-i386. There are some opinions to rename that port to x86 or ia32, but other think that's not worth the efford *shrug*
[08:55] <Yagisan> siretart: I know ;) we can't run on true i386 as glibc uses some i486 code. name should be left as i386 IMHO
[08:55] <Yagisan> siretart: but no objections to the cflags ?
[08:56] <Yagisan> it's a pity -frename-registers is broken, that could have been a possible win on amd64 for those packages
[08:57] <siretart> Yagisan: if you say you have measured a performance gain, I'm all for it!
[08:59] <Yagisan> siretart: excellent :) I have to thank my daughter for giving me the inspiration to do this, if she didn't break my expensive dvds
[08:59] <Yagisan> I'd never had tried to get them backed up, and wouldn't have spend hours tweaking it for speed
[09:05] <siretart> Yagisan: I'm currently testbuilding transcode and will upload it in a minute, thanks for you patch!
[09:06] <siretart> Yagisan: If you are at it, could you please have a look at malone bug #5601 and say me if this is still applicable to dapper?
[09:06] <Ubugtu> Malone bug #5601: transcode's ffmpeg not working In: transcode (Ubuntu), Severity: Normal, Assigned to: MOTU Media Team, Status: New https://launchpad.net/bugs/5601
[09:08] <Yagisan> siretart: sure, I'll check it out. BTW my patch for for the libxvidcore dependency may not be the right patch, but it does work
[09:08] <siretart> does anyone know ian_brasil?
[09:09] <Yagisan> siretart: crimsum mentioned it may be a shlibdeps issue
[09:09] <siretart> Yagisan: right. Lets have a look at libxvid
[09:11] <Yagisan> ok, cflags changed. now to debdiff, and send the patches to malone.
[09:13] <Yagisan> siretart: that bug you pointed me to, it looks like a missing dependency error
[09:14] <Yagisan> siretart: I'll check it out in a moment, but I think I saw something like it when I didn't have mjpeg-tools? installed
[09:14] <siretart> hm. interesting
[09:16] <siretart> Yagisan: I think the 2 bugs are closely related
[09:25] <Yagisan> siretart: CFLAGS patches are located at malone bug #6004 and malone bug #6003
[09:25] <Ubugtu> Malone bug #6004: Changed CFLAGS for a speed increase. In: xvidcore (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: New https://launchpad.net/bugs/6004
[09:25] <Ubugtu> Malone bug #6003: Changed CFLAGS for a speed increase. In: transcode (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: New https://launchpad.net/bugs/6003
[09:28] <siretart> Yagisan: I think I understand now why transcode is missing dependencies
[09:29] <siretart> Yagisan: the export_*.so modules don't link directly to the 'missing' libraries.
[09:30] <siretart> Yagisan: instead, they try to dlopen them, and fail horribly if that doesn't work
[09:31] <Yagisan> siretart: So my fix is ok ? BTW transcode in dapper can't install on amd64 because of missing deps
[09:32] <Yagisan> siretart: bug 5601 is obviously a missing dependency on ffmpeg then
[09:32] <Ubugtu> Malone bug #5601: transcode's ffmpeg not working In: transcode (Ubuntu), Severity: Normal, Assigned to: MOTU Media Team, Status: New https://launchpad.net/bugs/5601
[09:36] <siretart> Yagisan: I don't think so
[09:36] <siretart> Yagisan: ffmpeg is compiled in statically *sigh*
[09:36] <siretart> Yagisan: so I'm quite sure that it is not because of ffmpeg in this case, but rather about missing references about libdts
[09:37] <siretart> [transcode]  warning : /usr/lib/transcode/export_ffmpeg.so: undefined symbol: dts_init
[09:37] <siretart> this is making me very suspicous
[09:38] <Yagisan> siretart: I can't even find a libdts package on my breezy box
[09:38] <siretart> Yagisan: so you still on breezy? ah, I thought you are already using dapper
[09:39] <Yagisan> siretart: dapper is in a chroot. I don't move my production boxes over until release
[09:40] <siretart> Yagisan: libdts is another  static only lib. *sigh*
[09:40] <siretart> Yagisan: so there is only a libdts-dev
[09:41] <Yagisan> siretart: What is it with all these static only libraries ? It's a pain in the arse from a security and maintenance point of view
[09:41] <Yagisan> siretart: BTW, anything wrong with still using breezy ?
[09:43] <siretart> Yagisan: nono, nothings wrong with breezy, it was just a misunderstanding on my side
[09:43] <siretart> Yagisan: these static only libs are a real PITA, but unstable API/ABI in shared libraries are even more pain
[09:44] <siretart> Yagisan: but I get very sad when I get answers like this: http://mplayerhq.hu/pipermail/ffmpeg-devel/2005-December/005623.html :(
[09:46] <siretart> Yagisan: and regarding libdts, there is this debian bug report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=285590
[09:50] <Yagisan> siretart: I notice how upstream is incapable of doing anything that they ask there, and have the attitude of 2 year olds.
[09:50] <Yagisan> siretart: and that bug report also sucks.
[09:51] <siretart> Yagisan: what sucks even more is this: http://developers.videolan.org/libdca.html
[09:52] <siretart> Getting libdca
[09:52] <siretart> DTS Inc. claims that distributing this software is a violation of their patent EP 864 146. At DTS Inc. request, we decided, as a precautionary measure, to provisionally suspend the distribution of libdca while reviewing DTS Inc. claim. This is not an acknowledgement of the validity of the claim.
[09:52] <siretart> The previous name "libdts" was changed to "libdca" as a precautionary measure.
[09:52] <siretart> Yagisan: I think that the new dapper build of transcode does export_ffmpeg.so in transcode right
[09:52] <siretart> Yagisan: what is easier for you: test it yourself or instruct me how to test it? ;)
[09:53] <Yagisan> siretart: both are easy for me. Got a PAL dvd, or a .avi file handy
[09:54] <siretart> Yagisan: PAM dvd mounted. whats next?
[09:55] <Yagisan> siretart: a command like "transcode -x vob -i /cdrom/video_ts/vts_01_1.vob -w 50,50 -F mpeg4 -f 25 -y ffmpeg -o 001.avi"
[09:56] <Yagisan> should be sufficent to see if it works
[09:56] <siretart> Yagisan: ah, great.
[09:56] <Yagisan> siretart: hmm, I got a different error
[09:57] <siretart> working like a charm for me :)
[09:58] <Yagisan> siretart: you may want to stop that, because at 50 x 50, you'll get a postage stamp sized video :)
[09:59] <Yagisan> siretart: [export_ffmpeg.so]  Could not allocate enough memory.    <- on a box with 1.5GB of RAM =-O
[10:00] <Yagisan> siretart: works fine with an already decrypted dvd though
[10:01] <siretart> Yagisan: I transcoded it full size, and have 1GB ram (amd64)
[10:01] <siretart> closed that bug
[10:02] <Yagisan> siretart: that command is almost identical to the one in bug five six zero one, and I have it working on breezy
[10:02] <siretart> Yagisan: regarding your patch, I think a recommends is better suited than a hard depends. Recommends are supposed to be installed by default anyway. and transcode does work without that (without that specific feature, though)
[10:03] <Yagisan> siretart: OK. As long as it pulls xvid in when someone installs dvdrip or transcode, that's fine
[10:04] <siretart> Yagisan: and I just had a look at the source of export_ffmpeg
[10:04] <siretart> Yagisan: it is not possible to get that dependency detected automatically.
[10:04] <siretart> Yagisan: because it tries to dlopen xvid, and should give you a nice error message instead of failing to start, does it?
[10:05] <siretart> Yagisan: from what I see from the code, you should have got a message like '[export_xvid]  No libxvidcore API4 found'
[10:05] <siretart> right?
[10:06] <Yagisan> siretart: I did get an error message, and dvdrip automatically shutdown the node that didn't have xvid
[10:06] <Yagisan> siretart: from memory the error message was similar
[10:07] <Yagisan> siretart: but it certainly wasn't the expected behaviour
[10:07] <siretart> I'm currently considering moving the dependency to suggests
[10:08] <siretart> omg. there is some more marillat cruft left. transcode needed another upload anyway
[10:08] <Yagisan> siretart: not suggests thanks. I think recommends is better, esp as xvid is stable and works - sometimes better then the ffmeg included
[10:09] <Yagisan> s/ffmeg/ffmpeg
[10:09] <siretart> I see.
[10:09] <siretart> marillat had libdivxencore0 added to suggests
[10:09] <siretart> and wtf is xvid4conf ?!
[10:10] <Yagisan> siretart: libdivxencore segfaults on pentium 4 and will never be fixed
[10:10] <siretart> Yagisan: divxencore is a piece of unfree binary shit
[10:11] <Yagisan> siretart: xvid4conf lets you control how transcode use xvid with api version 4, eg how many b-frames, do you want gmc, qpel etc
[10:11] <siretart> Yagisan: we don't seem to have it in ubuntu, right?
[10:12] <Yagisan> siretart: I'd want it on the master node, but not on a client. I have it. just a sec, I'll see what repo I got it from
[10:12] <Yagisan> siretart: that's in breezy
[10:12] <siretart> stop, we have that already
[10:13] <siretart> ok
[10:16] <Yagisan> sireatrt: xvid4conf upstream 404s, and there was supposed to be a version 1.6 :(
[10:16] <Yagisan> siretart: /|\
[10:16] <siretart> Yagisan: I see that you are doing a great job with transcode and multimedia packages. May I invite you to the motumedia team? https://launchpad.net/people/motumedia
[10:17] <siretart> ;)
[10:19] <siretart> err, we have version 1.12-0.0 in the archive
[10:22] <Yagisan> siretart: So, you'd like a tester to join motumedia ?, as my C skills are non-existent
[10:22] <siretart> Yagisan: well, you are using multimedia related packages and know how to file bugs. :)
[10:23] <siretart> .oO( a ccache enabled pbuilder is really really handy :))
[10:24] <Yagisan> siretart: yep - have ccache enabled pbuilder for breezy amd64 and i386, and dapper amd64
[10:26] <Yagisan> siretart: Is there a mailing list, or irc channel you need me to join for motumedia ?
[10:27] <siretart> Yagisan: for now we are all in this channel.
[10:28] <siretart> Yagisan: our wiki page is here: https://wiki.ubuntu.com/MOTUMedia. We also have a mailing list mainly for malone bugs motumedia@tauware.de
[10:29] <Yagisan> siretart: OK. If I didn't stuff up, I should have submitted a request to join the team by now.
[10:42] <Yagisan> bbl - time to feed the kids
[11:03] <dholbach> hellas
[11:04] <minghua> hi dholbach
[11:05] <dholbach> hi minghua
[11:51] <paines> hi
[11:55] <pappan> hi paines
[12:09] <mvo> the dbus transition is on, I think avahi, banshee and vlc needs rebuilding in universe
[12:12] <Yagisan> re
[12:13] <Mithrandir> StevenK: not when the previous version was autosynced, since that version then was in Ubuntu
[12:36] <Tonio_> hi everyone
[01:51] <thierry> what's a "native packages"? The reviewer of my package said I shouldn't make one...
[01:51] <azeem> a source package which only had .tar.gz and .dsc as files
[01:52] <azeem> as opposed to .orig.tar.gz, .diff.gz and .dsc for regular source packages
[01:53] <thierry> ok so I should add .orig.tar.gz and .diff.gz ? but how? is there any option for debuild or something like that?
[01:55] <azeem> if there is an appropriately named .orig.tar.gz in the parent directory, it will get used an a .diff.gz be constructed from it
[01:55] <azeem> so probably all you have to do is get the prestine upstream tarball again and rename it appropriately
[01:56] <thierry> k
[01:58] <Kyral> Morning
[01:59] <thierry> Kyral : morning
[02:00] <thierry> azeem : so libfxscintilla-1.6_1.63.orig.tar.gz would be ok, or I need to add a 0ubuntu1 thing?
[02:00] <azeem> it's ok, upstream tarballs have no Debian/Ubuntu revisions
[02:00] <thierry> k
[02:01] <azeem> thierry: well, is your source package really named libfxscintilla-1.6?
[02:02] <thierry> azeem : no, but that's the name I want to give to the package
[02:02] <azeem> it has to match with what's in debian/changelog, e.g.
[02:02] <thierry> azeem : well it should be libfxscintilla1.6_1.63.orig.tar.gz
[02:03] <thierry> the "_1.63" thing is just what debuild add automatically, so I tough I had to add it there too
[02:04] <azeem> what is the first line of debian/changelog?
[02:04] <thierry> libfxscintilla1.6 (1.63-0ubuntu1) dapper; urgency=low
[02:04] <azeem> ok then
[02:05] <thierry> that's correct?
[02:05] <azeem> yes
[02:05] <thierry> so "sudo debuild" should give me my .diff.gz?
[02:05] <azeem> we won't know until you try
[02:06] <thierry> k, trying...
[02:06] <thierry> azeem : another thing, how do I adhere to current standards-version?
[02:06] <thierry> litian give me E: libfxscintilla1.6 source: invalid-standards-version 1.63
[02:06] <thierry> N:
[02:06] <thierry> N:   The source package refers to a `Standards-Version' which never
[02:06] <thierry> N:   existed. Please update your package to latest policy and set this
[02:06] <thierry> N:   control field appropriately.
[02:07] <azeem> make sure your package is following the current policy and then change the Standards-Version in debian/control to that
[02:07] <azeem> Standards-Versions pertains to the respective version of policy, not the package
[02:10] <thierry> Standards-Version: 1.63 should be ok? I don't understand what's my error...
[02:10] <azeem> 14:02 < azeem> Standards-Versions pertains to the respective version of policy, not the package
[02:10] <Yagisan> thierry: Current Standards version is 3.6.2 IIRC
[02:11] <thierry> ho ok!!!
[02:11] <azeem> Package: debian-policy
[02:11] <azeem> Version: 3.6.2.1
[02:11] <thierry> sorry, I'm a bit slow this morning
[02:11] <raphink> hehe
[02:11] <Yagisan> azeem: So, someone found a typo to get .1 ?
[02:11] <azeem> dunno
[02:11] <thierry> azeem : and do I add debian-policy to the deps?
[02:12] <azeem> thierry: no
[02:12] <thierry> azeem : got my diff.gz file :)
[02:13] <thierry> azeem : one last thing, the commenter said I should also make -dev package for my package... I add stuff to my control file but then? what should change in this package??
[02:15] <raphink> thierry: create blahblah-dev.install files and blahblah-0.install
[02:15] <raphink> that will describe which files go where
[02:15] <raphink> in each package
[02:15] <thierry> in /debian ? but I'm using cdbs... there about no change to make
[02:16] <raphink> with cdbs it's even easier
[02:16] <raphink> just create the .install files in debian/
[02:16] <raphink> thierry: is it a library?
[02:16] <thierry> raphink : yes
[02:17] <raphink> thierry: look at this : http://revu.tauware.de/revu1-incoming/libeduwidgetclock0-0511221440/libeduwidgetclock0-0.2/debian/
[02:17] <raphink> this is a library I packaged with cdbs
[02:17] <raphink> look at all the files
[02:20] <thierry> raphink : what's the use of  "debian/tmp/usr/lib/lib*.so.*" ? (just to make sure if I need to use that)
[02:20] <raphink> thierry: when the library is built, it is installed in debian/tmp/
[02:20] <raphink> so writing debian/tmp/usr/lib/lib*.so.* in a .install file
[02:21] <raphink> means that all files of this form (regexpr) will be installed
[02:21] <raphink> in /usr/lib/
[02:21] <thierry> raphink : k and debian/tmp/usr/share/apps/kdeedu/pics/clock.png is just to copy the icon right?
[02:21] <raphink> well don't worry about this one
[02:22] <raphink> it's not to be in your lib
[02:22] <raphink> adapt to your own liv
[02:22] <raphink> lib
[02:22] <thierry> k
[02:23] <thierry> raphink : I think that your whole blabla-dev.install file is suitable for me
[02:23] <raphink> that's why I gave it to you
[02:23] <thierry> :) thanks
[02:24] <thierry> raphink : in control, do I really need ${misc:Depends} ?
[02:25] <raphink> doesn't cost anything to keep it
[02:25] <raphink> this is to be replaced by variables when the lib compiles
[02:25] <Yagisan> G'day all. Anyone familiar with debarchiver ?
[02:25] <raphink> if the lib requires another lib to work, then you might need it
[02:25] <thierry> k
[02:26] <Yagisan> I'm getting the wonderfully confusing message of "Message: udeb owner () do not match ltsp_0.61~udubackport1_amd64.changes owner (1000)."
[02:27] <Yagisan> yet all packages are owned by the "jamie" user, and are in the "jamie" group, which is uid 1000
[02:27] <thierry> Yagisan : what's udeb?
[02:28] <thierry> Yagisan : maybe you udeb works with another user than jamie
[02:28] <thierry> like sudo jamie
[02:29] <thierry> raphink : are you a MOTU?
[02:29] <raphink> not yet
[02:29] <thierry> k
[02:29] <raphink> ;)
[02:30] <Yagisan> thierry: udebs are used by the install cds. I'm not trying to install the udeb, I'm trying to update a repo, to install all the other debs I built.
[02:31] <thierry> k... don't know then
[02:54] <Yagisan> any pbuilder gurus around ? I'd like it to not generate udebs while building packages, is this possible ?
[02:56] <Kyral> hey Mez
[02:59] <ogra> Yagisan, edit the control file ;)
[03:01] <Yagisan> ogra: I ah, manual created the sections, and slotted the debs into the repo. But the good news is I found a bug in debarchiver
[03:01] <Yagisan> ogra: but as I don't know perl, I can't create a patch for it
[03:04] <ogra> just make sure its known, so someone can fix it ;)
[03:05] <Yagisan> ogra: filling bug right now
[03:05] <ogra> :)
[03:08] <Yagisan> done. someone familiar with perl will need to check out malone bug #6011 when they have time.
[03:08] <Ubugtu> Malone bug #6011: Moves all debs into REJECT if any .udeb was built. In: debarchiver (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: New https://launchpad.net/bugs/6011
[03:15] <zakame> evening all ;D
[03:18] <raphink> hi zakame
[03:19] <zakame> heya raphink :D
[03:19] <raphink> :)
[03:20] <raphink> how ar eyou doing?
[03:20] <zakame> here, catching up after a busy day irl...
[03:20] <raphink> mhm
[03:20] <zakame> well, close to irl, as I helped my friend priest to install a new hda
[03:26] <thierry> strange... I changed my source package and rebuilt, but when I send to REVU my .sources.changes, I still get the same thing than the last upload
[03:28] <zakame> what `same thing'?
[03:29] <thierry> zakame : well the last upload I did before...
[03:30] <thierry> anyway I'm trying something, going to see if it works
[03:30] <zakame> thierry: did you check you REVU uid?
[03:31] <thierry> zakame : no, how do I do that?
[03:31] <zakame> thierry: what's this package?
[03:34] <thierry> libfxscintilla1.6
[03:35] <thierry> zakame : tried a last time to send it... going to see
[03:38] <zakame> thierry: I see the latest upload, http://revu.tauware.de/details.py?upid=1263
[03:47] <zakame> hm its BUG day right?
[03:50] <thierry> zakame : how I am suposed to get mypackage.tar.gz ? debuild doesn't give it...
[03:50] <zakame> indeed, you don't have a .orig.tar.gz
[03:51] <thierry> yes I do
[03:51] <zakame> thierry: doesn't the upstream lib have a tarball? if so just rename it then to <srcpkg>_<upstream-version>.orig.tar.gz
[03:52] <Yagisan> zakame: bug day ? is that where I see how many new bugs I can find ?
[03:52] <zakame> thierry: then put that in the dir outside your source tree
[03:52] <zakame> Yagisan: yeah, among other things :)
[03:52] <zakame> its also a HUG day too :D
[03:52] <thierry> zakame : I have the .orig.tar.gz, I just don't have the .tar.gz of the package I build
[03:53] <thierry> zakame : look at http://revu.tauware.de/details.py?upid=1263, it's not there
[03:54] <zakame> thierry:  yeah I'm checking it, did you try building this in a pbuilder?
[03:55] <thierry> going to try that...
[03:56] <Yagisan> zakame: excellent, I'll try to report more bugs then I fix today :-P
[03:56] <zakame> hm well next time you ought to do it in a pbuilder (or even in a regular dapper chroot) first, it saves a lot of pain :)
[03:57] <zakame> Yagisan: w00t! :)
[03:57] <thierry> zakame : I already did before, but I deleted the mypackage.tar.gz because I tough this was causing my upload to revu to stay the same... but now the mypackage.tar.gz doesn't recreate with debuild, but pbuilder was working fine before
[03:58] <zakame> thierry: REVU requires full source uploads, aka source pkgs from `debuild -S -sa` or `dpkg-buildpackage -S -sa`
[03:58] <zakame> brb
[03:59] <zakame> thierry: note, that means for ALL uploads made to REVU
[03:59] <thierry> k
[03:59] <thierry> going to retry with the -sa ...
[04:03] <thierry> zakame : pbuilder worked fine
[04:04] <thierry> zakame : seriously I don't understand how I am supposed to get a mypackage.tar.gz...
[04:09] <zakame> thierry: .orig.tar.gz , not just a mypackag.tar.gz... otherwise that'll be a Debian-native pkg
[04:09] <zakame> thierry: you also don't generate a .orig.tar.gz , just use the rename the original upstream tarball to such
[04:10] <thierry> zakame : I know! I have the .orig.tar.gz (but for a reason I don't know it didn't upload to REVU at the same time than the rest of my package) but I just don't know how to generate the mypackag.tar.gz
[04:10] <thierry> zakame : debuild doesn't create it...
[04:11] <zakame> er exactly why are you building that mypackage.tar.gz , its not needed really, and REVU iirc will silently drop that, since it won't be in the .dsc
[04:11] <zakame> or in the source.changes
[04:12] <thierry> k... then my package in REVU is ok?
[04:12] <zakame> well the comments from daemon@poleboy.de still hold
[04:14] <thierry> zakame : I changed all the stuff for it in the last upload... but why isn't there a DIR?
[04:14] <zakame> thierry: exactly because there's no .orig.tar.gz to extract :(
[04:15] <zakame> wb Mez :D
[04:15] <thierry> zakame : but I have one in my folder... why haven't it got on REVU??
[04:15] <Mez> ty, was just a relogin to see if itproperly saved the session
[04:16] <thierry> libfxscintilla1.6_1.63.orig.tar.gz
[04:16] <zakame> thierry: well REVU does something like `dpkg-source -x' on the .dsc, and since there's no .orig.tar.gz, there's no DIR
[04:16] <zakame> thierry: yes, upload that along with the .dsc , .diff.gz , and source.changes
[04:16] <thierry> zakame : but I DO have one on my computer in the same folder than .dsc, etc...
[04:17] <thierry> zakame : but that's what I did before! going to retry...
[04:21] <thierry> zakame : just resent... going to see if that worked in 5 minutes
[04:27] <thierry> zakame : good! worked fine...
[04:27] <thierry> zakame : could you review it? (If you have time for this)
[04:30] <zakame> thierry: hm have you checked this against lintian? I see your binary pkg name doesn't have the SONAME
[04:30] <zakame> thierry: also, your pkg desc's are so terse
[04:30] <thierry> zakame : lintian is empty : http://revu.tauware.de/revu1-incoming/libfxscintilla1.6-0512211025/lintian
[04:31] <thierry> zakame : what do you mean by terse?
[04:31] <zakame> thierry: the place where the long desc's supposed to be is basically just echoing the desc-synopsis
[04:32] <zakame> hi mhz :D cooking empanadas lately? :)
[04:32] <mhz> zakame: hey, mon
[04:32] <mhz> :)
[04:32] <mhz> empandaas.. nope.
[04:32] <thierry> zakame : ho, yeah I know, but that's all the info that was on the upstream website
[04:32] <mhz> Humitas? yes
[04:34] <zakame> thierry: well http://revu.tauware.de/revu1-incoming/libfxscintilla1.6-0512211025/libfxscintilla1.6-1.63/README seems to say otherwise
[04:35] <thierry> zakame : well that's about the same thing...
[04:35] <thierry> FXScintilla is an implementation of Scintilla for the FOX GUI Library.
[04:36] <zakame> thierry: but at least put some urls, esp. info about scintilla and fox-gui
[04:36] <thierry> all the stuff around is for scintilla and fox librairy... this line is the only info about fxscintilla
[04:36] <thierry> k
[04:37] <thierry> zakame : that's the only problem?
[04:38] <zakame> still checking
[04:48] <abedra> Does skype have any plans to fix their bug?
[04:48] <Treenaks> abedra: what? that they exist?
[04:48] <abedra> the breezy no worky bug
[04:48] <abedra> the reference
[04:48] <zakame> haha
[04:48] <Treenaks> abedra: ask sladen
[04:51] <thierry> zakame :  tell me, when you'll have finished checking it and I'll upload the last changes for the descriptions
[04:51] <zakame> ok :D
[04:52] <zakame> thierry: I'm pbuilder-satisfydepends on the pkg right now, so it could take a while
[04:53] <thierry> k... no problem take the time you want, as long as I end up with advocated package at the end ;)
[04:54] <zakame> haha... well, just to comfort you, even my REVU package is pending an advocate ;) though its lintian- and pbuilder-clean
[04:54] <thierry> k...
[04:56] <zakame> http://revu.tauware.de/details.py?upid=929
[05:20] <thierry> zakame : should every lib also have a -dev package?
[05:21] <zakame> thierry: it's needed when lib sources are needed for compiling, and that's pretty much what libs do ;)
[05:21] <siretart> slomo: around?
[05:22] <slomo> yes
[05:22] <siretart> slomo: ah, hi! :)
[05:22] <slomo> hi siretart ;)
[05:29] <zakame> thierry: I'll continue checking later :D
[05:29] <zakame> gn8 all
[05:29] <thierry> zakame : thanks, godd bye
[05:36] <abedra> besides REVU what is going on today?
[05:54] <sneaky> is anyone working on updating nmap
[05:55] <sneaky> looks like 3.81-2ubuntu1 is the most current
[05:56] <sneaky> 3.95 was release not too long ago
[05:56] <dholbach> what does debian have?
[05:58] <sneaky> 3.81
[06:14] <JohnnyMast> dholbach do you have time to release my revu package again ?
[06:15] <dholbach> dholbach: if you give me the link...
[06:16] <JohnnyMast> http://revu.tauware.de/details.py?upid=1248
[06:18] <JohnnyMast> dholbach: http://revu.tauware.de/details.py?upid=1248
[06:37] <JohnnyMast> dholbach question did you get my link earlyer ?
[06:38] <dholbach> JohnnyMast: yes
[06:39] <JohnnyMast> ok thanks
[06:42] <dholbach> JohnnyMast: did you build it in pbuilder for a test?
[06:42] <JohnnyMast> yep
[06:42] <dholbach> do you get this too:
[06:42] <dholbach> *scroll*
[06:42] <dholbach> python setup.py clean -a
[06:42] <dholbach>     TTB Installation Failed
[06:42] <dholbach>     -----------------------
[06:42] <dholbach>     You don't seem to have the gtk and/or gtk.glade modules for
[06:42] <dholbach>     Python. Please install it:
[06:42] <dholbach>     - 'python-glade2'  [Ubuntu/Debian] 
[06:42] <dholbach> make: [clean]  Error 1 (ignored)
[06:42] <dholbach> find . -name '*.pyc' | xargs rm -f
[06:42] <dholbach> rm -rf build
[06:44] <JohnnyMast> nothing wrong here
[06:44] <JohnnyMast> http://revu.tauware.de/details.py?upid=1248 is what i gave you right ?
[06:44] <dholbach> yep
[06:44] <JohnnyMast> because that sounds like the prev version i fixed and then uploaded the newest for
[06:45] <JohnnyMast> ow dang, dholbach i see it now
[06:48] <JohnnyMast> dholbach if you look at the build deps you see its included. Do you have any idea why it pops up ?
[06:48] <dholbach> JohnnyMast: do you have the -dev packages in the build-deps?
[06:49] <JohnnyMast> well i have this : Build-Depends-Indep: python (>= 2.2), python-gtk2 (>=2.0), python-dev , python-glade2
[06:52] <ogra> python-gtk2-dev is missing
[06:52] <ogra> instead of python-gtk2
[06:53] <JohnnyMast> orga is we didnt have you :) thanks !
[06:54] <\sh> moins
[06:54] <ogra> JohnnyMast, not sure if its enough
[06:55] <JohnnyMast> we will see im pbuilding atm
[06:55] <JohnnyMast> orgra its still missing python-glade2
[06:55] <dholbach> apart from that it lookx good
[06:56] <JohnnyMast> dholbach thanks, i tryed hard .. do you think after this is fixed its done ?
[06:57] <dholbach> i'lll poke a bit at it, but i think it looks good
[06:57] <seth_k|lappy> if someone is bored, could they archive http://revu.tauware.de/details.py?upid=1252 and review http://revu.tauware.de/details.py?upid=1253 ?
[06:59] <JohnnyMast> seth_k|lappy i could later on if i fixed this bug
[07:00] <seth_k|lappy> no hurry
[07:00] <JohnnyMast> :)
[07:00] <\sh> what I was missing yesterday at the meeting hours?
[07:01] <JohnnyMast> ok guys hint my on a gnome window manager in ubuntu coded in python
[07:01] <seth_k|lappy> \sh, it was a pretty bland meeting. We talked mostly about licensing for the wiki (public domain vs. GFDL)
[07:02] <\sh> seth_k|lappy: was it TB or CC? TB I think, right?
[07:02] <seth_k|lappy> \sh, oh, yesterday was a CC meeting
[07:02] <seth_k|lappy> dunno if there was a TB meeting too
[07:02] <seth_k|lappy> \sh, are you feeling better lately?
[07:03] <\sh> well...I was just sleeping like a hedgehog yesterday...
[07:03] <seth_k|lappy> hehe
[07:03] <\sh> seth_k|lappy: I think I'm feeling better, yes...ok..the coughing is not ok...but no fever anymore...
[07:03] <seth_k|lappy> that's good :) I'm glad to hear
[07:04] <\sh> yeah...just trying to eat something..and then checking the rest of the merges
[07:05] <\sh> ogra: how is suse?
[07:06] <ogra> better
[07:06] <\sh> ogra: sounds good :) give her my best greetings :)
[07:06] <ogra> sleeping currntly
[07:09] <\sh> ogra: just got a call from dmitry today...looks like that isp operations is fcked...only one guy left :)
[07:09] <ogra> lol
[07:10] <ogra> i told you, they would have raised your salary if you stayed :)
[07:10] <ogra> so dimitry can claim more now :)
[07:10] <\sh> ogra: they can't ...because of tarif contract :)
[07:10] <ogra> ah, there were always ways
[07:11] <JohnnyMast> can some one ltell a name of a gnome project using python + glade2 ?
[07:11] <\sh> ogra: dmitry is replacing klaus...and ian is the only guy left :)
[07:11] <ogra> i have seen tarif people getting more money than non tariff ones
[07:11] <\sh> JohnnyMast: straw
[07:11] <JohnnyMast> thanks \sh
[07:11] <ogra> JohnnyMast, hwdb-client ...
[07:12] <\sh> ogra: well...I don't mind anymore...it was the best I did...and now some new adventures will wait for me :)
[07:12] <JohnnyMast> good then i can compare the controle files and see what my package is missing
[07:12] <ogra> \sh, yup :)
[07:13] <seth_k|lappy> \sh, I'm working on kubuntu-team triage... is https://launchpad.net/distros/ubuntu/+source/kmymoney2/+bug/5194 fixed now?
[07:14] <ogra> JohnnyMast, oh, hwdb-client is probablky not the best then ... i usually dont use any makefiles in my python based packages ...
[07:14] <Ubugtu> Malone bug #5194: Does not build from upstream In: kmymoney2 (Ubuntu), Severity: Normal, Assigned to: Kubuntu Team, Status: New https://launchpad.net/bugs/5194
[07:14] <seth_k|lappy> I assume it is since we have a new version now
[07:14] <\sh> seth_k|lappy: no..I need to merge libaqbanking..which I will do just now :)
[07:14] <seth_k|lappy> \sh, ah, okay :) thanks for telling me
[07:14] <\sh> seth_k|lappy: I'm closing all my bugs when they are done :)
[07:15] <seth_k|lappy> yeah yeah ;) you're probably the only one
[07:15] <\sh> seth_k|lappy: problem was daniels...and he uploaded a fix for some problems with xvfb this morning :)
[07:18] <ogra> \sh, btw, waiting for a sync of net6 and obby to merge the new gobby :)
[07:19] <\sh> ogra: I checked yesterday morning for a new obby and gobby..but it wasn't there (obby and gobby should be 0.3.x(
[07:19] <ogra> it is
[07:19] <ogra> since 2 days already
[07:20] <ogra> (in debian)
[07:20] <ogra> but elmo didnt sync them yet ...
[07:20] <\sh> ogra: hups...
[07:20] <ogra> i mailed while pkern pushed them into debian
[07:23] <seth_k|lappy> yayy serversplit
[07:33] <\sh_away> bah...freenode is unstable
[07:34] <zul> duh...:)
[07:41] <pkern> \sh: (:
[07:41] <pkern> I just uploaded an initial, quite bare, revision of sobby, the dedicated server.
[07:41] <pkern> Not yet with init scripts or so. Just the binary and a manual page.
[07:42] <dholbach> who packages it? :)
[07:42] <lucas> hi
[07:44] <pkern> I spoke about the Debian package. ;)
[07:45] <ogra> dholbach, i'll pull it in  as soon as elmo finally syncs net6 and obby
[07:45] <pkern> Perhaps I should get some fun by uploading them to REVU :D
[07:45] <ogra> pkern, please dont
[07:45] <pkern> ogra: Ok ):P
[07:45] <ogra> i want them in edubuntu asap
[07:45] <pkern> ogra: k
[07:45] <ogra> so they'll go to main soon
[07:46] <ogra> :)
[07:46] <pkern> ogra: Sobby is stuck for ftp-master approval in Debian because it's entirely new. Just put together a little package in half an hour.
[07:46] <pkern> ogra: But hehe. :P
[07:47] <ogra> doesnt it get through the debian NEW queue within a week or less ?
[07:47] <ogra> i heard things have sped up a lot there
[07:47] <pkern> ogra: It's not so tiny currently, but hopefully.
[07:48] <ogra> and i guess sobby will at least need nte6 ...
[07:48] <ogra> *net6
[07:48] <pkern> ogra: obby too.
[07:48] <ogra> so we'll have to wait until elmo reacts on my mail ...
[07:48] <pkern> ogra: Ich habe mir den Mund verbrannt gegenber den ftp-masters (Don't know the English term). Getting something into Ubuntu is the far worst justification they ever heard. :)
[07:49] <pkern> ogra: I just included it in a rant, not into the mail to them. So it wasn't that hard.
[07:49] <ogra> hmm, you spoke to the wrong ftpmaster ;)
[07:49] <\sh_away> lol
[07:49] <pkern> ogra: Hehe.
[07:49] <ogra> isnt elmo still one of them in debian ?
[07:49] <pkern> ogra: Well, I don't think he does much.
[07:49] <pkern> ogra: elmo is still the bottleneck on various positions within Debian.
[07:49] <pkern> ogra: ):
[07:50] <pkern> ogra: Not for this, though.
[07:50] <ogra> yes, he's very busy with is job recently
[07:50] <ogra> he does a lo on launchpad atm ...
[07:50] <ogra> *lot
[07:50] <pkern> ogra: We had developer resignations because of him, more precisely because of keyring-maint. But I'm restricted on saying more about it. That's what annoys me, really.
[07:51] <\sh> pkern: but this is really more a problem of " why you don't have more people for this" problem?
[07:51] <\sh> pkern: I read some rants about it on d-d
[07:52] <pkern> \sh: It's not that he accepts one besides him. |:
[07:52] <\sh> pkern: I think it's more a problem of the debian board of directors ,)
[07:52] <pkern> \sh: The cabal |:
[07:55] <pkern> ogra: Gobby might go in without patching, Ubuntu has migrated to the epoch on gtkmm2.4, too.
[08:02] <ogra> GRRR
[08:02] <ogra> whats wrong with freenode today ...
[08:02] <ogra> this was my 20th disconnect ...
[08:03] <pkern> Hm. I thought my DSL line was responsible...
[08:04] <pkern> Ah lilo again...
[08:04] <ogra> not here, my DSL is fine the whole day, i thought the same this mornong ...
[08:04] <tseng> if you join oftc you will see you can stay connected for days/weeks
[08:04] <tseng> and no one dicks around with the servers every day
[08:05] <pkern> tseng: The same on Qnet or $insert_your_favourite_net_here, whatever. ;)
[08:06] <tseng> ok, oftc lets you stay connected and isnt full of rabid kids hopped up on jolt cola
[08:06] <tseng> :)
[08:07] <pkern> tseng: Hehe.
[08:07] <tseng> daniels wrote a spec to move the channels to oftc
[08:08] <pkern> tseng: http://irc.netsplit.de/cgi-bin/ncompare.cgi?n1=freenode&n2=OFTC <-- Well, no network is responsible for spambot attacks. And the probability increases with the network size.
[08:10] <\sh> well..a decent user authentication must be installed :)
[08:10] <\sh> with checking the original requester...if and only if you want a decent professional irc network
[08:11] <\sh> well..gpg auth could be done as well
[08:11] <\sh> that means a nice LP AuthServer implementation can be done ,)
[08:14] <\sh> and we could establish irc.ubuntu.com
[08:15] <seth_k|lappy> ugh, then I have to SSH tunnel to two different servers for IRC ;)
[08:15] <seth_k|lappy> my uni blocks IRC so I always connect via SSH
[08:17] <\sh> seth_k|lappy: or you have to convience your admins to allow to connect to irc.ubuntu.com ,)
[08:17] <seth_k|lappy> haha, tell you what, you come down and convince them :)
[08:17] <ajmitch> morning
[08:18] <seth_k|lappy> hi there ajmitch :)
[08:20] <\sh> yeah
[08:20] <\sh> he-man/she-ra xmas special from 1985 ,-)
[08:28] <lfittl> any motu here who has time to review something?
[08:28] <lfittl> i know, everybody hates that question ;)
[08:29] <sneaky> lfittl: what to review?
[08:30] <lfittl> sneaky: my package, http://revu.tauware.de/details.py?upid=1266
[08:30] <seth_k|lappy> if someone is bored, could they archive http://revu.tauware.de/details.py?upid=1252 and review http://revu.tauware.de/details.py?upid=1253 ?
[08:36] <seth_k|lappy> harsh, harsh :)
[08:37] <ajmitch> no, I'm busy doing other packages while I have time ;)
[08:38] <seth_k|lappy> hehe
[08:56] <seth_k|lappy> http://revu.tauware.de/details.py?upid=1230 needs archiving as well, it's been uploaded
[08:56] <ajmitch> they're all too lazy ;)
[08:57] <seth_k|lappy> or bored ;)
[08:59] <seth_k|lappy> the perils of being too important in more than one organization :)
[08:59] <siretart> ajmitch: you are doing debian work right now?
[08:59] <siretart> ajmitch: do you think you could sponsor me something? ;) - lintian clean and nice *g*
[08:59] <Kyral> hmm mebbe I'm stupid but how do you tell wget to download a file to someplace other than the working directory?
[09:00] <ajmitch> siretart: if it were something I could do in under 10 minutes ;)
[09:00] <seth_k|lappy> Kyral, the -P option
[09:01] <Kyral> ah
[09:01] <siretart> ajmitch: http://tiber.tauware.de/~siretart/nxtvepg/. its not urgent, if you are at it, would be great ;)
[09:01] <Kyral> ty
[09:02] <ajmitch> siretart: it's just that I'm going away for a week, later today :)
[09:02] <ajmitch> and I'm behind on my debian work
[09:02] <siretart> oh. ok.
[09:02] <siretart> you are on holiday then? great news :)
[09:02] <ajmitch> siretart: permanent holiday as of lunchtime ;)
[09:03] <siretart> ah, I see :)
[09:03] <ajmitch> when I get back I'll have to finish all my merges, etc
[09:03] <ajmitch> hold off \sh from taking them until then :)
[09:08] <JohnnyMast> dholbach . ping
[09:09] <JohnnyMast> ogra ping
[09:09] <dholbach> JohnnyMast: pong
[09:10] <dholbach> how can i be of your assistance? :)
[09:10] <dholbach> or was this a reply-to-ping test and i won, because i was quicker than ogra?
[09:10] <JohnnyMast> ok i was back at the package and noticed that the warning about python-glade2 was only in the unpatched part of the pbuild
[09:10] <dholbach> i don't know what you mean by "unpatched part of the pbuild"
[09:10] <JohnnyMast> no you both knew my problem
[09:11] <JohnnyMast> ile upload my log hold on
[09:11] <dholbach> did it work, when you build-depended on the respective -dev packages?
[09:13] <JohnnyMast> still that warning in clean but then further on in that build the patches are aplyed
[09:13] <JohnnyMast> and no it didnt work :(
[09:14] <dholbach> hmhm
[09:14] <dholbach> you could try to      strace -e open,stat setup.py    and see which files it looks for
[09:14] <dholbach> (if it doesn't wirte logs anyways=
[09:15] <JohnnyMast> Moritz says it hooks to X during setup
[09:17] <JohnnyMast> open("/usr/lib/python2.4/site-packages/gtk-2.0/gtk/glade.so", O_RDONLY) = 4
[09:18] <Hieronymus> slomo: ping?
[09:18] <slomo> Hieronymus: pong
[09:18] <Kyral> I have NO idea if this is gonna work
[09:20] <Kyral> But thats the fun part ain't it :D
[09:20] <Hieronymus> slomo: one month ago you said you planned to sync gnunet-gtk from Debian soon. See bug #4573
[09:20] <Ubugtu> Malone bug #4573: gnunet-gtk won't install In: gnunet (Ubuntu), Severity: Major, Assigned to: MOTU, Status: Accepted https://launchpad.net/bugs/4573
[09:21] <Kyral> Oh slomo, yousa gonna kill me but I uploaded another trival change to EasyChem >_<
[09:21] <slomo> Hieronymus: i'll talk to elmo when he's back... sorry :/ i didn't forget about this bug
[09:21] <JohnnyMast> dholbach alcording to Moritz (MOTU) the problem is that the needed patches arnt done before the cleaning.. in the cleaning it gives the error
[09:22] <slomo> dholbach: thanks for fixing gnome-games :)
[09:22] <dholbach> yes, might be
[09:22] <dholbach> slomo: de rien :)
[09:23] <JohnnyMast> dholbach is there away to aply the patches before the clean ?
[09:23] <slomo> JohnnyMast: no and it shouldn't be done
[09:24] <slomo> apply this patch directly to get it in the diff.gz
[09:24] <slomo> i see no other way
[09:24] <slomo> it's not very clean but the only solution for this patch :/
[09:24] <JohnnyMast> the problem is slomo its patching to late
[09:25] <slomo> when you have this patch directly in the diff.gz it's patched early enough... i.e. before clean
[09:25] <dholbach> yeah
[09:26] <JohnnyMast> build the build doesnt stop at all it just reports and then patches the warning
[09:26] <JohnnyMast> and then cleanly builds the package without errors nor warnings
[09:28] <JohnnyMast> but thats good then isnt it ?
[09:28] <JohnnyMast> because it builds the patched package
[09:33] <Kyral> hmm to make a source package I use dpkg-source -b right?
[09:34] <crimsun> yep
[09:35] <slomo> JohnnyMast: what?
[09:36] <JohnnyMast> nm
[09:36] <ajmitch> Kyral: if you're that desperate
[09:36] <Kyral> ajmitch: huh?
[09:37] <ajmitch> Kyral: I'd rather use debuild -S
[09:37] <ajmitch> as it'll run debian/rules clean first
[09:38] <Kyral> This isn't for the Repos
[09:38] <ajmitch> doesn't matter
[09:38] <ajmitch> all your packages should be to that quality anyway :)
[09:38] <Kyral> yah I know
[09:56] <crimsun> bye daniel
[09:57] <JohnnyMast> dholbach alright its fixed :)
[09:57] <JohnnyMast> oops
[09:58] <JohnnyMast> any one wants to review my fixed package ?
[09:59] <Hieronymus> Will people browse REVU to review packages, or will I have to ask here?
[10:00] <Hieronymus> http://revu.tauware.de/details.py?upid=1232
[10:01] <ajmitch> people browse revu
[10:03] <lucas> Hieronymus: fixing existing packages are more important than introducing new packages to fix
[10:04] <lucas> so you might be more helpful working on some merges
[10:05] <lucas> ajmitch: just had a thought. why don't we add a "vote" function to review, were random users could vote to see a REVU package reviewed ?
[10:05] <lucas> that would help detect packages that we really want in because there is a huge user community waiting
[10:05] <ajmitch> because voting can be easily abused as another way to mercilessly nag reviewers
[10:06] <lucas> of course, but it's still better than nothing
[10:08] <lucas> Hieronymus: your package is a native debian package
[10:09] <lucas> erm ah no
[10:09] <lucas> but the changelog entry is wrong
[10:09] <lucas> mmh
[10:09] <lucas> not sure finally
[10:09] <lucas> should it be -1ubuntu1 or -0ubuntu1 ?
[10:09] <lucas> maybe -0 is better since, with that, a debian upload triggers a merge
[10:10] <ajmitch> no MOTU should upload a package with -0
[10:12] <crimsun> no uploads should be 0, though I've seen 0.x for NMUs
[10:16] <Hieronymus> lucas: I'm using -0ubuntu1
[10:24] <ajmitch> hm
[10:26] <JohnnyMast> forget what i sayed about my updated package above ^^ its not valid