[12:04] <Kyral> a basic Text Editor should be able to handle all the text/* Mimetypes right?
[12:08] <LaserJock> beats me
[12:10] <Kyral> I'll test it :P
[12:12] <ogra> did the MOTUGames team see that ?  http://lists.ubuntu.com/archives/ubuntu-users/2006-January/064286.html
[12:13] <Kyral> Clean Lintian run on both src and deb! Yea!
[12:16] <Kyral> I cleared away all of ajmitch's complaints about the pack...at least the ones he told me ;P
[12:39] <Kyral> err
[12:39] <Kyral> I should hear Upstream's comments on it first
[12:39] <tseng> if upstream didnt want you to distribut it they wouldnt have made it gpl
[12:39] <Kyral> Its MIT actually
[12:39] <tseng> even better
[12:39] <Kyral> but I had to write a manpage, the control desc etc
[12:40] <Kyral> I wanted to hear what he thought of my writing lol
[12:42] <Kyral> But I suppose just filing the ITP couldn't hurt
[12:43] <LaserJock> and ITP just means you are working on it
[12:44] <Kyral> yah one thing I was worried about was that the version on the tarball was -b1
[12:44] <Kyral> and dh_make didn't like that
[12:45] <Kyral> so in the Debian changelog I have it listed as 0.1
[12:48] <LaserJock> Kyral: hmm, I don't know about that
[12:48] <Kyral> yah
[12:48] <Kyral> Thats why I emailed him ;P
[12:49] <Kyral> dh_make refused to let the version as -b1
[12:49] <Kyral> even with -p
[12:50] <Kyral> in the ITP I'm putting 0.1/b1 as version
[12:51] <azeem> Kyral: you can rename the tarball to something dh_make likes, run dh_make, then rename it back  (and change debian/changelog)
[12:51] <Kyral> azeem: there was no dir in the tarball lol
[12:51] <azeem> no dir?
[12:51] <Kyral> nope
[12:51] <azeem> ah, it extracts in .?
[12:51] <Kyral> literally it was a .c, a Makefile, and a Readme :P
[12:51] <Kyral> yah
[12:51] <azeem> what is this?
[12:52] <azeem> ah, GTKEdit still?
[12:52] <Kyral> http://revu.tauware.de/details.py?upid=1523
[12:52] <Kyral> yah
[12:52] <Kyral> so when I made the dir...
[12:52] <Kyral> okay so I'll do that and reupload
[12:52] <azeem> Kyral: I think this whole thing screams "Don't package me! Don't package me!" =)
[12:52] <Kyral> Azeem lol
[12:53] <Kyral> I use it on my 3 year old lappy so lol
[12:56] <Kyral> ITP Sent
[01:04] <thierry_> how can I clean only one particular file with debhelper?
[01:04] <thierry_> dh_clean filename ?
[01:04] <Kyral> rm?
[01:04] <jamessan> rm -f filename
[01:04] <jamessan> dh_clean is meant for cleaning up the debian stuff
[01:05] <thierry_> k
[01:05] <thierry_> jamessan : but rm isn't for deleting?
[01:05] <azeem> thierry_: why not?
[01:06] <jamessan> thierry_: I don't understand the question
[01:07] <tseng> ogra: hm g-p-m is is dying w/o a trace
[01:07] <tseng> ogra: do you see it also?
[01:07] <thierry_> azeem : well I want to clean the file, not deleting it, except if that's the same thing (wich I don't know)
[01:09] <jamessan> thierry_: well, what do you mean by clean?
[01:10] <azeem> thierry_: in this context (compiling programs) 'clean' means 'revert to initial state', which means 'remove/delete any newly generated files'
[01:10] <thierry_> azeem : ho ok!
[01:59] <LaserJock> Kyral: get that man page done?
[02:00] <Kyral> LaserJock: yah
[02:00] <Kyral> in nroff :P
[02:03] <Kyral> Look at REVU
[02:08] <LaserJock> Kyral: did you use a Docbook to make it
[02:10] <Kyral> Nope
[02:12] <LaserJock> so did you just edit the .1 file itself then?
[02:12] <Kyral> yah
[02:12] <Kyral> err no
[02:12] <Kyral> I wrote it from scratch
[02:13] <LaserJock> hmm, mine looks a bit different. I used the dh_make generated Docbook and edited it
[02:14] <Kyral> heh
[02:15] <LaserJock> It amazes me how many different ways you can do each task in packaging
[02:15] <LaserJock> which makes writing a packaging guide difficult sometimes >:(
[02:30] <dholbach> night guys.
[02:31] <Kyral> ight
[02:43] <LaserJock> sweet, my @ubuntu.com email works now
[03:27] <marcin> hello MOTU
[03:27] <marcin> could someone help me?
[03:28] <marcin> I would like to build some packages for dapper but I use breezy
[03:28] <marcin> so I want to configure pbuild
[03:28] <marcin> and I'm following procedure described on this https://wiki.ubuntu.com/DebootstrapChroot page
[03:28] <Burgundavia> marcin, have you see the pbuilderhowto?
[03:28] <marcin> unfortunately sudo debootstrap [--variant=buildd]  [--arch i386]  breezy /var/chroot/ http://archive.ubuntu.com/ubuntu/
[03:29] <marcin> doesn't want to work because it says that there is no such script as http://archiveblabla
[03:30] <marcin> Burgundavia: moment I'll try with this stuff
[03:30] <womble> marcin: You want --distribution breezy ...
[03:31] <marcin> well in fact I also should file bug report about pbuilder package...
[03:32] <womble> marcin: Why?  What's it doing wrong?
[03:32] <marcin> it has MIRRORSITE=http://ftp.jp.debian.org/debian
[03:32] <marcin> by default
[03:33] <marcin> well it's not bug in fact but...
[03:34] <womble> It'd certainly make creating a dapper chroot a little difficult without changing the mirror...
[03:36] <minghua> marcin has a point there, the ubuntu pbuilder package probably should default to a debian mirror
[03:36] <minghua> s/should/shouldn't/
[03:36] <Burgundavia> minghua, patch it
[03:38] <marcin> pbuilder howto says that I should copy /etc/apt/* to /etc/pbuilder/apt.config/
[03:38] <marcin> but no word about any changes in these config files..
[03:39] <minghua> Burgundavia: after UVF, perhaps :-)
[03:39] <marcin> do I need to change repositories in /etc/pbuilder/apt.config/sources.list to dapper if I want to build packages for dapper?
[03:39] <LaserJock> yes
[03:41] <derekS> i have a question about the gajim package, i wanna know if it was compiled with support for the wikipedia/dictionary/searchengine lookup. how do i find out?
[03:41] <marcin> ok - thanks
[03:41] <marcin> well it could be mentioned in howto ;)
[03:42] <marcin> derekS: apt-get source gajim
[03:42] <marcin> derekS: and take a look at debian/rules file
[03:42] <derekS> marcin: thanks
[03:42] <marcin> in downloaded source directory
[03:46] <marcin> ok guys
[03:46] <marcin> yet another problem
[03:46] <marcin> pbuilder create --distribution dapper
[03:46] <marcin> says that there is
[03:46] <marcin> E: No such script: /usr/lib/debootstrap/scripts/dapper
[03:46] <marcin> 
[03:46] <LaserJock> marcin: you can edit the wiki at any time ;-)
[03:47] <LaserJock> marcin: that's because you will need the dapper version of debootstrap
[03:47] <marcin> so I need to download this manually and install with dpkg?
[03:48] <LaserJock> what are you running now?
[03:48] <marcin> breezy
[03:49] <marcin> my dapper crashed few days ago
[03:49] <LaserJock> I might just try doing a breezy pbuilder and then dist-upgrading it to dapper
[03:49] <marcin> I thought that flight 3 could work better
[03:50] <marcin> but unfortunately #28811
[03:50] <marcin> LaserJock: no way I don't want to upgrade to dapper
[03:50] <LaserJock> marcin: no just the pbuilder
[03:51] <marcin> LaserJock: so apt-get update with dapper repos then install only pbuilder?
[03:52] <LaserJock> no, you can change the pbuilderrc and pbuilder sources.list and pbuilder update
[03:52] <LaserJock> I think it is on the how to wiki page
[03:53] <marcin> LaserJock: well not exactly
[03:54] <marcin> LaserJock: anyway you think that instead of pbuilder create --distribution dapper
[03:54] <LaserJock> marcin: it is under "Upgrading to Latest Development Release"
[03:54] <marcin> LaserJock: I should pbuilder update first?
[03:54] <LaserJock> no
[03:55] <marcin> LaserJock: aah right - got it
[03:56] <marcin> hehe E: failed to find /var/cache/pbuilder/base.tgz, have you done <pbuilder create> to create your base tarball yet?
[03:56] <marcin> 
[03:56] <LaserJock> did you make the breezy pbuilder?
[03:56] <marcin> nope :)
[03:56] <LaserJock> you need to do that first
[03:57] <marcin> ok ok...
[03:57] <LaserJock> also you will probably want universe support as well
[04:00] <marcin> LaserJock: is pbuilder create something time consuming?
[04:01] <LaserJock> yep
[04:01] <LaserJock> marcin: it is basically making a mini-Ubuntu install
[04:01] <LaserJock> with just the basic packages
[04:02] <marcin> ehh so - off to bed
[04:02] <marcin> it's 4:00 am here
[04:02] <LaserJock> ouch
[04:02] <marcin> thanks
[04:03] <marcin> I'll leave this pbuilder thing it should finish overnight
[04:03] <marcin> night
[04:04] <LaserJock> cya
[05:26] <LaserJock> Kyral: are you around?
[05:26] <Kyral> yah
[05:27] <LaserJock> Kyral: how did you change your key when you got your @ubuntu.com address?
[05:27] <Kyral> added the ID?
[05:28] <LaserJock> what about for revu?
[05:28] <Kyral> as long as its the same key
[05:28] <Kyral> same KeyID
[05:29] <LaserJock> so do you just now sign your packages with the @ubuntu.com address?
[05:29] <Kyral> its the same key really
[05:31] <LaserJock> ok, should I resend my key to the keyservers?
[05:31] <Kyral> yah
[06:14] <LaserJock> any MOTUs around?
[06:18] <LaserJock> hmm, I suppose it's a little early for the Germans
[06:18] <ajmitch> yes?
[06:19] <LaserJock> I was thinking of working on the kguitar merge
[06:20] <LaserJock> It appears pef did an 0ubuntu1 version
[06:20] <LaserJock> but now there is a Debian -2 version
[06:21] <LaserJock> so should I just try to build the Debian source in dapper and see if it works?
[06:24] <LaserJock> ajmitch: any thoughts?
[06:25] <ajmitch> yes, probably a good idea
[06:30] <LaserJock> well, it builds, installs, and works
[06:36] <LaserJock> ajmitch: so should we request a sync?
[06:38] <hub> ajmitch: so can I upload my packages that have 2 votes?
[06:38] <hub> :-)
[06:38] <ajmitch> hub: once your key is in
[06:38] <hub> ajmitch: yeah, I sent it
[06:38] <ajmitch> and you don't vote for your own packages, I hope :)
[06:39] <hub> ajmitch: no
[06:39] <ajmitch> yes, has elmo replied saying it's in?
[06:39] <ajmitch> LaserJock: probably
[06:39] <ajmitch> LaserJock: check that the orig.tar.gz is the same
[06:39] <hub> ajmitch: he hasn't yet, but I sent the key ID a few minutes ago
[06:39] <ajmitch> hub: might take a little while to process
[06:39] <hub> ajmitch: what is the procedure? I just upload with dput or is there something I missed on REVU....
[06:40] <ajmitch> judt dput
[06:40] <ajmitch> s/judt/just/
[06:40] <hub> okay
[06:45] <hub> ajmitch: btw is it only cdbs package that should patch config.{sub,guess} ?
[06:45] <ajmitch> hm?
[06:45] <hub> apparently dh-make make them being rewritten in clean:
[06:46] <ajmitch> yes
[06:46] <ajmitch> which makes things ugly, iirc
[06:46] <hub> yeah
[06:47] <ajmitch> especially when you go to make a debdiff
[06:47] <hub> so the packager has to work around it?
[06:47] <ajmitch> they can
[06:47] <ajmitch> or they ignore it
[06:48] <hub> so what is the policy for reviewing
[06:48] <ajmitch> I don't know if there is a policy
[06:48] <hub> ah ok
[06:48] <ajmitch> I really prefer that they not be in the diff.gz
[06:49] <hub> metoo
[06:51] <LaserJock> ajmitch: the two .orig.tar.gz's have slightly different sizes but I unpacked them both and diffed them and didn't come up with any differences
[06:51] <minghua> it's pretty trival to fix the dh-make's debian/rules
[06:51] <ajmitch> LaserJock: that doesn't matter
[06:51] <minghua> maybe I should write a wiki page for that
[06:51] <ajmitch> if they have differing md5sums you can't sync
[06:52] <LaserJock> why not?
[06:52] <LaserJock> I mean what can you do?
[06:52] <ajmitch> because you can't overwrite the orig.tar.gz in the archive with another that is slightly different
[06:53] <ajmitch> it breaks all manner of things
[06:53] <LaserJock> so what do we do?
[06:53] <ajmitch> the only thing you can do is merge by hand
[06:53] <LaserJock> so we create a ubuntu1 just because the .orig.tar.gz files aren't the same size?
[06:53] <ajmitch> yes
[06:54] <ajmitch> it's the only thing we can do
[06:54] <LaserJock> we can't get rid of the present Ubuntu packages?
[06:54] <ajmitch> nope
[06:55] <ajmitch> so this divergence will last until the next upstream version that we're allowed to sync
[06:55] <LaserJock> well, that's really weird, but OK :-)
[06:55] <ajmitch> no, it's not weird
[06:55] <ajmitch> remember that the sources lists that you download have the md5sums of all the files
[06:56] <LaserJock> right, but aren't those updated on a regular basis?
[06:56] <minghua> LaserJock: but your second upload doesn't have an orig.tar.gz
[06:56] <minghua> assuming no upstream version changes
[06:56] <ajmitch> it's just a Really Bad Thing to silently change a file in the archive
[06:57] <LaserJock> hmm, ok so I can see where it would mess stuff up
[06:57] <ajmitch> yeah
[06:57] <ajmitch> it's horrendously irritating when upstream releases a tarball & then silently changes it a few hours later
[06:58] <LaserJock> but what would I put in a changelog entry? ".orig.tar.gz doesn't have same md5sum"
[06:58] <minghua> LaserJock: sounds good to me :-)
[07:01] <LaserJock> ok, so I use the debian source, except switch .orig.tar.gz and update changelog?
[07:25] <LaserJock> ajmitch: I gotta go but I attached a debdiff to the bug report
[07:31] <ajmitch> hey Lathiat
[07:31] <ajmitch> got your talk ready yet? ;)
[07:31] <Lathiat> already?
[07:32] <Lathiat> bit soon isnt it?
[07:34] <LaserJock> ajmitch: can you take a look at the kguitar debdiff?
[07:36] <LaserJock> ok, later guys
[07:38] <raphink> hi guys
[07:40] <raphink> LaserJock_away: you're still there?
[08:07] <raphink> everybody's sleeping here?
[08:13] <ajmitch> not quite :)
[08:13] <StevenK> Almost.
[08:14] <ajmitch> heh
[08:14] <raphink> ah :)
[08:14] <ajmitch> early start too much for you, StevenK? :)
[08:14] <StevenK> Oh yes.
[08:14] <raphink> hehe
[08:14] <raphink> ajmitch: one question :
[08:14] <raphink> when merging, what shall we have in the changelog ?
[08:15] <raphink> the old changelog + the new debian entry + the merger entry ?
[08:15] <raphink> or do we keep all the new debian entries if there were several since it was last merged ?
[08:16] <raphink> i.e. do we want only the versions present in Ubuntu in the changelog ?
[08:16] <raphink> or all the debian versions?
[08:18] <ajmitch> all versions
[08:18] <raphink> ok
[08:18] <ajmitch> there's often several debian revisions
[08:18] <raphink> I requested a sync for a package
[08:19] <raphink> but actually the last version in Ubuntu was a -8ubuntu1
[08:19] <raphink> so i guess I should merge
[08:19] <raphink> at least to get the last ubuntu changelog in
[08:19] <raphink> right?
[08:19] <ajmitch> hm?
[08:19] <ajmitch> don't do that
[08:19] <raphink> what do you mean?
[08:20] <raphink> I just keep track of the last ubuntu version if I just sync the package
[08:20] <ajmitch> if you asked for a sync, then don't go re-adding changelog entries just to have them there
[08:20] <raphink> sorry
[08:20] <raphink> hmm ok
[08:20] <raphink> the sync was not performed yet
[08:20] <ajmitch> because then it'll never aync automatically
[08:20] <raphink> s/aync/sync/
[08:20] <ajmitch> s/aync/sync/
[08:20] <raphink> ;)
[08:20] <raphink> hehe
[08:21] <raphink> ajmitch: so I leave it as a sync and we miss last changelog and that's fine?
[08:22] <raphink> I mean if I add the changelog, even it was already synced, the -Xubuntu1 package will be newer than the sync so that's fine, no?
[08:22] <ajmitch> no, it's not fine to upload it
[08:22] <raphink> why?
[08:22] <ajmitch> you requested a sync, because ubuntu changes aren't needed anymore
[08:22] <ajmitch> so there's nothing to have in the changelog
[08:22] <raphink> ok :)
[08:22] <ajmitch> and I just said - having an ubuntu version introduces divergence, another package to merge for dapper+1
[08:22] <raphink> well there's nothing to have in the changelog about the new sync
[08:23] <raphink> but we lose track of the previous one
[08:23] <ajmitch> that's fine
[08:23] <ajmitch> that's fine
[08:23] <ajmitch> we don't want the previous one anymore
[08:23] <raphink> so if you look at the new changelog it's like the old ubuntu version never existed
[08:23] <raphink> ok
[08:23] <raphink> fine :)
[08:23] <ajmitch> yes
[08:23] <raphink> ty
[08:23] <raphink> another question
[08:23] <raphink> :)
[08:23] <raphink> if i want to join the MOTU team on LP, who do I ping?
[08:24] <ajmitch> a motu team admin
[08:24] <raphink> well you are an admin so i'll ping you :)
[08:24] <raphink> ajmitch: ping
[08:24] <raphink> :)
[08:24] <ajmitch> we don't use that team membership for anything
[08:24] <ajmitch> it used to be for bug
[08:24] <ajmitch> bugs
[08:24] <Fuddl> hi everybody
[08:25] <raphink> hi Fuddl
[08:25] <raphink> ajmitch: ok
[08:25] <raphink> hmm what exactly do I need now to be able to work as a MOTU?
[08:25] <raphink> like upload and so on?
[08:25] <ajmitch> have you sent your key to elmo?
[08:25] <raphink> ajmitch: hmm no my key ID is on my LP page
[08:25] <ajmitch> that's not enough
[08:25] <raphink> and my key is on the REVU keyring too, but I guess that doesn't cound
[08:25] <raphink> count
[08:25] <raphink> ok
[08:25] <ajmitch> https://wiki.ubuntu.com/Uploads
[08:26] <raphink> ty
[08:26] <ajmitch> New maintainers should mail keyring@ubuntu.com with their gpg key id to get added.
[08:26] <ajmitch> at the moment elmo manages the keyring manually
[08:26] <Fuddl> jieehaaa, i got in touch with the quake3 developers, they'll reviewing license issues and already started to remove some stuff in the svn repos. hopefully i can upload some "cleaned" quake3 packages to revu the next days *happy* :)
[08:26] <raphink> ok
[08:26] <StevenK> Now I get to wait another few weeks.
[08:26] <ajmitch> once we switch to soyuz (launchpad), it will be handled by team membership
[08:26] <raphink> ok
[08:28] <ajmitch> by now we expect that yo uknow what you're doing with packages :)
[08:28] <ajmitch> so don't break anything ;)
[08:29] <StevenK> Or do, since that seems to work for ajmitch.
[08:29] <ajmitch> StevenK: I'm too lazy to break things
[08:29] <ajmitch> that was not my doing
[08:30] <StevenK> Sure it was.
[08:30] <StevenK> Well, parts of it were.
[08:30] <ajmitch> I didn't do the initial breakage
[08:30] <raphink> ajmitch: I'll keep asking questions when in doubt though :)
[08:30] <ajmitch> raphink: please do
[08:31] <raphink> :)
[08:33] <raphink> hehe signed message sent :)
[08:34] <ajmitch> good
[08:34] <raphink> :)
[08:47] <raphink> :)
[08:48] <raphink> salut Gloubiboulga
[08:49] <Gloubiboulga> hello raphink, comment a va ?
[08:49] <raphink> bien merci et toi,
[08:49] <Gloubiboulga> a va :)
[08:50] <raphink> :)
[08:50] <raphink> koid9 ? ;)
[08:50] <Gloubiboulga> pas grand chose, et toi ? MOTU ?
[08:52] <raphink> dev en tout cas :)
[08:52] <raphink> depuis hier soir
[08:52] <Gloubiboulga> flicitations :)
[08:52] <raphink> j'attend pour tre ajout  la liste des MOTUs :)
[08:52] <raphink> merci :)
[09:02] <Gloubiboulga> ajmitch, ping
[09:14] <sivang> morning MOTUs!
[09:14] <raphink> hi sivang
[09:16] <sivang> hey raphink , got a terrible headache last night - so I stopped reading the library packaging guide, I wil lcontinue tomorrow. I will probably need some help after the initial packaging
[09:16] <raphink> sivang: do you use cdbs or just debhelper?
[09:16] <raphink> (or just neither, but I doubt so)
[09:25] <sivang> raphink: i wasthinking of using debhelper, what do you propose ?
[09:26] <raphink> using debhelper you mean?
[09:26] <sivang> yes
[09:26] <raphink> well the thing when you package a lib is that your source package has to generate multiple binary ones
[09:26] <sivang> right
[09:26] <raphink> so first of all you need to have multiple binaries in debian/control
[09:27] <raphink> dh_make generates that for you automatically and you just have to modify it
[09:27] <raphink> the -dev package should depend on the 0 one
[09:27] <raphink> then
[09:27] <sivang> ah right, it asksa you that
[09:27] <raphink> the easiest way to deal with multiply binary packages imo
[09:27] <raphink> is to use .install files
[09:27] <raphink> which is what dh_make does by default, too iirc
[09:28] <Gloubiboulga> I confirm
[09:28] <raphink> it generates yourlib0.install and yourlib-dev.install
[09:28] <raphink> automagically
[09:28] <sivang> woo hoo
[09:28] <raphink> so you just need to edit them and adjust them if necessary
[09:28] <raphink> note that the .install files should only contain debian/tmp/ stuff
[09:29] <raphink> since the lib will be built in debian/tmp
[09:29] <sivang> rigth, so it's only paths of where the lib should be installed and so?
[09:29] <raphink> and then you select each component of the built lib there and tell in which package (0 or -dev) it has to go
[09:29] <raphink> it's usually very easy since dh_make makes most of the job in the .install already
[09:29] <raphink> but you might have to modify the .install files
[09:30] <raphink> i.e. if your lib contains special files
[09:30] <raphink> or images or so
[09:30] <raphink> that might happen
[09:30] <sivang> ok, I think I have enough to get started already :) even without read cover to cover the lib packaging guide :)
[09:30] <raphink> then you have to determine whether these files go to the 0 or -dev packgae
[09:30] <raphink> yep ;)
[09:30] <raphink> good luck :)
[09:30] <sivang> I'm actually going to have it 1 from start, since this lib is already at version 1
[09:30] <sivang> is that ok?
[09:30] <sivang> or the 0 refers to the soname?
[09:31] <raphink> how do you mean?
[09:31] <raphink> hmmm
[09:31] <raphink> let me check :)
[09:31] <raphink> yes I think that's it
[09:32] <raphink> well if your library name is mylibx.y
[09:32] <raphink> then your binary packages should be
[09:32] <raphink> mylibx.y and mylibx.y-dev
[09:32] <raphink> and the associated .install files will be
[09:32] <raphink> mylibx.y.install and mylibx.y-dev.install
[09:33] <raphink> fine sivang ?
[09:33] <raphink> sivang: I suggest you take a look at some libs on REVU for example
[09:33] <StevenK> raphink: Fine, libfoo
[09:33] <raphink> so you can see how they are packaged
[09:33] <StevenK> :-P
[09:33] <raphink> yep libfoo is better StevenK
[09:34] <raphink> thanks ;)
[09:34] <raphink> libbar too ;)
[09:36] <sivang> thank you guys, and congretulations both for becoming official MOTUs
[09:36] <raphink> ty :)
[09:37] <raphink> sivang: just pick one on REVU ;)
[09:37] <raphink> hi \sh
[09:38] <\sh> moins
[09:47] <Gloubiboulga> hi \sh, I have a little question about a lib name
[09:47] <\sh> Gloubiboulga: which one?
[09:47] <Gloubiboulga> if a foo lib provides libfoo.so.0.3.1, what should be the package name ?
[09:49] <Gloubiboulga> it's fr libswitch : http://revu.tauware.de/details.py?upid=1518
[09:50] <\sh> Gloubiboulga: can I advice you to read http://www.debian.org/doc/debian-policy/ch-sharedlibs.html it describes your problem exactly and gives the answer :)
[09:50] <Gloubiboulga> ok :)
[09:55] <\sh> Gloubiboulga: it addresses your problem, right?
[09:55] <Gloubiboulga> \sh, yep, got my answer, thanks
[10:15] <dholbach> hello!
[10:20] <tepsipakki> ok, I'm back doing the gtkpod-aac.. the only problem left seems to be stuff installed in /usr/share/gtkpod, not /usr/share/gtkpod-aac..
[10:21] <tepsipakki> ah, hardcoded in Makefile
[10:22] <lucas> hi motus
[10:22] <zakame> hello all
[10:26] <\sh> ok..another attempt of packageing s.c.o.u.r.g.e
[10:26] <zakame> \sh: ooooh!!!
[10:27] <\sh> zakame: well..it's not directly a problem of scourge to be packaged...but the problem is pbuilder and scourge...somehow it builds in a chroot but not in pbuilder directly
[10:27] <siretart> \sh: did you read the licence issues of scourge?
[10:28] <\sh> siretart: yes
[10:28] <siretart> \sh: so we cannot redistribute that :(
[10:28] <\sh> siretart: not the data :)
[10:28] <\sh> siretart: the source indeed we can distribute
[10:31] <\sh> siretart: source == without the data directory
[10:32] <siretart> \sh: so the game is playable without the media?
[10:32] <\sh> siretart: no..but I'll work on a solution
[10:33] <\sh> The artwork in S.C.O.U.R.G.E. falls under three categories: Any art I made is free for reuse under the terms of the GPL. Art I 'borrowed' from polycount is subject to the rules set by their authors. Finally art created by Matt is owned by him, and is not available for reuse in other projects.
[10:33] <\sh> the question is, what is the artwork made by him, and is it enough for playing the game.
[10:34] <siretart> ah, so you are still investigating.. I see
[10:34] <\sh> siretart: the other solution would be to get an exclusive agreement with the other contributors for ubuntuy
[10:40] <siretart> exclusive agreements don't make software or artwork free
[10:40] <siretart> would have to go to multiverse anyway that way
[10:43] <TWD> Just a question concerning Launchpad, I've just been filling some bugs out about the latest Dapper live CD, and I've just realised that I've put them in upstream, is there a way to move them over to ubuntu Dapper?
[10:43] <TWD> I've tried adding a request for fix in distribution, but only ubuntu comes up, there doesn't seem to be a way to specify Dapper.
[10:44] <TWD> All help much appreciated
[10:46] <\sh> TWD: #launchpad can help :)
[10:46] <\sh> siretart: do you have to time to have a look on a configure log?
[10:48] <TWD> \sh: thanks, goin g there now
[10:52] <\sh> siretart: http://paste.ubuntu-nl.org/7312 (and it works in any chroot i have :)) same build-deps
[11:02] <tepsipakki> ok, I've finished gtkpod-aac, what next?
[11:08] <siretart> \sh: does it use libtool/autoconf? it this case you need to relibtoolize it to find the correct gl headers
[11:08] <\sh> siretart: well...i wonder why it works in a chroot
[11:21] <tepsipakki> http://users.tkk.fi/~tjaalton/gtkpod-aac/
[11:21] <\sh> siretart: and funny thing is, even in pbuilder login..it doesn't work...
[11:21] <\sh> siretart: (even after libtoolizing it)
[11:24] <siretart> hm. I'd have to take a look at it myself (checking configure.log and so on)
[11:26] <Yagisan> ajmitch: around ?
[11:30] <Yagisan> bbl
[11:40] <\sh> siretart: i'm checking everything different now..between a chroot build and an pbuilder env build
[12:03] <viviersf> i made a package
[12:03] <viviersf> it depends on impi-default-settings
[12:03] <viviersf> and when i apt-get remove impi-default-settings
[12:04] <viviersf> it doesnt want to remove the package
[12:04] <viviersf> why not ?
[12:46] <Hieronymus> Can someone help me with a watch file?
[12:49] <mbreit> hi guys
[12:51] <bunda> hi
[12:52] <tepsipakki> um, how do I change debian/control so that I can sign the .dsc since I'm not the maintainer?
[12:53] <mbreit> tepsipakki: iirc you don't need to change the control file... isn't there an option for dpkg-buildpackage?
[12:53] <\sh> debuild -S -k<your gpg uid>
[12:53] <tepsipakki> \sh: thanks!
[12:54] <\sh> or debuild -S -sa -k<your gpg uid> for source uploads
[12:54] <mbreit> hehe... i think i was too long away ;)))
[12:54] <bunda> I created a package cdpr (Cisco Discovery Protocol Reporter) for our local uni repository. I'd like to share it. What do I have do?
[12:55] <\sh> bunda: FOSS software? upload to revu.
[12:55] <mbreit> \sh: he nows about revu but needs someone to put his key into the keyring
[12:55] <bunda> It uses GPLv2...
[12:55] <mbreit> s/nows/knows/
[12:55] <\sh> mbreit:  we need a signed mail with the key id :)
[12:56] <\sh> to keyring@tiber.tauware.de
[12:56] <mbreit> \sh: i have his key... personally signed *g*
[12:56] <mbreit> \sh: does it get into the keyring automatically?
[12:57] <\sh> mbreit: but he needs to contact us somehow :)
[12:57] <\sh> mbreit: manual intervention
[12:57] <bunda> ??
[12:57] <mbreit> \sh: can i do this myself? i have admin rights on tiber...
[12:57] <\sh> mbreit: sure
[12:57] <mbreit> how?
[12:58] <siretart> can anyone with recent dapper check if the seahorse gedit plugin works?
[12:58] <\sh> siretart: no it doesn't build at all
[12:59] <\sh> siretart: I disabled it
[12:59] <mbreit> siretart: just a second, i just wanted to update to latest gedit ;)
[12:59] <\sh> siretart: problems with the interface between gedit 2.10 and 2.12
[12:59] <siretart> \sh: ah. now I see it in the changelog
[12:59] <siretart> 2005-09-19  Nate Nielsen  <nielsen@memberwebs.com>
[12:59] <siretart>         * configure.in: Now works with gedit 2.12. Patch from
[12:59] <siretart>         Mike Gardiner. (bug #316607)
[12:59] <\sh> siretart: the last version wasn't working
[12:59] <siretart> this is in /usr/share/doc/seahorse/changelog.gz
[01:00] <\sh> siretart: there was no patch at all :)
[01:00] <siretart> is there already a malone bug for this?
[01:00] <\sh> siretart: but it's a source problem..it uses old header files and old functions wich are not available anymore
[01:01] <\sh> siretart: no...I don't think so.
[01:01] <mbreit> \sh, siretart: how can I add bunda's key to the keyring on revu?
[01:01] <\sh> siretart: I came across this problem when I fixed malone #3353
[01:01] <Ubugtu> Malone bug 3353: "Seahorse freezes when synchronizing with keyring servers" Fix req. for: seahorse (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: Fix Released http://launchpad.net/bugs/3353
[01:02] <siretart> mbreit: /srv/revu1/scripts/revu-key import <keyid>
[01:02] <mbreit> siretart: thanks!
[01:02] <dholbach> hey mbreit
[01:02] <dholbach> mbreit: you should be on planet! :)
[01:03] <mbreit> dholbach: 1) i don't do very much ubuntu work atm (shame on me, but university is taking too much time), and 2) i don't blog interesting things...
[01:03] <\sh> siretart: the removal of this ldap key server was mentioned in upstreams mail archive somewher
[01:03] <\sh> e
[01:04] <dholbach> mbreit: I read your entry :)
[01:05] <\sh> dholbach: where?
[01:05] <dholbach> http://mobr.de/blog/feed
[01:06] <tepsipakki> damn, I just uploaded gtkpod-aac to revu, but the changelog had a false email-address, and shouldn't I receive a password to that address?
[01:07] <\sh> dholbach: ah google talk :)
[01:07] <\sh> dholbach: well...they are using jabbers dialback which gives problems with some jabber server implementations....thank god ejabberd has it implemented
[01:08] <\sh> there are some interesting threads on jabber-dev ml
[01:10] <\sh> slomo needs to be on planet as well :)
[01:10] <\sh> grmpf..bbl
[01:13] <crimsun> hmph, my sync requests are still outstanding. elmo must be swamped.
[01:24] <dholbach> Are there still biggies on the list for to-update-before-UVF?
[01:26] <mbreit> ah, btw: what's top of the todo list atm? i think i will have some time today...  so i can get back into motu work ;)
[01:26] <crimsun> dholbach: 'morning. More than likely. I'll check in an hour when I'm off the clock.
[01:27] <dholbach> mbreit: Tomorrow is Upstream Version Freeze.
[01:27] <dholbach> mbreit: so if we have bugs that can be fixed by a new Upstream Version - we should do that today.
[01:28] <dholbach> I want us to concentrate on bug fixing afterwards, not on pondering how to sneak in new upstream versions. :-)
[01:28] <mbreit> dholbach: tomorrow???? i hoped it would be in my semester holidays... when i have some time... it was in the breezy cycle ;)
[01:28] <siretart> dholbach: do you know the status with wine?
[01:28] <siretart> \sh_away: is wine up to date?
[01:28] <dholbach> siretart: no idea to be honest.
[01:28] <dholbach> siretart: but it sounds like a good idea to update.
[01:29] <dholbach> All the games and favourite other stuff too. :-)
[01:29] <dholbach> I did my share of updates yesterday and the day before. :-)
[01:32] <tepsipakki> also universe is affected with UVF at this point?
[01:33] <siretart> tepsipakki: yes
[01:33] <tepsipakki> damn
[01:35] <mbreit> hmm... bunda's package is still in the ftp incoming directory... shouldn't that be emptied every few minutes?
[01:39] <siretart> the cronjob runs every 5 mins
[01:39] <siretart> mbreit: the problem is that he uploaded a binary package.
[01:40] <mbreit> siretart: oh.. okay, i didn't see that
[01:40] <siretart> bunda: please upload source packages only. the incoming script does react to '*_source.changes' only
[01:41] <mbreit> siretart: i think that is my mistake... i am sitting next to him...
[01:41] <mbreit> siretart: shall i clean his files from the incoming directory?
[01:44] <siretart> mbreit: yes. the ftp server config does not support deleting/overwriting files. I did not figure out how to get vsftpd to do that
[01:45] <mbreit> siretart: thanks... and sorry again ;)
[01:45] <siretart> mbreit: the permissions on the incoming dir are scrwed up anyone. If you know about vsftpd config, feel free to set owner and permissions to more reasonable values
[01:45] <siretart> s/anyone/anyhow/
[01:46] <siretart> no need to sorry. I'm to lazy to fix that. thats the problem :)
[01:46] <mbreit> just one issue: can I add bunda as a user on revu?
[01:47] <mbreit> just for revu1 of course.. i do not mean a shell account!
[01:49] <sivang> Is Chris Moore here?
[01:49] <siretart> mbreit: sure. in /srv/revu/scripts there are scripts 'alter_user.py' and 'register_user.py' for that.
[01:50] <mbreit> siretart: thanks
[01:50] <siretart> mbreit: call them without args for help
[01:50] <siretart> mbreit: if you are interested into the details, loop at process_uploads.sh script, thats the script thats run every 5 mins
[01:50] <mbreit> i've just read that last script ;)
[01:52] <siretart> :)
[01:54] <mbreit> Adding failed, User wienczny@uni-paderborn.de already in database?
[01:54] <mbreit> Excption string is:
[01:54] <mbreit> ERROR:  duplicate key violates unique constraint "users_email_key"
[01:54] <siretart> mbreit: users are created on first package upload automatically
[01:55] <siretart> mbreit: you might also want to fire up 'psql -U revu revu' for direct sql access. password is in the config file
[01:55] <mbreit> siretart: the lost password script does not give a password for his adress...
[01:55] <siretart> gnarf. perhaps again a permissions issue :/
[01:58] <siretart> mbreit: is that a signing only key?
[01:58] <siretart> gpg: wienczny@uni-paderborn.de: skipped: unusable public key
[01:58] <mbreit> huch?
[01:58] <siretart> revu doesnt work with them
[01:58] <mbreit> it's not a signing only key
[01:59] <siretart> strange
[02:00] <Kyral> morning
[02:01] <Kyral> Is LP down for anyone else?
[02:01] <persia>  Kyral: It's intermittent for me.
[02:02] <Kyral> hmm
[02:02] <Kyral> maybe this would explain why my @ubuntu stopped working...
[02:03] <Kyral> are anyone elses's redirects not working?
[02:05] <lfittl> Kyral: <elmo> ...: your ubuntu.com email has been disbaled because it's looping back, please change your preferred email to something other  than you@ubuntu.com
[02:05] <Kyral> oh
[02:05] <Kyral> oops *reddens*
[02:06] <Kyral> as soon as LP comes back I'll change it
[02:06] <lfittl> ;)
[02:06] <Hieronymus> Can anyone tell me why this watch file is not working? (http://paste.ubuntu-nl.org/7321) with uscan output (http://paste.ubuntu-nl.org/7322)
[02:07] <Kyral> I assume once I change it the auto acript thing will kick in
[02:08] <lfittl> yep
[02:08] <Kyral> Mega Man on the brain
[02:09] <StevenK> Whee, my u.c works too.
[02:09] <StevenK> Now, how to hack Elisp.
[02:09] <tseng> Mega Man X2
[02:10] <Kyral> good game
[02:36] <marcin`> hello guys now I got my first package in /var/cache/pbuilder/result
[02:37] <marcin`> and also configured dput to use revu
[02:37] <marcin`> but... wtf should I upload?
[02:37] <StevenK> The .changes file
[02:38] <dholbach> if you have the bash completion on, dput <tab> <letter><tab>  should take you there :)
[02:38] <dholbach> maybe another <letter> helps too ;)
[02:38] <StevenK> Or use a better shell, like, say, zsh.
[02:39] <marcin`> heh...No signature on /var/***.changes
[02:40] <StevenK> I'm unsure if REVU needs a signature.
[02:41] <StevenK> If it doesn't, you can force the upload.
[02:43] <marcin`> StevenK: do I need also use -S -sa options with dput to upload to REVU?
[02:44] <marcin`> StevenK: and I'm affraid that it requires signature
[02:48] <dholbach> Yes, -S -sa.
[02:48] <dholbach> REVU doesn't keep the .orig.tar.gz.
[02:51] <marcin`> ehh
[02:52] <marcin`> you know guys... I would like to contribute but it's _little_ annoying :(
[02:52] <StevenK> Just takes a little time and effort to learn.
[02:52] <siretart> dholbach: it won't throw it away either
[02:52] <marcin`> dput -S -sa *.changes -> -S option not recognized
[02:52] <StevenK> Back in my day, we had to push packages uphill both ways in the snow to upload them.
[02:52] <siretart> marcin`: the -S -sa options are for dpkg-buildpackage
[02:53] <marcin`> siretart: but I use pbuilder to build package....
[02:54] <StevenK> pdebuild --debbuildopts '-S -sa'
[02:54] <marcin`> StevenK: ok thanks
[02:55] <marcin`> so what now with this gpg key?
[02:55] <marcin`> I have some keys.. I generated them about a year ago to register in launchpad...
[02:56] <marcin`> but to be honest I don't remember how to use these keys with packaging and mail
[02:56] <marcin`> what should I send to REVU to register?
[03:05] <Hieronymus> marcin`: you need to mail something@tauware.de I'll look it up for you
[03:06] <Hieronymus> keyring@tiber.tauware.de
[03:07] <Hieronymus> Ask for upload rights, mention your keyID and sign the message.
[03:07] <Hieronymus> This is probably also on the wiki
[03:09] <tepsipakki> the 'passwd-recover' on REVU isn't working like it should, I think
[03:09] <tepsipakki> after "Now paste the text..." there's nothing
[03:13] <siretart> marcin`: it is okay to tell me your keyid, too, if I'm around
[03:16] <marcin`> ok guys.. I know that it's on wiki - but (I hope so) I can create packahe
[03:16] <marcin`> package but I'm dumb when coming to gpg keys etc.
[03:17] <marcin`> I don't know how to get this 'keyid' thing
[03:17] <marcin`> anyway I'll read about it again and try to reconfigure evolution to use gpg again
[03:17] <mbreit> tepsipakki: we had a problem with that feature a few hours ago, but it's working for example for my login..
[03:22] <tepsipakki> mbreit: seems not to work for me :/
[03:22] <Lathiat> Any XFCe people about?
[03:23] <mbreit> tepsipakki: are you a new user or has it been working before?
[03:23] <tepsipakki> new
[03:25] <mbreit> tepsipakki: then i would guess it's the same bug... or do you have a signing only key?
[03:26] <Lathiat> hrm, packages.debian.org being down is proving to be a PITA
[03:26] <tepsipakki> mbreit: my gpg-key? it's a full-blown version afaik?
[03:27] <mbreit> tepsipakki: i have no idea where that bug is...
[03:27] <azeem> Lathiat: try packages.debian.net/<foo>
[03:28] <azeem> it's pretty slow though, and I am not sure whether it is really uptodate
[03:28] <jamessan> azeem: I didn't think searching like that was working
[03:28] <Lathiat> azeem: hrm
[03:28] <Lathiat> im just going to install an unstable chroot i thin
[03:28] <Lathiat> k
[03:28] <azeem> nah, it is uptodate
[03:28] <azeem> (note the .net)
[03:29] <jamessan> ah
[03:29] <jamessan> :)
[03:29] <mbreit> tepsipakki: what's your email?
[03:29] <tepsipakki> mbreit: I do get "IOError: [Errno 32]  Broken pipe" -errors occasionally when I try the recover
[03:29] <azeem> Lathiat: packages.debian.org/unstable/<section>/<package> works as well
[03:29] <azeem> (this time with .org)
[03:29] <azeem> those are the static pages which are still there
[03:29] <tepsipakki> mbreit: in REVU it's tjaalton@ubu.hut.fi, real one is @cc.hut.fi
[03:30] <Lathiat> going to linux.conf.au
[03:30] <Lathiat> now i have a passport i can get my key signed
[03:30] <Lathiat> followed by be abel to finally actualy upload to universe
[03:30] <Lathiat> and can get cracking again :)
[03:31] <mbreit> tepsipakki: i don't see that email address in the keyring...
[03:31] <tepsipakki> aaah
[03:31] <tepsipakki> =)
[03:32] <tepsipakki> tja@iki.fi worked..
[03:32] <tepsipakki> somehow I thought it took the email from the upload-data
[03:32] <mbreit> _that_ is in the keyring... i searched for "tjaa", so i did not find that *g*
[03:33] <tepsipakki> ..in .changes I had tjaalton@ubu.hut.fi
[03:34] <\sh> grmpf
[03:34] <\sh> siretart: what we need is a similar database like this one http://secure-testing.debian.net/debian-secure-testing/project/debsecan/release/1/
[03:34] <\sh> siretart: debsecan
[03:34] <siretart> \sh: right. we don't have that right now, my question was if somebody is willing to do that for ubuntu
[03:35] <\sh> siretart: if I can convince pitti to work on that database as well, no problem.
[03:35] <siretart> \sh: I think he is pretty busy, but you can try
[03:35] <\sh> siretart: and I have to try to get the format of this zlib compressed database...it's not gunzipable
[03:36] <\sh> siretart: what I need is the actual content of the database...so I have to check what's inside..but so or so, there is not a lot of differences
[03:39] <Yagisan> \sh: see my mail ?
[03:40] <\sh> yes..
[03:40] <Yagisan> \sh: I'll see if he says no
[03:40] <Yagisan> \sh: it's funny - I got your mail after I sent mine
[03:43] <Yagisan> siretart: I probably could do the work for that - assuming I have access to the needed resources
[03:43] <mbreit> siretart: i have found the problem we had with revu saying "unusable public key"... his subkey has expired some days ago ;)
[03:43] <siretart> mbreit: oh :)
[03:44] <\sh> Yagisan: we have to update this database and change the url for this. and adding ubuntu release names to the source..which is the easy task...it's just python
[03:44] <Lathiat> \sh: about?
[03:44] <Lathiat> yes :)
[03:44] <Lathiat> jabberd2
[03:44] <Lathiat> https://launchpad.net/distros/ubuntu/+source/jabberd2/+bug/3526
[03:44] <Ubugtu> Malone bug 3526: "SQL script are not shiped" Fix req. for: jabberd2 (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: Unconfirmed
[03:45] <Lathiat> just fixed that, seem reasonable to you?
[03:45] <Yagisan> \sh: found the database http://svn.debian.org/wsvn/secure-testing
[03:45] <\sh> Lathiat: fix it and upload :)
[03:45] <Lathiat> \sh: i cant upload, care to? :)
[03:45] <\sh> Lathiat: sure...debdiff?
[03:45] <Lathiat> \sh: yep gimme a couple
[03:46] <Yagisan> \sh: that database won't have ubuntu only .debs in it
[03:46] <\sh> Yagisan: we will put everything inside...
[03:47] <Lathiat> just waiting for pbuilder to put itself together
[03:47] <Lathiat> i need a faster net connection :)
[03:52] <\sh> Yagisan: let
[03:52] <\sh> grrr
[03:53] <\sh> Yagisan: let's take debians database and add our changes
[03:53] <siretart> that would be great and perhaps the best solution
[03:53] <Yagisan> \sh: I'd like to grab the tools too, *now* in case they disappear
[03:54] <\sh> Yagisan: if you want to work on it do it :)
[03:55] <Yagisan> \sh: sure - it's my interest (relates to my day job) - I'll go for it
[03:55] <mbreit> hmm... look like everything i would like to have in dapper before uvf is already in, so what else could i do now?
[03:55] <Yagisan> \sh: I'm not much of a coder, so if I need help I'll give a yell
[03:55] <\sh> Yagisan: see florians mail
[03:56] <\sh> Yagisan: would be cool if we can work it out...collaboration between debian security team and ubuntu
[03:56] <\sh> Yagisan: so we could use one database
[03:56] <Yagisan> \sh: I got a reply ?? hasn't arrived here yet
[03:57] <\sh> Yagisan: I have it already :)
[03:57] <Yagisan> \sh: cool. just arrived
[03:59] <Yagisan> \sh: ok - however - not being an ubuntu member I can't speak on behalf of the project
[04:01] <\sh> Yagisan: ok...talk to pitti about how we can easily take the ubuntu-cve data from him to inject them
[04:02] <Yagisan> \sh: will do. You also interested ?
[04:02] <\sh> Yagisan: secondly, we need a detailed plan, if debian security doesn't want to work with us..so if there is the possibilty to have debians security database + our changes as ascii diff somewhere..great:)
[04:02] <Yagisan> \sh: I need to go to bed soon - taking daughter to the doctor in 5hrs
[04:02] <\sh> Yagisan: I can help, yes :) interested in the sense of "I could need this tool for server administration" much better :)
[04:02] <Yagisan> \sh: of course
[04:03] <\sh> Yagisan: ok...trying to gather all information we need
[04:03] <\sh> Lathiat: ready?
[04:03] <Yagisan> \sh: if it's all from public data and they don't help we should be able to regenerate it if needed
[04:04] <Lathiat> pvbuilder just finished making
[04:04] <\sh> Yagisan: well...the source of the data of debian is public..so we can use this data + add data from us..seeing that the base of the db is ascii, we can maintain diffs
[04:05] <\sh> ah...btw...yestday, did someone raised the issue because of UVF exceptions and who can discuss them with mdz/kamion?
[04:05] <siretart> \sh: yes
[04:06] <\sh> siretart: ok..candidates approved?
[04:07] <Hieronymus> mbreit: I bet lots of people would like to have amsn 0.95 in dapper because it has webcam support
[04:07] <Hieronymus> and audio too, I think
[04:07] <siretart> \sh: the candidates weren't mentioned, so we decide on that (already done). no problem on that side
[04:08] <\sh> siretart: ok..so it's you, slomo, dholbach , ogra, ajmitch , and?
[04:08] <siretart> sistpoty and crimsun
[04:08] <\sh> cool :)
[04:08] <\sh> very good :)
[04:10] <mbreit> Hieronymus: that is just a merge with debian, right?
[04:10] <Hieronymus> mbreit: 0.95 is in Debian
[04:10] <siretart> \sh: is wine in dapper up to date?
[04:10] <Kyral> the autoscript is working again?
[04:10] <lucas> Kyral: who deals with those address ? I have a problem with mine
[04:11] <Kyral> elmo
[04:11] <lucas> ok, so I pinged the right person, thanks
[04:11] <\sh> siretart: if wine 0.9.5 is latest release, then yes :) and 0.9.5 is the last released wine :) so yes :)
[04:11] <hub> ogra: I couldn't find the source tarball for pimp
[04:11] <ogra> hub, hmm, let me look ...
[04:11] <siretart> great
[04:11] <Hieronymus> mbreit: but http://packages.debian.org/unstable/x11/amsn says it's only there for kfreebsd-i386 :/
[04:11] <Kyral> lucas: if he pings back mind telling him I'm sorry for messing up the redirect..
[04:12] <hub> ogra: the ftp server is down
[04:12] <ogra> hub, yes thats intentional
[04:13] <lucas> Kyral: ok, will do
[04:13] <\sh> Hieronymus: it's not in debian linux yet...only in debian freebsd
[04:13] <ogra> hub, http://www.grawert.net/software/pimp/pimp-0.1.6.tar.gz
[04:13] <mbreit> Hieronymus: i don't see any build-log for x86 for that version...
[04:13] <hub> ogra: thx
[04:13] <\sh> Hieronymus: for debian linux only 0.94 is there
[04:13] <Kyral> oh lucas can you review GTKEdit? ;P
[04:13] <ogra> hub, but its not good as a base, just have a look at how it looks and runs for some idea how to write a import tool
[04:13] <lucas> Kyral: I'm busy with real life stuff
[04:14] <ogra> hub, its gtk perl ... and not very good ...
[04:14] <hub> ogra: well it is to have a look
[04:14] <hub> and eventually package it :-)
[04:14] <Yagisan> \sh: I grabbed a copy of the s-t svn repo. I'll look at it when I get some free time today, otherwise if you need me feel free to email me - either my list email or my business email in my sig
[04:14] <lucas> ah ;)
[04:14] <hub> ogra: I already have my ideas
[04:14] <mbreit> Hieronymus: debian buildd says it built fine on ppc for example
[04:14] <ogra> hub, great ...
[04:14] <\sh> Yagisan: sure :) good night :)
[04:15] <ogra> hub, it was originally only a personal interim solution when usb storage cameras were not supported ...
[04:15] <ogra> hub, but it has a userbase ..
[04:16] <Lathiat> \sh: hrm
[04:16] <Lathiat> \sh: db-setup.mysql and oracle seem to magically get .gzd, yet .pgsql doesnt?
[04:16] <\sh> Lathiat: hmm...check dh_compress somehow in rules file?
[04:17] <Lathiat> there is no dh_compress
[04:18] <\sh> Lathiat: let me check one moment
[04:24] <Lathiat> \sh: http://bur.st/~lathiat/jabberd2-3526.debdiff -- works fine just weird 2 are .gz and one isnt, i'm going to bed now i'll see tomorrow
[04:24] <mbreit> Hieronymus: I will merge amsn...
[04:24] <\sh> mbreit: have fun...you have to take all actual plugins from the amsn-0.94 directory
[04:25] <\sh> mbreit: because in the default release source tarball there is only 3 of those plugins and not 10 or more just like in debian :)
[04:25] <mbreit> \sh: what's the problem?
[04:25] <hub> \sh: this Debian guy is a real ****
[04:25] <mbreit> \sh: wtf...
[04:26] <\sh> mbreit: you have to try if the plugins for 0.94 are still working with 0.95
[04:26] <\sh> mbreit: or forget the plugins at all :)
[04:26] <\sh> mbreit: which will give more complains
[04:27] <mbreit> \sh: in debian amsn package, there are only 3 subfolders in plugins/
[04:28] <\sh> mbreit: then he patched everything via diff.gz
[04:28] <\sh> fun
[04:29] <\sh> *gnarf*
[04:30] <\sh> hahha..yes he moved everything in to diff.gz fantastic
[04:30] <\sh> lol
[04:30] <mbreit> \sh: there are no plugins in diff.gz?
[04:30] <mbreit> at least for 0.95
[04:30] <\sh> mbreit: there are a lot in it :)
[04:31] <\sh> in 0.94
[04:31] <\sh> where did you get the 0.95 source package?
[04:31] <mbreit> debian
[04:31] <mbreit> http://ftp.debian.org/debian/pool/main/a/amsn/
[04:31] <\sh> mbreit: hmm..yes...so he changed everything
[04:33] <mbreit> \sh: but still the orig.tar.gz is bigger than the upstream tarball *sigh*
[04:34] <\sh> hehe
[04:35] <mbreit> I don't think that I want to touch that package....
[04:36] <\sh> mbreit: try to build ?
[04:37] <mbreit> so should i keep the tarball from debian?
[04:37] <\sh> mbreit: and check if https://launchpad.net/distros/ubuntu/+source/amsn/+bug/5089 is fixed :)
[04:37] <Ubugtu> Malone bug 5089: "[patch]  amsn .desktop file is old, not valid" Fix req. for: amsn (Ubuntu), Severity: Normal, Assigned to: MOTU Instant Messaging, Status: Fix Released
[04:38] <mbreit> i did
[04:38] <Hieronymus> it has no Version
[04:38] <mbreit> it is fixed, so we could request a sync with debian
[04:38] <mbreit> *if* it builds...
[04:39] <\sh> mbreit: try it :) for what are you here :)
[04:39] <\sh> Lathiat: uploaded
[04:39] <mbreit> \sh: well, I can't do everything at once ;)
[04:40] <\sh> mbreit: lol
[04:40] <\sh> mbreit: why the gods of unix invented multiple terms and screen?
[04:40] <\sh> heheh
[04:42] <mbreit> \sh: useless with only two hands ;)
[04:43] <\sh> mbreit: true :)
[04:44] <Hieronymus> it seems to work
[04:45] <mbreit> Hieronymus: you are too fast... I am still updating pbuilder ;)
[04:57] <mbreit> Hieronymus: looks like amsn 0.95-1 builds and works on amd64, can't test logging in 'cause I don't have a msn account
[04:58] <mbreit> but I'll request a sync from elmo anyway
[05:01] <Hieronymus> mbreit: I logged in
[05:01] <Hieronymus> amd64 as well
[05:03] <mbreit> email to elmo has been sent
[05:05] <mbreit> so what's next on the todo list?
[05:42] <\sh> laters.
[06:56] <\sh> lucas: please don't overreact only because a package maintainer said something...we have to concentrate on our distribution first, and then the rest. gparted is main, and it always had 0ubuntuX versions.
[06:57] <\sh> lucas: most of the main packages (gnome/kde) have those numbers and are different from those in ubuntu...but the gnome/kde teams are working with debian teams on those packages...so everything is fine.
[06:57] <dholbach> \sh: I discussed this with lucas. We might consider this as a process and at least, it should be documented.
[06:57] <dholbach> \sh: I proposed to take gparted as an example, because it was my 'fault'.
[06:58] <dholbach> It's certainly not a 'must'.
[06:58] <dholbach> But it's good if people know, how they 'could' do it.
[06:58] <\sh> dholbach: the problem is, those inquieries like joeys or others will increase, and that is the worst outcome of all this rants and flames
[06:59] <dholbach> You can't relate bug reports to rants.
[06:59] <\sh> dholbach: i'm only concerned, that we have to do more "legal" stuff, then everything else. Those incidents are really destroying the workflow
[06:59] <dholbach> Yes, we shouldn't make it a requirement.
[07:00] <dholbach> We don't want no MOTU police watching over people and what they do. But it's good to have it documented and the more people do it, the better.
[07:01] <\sh> dholbach: I don't say that we should not file bug reports, I don't want that "people coming over the sea, because somehow they see their furs swimming, and giving us more work with thinking about legal stuff then to do our work". If there is a solution for feeding the trolls@debian, please let's find it, and everybody can go back to work. right now, it's just a barrel with black powder
[07:01] <ogra> \sh, you totally misunderstood joeys mail
[07:02] <\sh> ogra: libmetakit was my incident today. it cost me more time to reply and explain the process, then everything. for a change which wasn't important to debian at all, and for a package where the next revision will be a sync. thx
[07:03] <ogra> why do you guys care one day before UVF for such political stuff ?
[07:03] <\sh> ogra: I did understand his concerncs, he has a point.
[07:04] <ogra> \sh, he only said that he puts people reporting bugs for his software in foreign distros to his killfile
[07:04] <\sh> ogra: that wsa the 2nd mail today.
[07:04] <\sh> please read the 1st
[07:04] <ogra> ...as long as the distro makers dont remove his name
[07:04] <ogra> i talk about the first
[07:05] <\sh> ogra:
[07:05] <\sh> Please consider ALL code written/maintained by me that is present in
[07:05] <\sh> Ubuntu and is not bit-identical to code/binaries in Debian to be not
[07:05] <\sh> suitable for release with my name on it.
[07:05] <dholbach> \sh: I just wanted to explain the gparted bit.
[07:06] <\sh> the first paragraph of the mail is not important, the second paragraph is even more important, because he has a point there
[07:06] <ogra> \sh, you omit the second paragraph
[07:06] <dholbach> \sh: and I think it's ok to explain the process.
[07:06] <\sh> ogra: it's the second. the first is with the killfile
[07:06] <ogra> yes, but you miread it
[07:06] <\sh> dholbach: for sure.
[07:06] <dholbach> Cool.
[07:06] <dholbach> So that's sorted out.
[07:07] <\sh> dholbach: but we have to respect, that "first comes ubuntu, then the rest" (that is my thinking(
[07:07] <\sh> ogra: ok..how would you read the second paragraph?
[07:08] <ogra> i would read the whole mail as mentioned above
[07:08] <ogra> and Kamion with whom i discussed it reads it the same way ....
[07:09] <\sh> ogra: can you ask him? I tried to reach joey via email, but he 1. refuses to answer, 2. I don't have name ,)
[07:09] <\sh> 3. I'm in his killfile
[07:09] <ogra> just answer his mail in the ML
[07:09] <\sh> ogra: nope...I don't answer anymore on d-d
[07:09] <ogra> i dont think he killfiles mailing lists
[07:10] <ogra> on -motu i mean
[07:11] <\sh> ogra: i did already :)
[07:11] <\sh> Message-Id: <200601170708.21709.sh@sourcecode.de>
[07:15] <ogra> and i 100% agree that we dont need a MOTU police like the one that seems to form here recently
[07:15] <Hieronymus> facecrime!
[07:16] <dholbach> I'm sure most of us don't want it and we have to keep this in mind. What I love about MOTU is, that it changes and copes with the different types of load, it's not static - let's all try (whenever we change) to keep low hierarchies and little amount of policies in mind and it'll all be good.
[07:16] <ogra> dholbach,++++++++++++
[07:17] <ogra> lets not morph MOTU in a debian subproject with all its bureocracy and annoyances please
[07:17] <seb128> you should educate people
[07:17] <seb128> no need of anything paper for that
[07:17] <ogra> seb128, exactly
[07:18] <seb128> just make clear that everybody wins by lowering the delta with Debian
[07:18] <ogra> seb128, nice to see you here btw :)
[07:18] <dholbach> May I introduce star educator MAAAAAAAAAGIIIIIIIIIC SEEEEEEEEEEEB :-)
[07:18] <ogra> seb128, yes, but not force people to do so
[07:18] <seb128> ie: sending useful fixes to <package_name>@packages.debian.org
[07:18] <seb128> or to the BTS
[07:19] <seb128> and not changing for little details like a typo fix or a desktop file, etc
[07:19] <\sh> seb128: so define: what is useful?
[07:19] <ogra> but we made this always optional and thst what makes MOTU attractive for many people
[07:19] <\sh> seb128: cxx transition renames?
[07:19] <seb128> yeah
[07:19] <ogra> seb128, recently people come in new and start writing policies which is not right imho ...
[07:20] <Kyral> Giving back is nice....but if you don't wanna send it to Debian..I'll be more than happy to for you ;P
[07:20] <seb128> that's a matter of godd sense
[07:20] <seb128> that's like working with upstream
[07:20] <seb128> you should know when a patch is a distro hack
[07:20] <seb128> or should go upstream because it fixes something
[07:21] <seb128> Kyral: what do you mean? happy to keep a divergence?
[07:22] <\sh> seb128: I send patches for the source stuff towards debian and upstream
[07:22] <Kyral> seb128: No, I mean if you don't wanna file an ITP for it in Debian, I'll file the ITP for you and maintain it in Debian :P
[07:23] <\sh> seb128: but trivial package renames will go away for the next release cycle or when debian is switching to new technologies like modular xorg or python2.4
[07:23] <\sh> packages in ubuntu but not in debian is again another story.
[07:27] <lucas> \sh: I'm not overreacting, I'm just saying that you were off topic
[07:27] <lucas> we you improve somebody else's work, it's good practice in the FLOSS community to notify him
[07:28] <lucas> that's what we do when we package a newer upstream release
[07:28] <seb128> Kyral: I bet you have a limit of what you can "maintain"
[07:28] <seb128> Kyral: or is "maintain" just uploading and not carring about the bugs coming next?
[07:29] <lucas> \sh: imagine you are a Debian maintainer. V 0.1 is packaged in Debian. You package 0.2 and then discover that all the work was already done in Ubuntu. How would you react ?
[07:29] <seb128> lucas: I disagree with that. Should I send 40 mails to the BTS every 2 weeks to notify every GNOME packager we are working on the new unstable version of their package?
[07:29] <\sh> lucas: sure...but it should be the decision of the creator of the package. and I think that most of the stuff in main is cared for, that those things are going back to debian. dholbach can whip me, when I'm wrong :)
[07:29] <lucas> seb128: we are discussing universe packages hre
[07:29] <seb128> lucas: same issue
[07:30] <Kyral> seb128: I'll fix bugs
[07:30] <Kyral> if possible
[07:30] <Kyral> ifnot I send to upstream :D
[07:30] <\sh> lucas: well, I would look first over my shoulder
[07:30] <seb128> if the new version is running dch -i and uploading no need to send a mail imho
[07:30] <Kyral> but I really should get back to classwork
[07:30] <ogra> hey, we have 24h until UVF, is it really the time for political discussions ?
[07:31] <\sh> lucas: not doing the work first and then looking.
[07:31] <\sh> lucas: but this is how I work.
[07:31] <lucas> it's not about politics, it's about improving processes so we actually have less work to do
[07:32] <ogra> lucas, for me its general chatter that could be done at a more appropriate time ...
[07:32] <lucas> seb128: btw, your example is wrong, since you are packaging gnome in debian too ;)
[07:32] <ogra> not 24h before an important deadline
[07:33] <seb128> lucas: not by myself and not everything :)
[07:34] <dholbach> People: get in all the crazy new stuff you want to instead of asking ogra and me in the next days, kthxbye.
[07:34] <dholbach> :)
[07:34] <ogra> ;)
[07:36] <tseng> iirc there are a few more people that can approve new upstreams
[07:36] <tseng> although i have yet to see a clear list
[07:36] <tseng> or at least the same list twice
[07:36] <ogra> tseng, sure, but still we have a date for UFV and every exception requires extra eyeballing and manpower
[07:37] <ogra> and surely some frustration for the denied packages
[07:41] <\sh> not to be in the line :)
[07:43] <dholbach> What about the wine update?
[07:43] <\sh> to 0.9.5?
[07:43] <bddebian> Heya gang
[07:43] <dholbach> HEY bddebian!
[07:43] <bddebian> Daniel!!!!!
[07:43] <dholbach> Just in time for UVF! :)
[07:43] <\sh> BARRY
[07:43] <bddebian> I heard. :'-(
[07:43] <bddebian> Heya \sh
[07:44] <\sh> dholbach: latest release of wine is in dapper
[07:44] <dholbach> Cool.
[07:44] <\sh> dholbach: since 2 weeks or so? i don't remember
[07:45] <dholbach> There was some chatter about this morning, so I thought I'd ask.
[07:45] <dholbach> We should grep through our MOTU bugs and see if there's urgent stuff to update.
[07:45] <\sh> ogra: btw...ssh -X works again, and I can't reproduce the bug with wine over remote
[07:46] <\sh> ogra: the bloody amd64 box needed a stupid reboot
[07:47] <\sh> ogra: DCOM98.exe (the installer of the bug reporter in edubuntu) does work perfectly, but the application or dll itself, can't be installed, because by default wine things it's 95 and not 98 or NT :)
[07:47] <\sh> s/things/thinks/
[07:48] <bddebian> DCOM98?? WTF? :-)
[07:48] <LaserJock> Kyral: so did you set your @ubuntu.com address as your preferred address in LP?
[07:51] <\sh> ok going back to "sending mails with cvs to companies :("
[07:51] <\sh> laters
[07:51] <robotgeek> LaserJock: question
[07:51] <LaserJock> yeah
[07:52] <robotgeek> LaserJock: http://www.pyrorobotics.org/
[07:53] <robotgeek> I would be willing to build Ubuntu package for this program, and all it several recommends
[07:53] <robotgeek> I don't think it's in debian yet
[07:53] <LaserJock> robotgeek: make sure to check out the license, but it looks pretty cool
[07:54] <LaserJock> robotgeek: well, check for ITPs or RFPs
[07:54] <robotgeek> LaserJock: i have a basic listing here, if you are interested. http://robotgeek.org/wiki/Main/PyroInstallation
[07:54] <ogra> \sh_away, you'll need ltsp, ssh -X isnt enough
[07:54] <ogra> but thats not a UVF task anyway ... i'll do some testing the next weeks
[07:55] <dholbach> YAY, GO ME!
[07:55] <ogra> go dholbach go !
[07:55] <ogra> (run forest run) :)
[07:55] <dholbach> There's a HUG DAY in three days?
[07:56] <robotgeek> 21'st, Bug Day, right?
[07:56] <dholbach> Nobody invited me.
[07:56] <bddebian> Heh
[07:56] <dholbach> Or you mean the Party I'm about to have at my place? :)
[07:56] <dholbach> robotgeek: I think it was 21 December, no?
[07:57] <robotgeek> damn, i missed it by over a week. 11th Jan, *sigh*
[07:57] <dholbach> We'll have a new one, don't worry. :)
[07:57] <robotgeek> well, alteast i scared you folks for a moment
[07:58] <bddebian> Didn't scare me, I'm useless lately :'-(
[07:59] <bunda> hi
[07:59] <mbreit> hi bunda ;)
[08:01] <LaserJock> ajmitch: ping?
[08:02] <LaserJock> robotgeek: pyrobot seems to be GPL and I can't find an ITP or RFP for it looks like fair game :-)
[08:03] <bunda> Does somebody have some time to do a review of my package cdpr?
[08:03] <LaserJock> robotgeek: you might try emailing the authors with your intentions, sometimes you need to get info from them so it is good to open a line of communication
[08:03] <robotgeek> LaserJock: HMm, i have to contact a lot of people. But will do so
[08:04] <robotgeek> about 7 packages, in all i think
[08:04] <LaserJock> robotgeek: ?
[08:04] <LaserJock> robotgeek: don't you just need to do pyrobot?
[08:04] <robotgeek> LaserJock: pyrobot acutally brings togehter about 6 other simulator packages
[08:05] <robotgeek> i think all of them are gpl
[08:05] <LaserJock> robotgeek: but do you need to package each seperatly?
[08:06] <robotgeek> LaserJock: yes, cause it's not really a dependency, and the simulators are from different places (Stanford, UCB etc)
[08:07] <mbreit> hey bddebian! (still around?)
[08:07] <LaserJock> robotgeek: anyway, if you can come up witha a source package it would be cool
[08:08] <robotgeek> LaserJock: i'll see what i can do. This has been one of my goals, but i've attained some confidence only now.
[08:08] <robotgeek> as always, i can bug you guys :)
[08:08] <LaserJock> sure
[08:08] <bunda> does anybody here have some time for a small review?
[08:10] <raphink> bunda: give it to me
[08:10] <robotgeek> i will attack the issue after my CategoryCleanups. later all
[08:11] <raphink> hmm I mean if you want, I can do it ;) just give me the url ;)
[08:11] <bunda> raphink http://revu.tauware.de/details.py?upid=1533
[08:11] <raphink> ok
[08:13] <bddebian> mbreit: Yep, sorry
[08:16] <pef> ocbook2x-man kvpnc.1.docbook
[08:16] <pef> I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd
[08:16] <pef> does anyone has this problem ?
[08:17] <pef> someone oups
[08:22] <LaserJock> could I get somebody to pastebin the output of "ls /etc/cron.daily" ?
[08:22] <bddebian> bbiam
[08:30] <LaserJock> hi lucas
[08:31] <lucas> re
[08:34] <lfittl> Any MOTU who has some time to review and upload http://revu.tauware.de/details.py?upid=1534 (this fixes malone 3349)?
[08:34] <gborzi> Hello, I need some help for a package (keytouch) I have submitted to MOTU.
[08:35] <gborzi> Is there anyone ?
[08:36] <Gloubiboulga> gborzi, about the config* files ?
[08:36] <gborzi> Yes! I tried the link trick, but it doesn't work.
[08:37] <raphink> bunda: almots done with reviewing your package :)
[08:37] <Gloubiboulga> these file already exist in the orig.tar.gz ?
[08:37] <Gloubiboulga> files*
[08:38] <gborzi> Yes, they are there. And the rules files overwrite them.
[08:39] <Gloubiboulga> gborzi, ask a MOTU to confirm, but I think you can just drop the lines about config.{sub,guess} in debian/rules
[08:40] <raphink> bunda: comments sent ;)
[08:40] <gborzi> Gloubiboulga: thanks for the suggestion, but I think those lines should not be dropped.
[08:40] <gborzi> Otherwise the build will use the upstream author's config.*
[08:43] <Gloubiboulga> :/
[08:43] <Gloubiboulga> It was such a bad suggestion?
[08:48] <LaserJock> so the questions is whether you need to get config.{sub,guess} in the diff.gz?
[08:49] <LaserJock> s/get/keep/
[08:49] <crimsun> you should avoid having it in diff.gz if at all possible
[08:50] <LaserJock> so can you just ignore them, I really don't understand
[08:50] <crimsun> having references to it in debian/rules is fine, though, presuming you b-d on autotools-dev (or something that pulls it in)
[08:51] <crimsun> well ideally upstream refreshes config.{guess,sub} periodically
[08:51] <raphink> I'm just wondering about whether it would be good to have commentaries on REVU sent to the packagers from the reviewer, automagically
[08:51] <LaserJock> sometimes I see that they are in the diff.gz. Is that because of the source package building process?
[08:51] <raphink> so the reviewer can just answer to get more infos for ex
[08:51] <crimsun> LaserJock: pretty much
[08:52] <LaserJock> crimsun: but they aren't needed are they, aren't they just recreated when the binary package is built?
[08:52] <crimsun> raphink: I think that functionality would be useful
[08:53] <crimsun> LaserJock: it's not necessary to have the full contents of config.{guess,sub} in the diff.gz, no.
[08:53] <raphink> crimsun: :)
[08:53] <raphink> sispoty is not here though
[08:53] <LaserJock> raphink: I think that might become a REVU2 feature ;-)
[08:53] <raphink> yep
[08:53] <raphink> if sistpoty wsa here I would suggest him
[08:56] <LaserJock> I think we also need to have more than the email address to identify people. irc or LP names would be nice
[08:57] <tseng> you can add your irc to LP
[08:57] <tseng> and jabber etc
[08:57] <raphink> yep
[08:57] <raphink> although I doubt packagers on REVU look at the LP page of the people who review their packages
[08:57] <Gloubiboulga> I do :)
[08:58] <LaserJock> I'm just saying it's hard to see who is uploading when all we have is their email address
[08:58] <tseng> you could do a lookup and link to the LP person page
[08:58] <tseng> or even switch user auth to LP
[08:58] <LaserJock> hmm, I think LP user auth might also be the plan for REVU2 but I can't remember
[08:59] <Kyral> LaserJock: Yah *redface*
[08:59] <LaserJock> could I get somebody to pastebin the output of "ls /etc/cron.daily" ?
[08:59] <Kyral> late
[08:59] <LaserJock> Kyral: don't worry I did it too, I'm glad I read the irc log ;-)
[08:59] <raphink> LaserJock: yes, when you get a comment on REVU, the name of the MOTU should be a link to his/her LP page
[08:59] <LaserJock> raphink: well, I think the uploader name is important too ;-)
[08:59] <raphink> sure
[09:00] <raphink> so uploaders would need to have an LP account
[09:00] <raphink> which would be good imo
[09:00] <Kyral> LJ did yours get set back yet?
[09:00] <LaserJock> Kyral: I just switched my preferred email back. I didn't get any emails about it or anything
[09:00] <Kyral> yah mine was disabled >_<
[09:02] <crimsun> siretart: ping
[09:03] <siretart> crimsun: pong (but phon)
[09:03] <crimsun> siretart: hi, what's the word on GL{u} b-ds so that we don't have to generate a merge based just on b-ds?
[09:04] <siretart> sorry?
[09:04] <crimsun> siretart: the Build-Depends alternatives so that we can just use Debian's GL{u}
[09:05] <crimsun> i.e., instead of libgl1-mesa-dev|libgl-dev, libglu1-mesa-dev|libglu-dev
[09:05] <siretart> xlibmesa-gl-dev | libgl1-mesa-dev | libgl-dev , libglu1-mesa-dev | libglu-dev
[09:05] <crimsun> siretart: excellent, thanks
[09:05] <siretart> should work for both debian and ubuntu
[09:05] <crimsun> right.
[09:05] <siretart> ah :)
[09:06] <crimsun> I remember you asking infinity in -devel last week, just didn't jot it down
[09:06] <siretart> imo we should introduce a dummy package 'xlibmesa-gl-dev' which just depends on libgl1-mesa-dev
[09:08] <LaserJock> that would certainly save a lot of merge time
[09:10] <mbreit> raphink: about your make target comment: a make target should be named as the file it creates, so make looks if the file does exist and is newer as the source files, otherwise is will build that target...
[09:10] <raphink> thanks mbreit :)
[09:10] <mbreit> raphink: in make, targets who are _not_ files, are the exception ;)
[09:11] <raphink> hehe ok ;)
[09:11] <raphink> well debian/rules usually contains mostly exceptions then
[09:11] <mbreit> so the dot in the target name is right there ;)
[09:11] <mbreit> well, debian/rules is no typical use of make ;)
[10:00] <pkern> ogra: You might want to sync gobby_0.3.0-2 in, which is linked against Avahi, thus providing Zeroconf support, but as Gobby was patched a simple sync probably doesn't work (due to epochs or so); obby_0.3.0-3 would have to be synced in first.
[10:00] <stratus> gobby avahi support sounds nice
[10:01] <pkern> It's only the howl compatibility layer, we haven't yet started to 0.4.x tree containing native support (additionally to howl because avahi is not soon to be ported onto mingw)
[10:04] <stratus> pkern, oh i see.
[10:04] <ajmitch> morning
[10:07] <lucas> debian 0.3.0-2 	 ubuntu 0.3.0-1ubuntu1
[10:07] <ajmitch> does it require a running avahi daemon?
[10:07] <ajmitch> yes I saw that thanks
[10:07] <pkern> ajmitch: Ew. That should be started automatically when it's installed on Debian/Ubuntu?
[10:08] <pkern> ajmitch: And yes, of course it does.
[10:08] <ajmitch> pkern: right - avahi is in main, but we have the policy of no listening ports by default
[10:08] <ajmitch> so the daemon isn't started, iirc
[10:08] <pkern> ajmitch: Well, most probably you're told to start mDNSresponder ;)
[10:09] <ajmitch> is it a runtime option in gobby? :)
[10:09] <pkern> And zeroconf is deactivated for the session
[10:09] <ajmitch> ok
[10:09] <pkern> Yep, but with failure message.
[10:09] <pkern> Currently mapping to howl.
[10:09] <ajmitch> hm
[10:10] <ajmitch> was avahi the only one that's DFSG-free?
[10:10] <pkern> yep
[10:10] <pkern> Howl 2 probably will be, too, taking the free mdnsresponder from avahi.
[10:10] <ajmitch> it gets messy & broken if two stacks try to claim reponsibility
[10:11] <pkern> ajmitch: Yep, currently there's only Avahi included in Debian and Ubuntu, so I see no problem.
[10:11] <ajmitch> yeah
[10:11] <pkern> ajmitch: I'll link against this lib anyway on Linux.
[10:11] <pkern> ajmitch: Against howl on OS X and Windows.
[10:11] <ajmitch> were you talking with the avahi developers recently about mingw?
[10:11] <ajmitch> I saw them talking about it in channel yesterday
[10:11] <pkern> Nope.
[10:12] <ogra> pkern, i'm very swamped currently and UVF is tomorrow
[10:12] <ogra> i couls ask for the sync now and let it fail on the buildds until i have time to fix it though
[10:12] <ajmitch> just saw that mingw's still considered not supported, so you're right :)
[10:13] <ogra> pkern, that would also solve your prob with scotts patches
[10:14] <pkern> ogra: UVF as in Debian as upstream or as in the part before the dash?
[10:14] <pkern> ogra: As this is a minor Debian revision only, no source code changes.
[10:14] <ajmitch> before the dash, actual upstream, AIUI
[10:18] <ogra_> GRRRR
[10:19] <ajmitch> how creative :)
[10:19] <ogra_> it was lying on the terrace ;)
[10:20] <ajmitch> time for me to finish off 4 zope merges & file bugs
[10:24] <lucas> who can add a mysql database for me on tiber ?
[10:24] <ajmitch> umm
[10:24] <ajmitch> you need mysql?
[10:24] <ogra_> #ugh
[10:24] <ajmitch> since it's mostly postgresql at the moment
[10:24] <ogra_> cant you take postgres ?
[10:24] <lucas> no, I'd like to use phpmyedit to store some info
[10:25] <lucas> and it only supports mysql
[10:25] <ajmitch> tiber only has 512MB RAM, so I'm not sure if running postgresql+mysql at the same time is a good thing
[10:25] <lucas> lucas@tiber:~$ w
[10:25] <lucas>  16:24:46 up 40 days, 32 min,  5 users,  load average: 0.00, 0.00, 0.00
[10:26] <lucas> it doesn't seem too loaded right now otoh
[10:26] <ogra_> and phppgadmin wont do it ?
[10:26] <lucas> no it's different
[10:26] <lucas> phpmyedit is about generating some simple table-based webapps
[10:27] <lucas> but anyway, I can start somewhere else
[10:27] <lucas> and move to tiber later
[10:27] <ogra_> would be nice to keep some consistency
[10:27] <ajmitch> ask admin@tiber, the alias goes to those of us who can do it
[10:27] <ajmitch> or ask siretart & sistpoty also
[10:27] <lucas> ogra: consistency like ?
[10:28] <ogra_> staying with one programming language, one database engine etc
[10:28] <lucas> ajmitch: I'll first check that phpmyedit really suits my need
[10:28] <lucas> I've never used it, only heard from it
[10:29] <ogra_> everything on tiber runs python, why add insecurity through php for example ?
[10:29] <lucas> because phpmyedit is written in PHP and uses MySQL ?
[10:29] <lucas> but anyway, I got your point, I'll host it elsewhere
[10:30] <ajmitch> it increases future maintenance workload
[10:39] <pkern> Ok, the next who tells me why the hell the Ubuntu package patches out howl compatibility support gets my personal cheer.
[10:40] <tseng> pkern: uh
[10:40] <tseng> pkern: if you could be specific and less agressive someone might have an answer
[10:40] <tseng> what package?
[10:40] <pkern> tseng: Avahi that is.
[10:41] <tseng> i doubt that it is "patched out" vs not enabled
[10:41] <tseng> but a question for slomo_
[10:41] <pkern> tseng: Removed from the Ubuntu revision of the Debian package out of debian/control.
[10:42] <ajmitch> he did have his reasons, and I think it was meant to be turned back on
[10:42] <Nafallo> doesn't the changelog say why?
[10:42] <pkern> Nafallo: Nope.
[10:42] <pkern> Nafallo: No reason specified.
[10:44] <ajmitch> 10:54 < sebest> and the compat libs are also disable on dapper?
[10:44] <ajmitch> 10:54 < slomo_> but the only reason for that is the 5 (3) years support for main for dapper... and we generally don't want more than one version of something in main
[10:44] <ajmitch> 10:54 < slomo_> yes... also because of the support
[10:45] <ajmitch> because the libs were meant to be supported only for a short time upstream, apparantly
[10:45] <ajmitch> whether that's still true or not, I don't know
[10:46] <pkern> Funny enough for libraries providing backwards support for an old library interface that's by itself unlikely to change, but ok.
[10:46] <ajmitch> I know
[10:46] <pkern> Yes, I also got threatened by the remove in the bug report.
[10:46] <ajmitch> 13:45 < mezcalero> no point in "waiting", since the compat layers are intended to be used *now* and dropped completely later, anyway
[10:46] <ajmitch> 13:45 < mezcalero> we provide it to smooth howl->avahi transition for distributions
[10:46] <ajmitch> 13:46 < mezcalero> because i am too lazy to do the splitting properly, the compat layers will stay until avahi 0.7
[10:46] <ajmitch> so 0.7
[10:46] <ajmitch> whenever that gets done
[10:46] <pkern> "Please integrate, but be aware that we will remove it in a year" <-- Hey come on |:
[10:47] <ajmitch> hardly useful for any sort of platform stability
[10:47] <pkern> Platform stability in Debian was about backporting all the fixes.
[10:47] <pkern> What's the policy in Ubuntu? Taking new upstream versions?
[10:47] <ajmitch> sometimes we have to
[10:48] <pkern> ajmitch: 0.7 would break the ABI anyway I guess
[10:48] <pkern> ajmitch: Which would be a nightmare ;)
[10:48] <ajmitch> like firefox, where it gets increasingly painful to backport security fixes
[10:48] <ajmitch> yeah
[10:48] <pkern> ajmitch: Yes, the lovely Firefox currently also known as Deer Park ;)
[10:50] <pkern> Whoever packaged libcamel1.2-8 some days ago should be lart'ed. *cough*
[10:51] <ajmitch> what did he break? :)
[10:52] <LaserJock> well, I had a conflict when I installed it
[10:53] <pkern> ajmitch: No replaces specified.
[10:53] <LaserJock> I had to remove libcamel1.2-7 fist
[10:53] <pkern> ajmitch: Thus two packages which were not mutally exclusive had the same file.
[10:53] <pkern> ajmitch: dpkg refusing *anything* to do with them.
[10:53] <ajmitch> what other package?
[10:53] <pkern> ajmitch: libcamel1.2-7 vs. libcamel1.2-8
[10:53] <pkern> ajmitch: -8 specifies another ABI, so the library filename should have been changed.
[10:54] <pkern> ajmitch: It wasn't.
[10:54] <pkern> ajmitch: Well, same filename then.
[10:54] <pkern> It seems fixed now, though.
[10:54] <ajmitch> yep
[10:54] <ajmitch> 2 uploads on the same day
[10:54] <ajmitch> I don't follow the bleeding edge closely enough :)
[10:55] <pkern> Hehe.
[10:55] <pkern> I do now, I already lost my clock ;)
[10:55] <pkern> (the one in the panel)
[10:55] <pkern> Came too close to the edge I suppose.
[10:58] <ajmitch> I wonder if we'll get zope 3.2 in main before UVF
[11:00] <ajmitch> morning womble
[11:00] <pkern> ajmitch: 2h left? ;)
[11:00] <ajmitch> pkern: not sure when the autosyncs stop - it was just accepted in debian :)
[11:01] <womble> hey ajmitch
[11:01] <pkern> ajmitch: Autosync against sid or etch?
[11:01] <ajmitch> sid
[11:02] <ajmitch> then we spend the next couple of months regretting what was synced :)
[11:02] <ogra> pkern, we only use sid ...
[11:02] <ogra> always
[11:02] <ajmitch> and experimental in some cases :)
[11:02] <Nafallo> sid and experimental to be totally honest :-)
[11:02] <lucas> MOTUs with upload rights: there are 50 open bugs on https://launchpad.net/people/motureviewers/+assignedbugs?field.searchtext=&search=Search&orderby=-priority%2C-severity&advanced=1&field.include_dupes.used=&field.statusexplanation=&field.status%3Alist=Unconfirmed&field.status%3Alist=Confirmed&field.status%3Alist=In+Progress&field.status%3Alist=Fix+Committed&field.status-empty-marker=1&field.severity-empty-marker=1&field.attachmenttype-empty-marke
[11:02] <lucas> r=1
[11:03] <ajmitch> but those are rare exceptions
[11:03] <ajmitch> lucas: tinyurl, please
[11:03] <lucas> (merges/syncs awaiting reviews)
[11:03] <ajmitch> I don't think I can get all that in :)
[11:03] <lucas> some of them would be worth trying
[11:03] <ajmitch> I know
[11:03] <ajmitch> but make it easy for me to cut & paste :)
[11:04] <ajmitch> & we'll put it in the topic
[11:04] <lucas> http://tinyurl.com/a3qjh
[11:04] <ajmitch> thanks
[11:05] <lucas> wait
[11:05] <lucas> http://tinyurl.com/do8cz
[11:05] <lucas> only fix commited ones
[11:06] <ajmitch> 26, that's an improvement
[11:07] <lucas> some of the other ones are probably relevant too, but let's deal with the correctly reported ones first
[11:08] <lucas> do you know how long it usually takes to get upload rights ?
[11:08] <ajmitch> depends on how busy elmo is
[11:08] <lucas> ok, so probably not before UVF ;)
[11:08] <LaserJock> ajmitch: did you look at my kguitar debdiff?
[11:08] <ajmitch> possibly not
[11:09] <ajmitch> I'm still waiting for him to process a bunch of merges I requested about a week ago
[11:09] <ajmitch> LaserJock: nope
[11:09] <crimsun> same here, ajmitch
[11:09] <slomo_> and same here ;)
[11:09] <ajmitch> hey slomo_
[11:09] <LaserJock> ajmitch: I got to thinking, why don't we just leave the sync/merge alone and keep the Ubuntu version until dapper+1
[11:10] <ajmitch> LaserJock: it depends whether you need the debian changes or not
[11:10] <LaserJock> It's all the same upstream, it's just that Ubuntu and Debian packaged it seperately
[11:12] <lucas> (I like this)
[11:12] <ajmitch> what do you like, lucas ?
[11:13] <lucas> ubuntu and debian packaging the same source, but differently
[11:13] <lucas> i was kidding
[11:13] <pkern> Taking the same source and having separate packaging efforts?
[11:13] <pkern> k
[11:13] <lucas> LaserJock: maybe asking the REVU uploader to merge the changes would be a good idea
[11:13] <ajmitch> pkern: even better, differing orig.tar.gz
[11:13] <ogra> fun
[11:14] <pkern> ajmitch: Who has it right?
[11:14] <lucas> I remember reading the two packages
[11:14] <lucas> both had some stuff right
[11:14] <lucas> so merging would really be great
[11:14] <ajmitch> pkern: same files, different md5sum
[11:14] <ajmitch> but I haven't checked what upstream has
[11:14] <pkern> ajmitch: Right as in, who took the upstream source verbatim
[11:15] <LaserJock> just a sec
[11:15] <pkern> You can't change it anyway, only which a new upstream version.
[11:15] <pkern> fun
[11:16] <ajmitch> enough to drive you to drink
[11:16] <LaserJock> orginal is a tar.bz2, maybe that is the problem
[11:17] <LaserJock> but anyway, I think we should just leave the Ubuntu version and sync next time
[11:18] <LaserJock> as long as there is a new upstream release there is no problem with syncing for dapper+1
[11:18] <pkern> LaserJock: It requires coordination (:
[11:18] <LaserJock> pkern: not really, we should sync on the next upstream release
[11:19] <ajmitch> and that still requires manual intervention
[11:19] <LaserJock> why?
[11:19] <ajmitch> because you still have to know to request the sync then
[11:20] <LaserJock> yes, but that is easier than figuring out why we did a merge in dapper ;-)
[11:20] <ajmitch> not if you have a decent changelog, saying 'sync this on new upstream kthx'
[11:21] <LaserJock> ok, so should I go ahead and send the merge?
[11:21] <ajmitch> might as well
[11:25] <LaserJock> ajmitch: ok so what do I debdiff to?
[11:26] <ajmitch> debian version, and state that when you upload it :)
[11:26] <ajmitch> and then I'll try & get to it eventually :)
[11:26] <LaserJock> but also say that you need to use the Ubuntu .orig.tar.gz?
[11:26] <ajmitch> sure
[11:26] <LaserJock> k
[11:29] <LaserJock> ajmitch: done
[11:33] <OpsVentus> Hello all, I wrote a Sudoku game, any intressed to include this in (K)Ubuntu (it's in Qt so should work on KDE and GNOME)
[11:35] <lucas> how does it compare to ksudoku - sudoku puzzle generator/solver
[11:35] <lucas> (and gnome-sudoku ?)
[11:36] <OpsVentus> havend seen ksudoku and gnome-sudoku used to be in the menu but didn't work and now is removed(also from apt-get)
[11:36] <OpsVentus> it dosn't solv puzzels(but I can work something out)
[11:37] <OpsVentus> but I think it works better
[11:37] <LaserJock> how can you find out who last changed a package?
[11:37] <lucas> ksudoku and gnome-sudoku are available in ubuntu
[11:38] <lucas> can you elaborate "didn't work" ?
[11:39] <lucas> (I've nothing against have 2 kde sudoku games in ubuntu, but it's better to check what are the problems with the existing ones first)
[11:39] <OpsVentus> yes, I try'd to start it, it gave a "starting gnome-sudoku" but then failed
[11:39] <ogra> LaserJock, there are these things called changelogs ...
[11:40] <OpsVentus> then I opened a terminal and did "gnome-sudoku", it gave a error, don't remember what
[11:40] <OpsVentus> but this was Badger
[11:40] <ogra> did you file a bug
[11:40] <ogra> so its fixed in dapper ?
[11:41] <OpsVentus> We'll for me it's simple if we have a good sudoku game, I'm not going to put my version in(I just use it myself)
[11:41] <OpsVentus> I don't know I didn't find it in Breezy
[11:41] <ajmitch> gnome-sudoku works for me
[11:41] <ogra> you just said you had an error
[11:41] <OpsVentus> yes, in Badger
[11:41] <ogra> yeah
[11:41] <LaserJock> ogra: I'm trying to find all the packages I've touched
[11:41] <OpsVentus> upgraded last week
[11:42] <ogra> would have been nice to file a bug to make us aware of it ...
[11:42] <ogra> additionally, i think your game might be a good addition, dont lock it away, OSS is about choice, lets offer it :)
[11:43] <OpsVentus> yes, I think it's an dependence fail, I can try the Live cd, should have the same problem, but if it works now, it's properly allready fixed
[11:43] <lucas> OpsVentus: you could add it to https://wiki.ubuntu.com/UniverseCandidates or package it yourself in REVU
[11:44] <ogra> oh, didnt we switch from UniverseCandidates to support request tickets long ago ?
[11:44] <ajmitch> ogra: if we did, I didn't hear of it
[11:45] <ogra> on the pre last motu meeting
[11:45] <dholbach> does the support tracker support assignments to teams?
[11:45] <ogra> i thought you were there
[11:45] <ogra> no idea
[11:45] <dholbach> if not, that's why
[11:45] <OpsVentus> Well, first I have to finish it(I only use it myself now, so it's missing some stuff like help) then I can put it in UniverseCandidates to see if it's good enough to reach more people
[11:45] <ogra> i only know we talked about it as alternative to set up a RT on tiber
[11:46] <ogra> and i saw siretart telling people to file a support request for a new package the guy wanted, so i thought it was already common practice
[11:47] <ajmitch> I haven't seen any support tickets either
[11:48] <ogra> i havent looked, i just remember the decision to use LP instead of a self maintained RT
[11:48] <ogra> as U-C replacement
[11:49] <Kyral> I hate C...
[11:49] <ogra> you dont like candidates  ?
[11:50] <LaserJock> I don't like UniverseCandidates much, something like the merge list would be great
[11:51] <ogra> LaserJock, thats why we wanted RT
[11:51] <Kyral> no I hate the language ;P
[11:53] <LaserJock> Kyral: hmm, I'm not much of a C fan so I'm thinking of converting our data aquisition software to Python :-)
[11:53] <ogra> cool idea :)#
[11:54] <LaserJock> right now it uses pgplot and ncurses
[11:54] <LaserJock> so I thought I could spruce it up a bit
[11:57] <Des_MM> Hi!, I found a bug in libnotify-dev 0.3 package (on debian and dapper Universe package). The problem is that it doesn't install config.h, so I added $(top_srcdir)/config.h in notifyinc_HEADERS but config.h gets installed in $(includedir) instead of $(includedir)/libnotify.  I think that this if because top_srcdir is ../  Any Ideas?