[00:26] <mattismyname> So, I'm trying to build a package of a library (my first try...).  This library can make use of other libraries if they exist on the system, but it does not require they be present (libtiff, libpng).  My question is...should I include these on the Build-Depends: line in the package control file?
[00:27] <RAOF> mattismyname: So this will depend on a number of things.
[00:27] <RAOF> 1) Are these libraries required to be present at compile time for them to be used?
[00:27] <RAOF> (The answer to that is almost certainly yes).
[00:27] <mattismyname> yes
[00:28] <RAOF> 2) Is the extra functionality provided by building against those libs useful?
[00:28] <RAOF> (Again, probably yes).
[00:28] <mattismyname> Yes
[00:28] <RAOF> 3) Do those libs trigger a licensing problem
[00:28] <RAOF> (More difficult to say :))
[00:28] <mattismyname> Estimate maybe 50% of the users will find the additional support useful
[00:28] <mattismyname> 3) Probably not.  Libs I'm talking about are libpng, libtiff, and jpeglib
[00:29] <RAOF> They'd be mainly LGPL/MIT, yes?
[00:29] <mattismyname> yes
[00:29] <RAOF> So, generally you want to build with as many dependencies as possible.  Librarys are cheap!
[00:30] <mattismyname> ok...that is the "rule of thumb" I was looking for :)
[00:30] <RAOF> The reasons why you might not want to build against a library are if it's obscure, poorly maintained, or badly licensed.
[00:30] <mattismyname> Thanks
[00:42] <mattismyname> Another question: The lib I'm packaging depends on "An OpenGL library or the Mesa library".  Now, I know how to specify that it depends on libgl1-mesa but how do I accomplish the other half of the "or" statement?  Is there some sort of libgl metapackage?  If so, how would I find it?  I've tried apt-cache search to no effect.
[00:46] <RAOF> mattismyname: The pipe character ('|') is used to denote an OR relationship.  So, you'd be after libgl1-mesa | libmesa-not-hwaccel, or something.
[00:47] <jdong> the vertical frobulator ('|')....
[00:47] <jdong> ^^ fixed it for you
[00:49] <RAOF> GAH!  Dear internet: I'm not interested in gaining a l0nger shl0ng!  Please GO AWAY!
[00:49] <mattismyname> Hmm...now I'm thinking I can just specify libgl1-dev as the dependency
[00:50] <mattismyname> But thanks for the info on the OR
[01:49] <lifeless> There will be a short interruption to bazaar.launchpad.net and the ubuntu wiki to deploy a fix for the performance problems.
[02:27] <mattismyname> Is there any reason putting a "cd" command in debian/rules would not take effect?  For example, after configure, the makefile gets placed in the src subdirectory so I need to cd into that directory for when the make command is issued.
[02:27] <mattismyname> I tried putting "cd src" on the correct line in the rules makefile but it doesn't seem to work...
[03:14] <RAOF> mattismyname: You need to remember that each (tab-indented) line of a makefile is run in a _separate shell_.
[03:16] <RAOF> mattismyname: This means that make runs "cd" in a shell, which promptly changes _that new shell's_ current directory, and then exits.
[05:33] <TheMuso> 5~/c
[06:12] <warp10> Good morning
[06:29] <geser> good morning
[06:44] <dholbach> good morning
[06:55] <geser> Guten Morgen dholbach
[06:56] <dholbach> hiya geser :)
[08:09] <AnAnt> Hello, does launchpad have svn ?
[08:14] <AnAnt> Hello, does launchpad have svn service I mean ?
[08:15] <siretart> AnAnt: launchpad has an svn import service
[08:15] <Hobbsee> AnAnt: #launchpad, surely
[08:15] <AnAnt> thanks
[09:22] <slomo_> siretart: gst-ffmpeg still works great with latest ffmpeg from experimental ;)
[09:24] <siretart> slomo_: yeah, but it requires that 015_build_imgresample.diff patch
[09:24] <siretart> slomo_: could you check if it is possible to patch gst-ffmpeg in a way so that it is no longer necessary?
[09:25] <slomo_> siretart: the patch is for adding the deprecated imgresample api to ffmpeg again?
[09:25] <siretart> excatly
[09:25] <slomo_> siretart: well, upstream plans to port to the new stuff :) don't know when this is started/done though
[09:25] <slomo_> i'll ask later
[09:26] <slomo_> siretart: or is it easy to do? can you give me an example or something? :)
[09:26] <siretart> slomo_: http://paste.debian.net/52207
[09:26] <siretart> that is the patch
[09:26] <slomo_> ok
[09:26] <slomo_> doesn't help me :)
[09:27] <slomo_> how is the new stuff called? do you have an example patch that converts from imgresample to the new, etc?
[09:27] <siretart> no idea right now, sorry
[09:27] <slomo_> ok
[09:27] <slomo_> well, i'll take a look later
[09:27] <slomo_> bbl :)
[09:27] <siretart> I'm currently thinking about how to get this to unstable..
[09:41] <\sh> siretart: if I propose to you a debdiff with a funny build-dep of wine to mplayer to compile some tools which are only running with it...would you take it?
[09:55] <slomo_> siretart: is this imgresample patch a problem for getting it into unstable?
[10:33] <slomo_> siretart: ok, the new stuff is swscale and it can do magic ;)
[10:34] <siretart> slomo_: I don't think so
[10:34] <siretart> slomo_: rather how to sell this to the release team
[10:36] <slomo_> ok, then i'll simply wait until next upstream release :)
[10:36] <slomo_> what could be the problem with the release team? except that it might introduce regressions but fixes a million bugs
[11:10] <warp10> Hi all!
[11:12] <\sh> siretart: forget the question..you are not responsible for mplayer ;)
[11:15] <\sh> Fujitsu: /window 15
[11:15] <\sh> grmpf
[11:17] <soren> \sh: /win is much faster.
[11:18] <soren> (to type)
[11:21] <\sh> soren: well, /win<tab> is cool...but not looking at the bottom line on irssi, forgetting about what I wanted to tell Fujitsu, and not Ctrl+U the input line..gives "\sh is angry about python"
[11:23] <tbf> is there something i should do for moving gnome-lirc-properties to the next stage?
[11:23] <tbf> https://launchpad.net/ubuntu/hardy/+queue?queue_state=0&queue_text=lirc
[11:24] <tbf> hmm... stop.... 28th was friday... i am just impatient - as usual
[11:24] <siretart> \sh: isn't wine in universe? you cannot build depend on packes in multiverse, can you?
[11:37] <\sh> siretart: yeah...but mplayer is multiverse...and mplayer is this what I want to change ;)
[11:37] <siretart> \sh: err, sorry, you confuse me.
[11:38] <siretart> \sh: do don't seriously propose to make mplayer build/test some tools of wine, which won't show up in the mplayer package anyways, are you?
[11:38] <siretart> s/do/you/
[11:39] <\sh> siretart: the tools are for converting videos from one to another...the vfw2enc e.g is a windows tool, which can be compiled via winegcc or mingGW...those tools need to be in the mencoder package if this is feasable ;) but after thinking about it, it's bad
[11:40] <\sh> siretart: the sources are already in the src package.
[11:40] <siretart> in which source package?
[11:40] <\sh> siretart: mplayer...i was confused with ffmpeg when I asked you...that's why I said, forget about it :)
[11:41] <siretart> if there are tools unbuilt in the mplayer source pacakge, then probably they should be built and installed
[11:41] <\sh> siretart: the idea came from http://www.mplayerhq.hu/DOCS/HTML-single/de/MPlayer.html#menc-feat-video-for-windows <- it's for converting movies into Flash media Files with vp6 encoding ;)
[11:41] <siretart> given they are of any use, of course
[11:41] <\sh> siretart: well, it needs to be build with a windows compatible compiler like winegcc or on windows with msvc or minGW..
[11:42] <siretart> I know that we do have minGW, no idea about winegcc
[11:42] <\sh> siretart: winegcc comes with wine :) I tested it already and it works...I wonder if it's a good idea to b-d on wine ;)
[11:42] <siretart> but
[11:43] <siretart> for http://www.mplayerhq.hu/DOCS/HTML-single/de/MPlayer.html#menc-feat-video-for-windows, don't you need the windows dlls anyways?
[11:43] <\sh> siretart: nope..they are built-in by wine
[11:43] <\sh> siretart: ah you mean the w32codecs ;)
[11:43] <\sh> siretart: they are only needed for running and converting video for windows stuff...but to building those tools, they are not needed.
[11:44] <siretart> so we could build those tools, but they would still be unusable without ripping some dlls from a windows installation?
[11:44] <\sh> siretart: yes
[11:45] <siretart> then it seems to be a waste of time to me
[11:45] <siretart> if you want to do it, go ahead, but I wouldn't spend any time on that
[11:45] <\sh> siretart: as I said, forget about it...I'll fork the package for my needs and provide a selfmade package for it
[11:46] <siretart> too bad that you can't publish it
[11:46] <\sh> siretart: well, I'll send the changes as debdiff to LP...just in case someone is interested to go with it...but I won't push it into hardy..
[11:47] <\sh> siretart: the reason behind this is, that I need to convert all types of videos into FLV media with vp6 encoding which will be pushed by adobe into the next flash player at the end of the year (AFAIK)...vp6 right now can't be played with it without any additional software from on2 e.g.
[11:50] <siretart> aha
[11:55] <\sh> siretart: and the good thing is, when we do it here...we pay as well license fees for it :(
[12:13]  * \sh is testing adobe air alpha 1 ,-)
[12:16] <sebner> \sh: just read the news :)
[12:16] <sebner> DktrKranz: buon giorno :)
[12:23] <\sh> jikes...wireshark 1.0
[12:23] <\sh> should we go with it?
[12:30]  * pochu waves
[12:31] <sebner> heya jono pochu
[12:31] <jono> hey seb
[12:31] <jono> hey sebner
[12:32] <\sh> jono: please explain thong-a-gong ? ;)
[12:32] <jono> \sh: heh, a man, in a thong, with a gong and lots of 5 min talks :)
[12:33] <sebner> \sh: it's a sync right? If we wait for debian I could do it if no one else is willing to do :)
[12:34] <\sh> sebner: dunno if debian comes faster then providing a 0ubuntu1 version...I'll have to check first, because it's fixing as well some security stuff
[12:34] <sebner> \sh: k
[12:52] <\sh> sebner: I'll take a look this evening...
[12:53] <sebner> \sh: bp
[12:53] <sebner> *np
[12:55] <Iulian> Hey
[13:15] <ScottK> siretart: I worked on one of Manoj packages last night for the first time and it really wasn't so bad.  They are different, but OTOH it only took about a minute to find the right knob to turn to get it to work with our default Python.
[13:17] <james_w> they are well structured and sensible, the problem is that they are just so different.
[13:24] <slytherin> Hi all. This is regarding the catch-all bug for python-xml dependency removal. It doesn't work for pyslide. A friend just reported. And I am reopening the bug.
[13:24] <slytherin> bobbo: ping
[13:25] <ScottK> slytherin: Did you add details of the failure?
[13:25] <slytherin> ScottK: No. I am adding. them
[13:25] <ScottK> slytherin: OK.  Let me know when you're done.
[13:27] <slytherin> ScottK: done
[13:28]  * ScottK looks
[13:29] <emgent> hello
[13:30] <emgent> keescook: when you have time please see bug #194687 it's a security regression for cacti. (debdiff attached)
[13:30] <ubotu> Launchpad bug 194687 in cacti "cacti web frontend fails with 'Invalid PHP_SELF Path' after upgrade" [Medium,In progress] https://launchpad.net/bugs/194687
[13:32] <emgent> i go at work, bye people
[13:40] <\sh> emgent: nope...it's not security...it's sru...the main part works if you don't run it from /<dir> but from /
[13:50] <mok0> Is there someone here who has fiddled with octave?
[13:53] <ScottK> mok0: You want sistpoty probably.
[13:54] <\sh> mok0: what's wrong with octave?
[13:54] <mok0> ScottK: ok, thanks.
[13:54] <\sh> packagewise or codeing wise?
[13:54] <mok0> It's got an unconventional debian/ directory layout
[13:54] <mok0> with a debian/in, that seems to hold templates for the "real" files
[13:55] <\sh> mok0: which package?
[13:55] <mok0> octave3.0
[13:56] <mok0> It's the only package that shows up in the "Science" menu item on the K-menu, I want to change that, so it appears in "Education/Math"
[13:56] <\sh> I wonder if octave is education ;)
[13:56] <mok0> I wonder if any of the programs in Education is education, but that's where they all are...
[13:57] <\sh> mok0: e.g.?
[13:57] <mok0> octave is the only one I have in "Science"
[13:57] <Fujitsu> Anything sciency is in Education, because f.d.o refuses to give us a sane category.
[13:58] <\sh> damn
[13:58] <mok0> Education has 4 entries: languages, mathematics, miscellaneous & science
[13:58] <\sh> mok0: ok...when you read debian/rules, you'll see that it copies files from debian/in/* to debian/
[13:58] <\sh> mok0: depending on the $(VERSION)
[13:59] <mok0> \sh: ok, that's what I was guessing... line no?
[13:59] <mok0> Ah
[13:59] <mok0> I see it
[13:59] <\sh> debian/%: debian/in/% slice -o $(sliceterm):$@ $<
[13:59] <mok0> sneaky
[13:59] <\sh>  cp debian/in/$(PACKAGE)-00list debian/patches/00list
[13:59] <\sh>         cp debian/in/$(PACKAGE)-watch debian/watch
[14:00] <\sh> I think they were building all ocatve{2.1,2.9,3.0} with the same package layout
[14:00] <mok0> \sh: right, so one needs to modify the files in debian/in
[14:00] <slytherin> ScottK: Did you look at pyslide problem? What is the reason for not working?
[14:00] <ScottK> slytherin: I'm looking at it now.
[14:00] <mok0> \sh: I guess it's nifty, but non-standard.
[14:00] <\sh> mok0: well, it looks like it just uses debian menu system and no .desktop files
[14:01] <ScottK> slytherin: It appears that pyslide needs some XML bits not provided by the standard python.
[14:01] <mok0> \sh: yeah it's a simple one-line fix :-)
[14:01] <\sh> oh of course ... desktop.in
[14:01] <ScottK> slytherin: Short version is it should have been tested more before uploading.
[14:01] <\sh> Categories=Development;Math;Science;
[14:01] <\sh> hmmm?
[14:01] <slytherin> ScottK: hmm. So adding the dependency again is the right thing to do, right?
[14:02] <mok0> \sh: yes. I haven't figured out what it should be
[14:02] <mok0> \sh: not really into the desktop/menu system yet
[14:02] <ScottK> slytherin: No.  We're trying to remove python-xml from the archive
[14:03] <slytherin> ScottK: so what do you suggest? Look for alternate APIs and then add patches?
[14:03] <ScottK> slytherin: Yes.  or as a last resort copy the needed bits of python-xml into the package and use it from a private directory.
[14:04] <ScottK> slytherin: Will you look into it?
[14:04] <\sh> mok0: you need to adjust examples/octave.desktop.in :)
[14:04] <\sh> mok0: the other stuff is done from rules it looks like
[14:04] <slytherin> ScottK: I will try tonoght.
[14:04]  * mok0 looks
[14:04] <ScottK> slytherin: OK.  I'll assign you the bug.  Let me know if you get stuck.
[14:05] <slytherin> ScottK: sure. tell me your timezone so that I will know when to ping you. :-)
[14:05] <mok0> \sh: yeah looks like it. I need to figure out how the Categories are mapped out to menu items.
[14:05] <ScottK> slytherin: -0400.  You?
[14:06] <slytherin> ScottK: +5:30
[14:06] <slytherin> ScottK: So you will be accessible to me when I am at home tonight. :-)
[14:06] <ScottK> slytherin: I'll be here most of my day, so chances are yes.
[14:15] <mok0> What is the difference between a .menu entry and a .desktop entry? Both seem to be read by kde4
[14:21] <slytherin> ScottK: a brief look doesn't give any idea. will do more debugging later
[14:21] <\sh> mok0: .menu files are debian specific...man menufiles
[14:22] <ScottK> slytherin: Thanks for looking into it.  We're down to 2 packages that need python-xml (until your report I thought it was one), so we're very close to being able to get rid of this package.
[14:22] <mok0> \sh: it is the /usr/share/applications entry that gives problems with octave
[14:22] <\sh> mok0: mok0 this should from the .desktop file then
[14:22] <mok0> \sh: yes, it is
[14:23] <\sh> mok0: ok...desktop-file-validate will give some warnings too..if you are on it, please fix them too
[14:23] <mok0> \sh: I will fix it and submit a patch
[14:23] <mok0> \sh: ok
[14:24] <\sh> mok0: when you file a bug ( or you did already, assign the bug to me...I was the stupid one who made octave3.0 possible :()
[14:24] <mok0> \sh: why was that stupid?
[14:25] <\sh> mok0: because the guy who touched it last or synced it is responsible ,->
[14:25] <mok0> \sh: ah :-)
[14:25] <mok0> \sh: now you'll get the chance to repent :-)
[14:29] <mok0> \sh: with such a minor change, is it necessary to create a patch in debian/patches, or is it ok to leave it with diff.gz ??
[14:31] <\sh> mok0: if it has a patch system, use it...if not leave it in diff.gz
[14:32] <mok0> let's see...
[14:32] <\sh> it has dpatch
[14:33] <mok0> patch it is, then :-)
[14:35] <\sh> mok0: dpatch-edit-patch :)
[14:35] <mok0> doing it this very minute :-)
[14:48] <bobbo> slytherin; pong
[14:49] <slytherin> bobbo: I was going to point you to pyslide problem. See if you can work on it.
[14:49] <bobbo> slytherin; ok, i'll have a look
[15:22] <mok0> \sh, what is your lp ident?
[15:25] <mok0> \sh, got it
[15:30] <sebner> aloha afflux :)
[15:30] <afflux> heya sebner :)
[15:33] <\sh> mok0: shermann :)
[15:34] <mok0> \sh thanks
[15:34] <\sh> sorry...we are in prelive rollout mood at work :)
[15:36] <mok0> \sh: bug 209701 is now owned by you :-)
[15:36] <ubotwo> Launchpad bug 209701 in octave3.0 "[hardy] octave appears by itself in science menu" [Undecided,New] https://launchpad.net/bugs/209701
[15:47] <sharperguy> Anyone know how to get an app to put an icon in the menu when you make install?
[15:57] <bddebian> Heya gang
[15:57] <hyperair_> hi
[15:57] <sharperguy> Anyone know how to get an app to put an icon in the menu when you make install?
[15:59] <nijaba> sharperguy: you need a desktop file
[15:59] <sharperguy> right
[15:59] <sebner> ahoi bddebian
[15:59] <mok0> \sh: damn
[15:59] <bddebian> Hi sebner
[16:00] <geser> Hi bddebian
[16:00] <bddebian> Heya geser
[16:00] <sharperguy> Yeah I remember those, so what do I do with it when I make it?
[16:00] <nijaba> sharperguy: look in /usr/share/applications/
[16:01] <sharperguy> right...
[16:03] <nijaba> sharperguy: this is documented in https://wiki.ubuntu.com/PackagingGuide/SupplementaryFiles
[16:04] <sharperguy> ok tu
[16:04] <sharperguy> *ty
[16:04] <sharperguy> *cheers (sorry I know this isnt IM)
[16:30] <\sh> mok0: ?? :)
[16:31] <mok0> \sh: ah, it's just that my patch wasn't getting applied... fixed now
[16:31] <mok0> \sh: I had to edit debian/in/octave3.0-00list ...
[16:31] <mok0> \sh: which I didn't, the first time around...
[16:32] <mok0> \sh: the package takes forever to build, even though I have a really fast machine
[16:33] <\sh> mok0: no problem :) I built normaly over night when it's a long waiting for results package ;()
[16:33] <mok0> \sh: yeah... I thought the fix was trivial, so I went ahead and uploaded before the package finished building :-P
[16:33] <\sh> siretart: are you sure about gnucash and hardy? gnucash in hardy is already Version: 2.2.4-1ubuntu1
[16:35] <siretart> \sh: did you really use the new gnucash with hbci on hardy yet?
[16:35] <\sh> siretart: no...but I thought before people are complaining about the version ;) does it work somehow with 2.2.4-1ubuntu1?
[16:35] <siretart> \sh: AFAIUI, it uses libgwenhyfar for the 'lowlevel' stuff. this means that if something is broken there, gnucash will be broken as well
[16:36] <siretart> I'm still on gutsy on my main laptop, because I know that gnucash does work there :)
[16:47] <proppy> hi
[16:48] <proppy> how can I create a ipex chroot ?
[16:56] <\sh> siretart: could you send me the changes you made on the 2.2.1 source for gnucash and I can try to build and test it...
[16:58] <RainCT> proppy: ipex?
[16:59] <siretart> \sh: there shouldn't be any changes necessary. just try the source from debian/unstable (+ your patches if applicable)
[16:59] <RainCT> proppy: if you Ibex (Hardy+1), it has no repositories yet, so you can't
[17:00] <proppy> RainCT: thanks for the tip
[17:00] <siretart> the codename is 'intrepid', not ibex
[17:01] <siretart> like 'hardy', and not 'heron'
[17:01] <siretart> or 'gutsy', and not 'gibbon'
[17:02] <\sh> siretart: so 2.2.4 in debian is already prepared? :)
[17:03] <siretart> prepared for what?
[17:03]  * \sh doesn't use hbci yet...so I don't know how to enable it ;)
[17:05] <siretart> ah, I see
[17:05] <siretart> you'll need this ofx plugin for libgwenhyfar and gnucash
[17:06] <\sh> siretart: ok...will read me through the guides and start convincing my bank to have webbanking and hbci
[17:06] <siretart> \sh: if all works well, there should be a new menu point: Actions-> Online Actions
[17:07] <siretart> try starting up gnucash and see if you have such a menu
[17:08] <\sh> gwenhyfar47?
[17:08] <siretart> yes, that's the new one
[17:09] <siretart> it is linked against gnutls instead of libssl, which was the point of the excercise
[17:09] <siretart> oh, that late already... :(
[17:09] <\sh> ok...yeah.../me needs to go too :9
[17:09] <\sh> ok..cu later
[17:11] <james_w> siretart: hi, where do the gnucash packages need testing from? Are they in hardy or a PPA?
[17:11] <siretart> james_w: gnucash itself should be up-to-date in hardy, however I don't expect them to work with hbci at all. updated packages are in the gnucash PPA, which desperatly need testing
[17:12] <siretart> see my mail to -motu earlier today
[17:12] <james_w> siretart: ok, thanks.
[17:13] <nxvl> james_w: hi!
[17:13] <james_w> hi nxvl
[17:13] <emgent> nxvl: heya
[17:14] <nxvl> emgent: :D
[17:15] <siretart> james_w: do you use gnucash with hbci?
[17:16] <james_w> ah, nope, I missed the point then? It's not just general testing you need (outside of the normal general testing that's always needed)?
[17:17] <siretart> well, installation and a small startup is also appreciated :)
[17:17] <james_w> I'm sure I can manage that.
[17:18] <siretart> the most interesting point however is if online banking via hbci works. TBH, I haven't met any user of hbci outside germany yet
[17:18] <siretart> so I was curious if english banks offer hbci as well
[17:18] <james_w> no, I just checked and my bank doesn't seem to offer it
[17:18] <james_w> I'll write and complain that I can't test your packages properly because they don't support it
[17:19] <siretart> it's pretty popular in germany, nearly every bank offer it. However, it seems that most desk clerks don't really understand it :/
[17:19] <siretart> yay :)
[17:19]  * siretart hugs james_w 
[17:46] <james_w> siretart: starts fine and the wizard runs ok. It's not terribly obvious now how to set opening balances for accounts in the wizard, I'm sure it used to be better.
[17:59] <milli> any committment for bug 180619 for Hardy?
[17:59] <ubotwo> Launchpad bug 180619 in vnc4 "Xorg module VNC cores on keyboard input" [Undecided,Confirmed] https://launchpad.net/bugs/180619
[17:59] <ScottK> warp10: Congratulations.
[17:59] <milli> I'm guessing no
[18:04] <huats> warp10: congrats
[18:10] <sebner> warp10: just saw the mail. congratulations :D
[18:10] <sebner> ScottK: did you notice my monodevelop FFe merge?
[18:11] <cody-somerville> warp10, congratsz :) You're the 112th member! :D
[18:11] <jpatrick> cody-somerville: who was the 111?
[18:11] <jpatrick> warp10: congrats!
[18:11] <sebner> jpatrick: cody-somerville himself ;)
[18:11] <ScottK> sebner: I saw it, but didn't have time to look at it.
[18:11] <jpatrick> sebner: ;)
[18:11] <sebner> ScottK: k. np
[18:12] <ScottK> sebner: I'm not the one you really want looking at Mono stuff anyway.  For me it's more of a feature if it's not working.
[18:13] <sebner> ScottK: hrhr. but it's working so *I* want it in hardy :P really np. I'll find someone else
[18:15] <sebner> cody-somerville: btw, why 112th member? LP shows 85 active and 25 inactive. So he is number 111th
[18:16] <cody-somerville> I was going by ubuntu-dev
[18:16] <cody-somerville> but it appears it is at 111 anyhow
[18:16] <cody-somerville> Someone must have deactivated
[18:17] <sebner> k
[18:28] <warp10> ScottK, huats, sebner, cody-somerville, jpatrick: thank you very much! :-)
[18:28] <pochu> warp10: congratulations!
[18:29] <warp10> hey pochu, thank you :)
[18:40] <mok0> If there are MOTUs online with time to spare, please take a look at at bug 188086 and bug188093 . I'd really like to get them out of the way. Thanks!
[18:40] <ubotwo> Launchpad bug 188086 in xtide "[needs-merge] xtide-2.9.5-2 from sid" [Wishlist,In progress] https://launchpad.net/bugs/188086
[18:40] <pochu> bug 188093
[18:40] <ubotwo> Launchpad bug 188093 in xtide-data "[needs-sync] xtide-data-20070318-1 from sid" [Wishlist,In progress] https://launchpad.net/bugs/188093
[19:32] <txwikinger> where can I see the packages again that have been dropped?
[19:35] <geser> txwikinger: you mean removed from the archive?
[19:35] <txwikinger> geser: yes
[19:35] <geser> http://people.ubuntu.com/~ubuntu-archive/removals.txt
[19:36] <txwikinger> thanks geser
[20:21] <ScottK> warp10: Don't forget to go back and upload anything you had in the sponsor's queue.
[20:21] <pochu> and everything else :)
[20:22] <ScottK> pochu: That's your job.  Thanks for bringing it up.
[20:30] <mok0> pocho, did you get a chance to look at the xtide bugs?
[20:31] <mok0> s/pocho/pochu
[20:31] <pochu> I didn't look at them
[20:31] <mok0> ok
[20:32] <mok0> pochu: I'll poke one of the guys who've been involved earlier...
[20:33] <pochu> if they are trivial I can look at them, but if they are not I prefer not to, as I have other things to do
[20:34] <mok0> pochu: they are pretty trivial
[20:34] <mok0> pochu: the main thing is that both get uploaded
[20:36] <pochu> mok0: doesn't bug 188086 need a FFe ?
[20:37] <mok0> pochu: no, because it fixes a bug
[20:37] <mok0> pochu: no new features
[20:37] <pochu> ah, ok
[20:38] <mok0> ScottK: are you here?
[20:39] <mok0> pochu: I dunno... you think I need to get an ack?
[20:39] <pochu> mok0: I haven't looked at the upstream changelog yet
[20:39] <pochu> I'm reading the bug and the debdiff right now
[20:39] <\sh> mok0: building octave
[20:40] <mok0> \sh: ... and that will go on for a while...
[20:41] <\sh> mok0: well, don't care...I had to recreate my whole dapper-hardy schroot lvm devices..
[20:42] <mok0> \sh: yikes. What happened?
[20:42] <\sh> mok0: see #ubuntu-devel
[20:43] <\sh> mok0: i didn't do an fsck of the ext3 fs on those..and now there were some lvm devices missing because of corrupted superblock
[20:43] <\sh> mok0: i fixed it now with recreating, and forcing mk-sbuild-lv to use xfs instead of crappy ext3
[20:43] <mok0> \sh: I've had that happen to me, but I never found out what happened
[20:44] <mok0> \sh: fsck hosed it
[20:44] <jdong> \sh: wait you're trusting xfs_repair over e2fsck?
[20:45] <\sh> jdong: no...I'm not trusting any tool which tells me to fix an corrupted fs :)
[20:45] <jdong> don't get me wrong, I love XFS and I use it, but "easy to repair" and "resistant to corruption" are NOT on the top of its feature lists :)
[20:45] <\sh> jdong: well, tbh i never had a failed xfs fs in my life...
[20:45] <\sh> jdong: but many ext2 and ext3 and reiserfs brokeness
[20:46] <\sh> (well, reiserfs is now in jail ;))
[20:46] <\sh> mok0: http://paste.ubuntu.com/6286/ and my device list grows
[20:46] <mok0> only version 4 :-)
[20:46] <jdong> \sh: well I'm gonna pop your bubble and say that I've had plenty of XFS failures, and not related to the 2.6.17 infamy either
[20:46] <warp10> ScottK: sure! I'm just waiting to be added into the team on launchpad.
[20:46]  * ScottK kicks nixternal
[20:47] <warp10> :)
[20:47] <\sh> jdong: well, i had my problems during upgrade from 2.6.12 to 2.6.14...where vanilla upstream changed the eit/gpt stuff and broke all >2TB devices we had :(
[20:47] <\sh> jdong: but I had never a problem with xfs...strange :(
[20:47] <jdong> \sh: ouch. My problems have usually been serious filesystem corruption, often beyond xfs_repair's abilities to resurrect, after a string of improper shutdowns
[20:47] <mok0> warp10: congrats with being  MOTUed
[20:48] <warp10> thank you mok0 :)
[20:48] <jdong> \sh: of course I'm using run-of-the-mill consumer-grade hard drives and one could easily place the blame on hardware....
[20:48]  * ScottK kicks mok0
[20:48] <mok0> *ouch*
[20:48] <jdong> but overall I've found EXT3 more resilient, though still not anywhere near perfect, to this
[20:50] <\sh> jdong: well, using XFS as main fs (only /boot is ext2) on my desktops and servers I'm quiet ok with it..no problems so far...server side as well...but the server half-life time is around 8 months and 2 years without rebooting (when they are not on the public front of the network)
[20:51] <jdong> \sh: awesome. I always find myself coming back to XFS for its consistent performance over long periods of time and superior backup/restore tools
[20:51] <jdong> my primary system is currently XFS 100%
[20:51] <jdong> but I do have to say that I've experienced massive XFS corruption on more than one occasion linked to bad powerdowns
[20:52] <\sh> jdong: and you should try to use ext3 on 6TB volumes...it's a shame that you have to wait at least 6-10 mins or more (depending on the raid controller) to succeed with the creation of the FS
[20:52] <jdong> just so that you're aware it's not bulletproof
[20:52] <jdong> \sh: oh no kidding, I wouldn't suggest using ext3 on that kind of setup
[20:52] <\sh> jdong: well, software is never bulletproof
[20:52] <jdong> ain't that the truth :)
[20:53] <\sh> bah...should I package wireshark 1.0 or do we get it for free from debian?
[21:07] <nixternal> warp10: Andrea Colangelo (warp10) has been added as a member of this team.
[21:07] <nixternal> sorry, it was the one thing I forgot to do :)
[21:09] <warp10> nixternal: :D Thank you!
[21:09] <nixternal> congrats and welcome!
[21:10] <warp10> nixternal: :) thank you! My pleasure to be member of the family
[21:11] <sebner> warp10: remember to join u-u-s ;)
[21:15] <\sh> warp10: btw...congrats :)
[21:17] <Scientus> any/j vmware
[21:18] <Matthias_M> Hi, just wanted to say that I uploaded gnocky_0.0.5-1_i386.deb using dput both to upload.ubuntu.com and revu.tauware.de see also https://bugs.launchpad.net/ubuntu/+bug/209236 this is my first package
[21:19] <crimsun> err
[21:20] <\sh> lol?
[21:21] <\sh> Matthias_M: I think you just got something wrong...
[21:21] <warp10> sebner: for sure! :)
[21:21] <warp10> \sh: thank you :)
[21:21] <\sh> Matthias_M: as you are not core nor universe member you can't upload to upload.ubuntu.com
[21:22] <Matthias_M> dput without parameters uploads to upload.ubuntu.com by default, but it is already rejected (got a mail a second ago)
[21:22] <sebner> warp10: great :D
[21:22] <sebner> Matthias_M: you shouldn't upload the *.deb ;)
[21:22] <\sh> Matthias_M: yes, that's why the documentation tells us, to use the revu part :)
[21:23] <Matthias_M> everything around the .deb is also uploaded
[21:23] <sebner> Matthias_M: dput revu package_version_source.changes
[21:23] <sebner> Matthias_M: https://wiki.ubuntu.com/MOTU/Packages/REVU
[21:23] <Matthias_M> done
[21:23]  * ScottK changed his dput.cf to upload to a place called bob after the first time he uploaded to u.u.c instead of his PPA by accident.
[21:23] <Matthias_M> but I can't login at http://revu.tauware.de/ and I don't see my uploaded package
[21:24] <\sh> Matthias_M: the .deb is not necessary .. we don't care about binary packages, just the .dsc,.diff.gz,.orig.tar.gz is important :)
[21:24] <\sh> ScottK: lol...in the old, dark days of motu, where we didn't have the "ubuntu" upload area as default, I uploaded every now and then to debian :)
[21:25] <Matthias_M> I just did dput revu '/home/matthias/.debcreator/gnocky/gnocky_0.0.5-1_i386.changes' and I think the program took care of that (dsc, tar.gz, diff.gz, deb, changes are uploaded)
[21:26] <Matthias_M> but it still says no REVU account exists and does not show my package
[21:26] <\sh> Matthias_M: you don't use the binary changes file..use the _source.changes file :)
[21:26] <\sh> Matthias_M: did you attach your public gpg key to your LP account? did you ask for a sync of the revu keyring to include your key
[21:27] <Matthias_M> I uploaded my GPG to LP yesterday, it says there is a 24h auto-sync.
[21:30] <james_w> I think it may be down at the moment, I'm not sure
[21:31] <Matthias_M> I reuploaded the sources version this time: gnocky_0.0.5-1_source.changes
[21:31] <\sh> mok0: I'm uploading the stuff after the build (eventually tomorrow morning...I'm going to bed now)
[21:31] <mok0> \sh: great, thanks
[21:49] <RainCT> Matthias_M: was your package on REVU accepted?
[21:51] <Matthias_M> I don't know, dput says it's okay, but I did not get an email.
[21:52] <RainCT> Matthias_M: At the moment REVU sends no emails (beside one to a mailing list). Can you see your package on http://revu.tauware.de?
[21:54] <Matthias_M> I don't see my package (gnocky 0.0.5) there and there is no message at http://lists.tauware.de/pipermail/motu-reviewers/2008-March/thread.html
[21:55] <Matthias_M> Besides, I also uploaded my package to http://mentors.debian.net/cgi-bin/welcome as Ubuntu is currently in feature freeze, you might cancel my request at REVU.
[21:57] <RainCT> Matthias_M: OK, then it was rejected. Although it says so, keys aren't synced automatically.
[22:00] <Matthias_M> hmm.. menthors.debian.net also does not reply to me via eMail
[22:00] <bddebian> Matthias_M: It has been down.  They are working on it
[22:00] <Matthias_M> ok, then I'll try again tomorrow. good night
[22:03] <blueyed_> warp10: congrats!
[22:13] <warp10> thank you blueyed :)
[22:13] <RainCT> good night
[23:14] <m-c> greetings masters of the universe!  would someone please glance at this bug, which appears to be related to packaging?  I believe the program's author attached at fix, too.
[23:14] <m-c> https://bugs.launchpad.net/ubuntu/+source/mumble/+bug/202672
[23:14] <ubotwo> Launchpad bug 202672 in mumble "installing mumble-server requires dbus" [Undecided,Confirmed]
[23:14] <m-c> slicer: this is yours
[23:15] <m-c> slicer: this is your application, I mean
[23:40] <emgent> hi dendrobates :)
[23:40] <dendrobates> hi emgent
[23:41] <dendrobates> you finally found me with a minute to spare  :)
[23:41] <emgent> ehehehe cool :)