[12:04] <hub_> lifeless: in dapper or still on revu?
[12:04] <lifeless> neither
[12:04] <hub_> ah
[12:04] <hub_> where?
[12:04] <lifeless> I have the package as source on people.ubuntu.com
[12:04] <lifeless> http://people.ubuntu.com/~robertc/
[12:04] <lifeless> opensync/upstream is a bzr branch of the upstream [effectively the upstream tarball] 
[12:05] <lifeless> theres also a debian patched version and the debian control dir
[12:05] <hub_> what about upload to universe?
[12:05] <lifeless> its not quite ready.
[12:05] <lifeless> I'll upload it to sid next weekend I think
[12:05] <hub_> okay
[12:05] <lifeless> I can't upload to universe, I'm not a MOTU
[12:06] <hub_> well if it is in Debian it will make its way :-)
[12:06] <hub_> I'll just apt-get source it :-)
[12:06] <hub_> I thought about packaging it, but I got stuck in various other things
[12:06] <hub_> unrelated
[12:07] <dholbach> damn, now i did a secret key combo and my kvm switch worked, i need to find out which one it was
[12:08] <lifeless> hub_: so me, ajmitch and azeem are teaming up to package the lot
[12:08] <lifeless> if you have spare cycles, the more the merrier
[12:08] <hub_> dholbach: on mine it is "scroll lock" twice and a number (not on the keypad)
[12:08] <hub_> lifeless: spare cycle? not currently
[12:09] <hub_> lifeless: but I'll see what I can do
[12:09] <hub_> and half borked latpop does not help
[12:12] <hub_> dholbach: I'd say RTFM
[12:12] <hub_> :-)
[12:12] <dholbach> hub_: i did - it just not seems to behave the way the manual says
[12:13] <dholbach> but it robust... i think it'll work fine with stepping-on-it--treatment
[12:13] <lfittl> bmonty: Could you review http://revu.tauware.de/details.py?upid=1127 again?
[12:13] <bmonty> lfittl: sure
[12:23] <bmonty> sistpoty: can you mark filelight as fixed on the REVU2 page?
[12:23] <dholbach> good night guys, i'm off to bed
[12:23] <bmonty> bye dholbach
[12:24] <lfittl> gn8 dholbach
[12:24] <dholbach> *wave*
[12:24] <sistpoty> gn8 dholbach
[12:24] <dholbach> and somebody review seveas' package :)
[12:24] <dholbach> *wave*
[12:25] <Seveas> yeah, somebody review my package :)
[12:25] <sistpoty> bmonty: done
[12:25] <bmonty> sistpoty: thanks
[12:25] <sistpoty> np
[12:44] <LaserJock_> could I get a couple of MOTUs to review plotdrop? It will be quick and painless, I promise
[12:46] <raphink> some of my packages on REVU have also been advocated once already and just need a check
[12:46] <raphink> wb ajmitch
[12:46] <sistpoty> I'm off to bed now...
[12:46] <raphink> ajmitch: would you have some time to review packages?
[12:46] <sistpoty> good night everyone
[12:47] <raphink> night sistpoty
[12:48] <ajmitch> raphink: maybe
[12:49] <raphink> :)
[12:49] <raphink> ajmitch: there's a large choice on REVU :) easiest ones might be the ones that have already been advocated :)
[12:49] <raphink> (not very sure)
[12:49] <lfittl> ajmitch: Do you have some time to review http://revu.tauware.de/details.py?upid=1127 again? (I just need that one to know how to do library packaging correctly)
[12:50] <raphink> I'll review it lfittl if you want
[12:50] <lfittl> raphink: that would be nice :)
[12:50] <raphink> so ajmitch can review my packages
[12:50] <raphink> unless you can review them :)
[12:51] <lfittl> I am no reviewer (yet) ;)
[12:51] <ajmitch> since usually I'd just do it sometime when I'm at home :)
[12:52] <raphink> lfittl: do you know about debian/*.install files ?
[12:52] <lfittl> raphink: sure, but like putting things in debian/rules if possible ;)
[12:52] <raphink> ok
[12:53] <raphink> it's just that I think using debian/*.install is easier for libs
[12:53] <raphink> for many things, but esp. for libs ;)
[12:53] <raphink> as you generate different files for different packages
[12:53] <raphink> but I understand if you don't like to use them :)
[12:53] <lfittl> good :)
[12:54] <raphink> dh_install src/libcafix.so.0.1.1 /usr/lib <-- you don't build the lib?
[12:55] <raphink> I might be wrong, but I think debhelper+cdbs usually builds the libs in debian/tmp/
[12:55] <lfittl> bad upstream makefile that puts the built lib in src/ ;)
[12:55] <raphink> not in src/
[12:55] <raphink> oh ok
[12:56] <raphink> that's a bit surprising but as long as it has an explanation ;)
[12:56] <raphink> did you report this to upstream?
[12:56] <lfittl> it seems upstream is almost dead
[12:56] <raphink> oh :(
[12:57] <lfittl> last release was 3 years ago ;)
[12:57] <raphink> ouch
[12:57] <raphink> hopefully releasing the package in Ubuntu might get people to work on it
[12:57] <raphink> never know
[12:57] <lfittl> maybe :)
[12:57] <ajmitch> yes, putting anything straight into /usr in packaging is a recipe for disaster
[12:58] <raphink> what do you mean ajmitch ?
[12:58] <raphink> what is put straight in /usr?
[12:59] <ajmitch> just saying that if you did it that way
[12:59] <ajmitch> dh_install should prepend the appropriate directory
[12:59] <ajmitch> iirc
[01:00] <raphink> ajmitch: I just meant that the source is usually built in debian/tmp
[01:00] <raphink> so that the lib is found in debian/tmp/usr/lib
[01:00] <raphink> but in that case it's built in src/
[01:01] <ajmitch> no, the source is built in place
[01:01] <ajmitch> and installed into debian/tmp using the DESTDIR argument
[01:01] <ajmitch> which this makefile happily ignores
[01:01] <raphink> which is usually automatic, using debhelper+cdbs, no?
[01:01] <ajmitch> mkdir -p /usr/lib
[01:01] <ajmitch> /usr/bin/install -c -m 644 include/cafix.h /usr/include/
[01:01] <ajmitch> /usr/bin/install -c -m 644 src/libcafix.a /usr/lib
[01:01] <ajmitch> /usr/bin/install -c -m 755 src/libcafix.so.0.1.1 /usr/lib/
[01:01] <raphink> ok
[01:01] <ajmitch> that looks to really not be healthy
[01:02] <raphink> ic
[01:02] <ajmitch> since it's installing files outside of the packaging
[01:03] <ajmitch> potentially overwriting the files installed on the system, etc
[01:03] <ajmitch> and generally messing things up
[01:03] <lfittl> ajmitch: should I patch the Makefile?
[01:03] <lfittl> or just disable the autotools install target
[01:04] <ajmitch> certainly patch the makefile
[01:04] <lfittl> anything else you found? :)
[01:06] <lfittl> k, I will patch the makefile tomorrow, just need to get some sleep now..
[01:06] <ajmitch> I think I need to write a check for packages touching files outside the build area
[01:06] <lfittl> good idea :)
[01:06] <ajmitch> and throw up big red warnings
[01:06] <lfittl> gn8 everybody
[01:06] <ajmitch> night
[01:07] <ajmitch> maybe take a manifest of files in the chroot after dependencies are installed..
[01:07] <ajmitch> and then check the list once the package is built..
[01:15] <seth_k|lappy> ajmitch, I think https://launchpad.net/bugs/5577 is FINALLY ready :P I sure need to get faster / better at those.
[01:15] <Ubugtu> Malone bug #5577: noteedit: merge new debian version In: noteedit (Ubuntu), Severity: Normal, Assigned to: MOTU Merge Team, Status: PendingUpload https://launchpad.net/bugs/5577
[01:34] <whiprush> ajmitch: did someone take logs of the MOTU-school thing?
[01:39] <ajmitch> whiprush: yes
[01:39] <ajmitch> http://netz.smurf.noris.de/logs/freenode/
[01:39] <whiprush> thanks.
[01:40] <ajmitch> whiprush: http://netz.smurf.noris.de/logs/freenode/2005/12/10/%23ubuntu-motu-school.log to be more precise
[01:40] <whiprush> found it
[01:40] <whiprush> thanks much
[01:41] <whiprush> how was the turnout?
[01:41] <ajmitch> and then you can read up on my incoherent caffeine-deprived ramblings
[01:41] <whiprush> reading now
[01:41] <whiprush> heh
[01:41] <ajmitch> 6am *pain*
[01:41] <whiprush> heh
[01:42] <Kyral> Welcome to mine. 8 AM Final Exam tomorrow
[01:42] <ajmitch> considering that I went to bed at about 2:30, I did well I think
[01:42] <Kyral> lol
[01:42] <Kyral> indeed
[01:43] <Kyral> oh, the only reason I'm pushing EasyChem right now is because I was handed the World file from the COSI Lab Build and told that if I can find all of them in Ubuntu, then next semester we will put Ubuntu as the lab build
[01:43] <Kyral> and EasyChem is on the list lol
[01:44] <ajmitch> does it work without crashing all over the place?
[01:44] <Kyral> Yup
[01:44] <Kyral> I corrected all the problems slomo_ noted
[01:45] <raphink> grrr
[01:46] <raphink> they'll have to hire policemen who can at least read...
[01:46] <ajmitch> Kyral: are there actually examples to install?
[01:47] <Kyral> ajmitch: You mean .debs?
[01:47] <ajmitch> no
[01:47] <ajmitch> examples
[01:47] <Kyral> I don't think I follow
[01:47] <ajmitch> you use dh_installexamples
[01:47] <Kyral> I do?
[01:48] <ajmitch> yep
[01:48] <Kyral> hmm so I do lol
[01:48] <ajmitch> and I don't know if anything gets into /usr/share/doc/easychem/examples
[01:48] <Kyral> I didn't notice that
[01:48] <ajmitch> let me do a test build on tiber
[01:48] <Kyral> Yah I was about to mention that
[01:49] <Kyral> I'll remove those and reupload, or do you wanna do the test first?
[01:49] <ajmitch> running a test build now
[01:49] <ajmitch> apart from that it looks ok
[01:49] <raphink> bye
[01:49] <ajmitch> but this is a 2 minute look ;)
[01:49] <Kyral> lol
[01:50] <ajmitch> does the makefile actually have an install target?
[01:51] <Kyral> in the orig source, no. But I patch one in and the patch is in debian/patches
[01:51] <ajmitch> ah right
[01:51] <Kyral> This was the reason for the first MOTU-School lol
[01:52] <ajmitch> yeah, not terribly tidy, having a prefix with /usr/bin
[01:53] <ajmitch> just because PREFIX is meant to be used for other files apart from the executable
[01:53] <Kyral> isn't that where it is supposed to go?
[01:54] <ajmitch> sure
[01:54] <ajmitch> but you'd usually set PREFIX=/usr
[01:54] <Kyral> oh
[01:54] <ajmitch> and install into ${DESTDIR}/${PREFIX}/bin
[01:55] <Kyral> ah
[01:55] <ajmitch> ( not {, iirc
[01:55] <ajmitch> but I guess it's alright as it is, just not optimal :)
[01:56] <ajmitch> how useful is it to install a TODO in french? ;)
[01:56] <Kyral> the upstream author is french ;P
[01:56] <ajmitch> I know, but you mentioned TODO in debian/docs
[01:56] <Kyral> and I don't know enough french to even TRY to translate it
[01:57] <ajmitch> it's fairly readable
[01:57] <ajmitch> but I'm not sure of its value
[01:57] <ajmitch> I suppose you can keep it :)
[01:58] <Kyral> I could register it on LP (after talking with upstream) and use Rosetta :D
[01:59] <bmonty> can someone help with figuring out why this build fails?  http://www.montynet.org/ubuntu/kshutdown-buildlog.txt
[02:00] <bmonty> supposedly this builds on debian, but even the debian package fails in the same way
[02:00] <Kyral> blame \sh or whoever taught the first MOTUSchool lol. Its the only patch method I know
[02:00] <ajmitch> bmonty: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342879
[02:01] <ajmitch> make & cdbs have decided to have a disagreement
[02:01] <ajmitch> Kyral: it's adequate for simple tasks
[02:02] <Kyral> I smell another MOTUSchool ;P
[02:02] <bmonty> ajmitch: looking...
[02:02] <ajmitch> Kyral: I think we were going to do a followup to talk about a better system (stamp per patch, using --dry-run first)
[02:03] <bmonty> ajmitch: ok, so this is a cdbs bug with no fix yet?
[02:04] <ajmitch> yep
[02:04] <ajmitch> only fix so far is downgrade make
[02:05] <bmonty> I guess this merge will wait until it gets fixed then :(
[02:05] <ajmitch> sorry
[02:05] <ajmitch> it affects a lot ofpackages
[02:05] <bmonty> yeah, so the fix shouldn't be long in coming :)
[02:06] <Kyral> So whats the verdict mitch lol
[02:07] <ajmitch> Kyral: I'd give it at least 4 out of 10 ;)
[02:08] <ajmitch> I like to check that a program runs before I give it a tick
[02:08] <Kyral> It runs on Dapper lol. I know because I tested it before I uploaded
[02:08] <ajmitch> s/runs/runs on my box/ :)
[02:08] <Kyral> lol
[02:15] <bmonty> doko: ping
[02:18] <seth_k|lappy> Kyral, french? I can translate it for you, I speak French
[02:19] <doko> bmonty: pong
[02:19] <bmonty> doko: I have a question on the gcc-snapshot package, it is on the merge list
[02:19] <Kyral> seth_k|lappy: lol shall we get it to Universe first? Then you can just do a NMU on it
[02:19] <seth_k|lappy> Kyral, alright
[02:20] <bmonty> doko: do you sync that package when debian updates it?
[02:21] <bmonty> or I should say, when you update it in debian :)
[02:22] <doko> bmonty: no, that won't work. what you should do: unpack it, run "debian/rules control", then package it as -ubuntu1, then upload
[02:22] <bmonty> doko: ok
[02:23] <bmonty> doko: out of curiosity, how come it can't be a sync?
[02:25] <Kyral> hmm, how do I figure out what bootservices are going off lol
[02:26] <doko> bmonty: differing build dependencies
[02:59] <Kyral> hmm, I don't need mdadm if I don't use RAID right?
[03:03] <Kyral> Okay here goes nothing
[03:12] <Kyral> I really wish that fsck.reiserfs didn't run at EVERY boot
[03:56] <bmonty> hey LaserJock
[03:56] <LaserJock> hi bmonty
[03:57] <LaserJock> bmonty: how's the little guy?
[03:57] <bmonty> LaserJock: lots of fun, he is starting to recognize me and smile
[03:58] <bmonty> almost 2 months old!
[03:58] <LaserJock> cool
[04:06] <bmonty> LaserJock: you want to see some pics of him?
[04:07] <LaserJock> bmonty: sure, love to
[04:18] <LaserJock> bmonty: are you up for a REVU review?
[04:18] <bmonty> LaserJock: not really, I'm finishing up a merge and then I'm probably going to bed, sorry
[04:18] <LaserJock> bmonty: np
[04:22] <ajmitch> hi bmonty, LaserJock
[04:22] <bmonty> hey ajmitch
[04:22] <LaserJock> hi ajmitch
[04:24] <ajmitch> LaserJock: what's the package?
[04:24] <LaserJock> plotdrop
[04:25] <ajmitch> just uploaded?
[04:26] <ajmitch> ah no, I see it
[04:31] <ajmitch> hm, interesting pbuilder output
[04:32] <LaserJock> really?
[04:32] <ajmitch> you were asking about why -stamp rules were used?
[04:32] <nmsa> hello, good morning
[04:33] <LaserJock> yeah
[04:34] <bmonty> hi nmsa
[04:34] <nmsa> I would like to contribute and maintain a package in ubuntu, just that I'm to new in this domain, I would like something simple @ the begining, maybe help someone at start, can I have some directions pls
[04:34] <ajmitch> I saw patch being called twice, i think :)
[04:35] <ajmitch> LaserJock: want to gently introduce nmsa to the wonderful world of MOTU for me? :)
[04:36] <LaserJock> ajmitch: only if you help me with -stamps later ;-)
[04:36] <ajmitch> sure..
[04:36] <LaserJock> nmsa: could you join #ubuntu-motu-school ?
[04:37] <nmsa> I'm on since ajmitch made the presentation
[04:40] <LaserJock> ajmitch: did you see anything else besides the -stamp thing or did you not get past that?
[04:41] <ajmitch> LaserJock: sorry, a little busy :)
[04:41] <ajmitch> overall it looked ok, nothing obvious jumped out at me
[04:44] <ajmitch> bmonty: cdbs breakage affects most of the gnome packages & kde, so I think we'll get a fix real soon
[04:44] <bmonty> yeah, I've been working on merges and without trying I've already run into three
[04:45] <minghua> the bug about make breaking CDBS?
[04:46] <ajmitch> minghua: yep
[04:48] <ajmitch> I didn't really need told that there's a new f-spot release by someone filing a bug
[04:48] <bmonty> is there a way that I can request that a buildd try to build a package?
[04:48] <ajmitch> yes
[04:49] <bmonty> ajmitch: mark it wont-fix
[04:49] <ajmitch> you bug lamont or infinity :)
[04:49] <ajmitch> hah
[04:49] <ajmitch> no, I mark it pending
[04:50] <bmonty> lamont: ping
[04:55] <LaserJock> ajmitch: does http://paste.ubuntu-nl.org/5642 look better?
[04:56] <bmonty> so if I register a project on launchpad for my python app do you like ubuntu-spy or ump (for ubuntu mirror profiler) or something else?
[04:58] <ajmitch> LaserJock: at a glance, I think it's better
[04:59] <LaserJock> bmonty: how about Super Wicked Fast Ubuntu Mirror Finder (swfumf) ?
[05:00] <bmonty> too hard to type :)
[05:00] <LaserJock> oh well, I'm no good with names
[05:02] <bmonty> the debian prog is called apt-spy, but I think ubuntu-spy implies that canonical is pulling a big brother :)
[05:02] <ajmitch> you mean they're not?
[05:03] <ajmitch> oh darn, I was hoping they would... ;)
[05:03] <ajmitch> since I'm sure that mark cares *lots* about reading everyone's email ;)
[05:03] <bmonty> yeah I'm sure he does
[05:05] <bmonty> slashdot quote: "I for one welcome our canonical overlords"
[05:07] <ajmitch> ok, bbiab
[05:09] <LaserJock> bmonty: thanks for the support, I just hope to live up to the MOTU
[05:09] <bmonty> :)
[05:12] <bmonty> goodnight everyone
[05:20] <LaserJock> ajmitch: ok, I uploaded a new -stampified version ;-)
[05:23] <ajmitch> ooh, vrms merge
[05:23] <StevenK> Yup.
[05:23] <StevenK> vrms 1.11 can be synced
[05:23] <ajmitch> make sure it works with restricted & multiverse, otherwise you might get critical bugs filed ;)
[05:23] <ajmitch> see 3704
[05:27] <StevenK> root@broken:/# dpkg -l vrms | tail -n 1
[05:27] <StevenK> ii  vrms           1.11           virtual Richard M. Stallman
[05:27] <StevenK> root@broken:/# vrms Non-free packages installed on broken
[05:27] <StevenK> abs-guide                 The Advanced Bash-Scripting Guide
[05:27] <StevenK> That do you?
[05:27] <StevenK> I read the source and the patch, and they both looked fine, but I thought I'd humour you.
[05:28] <ajmitch> sure
[05:28] <ajmitch> I just found it funny that someone would file a critical bug on vrms
[05:28] <StevenK> Yeah
[05:28] <StevenK> ajmitch: Request a sync, since you cared enough to point out the bug? :-)
[05:29] <ajmitch> since it didn't pick up the 'immoral' software
[05:30] <StevenK> ajmitch: Ta
[05:30] <ajmitch> no idea why we got 1.10-0ubuntu1
[05:31] <ajmitch> it shoul have at least been 1.10ubuntu1
[05:31] <StevenK> Martin Meredith is the person to ask.
[05:32] <ajmitch> he hasn't been around irc much lately
[05:32] <ajmitch> I've hardly seen him since ubz
[08:56] <sivang_away> morning all
[08:58] <crimsun> 'morning sivang
[08:59] <sivang_away> hey crimsun
[08:59] <sivang_away> crimsun: you have any idea what this is about:
[09:00] <sivang_away> 07:57 [freenode]  -!- sivang #launchpad Cannot send to channel so cannot change nicks
[09:00] <sivang_away> I've never had that before.
[09:00] <crimsun> sivang_away: ah, that's probably due to the mess freenode was in this weekend. Try reconnecting.
[09:00] <sivang_away> I see, ok, thanks/
[09:01] <sivang> crimsun: ok, seems that helped :)
[09:01] <crimsun> :)
[09:39] <siretart> morning
[09:40] <crimsun> 'morning siretart
[09:52] <dholbach> good morning motus
[09:52] <crimsun> re dholbach
[09:52] <dholbach> hey crimsun, koke :)
[09:53] <jsgotangco> good morning o great one dholbach
[09:53] <dholbach> haha
[09:53] <koke> hi all!
[09:53] <koke> today is below zero here :)
[09:53] <koke> what a cool morning
[09:53] <jsgotangco> that's nice indeed
[09:54] <minghua> anybody using piuparts?  I wonder if piuparts can use a local directory for apt cache as pbuilder does
[09:54] <ajmitch> hey people
[09:55] <minghua> hi ajmitch
[09:57] <crimsun> 3.80+3.81.b3.3.80-1ubuntu1. wow.
[09:58] <ajmitch> impressive
[09:58] <ajmitch> make?
[09:58] <crimsun> yep
[10:02] <jsgotangco> hello professor ajmitch
[10:03] <ajmitch> :P
[10:03] <sivang> crimsun: it doesn't work too good for some of the pakcages I tried building
[10:10] <crimsun> sivang: yeah, infinity just reverted it, hence the nasty versioning :)
[10:20] <siretart> huhu dholbach
[10:20] <Tonio_> hieveryone
[10:33] <siretart> huhu Tonio_
[10:33] <ajmitch> siretart: I was thinking today - we don't really need to setup a separate chroot system apart from pbuilder
[10:34] <ajmitch> since with hooks & multiple configs we should be able to do what we need
[10:34] <siretart> ajmitch: there was a plan to use sbuild on tiber
[10:34] <siretart> which doesn't work without a chroot
[10:34] <ajmitch> sure, you could use sbuild for building
[10:34] <ajmitch> but pbuilder & piuparts for testing packages
[10:35] <siretart> you right, we could rely on pbuilder and piuparts in the beginning
[10:35] <siretart> and add another sbuild 'test' later
[10:35] <ajmitch> right
[10:36] <ajmitch> we want to write as little as possible to start with :)
[10:36] <siretart> okay
[12:51] <siretart> SloMoSnail: ping
[01:13] <raphink> hi siretart
[01:19] <raphink> is it ok to package a program from binary and include the source in the package ?
[01:19] <raphink> :s
[01:27] <siretart> raphink: err, sounds strange. why should the user want the source?
[01:27] <siretart> or better, would?
[01:27] <raphink> well I mean
[01:27] <raphink> there's an app I'd like to package
[01:28] <raphink> but there's no Makefile in it
[01:28] <raphink> instead
[01:28] <raphink> the binary is provided with a install.sh script and the source tarball
[01:28] <raphink> that contains no Makefile as I said
[01:28] <raphink> i don't know how to create Makefiles from scratch
[01:28] <siretart> ah, so your upstream consists of several files, right?
[01:29] <azeem> raphink: looks like a great opportunity to learn about Makefiles
[01:29] <azeem> raphink: automake is pretty easy to learn, apt-get install autobook
[01:29] <raphink> my upstream consists of a tarball that contains the bin, an install script and the source tarball with no Makefil
[01:29] <raphink> ok
[01:29] <raphink> I tried to open the dir as an existing project in Kdevelop
[01:30] <raphink> but it doesn't build
[01:31] <azeem> those hardcore, bare-bone projects probably don't play well with a graphical IDE
[01:31] <lathiat> dont necesarily need to use make files to build
[01:31] <lathiat> how is it normally built?
[01:31] <raphink> azeem: it's a pretty advanced project, provided by my ISP
[01:31] <raphink> it's in cpp with qt I believe
[01:32] <azeem> oh
[01:32] <azeem> isn't there a README or something in the source tree?
[01:32] <raphink> it doesn't say how to build
[01:33] <raphink> well I believe it might depend on other libs
[01:33] <raphink> but I don't know which ones
[01:33] <raphink> I have to look in the files ;)
[01:33] <lathiat> pbuilder is good for that
[01:33] <raphink> for what?
[01:34] <lathiat> making sure you get all the deps
[01:34] <lathiat> it builds inside a clean install
[01:34] <lathiat> and just installs the deps you specify in build-depends
[01:34] <raphink> sure I know that
[01:35] <lathiat> just some fun trial and error and off you go
[01:35] <lathiat> :)
[01:35] <raphink> my problem is to know what the deps are so far lathiat ;)
[01:51] <lathiat> tseng: how goes the RoR hacking?
[01:53] <tseng> lathiat: http://headrush.typepad.com/creating_passionate_users/2005/12/have_you_update.html
[01:54] <lathiat> heh
[03:10] <zakame> evening all! :D
[03:13] <sivang> evening zakame
[03:13] <zakame> hi sivang , mhz ! :-)
[03:14] <mhz> hey zakame
[03:30] <zakame> heya \sh :-)
[03:34] <raphink> keydevelop3 can't be used to build apps with qt4 ?
[03:36] <Amaranth> probably not
[03:45] <\sh> moins
[04:03] <eth42> is MOTU also MOTM or is multiverse covered somewhere else?
[04:05] <zakame> eth42: the launchpad group ubuntu-dev covers both universe and multiverse
[04:07] <eth42> zakame: erm, what's exactly is a launchpad group?
[04:07] <tseng> a group of people on launchpad.net
[04:07] <zakame> eth42: https://launchpad.net/people/ubuntu-dev/ :-)
[04:07] <eth42> thanks :-)
[04:12] <eth42> I noticed that the faac package comes without mp4 support (I suppose it was simply not activated when it was compiled). Is there any reason for this?
[04:12] <tseng> youd have to ask SloMoSnail (slomo) another day
[04:12] <tseng> i dont think he is here
[04:12] <eth42> tseng: ok
[04:14] <siretart> eth42: you may want to check the buildlogs
[04:15] <eth42> siretart: how do I do that? (sorry for being ignorant on this but I have no experience with deb but only rpm)
[04:15] <siretart> eth42: http://people.ubuntu.com/~lamont/buildLogs/f/faac/
[04:15] <eth42> thanks :-)
[04:15] <siretart> no problem, where are here to help
[04:16] <siretart> was just searching for the correct buildlog
[04:18] <siretart> eth42: please help me to remember, what lib/software is needed for mp4 support?
[04:18] <eth42> well, according to the buildlog it seems to be mp4v2 which is missing
[04:20] <eth42> siretart: at least this is my understanding of the line checking for MP4MetadataDelete in -lmp4v2... no
[04:21] <siretart> eth42: hm. you should really talk to sebastian (slomo). he did a lot of work on the package
[04:28] <eth42> is there an easy way to just recompile the package? (since I have the library installed from source)
[04:28] <eth42> I tried "apt-get source faac --compile" but that failed since the source package could not be found.
[04:28] <Hieronymus> eth42: apt-get -b source packagename
[04:29] <Hieronymus> hmm, that should be the same. Weird
[04:30] <eth42> hehe
[04:30] <eth42> :-)
[04:30] <ogra> you need multiverse deb-src in your sources.list
[04:30] <Hieronymus> eth42: if you apt-cache search faad or apt-cache info faad, you'll see no package
[04:31] <eth42> I can't find a source repository for multiverse in synaptic. what am i missing? mhh
[04:32] <zakame> eth42: err deb-src on multiverse?
[04:33] <eth42> Hieronymus: apt-cache search faad shows 4 packages, faac 3
[04:36] <eth42> zakame, for some reason there was no deb-src multiverse line in /etc/apt/sources.list only one for universe...
[04:36] <eth42> I simply added multiverse to that line, and it worked
[04:37] <raphink> is it ok to remove lots of unuseful things from a source before packaging it ?
[04:37] <zakame> eth42: good work then
[04:37] <eth42> but I expected that synaptic would offer this choise as well
[04:37] <eth42> thanks!
[04:37] <zakame> raphink: define un-useful :)
[04:38] <raphink> zakame: I'm packaging a program that is used by my ISP to allow users to play their media files on their TV using the modem
[04:38] <raphink> the tarball provided by my ISP includes a tarball of VLC
[04:39] <raphink> at a certain time, this was useful since the hack done to VLC by my ISP was not yet in the VLC trunk
[04:39] <zakame> raphink: ah... could you build that using the already-packaged vlc then?
[04:39] <raphink> but now VLC has merged it so it's stupid to distribute vlc together with it
[04:39] <raphink> sure zakame
[04:39] <raphink> but then I need totally review the package
[04:39] <raphink> I mean
[04:40] <raphink> clean unuseful things
[04:40] <raphink> obsolete
[04:40] <raphink> that would have the package be around 12MB instead of 1
[04:40] <raphink> so I'd need to actually remove two things from the source : the vlc tarball and the source of another app that is now obsolete
[04:40] <ogra> raphink, as long as you dont change the upstream source (orig.tar.gz) everything is allowed here ;)
[04:40] <zakame> raphink: ooh! well, make sure it works before removing
[04:41] <raphink> ogra so I would do that through patches?
[04:41] <raphink> sure zakame
[04:41] <ogra> everything as in policy compliant indeed
[04:41] <raphink> ok
[04:41] <zakame> raphink: err this is a NEW package right?
[04:41] <ogra> raphink, for example ... or through the rules file ...
[04:41] <raphink> that'll still make a very big debdiff
[04:41] <raphink> zakame: yes it's a new package
[04:42] <raphink> ogra : like a series of rm in the build section?
[04:42] <zakame> ogra: but then again, -policy allows a repackaged source, as long there's notice of repackaging :)
[04:42] <ogra> zakame, yes, but that should be a last resort ...
[04:42] <ogra> raphink, for example, yes ...
[04:42] <raphink> from the way the source looks, it might be easier to just take the few required things from it and repackage
[04:43] <ogra> or just omit the building of parts you dont want ...
[04:43] <zakame> raphink: or you can convince your good upstream to drop their pre-packaged vlc ;)
[04:43] <raphink> hmm
[04:43] <raphink> the good upstream is my ISP
[04:43] <raphink> and I don't think they mind so much
[04:44] <zakame> then have them release a new version without the extra stuff
[04:44] <raphink> mhm
[04:45] <raphink> I'll see
[04:46] <jsgotangco> hiya
[04:46] <eth42> I wonder how the faac deb-src could get compiled if it requests a package libmp4-dev for build which I cannot find for any Ubuntu distribution...
[04:46] <zakame> er its libmp4v2-dev
[04:47] <siretart> eth42: if you look in the source package, there is a file called 'debian/control'
[04:47] <siretart> eth42: in that file, there is a line 'Build-Depends'
[04:48] <siretart> eth42: this line holds a list of packages which have to be installed to build that package. the autobuilders will install these packages in prior building the package. that installation process is also shown in the buildlogs I pointed you to
[04:48] <eth42> siretart, yeah I've found such a line in faac_1.24-0.2.dsc
[04:49] <raphink> hmmm : ogra : the vlc tarball provided by my ISP has been modified quite a lot from the original vlc
[04:49] <eth42> siretart: how do I start the build after removing the reference to libmp4-dev?
[04:49] <raphink> there's a 6MB diff
[04:49] <ogra> raphink, oh, its vlc ?
[04:49] <raphink> :s
[04:50] <siretart> eth42: type 'dpkg-buildpackage -us -uc'
[04:50] <eth42> thanks!
[04:50] <siretart> the -us -uc is to supress signing the package
[04:50] <raphink> ogra : yes, my ISP uses VLC for its app. But they provide a modified version of VLC, with 6MB diff, although it works fine with the standard VLC too
[04:50] <ogra> then i'd rather try to get it in the vlc package we have and let it produce a differently named binary
[04:51] <ogra> i.e. vlc-webtv-<providername>
[04:51] <raphink> ogra : well I shall explain better
[04:51] <ogra> note that we have a target for dapper to aviod and remove duplication ... that should be taken into regard for universe as well where possible
[04:52] <raphink> ogra : the current vlc already contains lots of modifs from my ISP, and what is useful in this tarball to have the webtv service work is only a bashscript to launch VLC with special options and a folder containing pages to be shown on the TV, programmed in a kind of HTML
[04:53] <ogra> so aply this to our vlc and make it a new binary package then ...
[04:53] <zakame> er what bin makes `mkinstalldirs' again?
[04:53] <raphink> ogra : I should add this to the vlc source package and make it procude a different package from it, that's what you mean?
[04:54] <raphink> s/procude/produce/
[04:54] <ogra> yes
[04:54] <raphink> hmmm
[04:54] <ogra> make it produce an addon package to vlc, or if necessary a new binary
[04:54] <ogra> (with different name)
[04:55] <raphink> why not package it separately and have it depend on VLC?
[04:59] <siretart> raphink: because we want to avoid duplication
[05:00] <raphink> nothing would be duplicate siretart
[05:00] <siretart> raphink: then I didn't get you
[05:00] <eth42> siretart: thanks for the help -- I could successfully compile faac. But what does the message "dpkg-buildpackage: binary and diff upload (original source NOT included)" mean. Did it upload something?!
[05:00] <raphink> it's a bit complicate I reckon
[05:00] <tseng> eth42: it did not
[05:00] <eth42> ok :-)
[05:00] <siretart> eth42: that means that you didn't download the source with `apt-get` *G*
[05:00] <siretart> eth42: seriously
[05:01] <raphink> siretart: my ISP has worked on modifying VLC to produce the Freeplayer for years. A few years ago, they have released a modified version of VLC that allowed to do so. Then VLC got that diffs in the main trunk.
[05:01] <siretart> eth42: dpkg-buildpackage (dpkg-source, to be exact) searches for a ../<packagename>_<verision>.orig.tar.gz
[05:01] <siretart> eth42: if it doesn't exist, you get that message
[05:01] <eth42> ah, ok
[05:02] <raphink> siretart: now the service works with the current VLC provided by the VLC package, it just requires a small bash script to launch VLC with options and a folder that contains HTML pages used by the modem to browse the computer from the TV screen.
[05:02] <siretart> raphink: if it is just a small bash script, why not adding it to the existing vlc package?
[05:02] <raphink> siretart: still, the tarball provided by the ISP contains a VLC tarball, that is quite different from the one I got with apt-get source
[05:03] <raphink> siretart: I'll have to modify the vlc package source manually
[05:03] <raphink> if that's fine, then it's ok ;)
[05:03] <siretart> raphink: what modification would you need? what could break from that?
[05:03] <raphink> nothing could break siretart
[05:04] <raphink> I just need to add a freeplayer/ folder at the root of the vlc package, put the stuff in it
[05:04] <raphink> and add rules to debian/rules to install all this at the right place
[05:04] <siretart> raphink: you just said you needed to modfy something, what?
[05:04] <raphink> so something like /usr/share/freeplayer, with links to /usr/bin
[05:04] <siretart> raphink: or just the packaging?
[05:04] <raphink> siretart: I need to _add_ something to the source
[05:04] <raphink> that's what I mean
[05:05] <raphink> package source that is
[05:05] <siretart> raphink: ah, thats fine, just add it to the package :)
[05:05] <raphink> ok
[05:05] <raphink> :)
[05:06] <raphink> siretart: but if someone updates vlc, there's a chance the freeplayer is lost on the way, no?
[05:07] <siretart> raphink: if you document that in debian/changelog, there should be no problem
[05:07] <siretart> raphink: because when merging, we look for such changes
[05:07] <raphink> ok
[05:07] <raphink> yep
[05:08] <siretart> raphink: does vlc upstream know about this script? perhaps they could add it to their distribution?
[05:08] <raphink> siretart: I bet they know about it, since the current vlc was largely modified to work with it
[05:09] <siretart> well, perhaps it will show up in the next release then.
[05:09] <zakame> gn8 all :D
[05:09] <siretart> gn8 zakame
[05:09] <raphink> I don't think so siretart
[05:10] <raphink> it's only used by my ISP so far
[05:10] <raphink> since it works with the modem they build
[05:13] <siretart> :(
[05:14] <raphink> heh
[05:22] <chillywilly> quick question: How would I know if the GD PHP lib that is packaged is the one internal PHP GD lib?
[05:23] <siretart> chillywilly: you would have to check the buildlogs
[05:23] <siretart> http://people.ubunut.com/~lamont
[05:23] <chillywilly> ok
[05:24] <chillywilly> 404 on that
[05:24] <siretart> oh
[05:25] <lamont__> chillywilly: http://people.ubuntu.com/~lamont/buildLogs
[05:26] <tseng> alternatively you could look at the configure call in debian/rules in the source package
[05:27] <tseng> and the build-depends
[05:30] <chillywilly> yea I did apt-get source before, need to look at the rules file yet
[05:32] <amoll> hi there, i would like to add a deb package to the Ubuntu repositiory, could you please tell me which person to connect?
[05:32] <chillywilly> --with-gd=shared,/usr --enable-gd-native-ttf
[05:32] <siretart> amoll: please see https://wiki.ubuntu.com/REVU
[05:32] <chillywilly> not sure if that buids the "internal" gd lib but I'll rtfm ;)
[05:35] <siretart> amoll: in short: if you have a new package, you need to show it to us
[05:35] <siretart> amoll: then we can review and upload it for you to the archive
[05:35] <raphink> siretart: after adding freeplayer/, I get a very predictable error : unrepresentable changes to source
[05:35] <siretart> amoll: what package do you have?
[05:35] <raphink> how can I avoide that?
[05:35] <tseng> chillywilly: it says shared
[05:35] <siretart> raphink: you added binary data to the package
[05:35] <siretart> raphink: don't do that :)
[05:36] <tseng> chillywilly: iirc the other flag is --with-gd-internal, see ./configure --help
[05:36] <raphink> where do I add it siretart then?
[05:36] <tseng> maybe --with-gd=internal
[05:36] <siretart> raphink: you told before you just want to add a bash script, no? doesn't sound like binary data
[05:36] <chillywilly> tseng: bah, I should beat someone for requiring the internal gd lib ;)
[05:37] <raphink> there's a script _and_ a folder containing html, pdf and images
[05:37] <tseng> chillywilly: eh..?
[05:37] <siretart> raphink: how big is it?
[05:37] <tseng> chillywilly: didnt we just say we dont
[05:37] <raphink> so the issue is with the images and pdf
[05:37] <raphink> not big
[05:37] <amoll> a molecular viewer: www.ballview.org
[05:37] <chillywilly> tseng: my comment was the people wo wrote this PHP app should be beaten for requiring the internal gd lib
[05:38] <raphink> siretart: the whole directory I added is 248 KB
[05:38] <chillywilly> who*
[05:38] <tseng> chillywilly: i see.
[05:38] <tseng> shared libs are elite
[05:38] <siretart> raphink: which I'd consider as rather big
[05:38] <raphink> siretart: the pdf being 158KB
[05:39] <raphink> the images are very small (about 1kB each)
[05:39] <siretart> raphink: the problem is that diff cannot represent binary 'changes'
[05:39] <raphink> yes
[05:40] <raphink> I understand that
[05:40] <siretart> raphink: so you would have to workaround by using uuencode/uudecode
[05:40] <raphink> o_O
[05:40] <Kyral> amoll: You want that for MOTUScience?
[05:40] <siretart> raphink: so you rather want to introduce a new package, like mplayer-skins
[05:40] <raphink> I guess so siretart
[05:41] <amoll> Kyral: Yes I guess it would fit nicely
[05:41] <raphink> but then to have it clean I should just repackage the source aswell
[05:41] <Kyral> amoll: I can't find the license...
[05:41] <Kyral> amoll: and this http://www.ballview.org/Overview/Download seems to indicate that it wouldn't be GPL compatiable
[05:42] <raphink> siretart: next problem is that there is no version number on this script... it just calls vlc  with some options
[05:42] <amoll> Kyral: Well its GPL for the viewer and LGPL for the library
[05:42] <amoll> Kyral: The text is outdated, sorry...
[05:42] <Kyral> Okay now stupid question lol, are you upstream by anychance?
[05:43] <Kyral> upstream == Developer
[05:44] <Kyral> nm I answered my own question
[05:44] <Kyral> boy do I feel stupid now
[05:45] <Kyral> sorry
[05:46] <azeem> argh, all caps directories
[05:47] <azeem> argh, a "Do you accept these terms (y/n)?" question when running ./configure
[05:47] <Kyral> amoll: Add it to wiki.ubuntu.com/MOTUScience and we'll look at it when half the team isn't in Final Exams (Next Week ;P)
[05:47] <Kyral> azeem: whats this?
[05:48] <ogra> azeem, lol ... the buildd needs AI then :)
[05:48] <azeem> when you run ./configure, the first thing it does is catting the LGPL boilerplate to stdout and asking you the above question
[05:48] <azeem> ogra: or dpatch :)
[05:48] <ogra> hehe
[05:49] <azeem> dnl   Require the user to accept the license (once)
[05:49] <azeem> CF_CHECK_LICENSE
[05:49] <Kyral> azeem: what package (contemplates shutting up lol)
[05:49] <azeem> Kyral: Ball
[05:49] <Kyral> ah
[05:49] <Kyral> so I made an idiot of my self for no reason?
[05:50] <azeem> Kyral: I didn't get that idiot part at all, sorry =)
[05:50] <Kyral> meh
[05:50] <Kyral> remind me to scroll up before I start asking questions :P
[05:51] <Hieronymus> azeem: it asks you to agree to the LGPL?
[05:51] <azeem> yes
[05:51] <Hieronymus> azeem: but that's not an EULA but a redistribution license
[05:51] <azeem> http://www.ballview.org/Gallery <- awesome
[05:52] <Kyral> indeed
[05:52] <Kyral> It makes EasyChem look REALLY bad :D
[05:52] <azeem> EasyChem is a structur editor, not a 3D viewer, no?
[05:52] <azeem> I haven't followed too much
[05:52] <Kyral> yah good point
[05:52] <azeem> Ballview competes with e.g. PyMOL
[05:53] <Kyral> I dunno, I just package the things
[05:53] <amoll> Kyral: How do I do this?
[05:53] <Kyral> amoll: huh?
[05:54] <amoll> Well it seems you like our pictures ;)
[05:54] <azeem> amoll: why does the user need to agree to the LGPL when building from source?
[05:54] <Kyral> How do you do what? (Sorry, a "How do you do..." question sends me into support mode)
[05:55] <amoll> Good question. The configure script doesnt stem from me
[05:55] <Kyral> I can't even get to the Source without registering
[05:56] <amoll> My boss wants to know who is using our software
[05:56] <azeem> Kyral: I culd
[05:56] <azeem> eh, could
[05:56] <azeem> wget http://www.ballview.org/Downloads/Releases/BALL-1.1.tar.gz
[05:56] <Kyral> Isn't unrestricted access to the source a part of the GPL....
[05:57] <Kyral> I dunno...
[05:57] <azeem> Kyral: try the URL
[05:57] <Hieronymus> Kyral: no
[05:57] <Hieronymus> but you can just register, download and redistribute
[05:57] <Kyral> I dunno, my head hurts its Finals week. NO MORE THINKY! ;P
[05:57] <Hieronymus> unless binaries don't need registration
[05:57] <IzzyCC> hey guys, where can I go to get help installing php5/mysql5? id rather just pay a few bucks and have it done than get even more frustrated than I am
[05:58] <IzzyCC> (#ubuntu isnt answering)
[05:58] <Kyral> If its in the Repos the source would be available through the deb-src lines
[05:58] <amoll> the binaries of the viewer are available under GPL
[05:58] <amoll> the library unter LGPL
[05:58] <Seveas> IzzyCC, if #ubuntu isn't answering, that's no reason to ask in here
[05:58] <Kyral> Unless we put it in Multiverse
[05:58] <azeem> amoll: and the source of the viewer?
[05:58] <azeem> amoll: or is that the library?
[05:58] <Kyral> I'll take myself out of the convo now
[05:58] <amoll> azeem: its in the library
[05:58] <Hieronymus> Kyral: if it's GPL, you can just redistribute, or what are you talking about?
[05:58] <azeem> ah
[05:59] <IzzyCC> Seveas i figured there would be more people willing to get some side money that are active here, than there filled with people who are as newbie as me
[05:59] <azeem> amoll: how can you license the binary different to the source, or did I misunderstand you?
[05:59] <Seveas> IzzyCC, there are lots of smart people there too, just wait and ask again later
[05:59] <Kyral> Hieronymus: I mean that it would bypass the registration
[05:59] <Seveas> of ask on the mailinglist
[05:59] <Kyral> Completely since people could also go to packages.ubuntu.com and download it there
[05:59] <IzzyCC> Seveas aye, thanks
[06:00] <amoll> azeem: well the idea is that the binary can be distributed freely
[06:00] <azeem> amoll: that wouldn't change with LGPL?
[06:00] <Kyral> The source has to be under GPL too right?
[06:00] <Kyral> or...
[06:00] <amoll> azeem: well that wasnt my idea, I am not sure
[06:01] <Kyral> Wouldn't be the same as SunJava?
[06:01] <azeem> if you distribute that binary under the GPL, you have to offer the people who download it the source under the GPL as well
[06:02] <amoll> well the viewer has still some source left, which isnt in the library. I guess this code could be distributed under the GPL
[06:02] <amoll> but to use it, it would depend on the library, which is under LGPL
[06:02] <azeem> ah, ok
[06:02] <azeem> that makes sense
[06:02] <Kyral> Whats the difference between GPL and LGPL anyway?
[06:02] <azeem> but then you need to offer that GPL source somewhere
[06:02] <Hieronymus> Kyral: LGPL allows linking to proprietary software
[06:03] <Kyral> So if the lib is propreitary
[06:03] <azeem> "the lib"? which library?
[06:03] <Kyral> then the binary/source of the viewer would be under PGPL
[06:03] <Kyral> err
[06:03] <Kyral> LGPL
[06:03] <Hieronymus> ehm, hasn't amol said three times now that the viewer is GPL and the library is LGPL. What's the fuss about?
[06:04] <Kyral> Because it sounds like that you cannot get the source of the library
[06:04] <amoll> of course you can get it, but you have to register for free
[06:04] <amoll> is that a serious problem?
[06:05] <Kyral> and if the lib is in the repos you would be able to bypass the registration
[06:05] <Hieronymus> Kyral: so _what_?
[06:05] <Kyral> it seems like that is unwanted thats what ;P
[06:05] <azeem> amoll: no, but you need to understand that other people can just distribute the source/binary to others, without registration
[06:05] <azeem> like Ubuntu/Debian would
[06:05] <Kyral> or Gentoo...
[06:07] <Kyral> I personally never understood why people are so concerned about who is using it. To me no feedback means its working. Its when it doesn't work is when I want to here about it
[06:19] <amoll> Well we are really glad if we get feedback, but at the same time we would like to have an overview of who is using our software, also if they dont send any comments...
[06:19] <azeem> sure, just pointing it out
[06:20] <azeem> amoll: quite some people more from the Free Software community rather than the Bioinformatics community mind consider these registration forms mildly rude, perhaps
[06:40] <siretart> re
[07:02] <JohnnyMast> sirestart i have a problem with pbuilder it asks about a base archive ?? http://pastebin.com/461124, do know this problem ?
[07:03] <siretart> JohnnyMast: err, Line 9 tells exactly whats wrong and even how to fix it ;)
[07:03] <siretart> JohnnyMast: have a look at our PbuilderHowto in the wiki first
[07:04] <JohnnyMast> i did that already
[07:04] <JohnnyMast> yes that where the steps i took
[07:04] <JohnnyMast> is it a problem if you create a dapper chroot on dapper ?
[07:05] <LaserJock> hi Kyral
[07:05] <siretart> well, do you have a /var/cache/pbuilder/base.tgz at all?
[07:06] <JohnnyMast> no siretart
[07:06] <JohnnyMast> but it installed the chroot
[07:06] <siretart> JohnnyMast: that base.tgz is your chroot
[07:07] <JohnnyMast> i see but i saw pbuilder checking deps and downloading and installing stuff
[07:07] <JohnnyMast> i gues i overlooked something then
[07:08] <siretart> perhaps there was an error
[07:08] <siretart> the result of pbuilder create should be that base.tgz
[07:09] <JohnnyMast> im gonna redo the steps and report back to you if it fails, its not the first time something fails on dapper for me
[07:15] <siretart> JohnnyMast: the wiki mentions that it may be necessary to create a breezy chroot first, and upgrade that to dapper then
[07:16] <siretart> JohnnyMast: I have no idea if this is true today, and this can change with every day.
[07:16] <JohnnyMast> well let me try that
[07:16] <LaserJock> that is what I had to do but that was a while ago
[07:17] <JohnnyMast> it never hurts to try
[07:17] <LaserJock> I think that debootstrap didn't work for a while on dapper
[07:17] <LaserJock> but I don't know if that has been fixed
[07:18] <siretart> LaserJock: this is because of broken dependencies. they can get broken and fixed with every upload of a 'base package' (packages installed by debootstrap)
[07:18] <LaserJock> siretart: ah, makes sense
[07:19] <LaserJock> is REVUDay over?
[07:19] <JohnnyMast> well, its building a breezy chroot now. If its done i will check the the base.tgz file is there if it is i will follow the wiki steps to update to dapper
[07:21] <LaserJock> Hieronymus: ping?
[07:21] <Hieronymus> LaserJock: pong!
[07:21] <LaserJock> Hieronymus: It looks like your ATI driver doesn't like ghemical
[07:22] <Hieronymus> LaserJock: yeah
[07:22] <LaserJock> Hieronymus: You could email the ghemical-devel mailing list
[07:26] <JohnnyMast> on breezy it didnt create the base.tgz as well, but i think i saw an error on that my cd was not inserted
[07:30] <siretart> hey Mez
[07:30] <siretart> Mez: how are you
[07:31] <Kyral> hey guys
[07:31] <Mez> siretart: been better
[07:32] <siretart> :(
[07:32] <Hieronymus> LaserJock: hmm.. I'm lazy :) will put it in my stickywiki
[07:32] <Mez> siretart: I've been having a ****** time since Montral
[07:33] <Mez> and it's just getting worse
[07:36] <Kyral> Are we still doing bootcharting for Devel?
[07:37] <tseng> of course
[07:37] <tseng> the more the merrier
[07:37] <Kyral> very nice. Because I am quite happy with myself. Got my lappy down to 15 seconds flat in Dapper
[07:37] <slomo> siretart: hm, do you have a contact address for this eth42 guy? ;)
[07:37] <siretart> slomo: sorry
[07:37] <siretart> ah, there you are
[07:37] <siretart> query
[07:43] <LaserJock> crap, spilled a spool of 100 cd's on the floor >:(
[07:43] <Kyral> ouch
[07:44] <LaserJock> luckly, the were mostly Fedora, Mandrake, and Suse isos ;-)
[07:44] <Kyral> lol
[07:46] <LaserJock> that is one nice thing about Ubuntu, only 1 cd
[07:47] <Kyral> hehe
[07:48] <slomo> siretart: anyway, i don't see why he thinks faac is without mp4 support... it is built in on breezy/dapper on all arches ;)
[07:51] <Hieronymus> I'm making a .deb for bulldozer, an extension for nautilus which integrates build systems (make, ant etc.). If you use a format bulldozer knows but you haven't installed, like ant, it will give an error. Two questions: 1. Should I Depend: on these packages? 2. Two of these supported build systems are maven and maven2, but they're not in Ubuntu. What should I do?
[07:53] <JohnnyMast> pack them as well ?? :p
[07:54] <Hieronymus> ehh.. :p
[07:57] <Hieronymus> JohnnyMast: I picked this program because it's small and easy, and I don't feel like figuring out this maven thing ;-)
[07:58] <JohnnyMast> well you could depend on the package, how important is it ?
[07:59] <Hieronymus> JohnnyMast: I could depend on ant and nant, but not on maven and maven2.
[08:00] <JohnnyMast> but you could reconment it for later
[08:00] <JohnnyMast> because i get from this both arn on debian ?
[08:00] <JohnnyMast> *arnt
[08:00] <Hieronymus> What happens if you choose to build an {ant,nant,maven,maven2} file is you get an error because child process {ant,nant,maven,maven2} couldn't be executed
[08:01] <Hieronymus> JohnnyMast: maven and maven2 aren't in Debian
[08:01] <JohnnyMast> well if you depend it will only fail on maven and maven2
[08:02] <JohnnyMast> well thats why i sayed you could reconment it and see if its possible to add the packages later on
[08:02] <Hieronymus> but then again, should I depend on it? Most people won't want to install nant and ant
[08:03] <jamessan|work> could you convince upstream to gracefully handle a missing binary?
[08:04] <Hieronymus> jamessan|work: what is gracefully?
[08:04] <JohnnyMast> maybe they do already
[08:04] <JohnnyMast> Hieronymus: "goed afhandelen"
[08:04] <Hieronymus> JohnnyMast: I know what the words mean, just not what jamessan|work means
[08:05] <jamessan|work> Hieronymus: having them detect that the binary is missing and give a nice message instead of just failing
[08:05] <jamessan|work> If they already do that, then I'd say you could package it as is and Recommend the build systems
[08:05] <Hieronymus> http://members.home.nl/jeroen-91/temp/Schermafdruk-Fout.png
[08:06] <Hieronymus> basically it says 'error, you can't execute target build, because child process ant failed'
[08:06] <jamessan|work> that seems to be that path that file-roller took.  the common archival formats are depended on and the less common ones are just recommended
[08:07] <Hieronymus> jamessan|work: okay, I'll stick with recommended
[08:07] <jamessan|work> yeah, I wouldn't call that an extrememly user-friendly error message, but they may argue that it is good enough for people that are attempting to compile software
[08:07] <Hieronymus> but what about maven and maven2? Can I recommend them even though they don't exist in debian and ubuntu (yet)
[08:08] <jamessan|work> You could mention that they are supported in the long package description and when/if they are included in Debian you would include them in the recommendations
[08:08] <jamessan|work> s!Debian!Debian/Ubuntu!
[08:09] <jamessan|work> in fact, I'd highly recommend taking a look at "apt-cache show file-roller" for inspiration
[08:14] <kerosin> i have a maybe stupid question: if i create a package with a c++ library and application on a 32 bit machine, will it run also on a athlon64 machine?
[08:15] <Hieronymus> kerosin: no
[08:15] <Hieronymus> you'd have to recompile it for the athlon64
[08:36] <lucas> hi
[08:36] <lucas> I'm looking for a sponsor for bug #5035
[08:36] <Ubugtu> Malone bug #5035: ruby (Ubuntu) - shared library installed to incorrect directory on amd64 In: libgettext-ruby (Ubuntu), Severity: Normal, Assigned to: MOTU Reviewers Team, Status: New https://launchpad.net/bugs/5035
[08:36] <lucas> there's a debdiff attached. the fix is a one liner, but the bug renders the package unusable
[08:37] <lucas> (on amd64)
[08:44] <Hieronymus> lucas: I think you should use "Close malone #5035" in you debian/changelog
[08:44] <Ubugtu> Malone bug #5035: ruby (Ubuntu) - shared library installed to incorrect directory on amd64 In: libgettext-ruby (Ubuntu), Severity: Normal, Assigned to: MOTU Reviewers Team, Status: New https://launchpad.net/bugs/5035
[08:44] <Hieronymus> *Closes
[08:45] <lucas> it won't break the fix :)
[08:45] <lucas> I'll add a note to the bug, so the reviewer will know he has to add the closes line
[08:49] <littlepaul> ping whiprush
[09:11] <ajmitch> Hieronymus: we don't have to add the closes line in changelogs
[09:11] <ajmitch> that's done in debian because uploads can automatically close the bugs
[09:11] <ajmitch> it can be good to mention it, certainly
[09:12] <Hieronymus> ajmitch: I know, I thought Ubuntu'd do that to
[09:14] <ajmitch> it might happen when we shift to launchpad for uploads
[09:14] <ajmitch> but not yet
[09:51] <Tonio_> hi
[09:52] <ajmitch> hello
[10:06] <cyberix> Have you seen http://www.netsplit.com/software/gnome-space-chart/
[10:08] <ajmitch> if it's yet another new candidate for packaging, add it to UniverseCandidates
[10:08] <ajmitch> if keybuk doesn't package it himself
[10:19] <JohnnyMast> ajmitch sorry about yesterday
[10:21] <ajmitch> ok
[10:21] <JohnnyMast> didnt mean it that way :|
[10:23] <LaserJock> ajmitch: could you review plotdrop again? I fixed the -stamp issue, I believe.
[10:23] <ajmitch> not right not
[10:23] <ajmitch> not right now, I mean
[10:26] <LaserJock> ajmitch: well, just whenever you can, I'm not in a big hurry, but I just wanted you to know that it is waiting there for you :-)
[10:26] <ajmitch> or any other MOTU :)
[10:27] <LaserJock> ajmitch: yes, for sure.
[10:37] <LaserJock> hmm, this stinks. Debian got rid of the wxwindows2.4 version that the Ubuntu package was based on so the MoM debdiffs are for the previous version (stable) and are 1.5MB
[10:37] <Kyral> O_O
[10:37] <ajmitch> LaserJock: so don't rely on MoM output
[10:37] <ajmitch> just look at the ubuntu changes & apply the ones that are needed manually
[10:37] <LaserJock> yeah, but it makes it harder to see what the ubuntu changes were
[10:37] <ajmitch> nah
[10:38] <ajmitch> changelogs :)
[10:38] <LaserJock> if the changelogs are good ;-)
[10:38] <ajmitch> sure
[10:38] <ajmitch> this is encouragement for you to write good changelogs in future
[10:39] <LaserJock> for sure
[10:40] <LaserJock> hmm, changelog looks good. shouldn't be too bad then
[10:42] <lucas> ajmitch: if you are really bored, I have 4 simple syncs/merges and one bug with patch to review ;)
[10:49] <LaserJock> what is the difference between := and = in debian/rules ?
[10:49] <lucas> debian/rules is a makefile
[10:49] <lucas> so the GNU make manual should have the answer
[10:50] <Mithrandir> it's an immediate assignment vs non-immediate.
[10:50] <lucas> if I remember correctly, it has to do with how rules are overriden by included files
[10:50] <JohnnyMast> does revu autmaticly build the uploaded packages ?
[10:51] <LaserJock> Mithrandir and lucas: thanks
[10:51] <ajmitch> JohnnyMast: no, that's unsafe to do
[10:51] <ajmitch> since we allow plenty of people to upload to the box
[10:51] <JohnnyMast> aah ok thanks
[10:52] <JohnnyMast> i saw it will be optional in revu2
[10:52] <dholbach> have a nive evening
[10:53] <ajmitch> JohnnyMast: it'll be as optional as it is now - except more people (MOTUs) can get a build done
[10:53] <ajmitch> at the moment people in the right group on the revu server can run pbuilder
[10:53] <JohnnyMast> well i can say thats wise
[10:54] <ajmitch> we decided that building everything that comes in might not be so safe :)
[10:55] <JohnnyMast> well i can be save even now
[10:55] <JohnnyMast> in theory
[10:56] <ajmitch> sure, but everyone should have built their package before they upload, right?
[10:56] <JohnnyMast> if some one has an evil setup.py with back connecting code .. unless the bug is hightly firewalled
[11:00] <JohnnyMast> if that would be possible there still was the problem of the chroot that was cleaned after the buiild
[11:00] <ajmitch> the easy way is to just say that we don't autobuild packages
[11:00] <ajmitch> we have limited resources, both in hardware & developers
[11:01] <JohnnyMast> yes i do understand that
[11:13] <ajmitch> hello \sh
[11:15] <\sh> hey ajmitch
[11:16] <\sh> ajmitch: we got a german translation about ubuntu motu school :)
[11:16] <ajmitch> I know
[11:16] <ajmitch> he asked me if it was ok to translate
[11:17] <\sh> ajmitch: littlepaul?
[11:17] <ajmitch> \sh: now we just need a summary & writeup of the last one
[11:17] <ajmitch> yes
[11:17] <\sh> ajmitch: sure :)
[11:32] <ajmitch> hm, I thought there was something about the motu school on the wiki
[11:34] <JohnnyMast> yeah i was looking for the irc logs, maybe some one has them for me ?
[11:34] <ajmitch> yes
[11:34] <ajmitch> see topic in that channel