#ubuntu-motu 2006-01-23
<Kyral> a basic Text Editor should be able to handle all the text/* Mimetypes right?
<LaserJock> beats me
* Kyral shrugs
<Kyral> I'll test it :P
<ogra> did the MOTUGames team see that ?  http://lists.ubuntu.com/archives/ubuntu-users/2006-January/064286.html
<Kyral> Clean Lintian run on both src and deb! Yea!
<Kyral> I cleared away all of ajmitch's complaints about the pack...at least the ones he told me ;P
* Kyral goes to file an ITP for GTKEdit
<Kyral> err
<Kyral> I should hear Upstream's comments on it first
<tseng> if upstream didnt want you to distribut it they wouldnt have made it gpl
<Kyral> Its MIT actually
<tseng> even better
<Kyral> but I had to write a manpage, the control desc etc
<Kyral> I wanted to hear what he thought of my writing lol
<Kyral> But I suppose just filing the ITP couldn't hurt
<LaserJock> and ITP just means you are working on it
<Kyral> yah one thing I was worried about was that the version on the tarball was -b1
<Kyral> and dh_make didn't like that
<Kyral> so in the Debian changelog I have it listed as 0.1
<LaserJock> Kyral: hmm, I don't know about that
<Kyral> yah
<Kyral> Thats why I emailed him ;P
<Kyral> dh_make refused to let the version as -b1
<Kyral> even with -p
<Kyral> in the ITP I'm putting 0.1/b1 as version
<azeem> Kyral: you can rename the tarball to something dh_make likes, run dh_make, then rename it back  (and change debian/changelog)
<Kyral> azeem: there was no dir in the tarball lol
<azeem> no dir?
<Kyral> nope
<azeem> ah, it extracts in .?
<Kyral> literally it was a .c, a Makefile, and a Readme :P
<Kyral> yah
<azeem> what is this?
<azeem> ah, GTKEdit still?
<Kyral> http://revu.tauware.de/details.py?upid=1523
<Kyral> yah
<Kyral> so when I made the dir...
<Kyral> okay so I'll do that and reupload
<azeem> Kyral: I think this whole thing screams "Don't package me! Don't package me!" =)
<Kyral> Azeem lol
<Kyral> I use it on my 3 year old lappy so lol
<Kyral> ITP Sent
<thierry_> how can I clean only one particular file with debhelper?
<thierry_> dh_clean filename ?
<Kyral> rm?
<jamessan> rm -f filename
<jamessan> dh_clean is meant for cleaning up the debian stuff
<thierry_> k
<thierry_> jamessan : but rm isn't for deleting?
<azeem> thierry_: why not?
<jamessan> thierry_: I don't understand the question
<tseng> ogra: hm g-p-m is is dying w/o a trace
<tseng> ogra: do you see it also?
<thierry_> azeem : well I want to clean the file, not deleting it, except if that's the same thing (wich I don't know)
<jamessan> thierry_: well, what do you mean by clean?
<azeem> thierry_: in this context (compiling programs) 'clean' means 'revert to initial state', which means 'remove/delete any newly generated files'
<thierry_> azeem : ho ok!
<LaserJock> Kyral: get that man page done?
<Kyral> LaserJock: yah
<Kyral> in nroff :P
<Kyral> Look at REVU
<LaserJock> Kyral: did you use a Docbook to make it
<Kyral> Nope
<LaserJock> so did you just edit the .1 file itself then?
<Kyral> yah
<Kyral> err no
<Kyral> I wrote it from scratch
<LaserJock> hmm, mine looks a bit different. I used the dh_make generated Docbook and edited it
<Kyral> heh
<LaserJock> It amazes me how many different ways you can do each task in packaging
<LaserJock> which makes writing a packaging guide difficult sometimes >:(
<dholbach> night guys.
<Kyral> ight
<LaserJock> sweet, my @ubuntu.com email works now
<marcin> hello MOTU
<marcin> could someone help me?
<marcin> I would like to build some packages for dapper but I use breezy
<marcin> so I want to configure pbuild
<marcin> and I'm following procedure described on this https://wiki.ubuntu.com/DebootstrapChroot page
<Burgundavia> marcin, have you see the pbuilderhowto?
<marcin> unfortunately sudo debootstrap [--variant=buildd]  [--arch i386]  breezy /var/chroot/ http://archive.ubuntu.com/ubuntu/
<marcin> doesn't want to work because it says that there is no such script as http://archiveblabla
<marcin> Burgundavia: moment I'll try with this stuff
<womble> marcin: You want --distribution breezy ...
<marcin> well in fact I also should file bug report about pbuilder package...
<womble> marcin: Why?  What's it doing wrong?
<marcin> it has MIRRORSITE=http://ftp.jp.debian.org/debian
<marcin> by default
<marcin> well it's not bug in fact but...
<womble> It'd certainly make creating a dapper chroot a little difficult without changing the mirror...
<minghua> marcin has a point there, the ubuntu pbuilder package probably should default to a debian mirror
<minghua> s/should/shouldn't/
<Burgundavia> minghua, patch it
<marcin> pbuilder howto says that I should copy /etc/apt/* to /etc/pbuilder/apt.config/
<marcin> but no word about any changes in these config files..
<minghua> Burgundavia: after UVF, perhaps :-)
<marcin> do I need to change repositories in /etc/pbuilder/apt.config/sources.list to dapper if I want to build packages for dapper?
<LaserJock> yes
<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?
<marcin> ok - thanks
<marcin> well it could be mentioned in howto ;)
<marcin> derekS: apt-get source gajim
<marcin> derekS: and take a look at debian/rules file
<derekS> marcin: thanks
<marcin> in downloaded source directory
<marcin> ok guys
<marcin> yet another problem
<marcin> pbuilder create --distribution dapper
<marcin> says that there is
<marcin> E: No such script: /usr/lib/debootstrap/scripts/dapper
<marcin> 
<LaserJock> marcin: you can edit the wiki at any time ;-)
<LaserJock> marcin: that's because you will need the dapper version of debootstrap
<marcin> so I need to download this manually and install with dpkg?
<LaserJock> what are you running now?
<marcin> breezy
<marcin> my dapper crashed few days ago
<LaserJock> I might just try doing a breezy pbuilder and then dist-upgrading it to dapper
<marcin> I thought that flight 3 could work better
<marcin> but unfortunately #28811
<marcin> LaserJock: no way I don't want to upgrade to dapper
<LaserJock> marcin: no just the pbuilder
<marcin> LaserJock: so apt-get update with dapper repos then install only pbuilder?
<LaserJock> no, you can change the pbuilderrc and pbuilder sources.list and pbuilder update
<LaserJock> I think it is on the how to wiki page
<marcin> LaserJock: well not exactly
<marcin> LaserJock: anyway you think that instead of pbuilder create --distribution dapper
<LaserJock> marcin: it is under "Upgrading to Latest Development Release"
<marcin> LaserJock: I should pbuilder update first?
<LaserJock> no
<marcin> LaserJock: aah right - got it
<marcin> hehe E: failed to find /var/cache/pbuilder/base.tgz, have you done <pbuilder create> to create your base tarball yet?
<marcin> 
<LaserJock> did you make the breezy pbuilder?
<marcin> nope :)
<LaserJock> you need to do that first
<marcin> ok ok...
<LaserJock> also you will probably want universe support as well
<marcin> LaserJock: is pbuilder create something time consuming?
<LaserJock> yep
<LaserJock> marcin: it is basically making a mini-Ubuntu install
<LaserJock> with just the basic packages
<marcin> ehh so - off to bed
<marcin> it's 4:00 am here
<LaserJock> ouch
<marcin> thanks
<marcin> I'll leave this pbuilder thing it should finish overnight
<marcin> night
<LaserJock> cya
<LaserJock> Kyral: are you around?
<Kyral> yah
<LaserJock> Kyral: how did you change your key when you got your @ubuntu.com address?
<Kyral> added the ID?
<LaserJock> what about for revu?
<Kyral> as long as its the same key
<Kyral> same KeyID
<LaserJock> so do you just now sign your packages with the @ubuntu.com address?
<Kyral> its the same key really
<LaserJock> ok, should I resend my key to the keyservers?
<Kyral> yah
<LaserJock> any MOTUs around?
<LaserJock> hmm, I suppose it's a little early for the Germans
<ajmitch> yes?
<LaserJock> I was thinking of working on the kguitar merge
<LaserJock> It appears pef did an 0ubuntu1 version
<LaserJock> but now there is a Debian -2 version
<LaserJock> so should I just try to build the Debian source in dapper and see if it works?
<LaserJock> ajmitch: any thoughts?
<ajmitch> yes, probably a good idea
<LaserJock> well, it builds, installs, and works
<LaserJock> ajmitch: so should we request a sync?
<hub> ajmitch: so can I upload my packages that have 2 votes?
<hub> :-)
<ajmitch> hub: once your key is in
<hub> ajmitch: yeah, I sent it
<ajmitch> and you don't vote for your own packages, I hope :)
<hub> ajmitch: no
<ajmitch> yes, has elmo replied saying it's in?
<ajmitch> LaserJock: probably
<ajmitch> LaserJock: check that the orig.tar.gz is the same
<hub> ajmitch: he hasn't yet, but I sent the key ID a few minutes ago
<ajmitch> hub: might take a little while to process
<hub> ajmitch: what is the procedure? I just upload with dput or is there something I missed on REVU....
<ajmitch> judt dput
<ajmitch> s/judt/just/
<hub> okay
<hub> ajmitch: btw is it only cdbs package that should patch config.{sub,guess} ?
<ajmitch> hm?
<hub> apparently dh-make make them being rewritten in clean:
<ajmitch> yes
<ajmitch> which makes things ugly, iirc
<hub> yeah
<ajmitch> especially when you go to make a debdiff
<hub> so the packager has to work around it?
<ajmitch> they can
<ajmitch> or they ignore it
<hub> so what is the policy for reviewing
<ajmitch> I don't know if there is a policy
<hub> ah ok
<ajmitch> I really prefer that they not be in the diff.gz
<hub> metoo
<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
<minghua> it's pretty trival to fix the dh-make's debian/rules
<ajmitch> LaserJock: that doesn't matter
<minghua> maybe I should write a wiki page for that
<ajmitch> if they have differing md5sums you can't sync
<LaserJock> why not?
<LaserJock> I mean what can you do?
<ajmitch> because you can't overwrite the orig.tar.gz in the archive with another that is slightly different
<ajmitch> it breaks all manner of things
<LaserJock> so what do we do?
<ajmitch> the only thing you can do is merge by hand
<LaserJock> so we create a ubuntu1 just because the .orig.tar.gz files aren't the same size?
<ajmitch> yes
<ajmitch> it's the only thing we can do
<LaserJock> we can't get rid of the present Ubuntu packages?
<ajmitch> nope
<ajmitch> so this divergence will last until the next upstream version that we're allowed to sync
<LaserJock> well, that's really weird, but OK :-)
<ajmitch> no, it's not weird
<ajmitch> remember that the sources lists that you download have the md5sums of all the files
<LaserJock> right, but aren't those updated on a regular basis?
<minghua> LaserJock: but your second upload doesn't have an orig.tar.gz
<minghua> assuming no upstream version changes
<ajmitch> it's just a Really Bad Thing to silently change a file in the archive
<LaserJock> hmm, ok so I can see where it would mess stuff up
<ajmitch> yeah
<ajmitch> it's horrendously irritating when upstream releases a tarball & then silently changes it a few hours later
<LaserJock> but what would I put in a changelog entry? ".orig.tar.gz doesn't have same md5sum"
<minghua> LaserJock: sounds good to me :-)
<LaserJock> ok, so I use the debian source, except switch .orig.tar.gz and update changelog?
<LaserJock> ajmitch: I gotta go but I attached a debdiff to the bug report
<ajmitch> hey Lathiat
<ajmitch> got your talk ready yet? ;)
<Lathiat> already?
<Lathiat> bit soon isnt it?
<LaserJock> ajmitch: can you take a look at the kguitar debdiff?
<LaserJock> ok, later guys
<raphink> hi guys
<raphink> LaserJock_away: you're still there?
<raphink> everybody's sleeping here?
<ajmitch> not quite :)
<StevenK> Almost.
<ajmitch> heh
<raphink> ah :)
<ajmitch> early start too much for you, StevenK? :)
<StevenK> Oh yes.
<raphink> hehe
<raphink> ajmitch: one question :
<raphink> when merging, what shall we have in the changelog ?
<raphink> the old changelog + the new debian entry + the merger entry ?
<raphink> or do we keep all the new debian entries if there were several since it was last merged ?
<raphink> i.e. do we want only the versions present in Ubuntu in the changelog ?
<raphink> or all the debian versions?
<ajmitch> all versions
<raphink> ok
<ajmitch> there's often several debian revisions
<raphink> I requested a sync for a package
<raphink> but actually the last version in Ubuntu was a -8ubuntu1
<raphink> so i guess I should merge
<raphink> at least to get the last ubuntu changelog in
<raphink> right?
<ajmitch> hm?
<ajmitch> don't do that
<raphink> what do you mean?
<raphink> I just keep track of the last ubuntu version if I just sync the package
<ajmitch> if you asked for a sync, then don't go re-adding changelog entries just to have them there
<raphink> sorry
<raphink> hmm ok
<raphink> the sync was not performed yet
<ajmitch> because then it'll never aync automatically
<raphink> s/aync/sync/
<ajmitch> s/aync/sync/
<raphink> ;)
<raphink> hehe
* raphink just woke up
<raphink> ajmitch: so I leave it as a sync and we miss last changelog and that's fine?
<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?
<ajmitch> no, it's not fine to upload it
<raphink> why?
<ajmitch> you requested a sync, because ubuntu changes aren't needed anymore
<ajmitch> so there's nothing to have in the changelog
<raphink> ok :)
<ajmitch> and I just said - having an ubuntu version introduces divergence, another package to merge for dapper+1
<raphink> well there's nothing to have in the changelog about the new sync
<raphink> but we lose track of the previous one
<ajmitch> that's fine
<ajmitch> that's fine
<ajmitch> we don't want the previous one anymore
<raphink> so if you look at the new changelog it's like the old ubuntu version never existed
<raphink> ok
<raphink> fine :)
<ajmitch> yes
<raphink> ty
<raphink> another question
<raphink> :)
<raphink> if i want to join the MOTU team on LP, who do I ping?
<ajmitch> a motu team admin
<raphink> well you are an admin so i'll ping you :)
<raphink> ajmitch: ping
<raphink> :)
<ajmitch> we don't use that team membership for anything
<ajmitch> it used to be for bug
<ajmitch> bugs
<Fuddl> hi everybody
<raphink> hi Fuddl
<raphink> ajmitch: ok
<raphink> hmm what exactly do I need now to be able to work as a MOTU?
<raphink> like upload and so on?
<ajmitch> have you sent your key to elmo?
<raphink> ajmitch: hmm no my key ID is on my LP page
<ajmitch> that's not enough
<raphink> and my key is on the REVU keyring too, but I guess that doesn't cound
<raphink> count
<raphink> ok
<ajmitch> https://wiki.ubuntu.com/Uploads
<raphink> ty
<ajmitch> New maintainers should mail keyring@ubuntu.com with their gpg key id to get added.
* StevenK sent it this morning.
<ajmitch> at the moment elmo manages the keyring manually
<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* :)
<raphink> ok
<StevenK> Now I get to wait another few weeks.
<ajmitch> once we switch to soyuz (launchpad), it will be handled by team membership
* raphink has to set an email client on this machine :s
<raphink> ok
<ajmitch> by now we expect that yo uknow what you're doing with packages :)
<ajmitch> so don't break anything ;)
<StevenK> Or do, since that seems to work for ajmitch.
* StevenK runs.
* StevenK whispers 'clanlib' in ajmitch's ear. :-P
<ajmitch> StevenK: I'm too lazy to break things
<ajmitch> that was not my doing
<StevenK> Sure it was.
<StevenK> Well, parts of it were.
<ajmitch> I didn't do the initial breakage
<raphink> ajmitch: I'll keep asking questions when in doubt though :)
<ajmitch> raphink: please do
<raphink> :)
<raphink> hehe signed message sent :)
<ajmitch> good
<raphink> :)
* StevenK manages to backport quodlibet 0.16 to breezy.
<raphink> :)
<raphink> salut Gloubiboulga
<Gloubiboulga> hello raphink, comment a va ?
<raphink> bien merci et toi,
<Gloubiboulga> a va :)
<raphink> :)
<raphink> koid9 ? ;)
<Gloubiboulga> pas grand chose, et toi ? MOTU ?
<raphink> dev en tout cas :)
<raphink> depuis hier soir
<Gloubiboulga> flicitations :)
<raphink> j'attend pour tre ajout  la liste des MOTUs :)
<raphink> merci :)
<Gloubiboulga> ajmitch, ping
<sivang> morning MOTUs!
<raphink> hi sivang
<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
<raphink> sivang: do you use cdbs or just debhelper?
<raphink> (or just neither, but I doubt so)
<sivang> raphink: i wasthinking of using debhelper, what do you propose ?
<raphink> using debhelper you mean?
<sivang> yes
<raphink> well the thing when you package a lib is that your source package has to generate multiple binary ones
<sivang> right
<raphink> so first of all you need to have multiple binaries in debian/control
<raphink> dh_make generates that for you automatically and you just have to modify it
<raphink> the -dev package should depend on the 0 one
<raphink> then
<sivang> ah right, it asksa you that
<raphink> the easiest way to deal with multiply binary packages imo
<raphink> is to use .install files
<raphink> which is what dh_make does by default, too iirc
<Gloubiboulga> I confirm
<raphink> it generates yourlib0.install and yourlib-dev.install
<raphink> automagically
<sivang> woo hoo
<raphink> so you just need to edit them and adjust them if necessary
<raphink> note that the .install files should only contain debian/tmp/ stuff
<raphink> since the lib will be built in debian/tmp
<sivang> rigth, so it's only paths of where the lib should be installed and so?
<raphink> and then you select each component of the built lib there and tell in which package (0 or -dev) it has to go
<raphink> it's usually very easy since dh_make makes most of the job in the .install already
<raphink> but you might have to modify the .install files
<raphink> i.e. if your lib contains special files
<raphink> or images or so
<raphink> that might happen
<sivang> ok, I think I have enough to get started already :) even without read cover to cover the lib packaging guide :)
<raphink> then you have to determine whether these files go to the 0 or -dev packgae
<raphink> yep ;)
<raphink> good luck :)
<sivang> I'm actually going to have it 1 from start, since this lib is already at version 1
<sivang> is that ok?
<sivang> or the 0 refers to the soname?
<raphink> how do you mean?
<raphink> hmmm
<raphink> let me check :)
* sivang not sure he explains the question right..
<raphink> yes I think that's it
<raphink> well if your library name is mylibx.y
<raphink> then your binary packages should be
<raphink> mylibx.y and mylibx.y-dev
<raphink> and the associated .install files will be
<raphink> mylibx.y.install and mylibx.y-dev.install
* raphink thinks mylib sounds very MS-like :s
<raphink> fine sivang ?
<raphink> sivang: I suggest you take a look at some libs on REVU for example
<StevenK> raphink: Fine, libfoo
<raphink> so you can see how they are packaged
<StevenK> :-P
<raphink> yep libfoo is better StevenK
<raphink> thanks ;)
<raphink> libbar too ;)
<sivang> thank you guys, and congretulations both for becoming official MOTUs
<raphink> ty :)
* sivang .oO(I wonder if I should take a look at a specific package)
<raphink> sivang: just pick one on REVU ;)
<raphink> hi \sh
<\sh> moins
<Gloubiboulga> hi \sh, I have a little question about a lib name
<\sh> Gloubiboulga: which one?
<Gloubiboulga> if a foo lib provides libfoo.so.0.3.1, what should be the package name ?
<Gloubiboulga> it's fr libswitch : http://revu.tauware.de/details.py?upid=1518
<\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 :)
<Gloubiboulga> ok :)
<\sh> Gloubiboulga: it addresses your problem, right?
<Gloubiboulga> \sh, yep, got my answer, thanks
<dholbach> hello!
<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..
<tepsipakki> ah, hardcoded in Makefile
<lucas> hi motus
<zakame> hello all
<\sh> ok..another attempt of packageing s.c.o.u.r.g.e
<zakame> \sh: ooooh!!!
<\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
<siretart> \sh: did you read the licence issues of scourge?
<\sh> siretart: yes
<siretart> \sh: so we cannot redistribute that :(
<\sh> siretart: not the data :)
<\sh> siretart: the source indeed we can distribute
<\sh> siretart: source == without the data directory
<siretart> \sh: so the game is playable without the media?
<\sh> siretart: no..but I'll work on a solution
<\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.
<\sh> the question is, what is the artwork made by him, and is it enough for playing the game.
<siretart> ah, so you are still investigating.. I see
<\sh> siretart: the other solution would be to get an exclusive agreement with the other contributors for ubuntuy
<siretart> exclusive agreements don't make software or artwork free
<siretart> would have to go to multiverse anyway that way
<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?
<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.
<TWD> All help much appreciated
<\sh> TWD: #launchpad can help :)
<\sh> siretart: do you have to time to have a look on a configure log?
<TWD> \sh: thanks, goin g there now
<\sh> siretart: http://paste.ubuntu-nl.org/7312 (and it works in any chroot i have :)) same build-deps
<tepsipakki> ok, I've finished gtkpod-aac, what next?
<siretart> \sh: does it use libtool/autoconf? it this case you need to relibtoolize it to find the correct gl headers
<\sh> siretart: well...i wonder why it works in a chroot
* irvin is away: I'm busy
<tepsipakki> http://users.tkk.fi/~tjaalton/gtkpod-aac/
<\sh> siretart: and funny thing is, even in pbuilder login..it doesn't work...
<\sh> siretart: (even after libtoolizing it)
<siretart> hm. I'd have to take a look at it myself (checking configure.log and so on)
<Yagisan> ajmitch: around ?
<Yagisan> bbl
<\sh> siretart: i'm checking everything different now..between a chroot build and an pbuilder env build
<viviersf> i made a package
<viviersf> it depends on impi-default-settings
<viviersf> and when i apt-get remove impi-default-settings
<viviersf> it doesnt want to remove the package
<viviersf> why not ?
<Hieronymus> Can someone help me with a watch file?
<mbreit> hi guys
<bunda> hi
<tepsipakki> um, how do I change debian/control so that I can sign the .dsc since I'm not the maintainer?
<mbreit> tepsipakki: iirc you don't need to change the control file... isn't there an option for dpkg-buildpackage?
<\sh> debuild -S -k<your gpg uid>
<tepsipakki> \sh: thanks!
<\sh> or debuild -S -sa -k<your gpg uid> for source uploads
<mbreit> hehe... i think i was too long away ;)))
<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?
<\sh> bunda: FOSS software? upload to revu.
<mbreit> \sh: he nows about revu but needs someone to put his key into the keyring
<bunda> It uses GPLv2...
<mbreit> s/nows/knows/
<\sh> mbreit:  we need a signed mail with the key id :)
<\sh> to keyring@tiber.tauware.de
<mbreit> \sh: i have his key... personally signed *g*
<mbreit> \sh: does it get into the keyring automatically?
<\sh> mbreit: but he needs to contact us somehow :)
<\sh> mbreit: manual intervention
<bunda> ??
<mbreit> \sh: can i do this myself? i have admin rights on tiber...
<\sh> mbreit: sure
<mbreit> how?
<siretart> can anyone with recent dapper check if the seahorse gedit plugin works?
<\sh> siretart: no it doesn't build at all
<\sh> siretart: I disabled it
<mbreit> siretart: just a second, i just wanted to update to latest gedit ;)
<\sh> siretart: problems with the interface between gedit 2.10 and 2.12
<siretart> \sh: ah. now I see it in the changelog
<siretart> 2005-09-19  Nate Nielsen  <nielsen@memberwebs.com>
<siretart>         * configure.in: Now works with gedit 2.12. Patch from
<siretart>         Mike Gardiner. (bug #316607)
<\sh> siretart: the last version wasn't working
<siretart> this is in /usr/share/doc/seahorse/changelog.gz
<\sh> siretart: there was no patch at all :)
<siretart> is there already a malone bug for this?
<\sh> siretart: but it's a source problem..it uses old header files and old functions wich are not available anymore
<\sh> siretart: no...I don't think so.
<mbreit> \sh, siretart: how can I add bunda's key to the keyring on revu?
<\sh> siretart: I came across this problem when I fixed malone #3353
<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
<siretart> mbreit: /srv/revu1/scripts/revu-key import <keyid>
<mbreit> siretart: thanks!
<dholbach> hey mbreit
<dholbach> mbreit: you should be on planet! :)
<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...
<\sh> siretart: the removal of this ldap key server was mentioned in upstreams mail archive somewher
<\sh> e
<dholbach> mbreit: I read your entry :)
<\sh> dholbach: where?
<dholbach> http://mobr.de/blog/feed
<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?
<\sh> dholbach: ah google talk :)
<\sh> dholbach: well...they are using jabbers dialback which gives problems with some jabber server implementations....thank god ejabberd has it implemented
<\sh> there are some interesting threads on jabber-dev ml
<\sh> slomo needs to be on planet as well :)
<\sh> grmpf..bbl
<crimsun> hmph, my sync requests are still outstanding. elmo must be swamped.
<dholbach> Are there still biggies on the list for to-update-before-UVF?
<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 ;)
<crimsun> dholbach: 'morning. More than likely. I'll check in an hour when I'm off the clock.
<dholbach> mbreit: Tomorrow is Upstream Version Freeze.
<dholbach> mbreit: so if we have bugs that can be fixed by a new Upstream Version - we should do that today.
<dholbach> I want us to concentrate on bug fixing afterwards, not on pondering how to sneak in new upstream versions. :-)
<mbreit> dholbach: tomorrow???? i hoped it would be in my semester holidays... when i have some time... it was in the breezy cycle ;)
<siretart> dholbach: do you know the status with wine?
<siretart> \sh_away: is wine up to date?
<dholbach> siretart: no idea to be honest.
<dholbach> siretart: but it sounds like a good idea to update.
<dholbach> All the games and favourite other stuff too. :-)
<dholbach> I did my share of updates yesterday and the day before. :-)
<tepsipakki> also universe is affected with UVF at this point?
<siretart> tepsipakki: yes
<tepsipakki> damn
<mbreit> hmm... bunda's package is still in the ftp incoming directory... shouldn't that be emptied every few minutes?
<siretart> the cronjob runs every 5 mins
<siretart> mbreit: the problem is that he uploaded a binary package.
<mbreit> siretart: oh.. okay, i didn't see that
<siretart> bunda: please upload source packages only. the incoming script does react to '*_source.changes' only
<mbreit> siretart: i think that is my mistake... i am sitting next to him...
<mbreit> siretart: shall i clean his files from the incoming directory?
<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
<mbreit> siretart: thanks... and sorry again ;)
<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
<siretart> s/anyone/anyhow/
<siretart> no need to sorry. I'm to lazy to fix that. thats the problem :)
<mbreit> just one issue: can I add bunda as a user on revu?
<mbreit> just for revu1 of course.. i do not mean a shell account!
<sivang> Is Chris Moore here?
<siretart> mbreit: sure. in /srv/revu/scripts there are scripts 'alter_user.py' and 'register_user.py' for that.
<mbreit> siretart: thanks
<siretart> mbreit: call them without args for help
<siretart> mbreit: if you are interested into the details, loop at process_uploads.sh script, thats the script thats run every 5 mins
<mbreit> i've just read that last script ;)
<siretart> :)
<mbreit> Adding failed, User wienczny@uni-paderborn.de already in database?
<mbreit> Excption string is:
<mbreit> ERROR:  duplicate key violates unique constraint "users_email_key"
<siretart> mbreit: users are created on first package upload automatically
<siretart> mbreit: you might also want to fire up 'psql -U revu revu' for direct sql access. password is in the config file
<mbreit> siretart: the lost password script does not give a password for his adress...
<siretart> gnarf. perhaps again a permissions issue :/
<siretart> mbreit: is that a signing only key?
<siretart> gpg: wienczny@uni-paderborn.de: skipped: unusable public key
<mbreit> huch?
<siretart> revu doesnt work with them
<mbreit> it's not a signing only key
<siretart> strange
<Kyral> morning
<Kyral> Is LP down for anyone else?
<persia>  Kyral: It's intermittent for me.
<Kyral> hmm
<Kyral> maybe this would explain why my @ubuntu stopped working...
<Kyral> are anyone elses's redirects not working?
<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
<Kyral> oh
<Kyral> oops *reddens*
<Kyral> as soon as LP comes back I'll change it
<lfittl> ;)
* Kyral feels stupid now...
<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)
<Kyral> I assume once I change it the auto acript thing will kick in
<lfittl> yep
<Kyral> Mega Man on the brain
<StevenK> Whee, my u.c works too.
<StevenK> Now, how to hack Elisp.
<tseng> Mega Man X2
<Kyral> good game
<marcin`> hello guys now I got my first package in /var/cache/pbuilder/result
<marcin`> and also configured dput to use revu
<marcin`> but... wtf should I upload?
<StevenK> The .changes file
<dholbach> if you have the bash completion on, dput <tab> <letter><tab>  should take you there :)
<dholbach> maybe another <letter> helps too ;)
<StevenK> Or use a better shell, like, say, zsh.
<marcin`> heh...No signature on /var/***.changes
<StevenK> I'm unsure if REVU needs a signature.
<StevenK> If it doesn't, you can force the upload.
<marcin`> StevenK: do I need also use -S -sa options with dput to upload to REVU?
<marcin`> StevenK: and I'm affraid that it requires signature
<dholbach> Yes, -S -sa.
<dholbach> REVU doesn't keep the .orig.tar.gz.
<marcin`> ehh
<marcin`> you know guys... I would like to contribute but it's _little_ annoying :(
<StevenK> Just takes a little time and effort to learn.
<siretart> dholbach: it won't throw it away either
<marcin`> dput -S -sa *.changes -> -S option not recognized
<StevenK> Back in my day, we had to push packages uphill both ways in the snow to upload them.
<siretart> marcin`: the -S -sa options are for dpkg-buildpackage
<marcin`> siretart: but I use pbuilder to build package....
<StevenK> pdebuild --debbuildopts '-S -sa'
<marcin`> StevenK: ok thanks
<marcin`> so what now with this gpg key?
<marcin`> I have some keys.. I generated them about a year ago to register in launchpad...
<marcin`> but to be honest I don't remember how to use these keys with packaging and mail
<marcin`> what should I send to REVU to register?
* StevenK buggers off to bed.
<Hieronymus> marcin`: you need to mail something@tauware.de I'll look it up for you
<Hieronymus> keyring@tiber.tauware.de
<Hieronymus> Ask for upload rights, mention your keyID and sign the message.
<Hieronymus> This is probably also on the wiki
<tepsipakki> the 'passwd-recover' on REVU isn't working like it should, I think
<tepsipakki> after "Now paste the text..." there's nothing
<siretart> marcin`: it is okay to tell me your keyid, too, if I'm around
<marcin`> ok guys.. I know that it's on wiki - but (I hope so) I can create packahe
<marcin`> package but I'm dumb when coming to gpg keys etc.
<marcin`> I don't know how to get this 'keyid' thing
<marcin`> anyway I'll read about it again and try to reconfigure evolution to use gpg again
<mbreit> tepsipakki: we had a problem with that feature a few hours ago, but it's working for example for my login..
<tepsipakki> mbreit: seems not to work for me :/
<Lathiat> Any XFCe people about?
<mbreit> tepsipakki: are you a new user or has it been working before?
<tepsipakki> new
<mbreit> tepsipakki: then i would guess it's the same bug... or do you have a signing only key?
<Lathiat> hrm, packages.debian.org being down is proving to be a PITA
<tepsipakki> mbreit: my gpg-key? it's a full-blown version afaik?
<mbreit> tepsipakki: i have no idea where that bug is...
<azeem> Lathiat: try packages.debian.net/<foo>
<azeem> it's pretty slow though, and I am not sure whether it is really uptodate
<jamessan> azeem: I didn't think searching like that was working
<Lathiat> azeem: hrm
<Lathiat> im just going to install an unstable chroot i thin
<Lathiat> k
<azeem> nah, it is uptodate
<azeem> (note the .net)
<jamessan> ah
<jamessan> :)
<mbreit> tepsipakki: what's your email?
<tepsipakki> mbreit: I do get "IOError: [Errno 32]  Broken pipe" -errors occasionally when I try the recover
<azeem> Lathiat: packages.debian.org/unstable/<section>/<package> works as well
<azeem> (this time with .org)
<azeem> those are the static pages which are still there
<tepsipakki> mbreit: in REVU it's tjaalton@ubu.hut.fi, real one is @cc.hut.fi
<Lathiat> going to linux.conf.au
<Lathiat> now i have a passport i can get my key signed
<Lathiat> followed by be abel to finally actualy upload to universe
<Lathiat> and can get cracking again :)
<mbreit> tepsipakki: i don't see that email address in the keyring...
<tepsipakki> aaah
<tepsipakki> =)
<tepsipakki> tja@iki.fi worked..
<tepsipakki> somehow I thought it took the email from the upload-data
<mbreit> _that_ is in the keyring... i searched for "tjaa", so i did not find that *g*
<tepsipakki> ..in .changes I had tjaalton@ubu.hut.fi
<\sh> grmpf
<\sh> siretart: what we need is a similar database like this one http://secure-testing.debian.net/debian-secure-testing/project/debsecan/release/1/
<\sh> siretart: debsecan
<siretart> \sh: right. we don't have that right now, my question was if somebody is willing to do that for ubuntu
<\sh> siretart: if I can convince pitti to work on that database as well, no problem.
<siretart> \sh: I think he is pretty busy, but you can try
<\sh> siretart: and I have to try to get the format of this zlib compressed database...it's not gunzipable
<\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
<Yagisan> \sh: see my mail ?
<\sh> yes..
<Yagisan> \sh: I'll see if he says no
<Yagisan> \sh: it's funny - I got your mail after I sent mine
<Yagisan> siretart: I probably could do the work for that - assuming I have access to the needed resources
<mbreit> siretart: i have found the problem we had with revu saying "unusable public key"... his subkey has expired some days ago ;)
<siretart> mbreit: oh :)
<\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
<Lathiat> \sh: about?
<Lathiat> yes :)
<Lathiat> jabberd2
<Lathiat> https://launchpad.net/distros/ubuntu/+source/jabberd2/+bug/3526
<Ubugtu> Malone bug 3526: "SQL script are not shiped" Fix req. for: jabberd2 (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: Unconfirmed
<Lathiat> just fixed that, seem reasonable to you?
<Yagisan> \sh: found the database http://svn.debian.org/wsvn/secure-testing
<\sh> Lathiat: fix it and upload :)
<Lathiat> \sh: i cant upload, care to? :)
<\sh> Lathiat: sure...debdiff?
<Lathiat> \sh: yep gimme a couple
<Yagisan> \sh: that database won't have ubuntu only .debs in it
<\sh> Yagisan: we will put everything inside...
<Lathiat> just waiting for pbuilder to put itself together
* Lathiat twiddles
<Lathiat> i need a faster net connection :)
<\sh> Yagisan: let
<\sh> grrr
<\sh> Yagisan: let's take debians database and add our changes
<siretart> that would be great and perhaps the best solution
<Yagisan> \sh: I'd like to grab the tools too, *now* in case they disappear
<\sh> Yagisan: if you want to work on it do it :)
<Yagisan> \sh: sure - it's my interest (relates to my day job) - I'll go for it
<mbreit> hmm... look like everything i would like to have in dapper before uvf is already in, so what else could i do now?
<Yagisan> \sh: I'm not much of a coder, so if I need help I'll give a yell
<\sh> Yagisan: see florians mail
<\sh> Yagisan: would be cool if we can work it out...collaboration between debian security team and ubuntu
<\sh> Yagisan: so we could use one database
<Yagisan> \sh: I got a reply ?? hasn't arrived here yet
<\sh> Yagisan: I have it already :)
<Yagisan> \sh: cool. just arrived
<Yagisan> \sh: ok - however - not being an ubuntu member I can't speak on behalf of the project
<\sh> Yagisan: ok...talk to pitti about how we can easily take the ubuntu-cve data from him to inject them
<Yagisan> \sh: will do. You also interested ?
<\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:)
<Yagisan> \sh: I need to go to bed soon - taking daughter to the doctor in 5hrs
<\sh> Yagisan: I can help, yes :) interested in the sense of "I could need this tool for server administration" much better :)
<Yagisan> \sh: of course
<\sh> Yagisan: ok...trying to gather all information we need
<\sh> Lathiat: ready?
<Yagisan> \sh: if it's all from public data and they don't help we should be able to regenerate it if needed
<Lathiat> pvbuilder just finished making
<\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
<\sh> ah...btw...yestday, did someone raised the issue because of UVF exceptions and who can discuss them with mdz/kamion?
* Yagisan downloading svn now just to check out that repo
<siretart> \sh: yes
<\sh> siretart: ok..candidates approved?
<Hieronymus> mbreit: I bet lots of people would like to have amsn 0.95 in dapper because it has webcam support
<Hieronymus> and audio too, I think
<siretart> \sh: the candidates weren't mentioned, so we decide on that (already done). no problem on that side
<\sh> siretart: ok..so it's you, slomo, dholbach , ogra, ajmitch , and?
<siretart> sistpoty and crimsun
<\sh> cool :)
<\sh> very good :)
<mbreit> Hieronymus: that is just a merge with debian, right?
* Kyral still feels like an idiot for directing his @ubuntu back onto itself...
<Hieronymus> mbreit: 0.95 is in Debian
<siretart> \sh: is wine in dapper up to date?
<Kyral> the autoscript is working again?
<lucas> Kyral: who deals with those address ? I have a problem with mine
<Kyral> elmo
<lucas> ok, so I pinged the right person, thanks
<\sh> siretart: if wine 0.9.5 is latest release, then yes :) and 0.9.5 is the last released wine :) so yes :)
<hub> ogra: I couldn't find the source tarball for pimp
<ogra> hub, hmm, let me look ...
<siretart> great
<Hieronymus> mbreit: but http://packages.debian.org/unstable/x11/amsn says it's only there for kfreebsd-i386 :/
<Kyral> lucas: if he pings back mind telling him I'm sorry for messing up the redirect..
<hub> ogra: the ftp server is down
<ogra> hub, yes thats intentional
<lucas> Kyral: ok, will do
<\sh> Hieronymus: it's not in debian linux yet...only in debian freebsd
<ogra> hub, http://www.grawert.net/software/pimp/pimp-0.1.6.tar.gz
* Kyral feels like idiot ;P
<mbreit> Hieronymus: i don't see any build-log for x86 for that version...
<hub> ogra: thx
<\sh> Hieronymus: for debian linux only 0.94 is there
<Kyral> oh lucas can you review GTKEdit? ;P
<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
<lucas> Kyral: I'm busy with real life stuff
<ogra> hub, its gtk perl ... and not very good ...
* Kyral points to the :P
<hub> ogra: well it is to have a look
<hub> and eventually package it :-)
<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
<lucas> ah ;)
<hub> ogra: I already have my ideas
<mbreit> Hieronymus: debian buildd says it built fine on ppc for example
<ogra> hub, great ...
* Yagisan is off to bed
<\sh> Yagisan: sure :) good night :)
<ogra> hub, it was originally only a personal interim solution when usb storage cameras were not supported ...
<ogra> hub, but it has a userbase ..
<Lathiat> \sh: hrm
<Lathiat> \sh: db-setup.mysql and oracle seem to magically get .gzd, yet .pgsql doesnt?
<\sh> Lathiat: hmm...check dh_compress somehow in rules file?
<Lathiat> there is no dh_compress
<\sh> Lathiat: let me check one moment
<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
<mbreit> Hieronymus: I will merge amsn...
<\sh> mbreit: have fun...you have to take all actual plugins from the amsn-0.94 directory
<\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 :)
<mbreit> \sh: what's the problem?
<hub> \sh: this Debian guy is a real ****
<mbreit> \sh: wtf...
<\sh> mbreit: you have to try if the plugins for 0.94 are still working with 0.95
<\sh> mbreit: or forget the plugins at all :)
<\sh> mbreit: which will give more complains
* Kyral stabs his college
<mbreit> \sh: in debian amsn package, there are only 3 subfolders in plugins/
<\sh> mbreit: then he patched everything via diff.gz
<\sh> fun
<\sh> *gnarf*
<\sh> hahha..yes he moved everything in to diff.gz fantastic
<\sh> lol
<mbreit> \sh: there are no plugins in diff.gz?
<mbreit> at least for 0.95
<\sh> mbreit: there are a lot in it :)
<\sh> in 0.94
<\sh> where did you get the 0.95 source package?
<mbreit> debian
<mbreit> http://ftp.debian.org/debian/pool/main/a/amsn/
<\sh> mbreit: hmm..yes...so he changed everything
<mbreit> \sh: but still the orig.tar.gz is bigger than the upstream tarball *sigh*
<\sh> hehe
<mbreit> I don't think that I want to touch that package....
<\sh> mbreit: try to build ?
<mbreit> so should i keep the tarball from debian?
<\sh> mbreit: and check if https://launchpad.net/distros/ubuntu/+source/amsn/+bug/5089 is fixed :)
<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
<mbreit> i did
* Hieronymus just looked at the .desktop file from Debian amsn 0.95
<Hieronymus> it has no Version
<mbreit> it is fixed, so we could request a sync with debian
<mbreit> *if* it builds...
<\sh> mbreit: try it :) for what are you here :)
<\sh> Lathiat: uploaded
<mbreit> \sh: well, I can't do everything at once ;)
<\sh> mbreit: lol
<\sh> mbreit: why the gods of unix invented multiple terms and screen?
<\sh> heheh
<mbreit> \sh: useless with only two hands ;)
<\sh> mbreit: true :)
* Hieronymus built amsn 0.95 from Debian
<Hieronymus> it seems to work
<mbreit> Hieronymus: you are too fast... I am still updating pbuilder ;)
<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
<mbreit> but I'll request a sync from elmo anyway
<Hieronymus> mbreit: I logged in
<Hieronymus> amd64 as well
<mbreit> email to elmo has been sent
<mbreit> so what's next on the todo list?
<\sh> laters.
<\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.
<\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.
<dholbach> \sh: I discussed this with lucas. We might consider this as a process and at least, it should be documented.
<dholbach> \sh: I proposed to take gparted as an example, because it was my 'fault'.
<dholbach> It's certainly not a 'must'.
<dholbach> But it's good if people know, how they 'could' do it.
<\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
<dholbach> You can't relate bug reports to rants.
<\sh> dholbach: i'm only concerned, that we have to do more "legal" stuff, then everything else. Those incidents are really destroying the workflow
<dholbach> Yes, we shouldn't make it a requirement.
<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.
<\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
<ogra> \sh, you totally misunderstood joeys mail
<\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
<ogra> why do you guys care one day before UVF for such political stuff ?
<\sh> ogra: I did understand his concerncs, he has a point.
<ogra> \sh, he only said that he puts people reporting bugs for his software in foreign distros to his killfile
<\sh> ogra: that wsa the 2nd mail today.
<\sh> please read the 1st
<ogra> ...as long as the distro makers dont remove his name
<ogra> i talk about the first
<\sh> ogra:
<\sh> Please consider ALL code written/maintained by me that is present in
<\sh> Ubuntu and is not bit-identical to code/binaries in Debian to be not
<\sh> suitable for release with my name on it.
<dholbach> \sh: I just wanted to explain the gparted bit.
<\sh> the first paragraph of the mail is not important, the second paragraph is even more important, because he has a point there
<ogra> \sh, you omit the second paragraph
<dholbach> \sh: and I think it's ok to explain the process.
<\sh> ogra: it's the second. the first is with the killfile
<ogra> yes, but you miread it
<\sh> dholbach: for sure.
<dholbach> Cool.
<dholbach> So that's sorted out.
<\sh> dholbach: but we have to respect, that "first comes ubuntu, then the rest" (that is my thinking(
<\sh> ogra: ok..how would you read the second paragraph?
<ogra> i would read the whole mail as mentioned above
<ogra> and Kamion with whom i discussed it reads it the same way ....
<\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 ,)
<\sh> 3. I'm in his killfile
<ogra> just answer his mail in the ML
<\sh> ogra: nope...I don't answer anymore on d-d
<ogra> i dont think he killfiles mailing lists
<ogra> on -motu i mean
<\sh> ogra: i did already :)
<\sh> Message-Id: <200601170708.21709.sh@sourcecode.de>
* ogra is *very* annoyed by the politics that took place in MOTU over the last weeks
<ogra> and i 100% agree that we dont need a MOTU police like the one that seems to form here recently
<Hieronymus> facecrime!
<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.
<ogra> dholbach,++++++++++++
<ogra> lets not morph MOTU in a debian subproject with all its bureocracy and annoyances please
<seb128> you should educate people
<seb128> no need of anything paper for that
<ogra> seb128, exactly
<seb128> just make clear that everybody wins by lowering the delta with Debian
<ogra> seb128, nice to see you here btw :)
<dholbach> May I introduce star educator MAAAAAAAAAGIIIIIIIIIC SEEEEEEEEEEEB :-)
<ogra> seb128, yes, but not force people to do so
<seb128> ie: sending useful fixes to <package_name>@packages.debian.org
<seb128> or to the BTS
<seb128> and not changing for little details like a typo fix or a desktop file, etc
<\sh> seb128: so define: what is useful?
<ogra> but we made this always optional and thst what makes MOTU attractive for many people
<\sh> seb128: cxx transition renames?
<seb128> yeah
<ogra> seb128, recently people come in new and start writing policies which is not right imho ...
<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
<seb128> that's a matter of godd sense
<seb128> that's like working with upstream
<seb128> you should know when a patch is a distro hack
<seb128> or should go upstream because it fixes something
* Kyral gets back to work
<seb128> Kyral: what do you mean? happy to keep a divergence?
<\sh> seb128: I send patches for the source stuff towards debian and upstream
<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
<\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
<\sh> packages in ubuntu but not in debian is again another story.
<lucas> \sh: I'm not overreacting, I'm just saying that you were off topic
<lucas> we you improve somebody else's work, it's good practice in the FLOSS community to notify him
<lucas> that's what we do when we package a newer upstream release
<seb128> Kyral: I bet you have a limit of what you can "maintain"
<seb128> Kyral: or is "maintain" just uploading and not carring about the bugs coming next?
<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 ?
<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?
<\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 :)
<lucas> seb128: we are discussing universe packages hre
<seb128> lucas: same issue
<Kyral> seb128: I'll fix bugs
<Kyral> if possible
<Kyral> ifnot I send to upstream :D
<\sh> lucas: well, I would look first over my shoulder
<seb128> if the new version is running dch -i and uploading no need to send a mail imho
<Kyral> but I really should get back to classwork
<ogra> hey, we have 24h until UVF, is it really the time for political discussions ?
<\sh> lucas: not doing the work first and then looking.
<\sh> lucas: but this is how I work.
<lucas> it's not about politics, it's about improving processes so we actually have less work to do
<ogra> lucas, for me its general chatter that could be done at a more appropriate time ...
<lucas> seb128: btw, your example is wrong, since you are packaging gnome in debian too ;)
<ogra> not 24h before an important deadline
<seb128> lucas: not by myself and not everything :)
<dholbach> People: get in all the crazy new stuff you want to instead of asking ogra and me in the next days, kthxbye.
<dholbach> :)
<ogra> ;)
* ogra is on a conference anyway the next days :)
<tseng> iirc there are a few more people that can approve new upstreams
<tseng> although i have yet to see a clear list
<tseng> or at least the same list twice
<ogra> tseng, sure, but still we have a date for UFV and every exception requires extra eyeballing and manpower
<ogra> and surely some frustration for the denied packages
* \sh is glad 
<\sh> not to be in the line :)
<dholbach> What about the wine update?
<\sh> to 0.9.5?
<bddebian> Heya gang
<dholbach> HEY bddebian!
<bddebian> Daniel!!!!!
<dholbach> Just in time for UVF! :)
<\sh> BARRY
<bddebian> I heard. :'-(
<bddebian> Heya \sh
<\sh> dholbach: latest release of wine is in dapper
<dholbach> Cool.
<\sh> dholbach: since 2 weeks or so? i don't remember
<dholbach> There was some chatter about this morning, so I thought I'd ask.
<dholbach> We should grep through our MOTU bugs and see if there's urgent stuff to update.
<\sh> ogra: btw...ssh -X works again, and I can't reproduce the bug with wine over remote
<\sh> ogra: the bloody amd64 box needed a stupid reboot
<\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 :)
<\sh> s/things/thinks/
<bddebian> DCOM98?? WTF? :-)
<LaserJock> Kyral: so did you set your @ubuntu.com address as your preferred address in LP?
<\sh> ok going back to "sending mails with cvs to companies :("
<\sh> laters
<robotgeek> LaserJock: question
<LaserJock> yeah
<robotgeek> LaserJock: http://www.pyrorobotics.org/
<robotgeek> I would be willing to build Ubuntu package for this program, and all it several recommends
<robotgeek> I don't think it's in debian yet
<LaserJock> robotgeek: make sure to check out the license, but it looks pretty cool
<LaserJock> robotgeek: well, check for ITPs or RFPs
<robotgeek> LaserJock: i have a basic listing here, if you are interested. http://robotgeek.org/wiki/Main/PyroInstallation
<ogra> \sh_away, you'll need ltsp, ssh -X isnt enough
<ogra> but thats not a UVF task anyway ... i'll do some testing the next weeks
* dholbach does a Universe update.
<dholbach> YAY, GO ME!
<ogra> go dholbach go !
* robotgeek notes that there are 3 more days to UbuntuHugDay
<ogra> (run forest run) :)
<dholbach> There's a HUG DAY in three days?
* dholbach blinks.
<robotgeek> 21'st, Bug Day, right?
<dholbach> Nobody invited me.
<bddebian> Heh
<dholbach> Or you mean the Party I'm about to have at my place? :)
<dholbach> robotgeek: I think it was 21 December, no?
<robotgeek> damn, i missed it by over a week. 11th Jan, *sigh*
<dholbach> We'll have a new one, don't worry. :)
<robotgeek> well, alteast i scared you folks for a moment
<bddebian> Didn't scare me, I'm useless lately :'-(
<bunda> hi
<mbreit> hi bunda ;)
<LaserJock> ajmitch: ping?
<LaserJock> robotgeek: pyrobot seems to be GPL and I can't find an ITP or RFP for it looks like fair game :-)
<bunda> Does somebody have some time to do a review of my package cdpr?
<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
<robotgeek> LaserJock: HMm, i have to contact a lot of people. But will do so
<robotgeek> about 7 packages, in all i think
<LaserJock> robotgeek: ?
<LaserJock> robotgeek: don't you just need to do pyrobot?
<robotgeek> LaserJock: pyrobot acutally brings togehter about 6 other simulator packages
<robotgeek> i think all of them are gpl
<LaserJock> robotgeek: but do you need to package each seperatly?
<robotgeek> LaserJock: yes, cause it's not really a dependency, and the simulators are from different places (Stanford, UCB etc)
<mbreit> hey bddebian! (still around?)
<LaserJock> robotgeek: anyway, if you can come up witha a source package it would be cool
<robotgeek> LaserJock: i'll see what i can do. This has been one of my goals, but i've attained some confidence only now.
<robotgeek> as always, i can bug you guys :)
<LaserJock> sure
<bunda> does anybody here have some time for a small review?
<raphink> bunda: give it to me
<robotgeek> i will attack the issue after my CategoryCleanups. later all
<raphink> hmm I mean if you want, I can do it ;) just give me the url ;)
<bunda> raphink http://revu.tauware.de/details.py?upid=1533
<raphink> ok
<bddebian> mbreit: Yep, sorry
<pef> ocbook2x-man kvpnc.1.docbook
<pef> I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd
<pef> does anyone has this problem ?
<pef> someone oups
<LaserJock> could I get somebody to pastebin the output of "ls /etc/cron.daily" ?
<bddebian> bbiam
<LaserJock> hi lucas
<lucas> re
<lfittl> Any MOTU who has some time to review and upload http://revu.tauware.de/details.py?upid=1534 (this fixes malone 3349)?
<gborzi> Hello, I need some help for a package (keytouch) I have submitted to MOTU.
<gborzi> Is there anyone ?
<Gloubiboulga> gborzi, about the config* files ?
<gborzi> Yes! I tried the link trick, but it doesn't work.
<raphink> bunda: almots done with reviewing your package :)
<Gloubiboulga> these file already exist in the orig.tar.gz ?
<Gloubiboulga> files*
<gborzi> Yes, they are there. And the rules files overwrite them.
<Gloubiboulga> gborzi, ask a MOTU to confirm, but I think you can just drop the lines about config.{sub,guess} in debian/rules
<raphink> bunda: comments sent ;)
<gborzi> Gloubiboulga: thanks for the suggestion, but I think those lines should not be dropped.
<gborzi> Otherwise the build will use the upstream author's config.*
<Gloubiboulga> :/
<Gloubiboulga> It was such a bad suggestion?
<LaserJock> so the questions is whether you need to get config.{sub,guess} in the diff.gz?
<LaserJock> s/get/keep/
<crimsun> you should avoid having it in diff.gz if at all possible
<LaserJock> so can you just ignore them, I really don't understand
<crimsun> having references to it in debian/rules is fine, though, presuming you b-d on autotools-dev (or something that pulls it in)
<crimsun> well ideally upstream refreshes config.{guess,sub} periodically
<raphink> I'm just wondering about whether it would be good to have commentaries on REVU sent to the packagers from the reviewer, automagically
<LaserJock> sometimes I see that they are in the diff.gz. Is that because of the source package building process?
<raphink> so the reviewer can just answer to get more infos for ex
<crimsun> LaserJock: pretty much
<LaserJock> crimsun: but they aren't needed are they, aren't they just recreated when the binary package is built?
<crimsun> raphink: I think that functionality would be useful
<crimsun> LaserJock: it's not necessary to have the full contents of config.{guess,sub} in the diff.gz, no.
<raphink> crimsun: :)
<raphink> sispoty is not here though
<LaserJock> raphink: I think that might become a REVU2 feature ;-)
<raphink> yep
<raphink> if sistpoty wsa here I would suggest him
* raphink wonders if he could write a filter to apply to Motu-reviewers emails, so that when a comment has been posted by him, it gets the email of the packager from the email and forwards it
<LaserJock> I think we also need to have more than the email address to identify people. irc or LP names would be nice
<tseng> you can add your irc to LP
<tseng> and jabber etc
<raphink> yep
<raphink> although I doubt packagers on REVU look at the LP page of the people who review their packages
<Gloubiboulga> I do :)
<LaserJock> I'm just saying it's hard to see who is uploading when all we have is their email address
<tseng> you could do a lookup and link to the LP person page
<tseng> or even switch user auth to LP
<LaserJock> hmm, I think LP user auth might also be the plan for REVU2 but I can't remember
<Kyral> LaserJock: Yah *redface*
<LaserJock> could I get somebody to pastebin the output of "ls /etc/cron.daily" ?
<Kyral> late
<LaserJock> Kyral: don't worry I did it too, I'm glad I read the irc log ;-)
<raphink> LaserJock: yes, when you get a comment on REVU, the name of the MOTU should be a link to his/her LP page
<LaserJock> raphink: well, I think the uploader name is important too ;-)
<raphink> sure
<raphink> so uploaders would need to have an LP account
<raphink> which would be good imo
<Kyral> LJ did yours get set back yet?
<LaserJock> Kyral: I just switched my preferred email back. I didn't get any emails about it or anything
<Kyral> yah mine was disabled >_<
<crimsun> siretart: ping
<siretart> crimsun: pong (but phon)
<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?
<siretart> sorry?
<crimsun> siretart: the Build-Depends alternatives so that we can just use Debian's GL{u}
<crimsun> i.e., instead of libgl1-mesa-dev|libgl-dev, libglu1-mesa-dev|libglu-dev
<siretart> xlibmesa-gl-dev | libgl1-mesa-dev | libgl-dev , libglu1-mesa-dev | libglu-dev
<crimsun> siretart: excellent, thanks
<siretart> should work for both debian and ubuntu
<crimsun> right.
<siretart> ah :)
<crimsun> I remember you asking infinity in -devel last week, just didn't jot it down
<siretart> imo we should introduce a dummy package 'xlibmesa-gl-dev' which just depends on libgl1-mesa-dev
<LaserJock> that would certainly save a lot of merge time
<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...
<raphink> thanks mbreit :)
<mbreit> raphink: in make, targets who are _not_ files, are the exception ;)
<raphink> hehe ok ;)
<raphink> well debian/rules usually contains mostly exceptions then
<mbreit> so the dot in the target name is right there ;)
<mbreit> well, debian/rules is no typical use of make ;)
<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.
<stratus> gobby avahi support sounds nice
<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)
<stratus> pkern, oh i see.
<ajmitch> morning
* ajmitch checks to see what version we have at the moment
<lucas> debian 0.3.0-2 	 ubuntu 0.3.0-1ubuntu1
<ajmitch> does it require a running avahi daemon?
<ajmitch> yes I saw that thanks
<pkern> ajmitch: Ew. That should be started automatically when it's installed on Debian/Ubuntu?
<pkern> ajmitch: And yes, of course it does.
<ajmitch> pkern: right - avahi is in main, but we have the policy of no listening ports by default
<ajmitch> so the daemon isn't started, iirc
<pkern> ajmitch: Well, most probably you're told to start mDNSresponder ;)
<ajmitch> is it a runtime option in gobby? :)
<pkern> And zeroconf is deactivated for the session
<ajmitch> ok
<pkern> Yep, but with failure message.
<pkern> Currently mapping to howl.
<ajmitch> hm
<ajmitch> was avahi the only one that's DFSG-free?
<pkern> yep
<pkern> Howl 2 probably will be, too, taking the free mdnsresponder from avahi.
<ajmitch> it gets messy & broken if two stacks try to claim reponsibility
<pkern> ajmitch: Yep, currently there's only Avahi included in Debian and Ubuntu, so I see no problem.
<ajmitch> yeah
<pkern> ajmitch: I'll link against this lib anyway on Linux.
<pkern> ajmitch: Against howl on OS X and Windows.
<ajmitch> were you talking with the avahi developers recently about mingw?
<ajmitch> I saw them talking about it in channel yesterday
<pkern> Nope.
<ogra> pkern, i'm very swamped currently and UVF is tomorrow
<ogra> i couls ask for the sync now and let it fail on the buildds until i have time to fix it though
<ajmitch> just saw that mingw's still considered not supported, so you're right :)
<ogra> pkern, that would also solve your prob with scotts patches
<pkern> ogra: UVF as in Debian as upstream or as in the part before the dash?
<pkern> ogra: As this is a minor Debian revision only, no source code changes.
<ajmitch> before the dash, actual upstream, AIUI
<ogra_> GRRRR
* ogra_ throws a frozen pumpkin on the german telekom
<ajmitch> how creative :)
<ogra_> it was lying on the terrace ;)
<ajmitch> time for me to finish off 4 zope merges & file bugs
<lucas> who can add a mysql database for me on tiber ?
<ajmitch> umm
<ajmitch> you need mysql?
<ogra_> #ugh
<ajmitch> since it's mostly postgresql at the moment
<ogra_> cant you take postgres ?
<lucas> no, I'd like to use phpmyedit to store some info
<lucas> and it only supports mysql
<ajmitch> tiber only has 512MB RAM, so I'm not sure if running postgresql+mysql at the same time is a good thing
<lucas> lucas@tiber:~$ w
<lucas>  16:24:46 up 40 days, 32 min,  5 users,  load average: 0.00, 0.00, 0.00
<lucas> it doesn't seem too loaded right now otoh
<ogra_> and phppgadmin wont do it ?
<lucas> no it's different
<lucas> phpmyedit is about generating some simple table-based webapps
<lucas> but anyway, I can start somewhere else
<lucas> and move to tiber later
<ogra_> would be nice to keep some consistency
<ajmitch> ask admin@tiber, the alias goes to those of us who can do it
<ajmitch> or ask siretart & sistpoty also
<lucas> ogra: consistency like ?
<ogra_> staying with one programming language, one database engine etc
<lucas> ajmitch: I'll first check that phpmyedit really suits my need
<lucas> I've never used it, only heard from it
<ogra_> everything on tiber runs python, why add insecurity through php for example ?
<lucas> because phpmyedit is written in PHP and uses MySQL ?
<lucas> but anyway, I got your point, I'll host it elsewhere
<ajmitch> it increases future maintenance workload
<pkern> Ok, the next who tells me why the hell the Ubuntu package patches out howl compatibility support gets my personal cheer.
<tseng> pkern: uh
<tseng> pkern: if you could be specific and less agressive someone might have an answer
<tseng> what package?
<pkern> tseng: Avahi that is.
<tseng> i doubt that it is "patched out" vs not enabled
<tseng> but a question for slomo_
<pkern> tseng: Removed from the Ubuntu revision of the Debian package out of debian/control.
<ajmitch> he did have his reasons, and I think it was meant to be turned back on
<Nafallo> doesn't the changelog say why?
<pkern> Nafallo: Nope.
<pkern> Nafallo: No reason specified.
* Nafallo spanks slomo for being a naughty boy
* ajmitch is reading the irc logs for a reason
<ajmitch> 10:54 < sebest> and the compat libs are also disable on dapper?
<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
<ajmitch> 10:54 < slomo_> yes... also because of the support
<ajmitch> because the libs were meant to be supported only for a short time upstream, apparantly
<ajmitch> whether that's still true or not, I don't know
<pkern> Funny enough for libraries providing backwards support for an old library interface that's by itself unlikely to change, but ok.
<ajmitch> I know
<pkern> Yes, I also got threatened by the remove in the bug report.
<ajmitch> 13:45 < mezcalero> no point in "waiting", since the compat layers are intended to be used *now* and dropped completely later, anyway
<ajmitch> 13:45 < mezcalero> we provide it to smooth howl->avahi transition for distributions
<ajmitch> 13:46 < mezcalero> because i am too lazy to do the splitting properly, the compat layers will stay until avahi 0.7
<ajmitch> so 0.7
<ajmitch> whenever that gets done
<pkern> "Please integrate, but be aware that we will remove it in a year" <-- Hey come on |:
<ajmitch> hardly useful for any sort of platform stability
<pkern> Platform stability in Debian was about backporting all the fixes.
<pkern> What's the policy in Ubuntu? Taking new upstream versions?
<ajmitch> sometimes we have to
<pkern> ajmitch: 0.7 would break the ABI anyway I guess
<pkern> ajmitch: Which would be a nightmare ;)
<ajmitch> like firefox, where it gets increasingly painful to backport security fixes
<ajmitch> yeah
<pkern> ajmitch: Yes, the lovely Firefox currently also known as Deer Park ;)
<pkern> Whoever packaged libcamel1.2-8 some days ago should be lart'ed. *cough*
<ajmitch> what did he break? :)
* ajmitch sees the culprit in another channel
<LaserJock> well, I had a conflict when I installed it
<pkern> ajmitch: No replaces specified.
<LaserJock> I had to remove libcamel1.2-7 fist
<pkern> ajmitch: Thus two packages which were not mutally exclusive had the same file.
<pkern> ajmitch: dpkg refusing *anything* to do with them.
<ajmitch> what other package?
<pkern> ajmitch: libcamel1.2-7 vs. libcamel1.2-8
<pkern> ajmitch: -8 specifies another ABI, so the library filename should have been changed.
* ajmitch sees libcamel1.2-7 in conflicts & replaces
<pkern> ajmitch: It wasn't.
<pkern> ajmitch: Well, same filename then.
<pkern> It seems fixed now, though.
<ajmitch> yep
<ajmitch> 2 uploads on the same day
<ajmitch> I don't follow the bleeding edge closely enough :)
<pkern> Hehe.
<pkern> I do now, I already lost my clock ;)
<pkern> (the one in the panel)
<pkern> Came too close to the edge I suppose.
<ajmitch> I wonder if we'll get zope 3.2 in main before UVF
<ajmitch> morning womble
<pkern> ajmitch: 2h left? ;)
<ajmitch> pkern: not sure when the autosyncs stop - it was just accepted in debian :)
<womble> hey ajmitch
<pkern> ajmitch: Autosync against sid or etch?
<ajmitch> sid
<ajmitch> then we spend the next couple of months regretting what was synced :)
<ogra> pkern, we only use sid ...
<ogra> always
<ajmitch> and experimental in some cases :)
<Nafallo> sid and experimental to be totally honest :-)
<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
<lucas> r=1
<ajmitch> but those are rare exceptions
<ajmitch> lucas: tinyurl, please
<lucas> (merges/syncs awaiting reviews)
<ajmitch> I don't think I can get all that in :)
<lucas> some of them would be worth trying
<ajmitch> I know
<ajmitch> but make it easy for me to cut & paste :)
<ajmitch> & we'll put it in the topic
<lucas> http://tinyurl.com/a3qjh
<ajmitch> thanks
* ..[topic/#ubuntu-motu:ajmitch] : Ubuntu Masters of the Universe: Ubuntu Universe Repository Maintainers | http://wiki.ubuntu.com/MOTU | http://wiki.ubuntu.com/MOTUTodo | How To Track Merge Status -> https://wiki.ubuntu.com/MOTUToMerge | Grab your merge here: http://tiber.tauware.de/~sistpoty/MoM/index.py?state=new | sign up for ubuntu-motu@lists.ubuntu.com now! | Merges to review & upload: http://tinyurl.com/a3qjh
<lucas> wait
<lucas> http://tinyurl.com/do8cz
<lucas> only fix commited ones
<ajmitch> 26, that's an improvement
<lucas> some of the other ones are probably relevant too, but let's deal with the correctly reported ones first
<lucas> do you know how long it usually takes to get upload rights ?
<ajmitch> depends on how busy elmo is
<lucas> ok, so probably not before UVF ;)
<LaserJock> ajmitch: did you look at my kguitar debdiff?
<ajmitch> possibly not
<ajmitch> I'm still waiting for him to process a bunch of merges I requested about a week ago
<ajmitch> LaserJock: nope
<crimsun> same here, ajmitch
<slomo_> and same here ;)
<ajmitch> hey slomo_
<LaserJock> ajmitch: I got to thinking, why don't we just leave the sync/merge alone and keep the Ubuntu version until dapper+1
<ajmitch> LaserJock: it depends whether you need the debian changes or not
<LaserJock> It's all the same upstream, it's just that Ubuntu and Debian packaged it seperately
<lucas> (I like this)
<ajmitch> what do you like, lucas ?
<lucas> ubuntu and debian packaging the same source, but differently
<lucas> i was kidding
<pkern> Taking the same source and having separate packaging efforts?
<pkern> k
<lucas> LaserJock: maybe asking the REVU uploader to merge the changes would be a good idea
<ajmitch> pkern: even better, differing orig.tar.gz
<ogra> fun
<pkern> ajmitch: Who has it right?
<lucas> I remember reading the two packages
<lucas> both had some stuff right
<lucas> so merging would really be great
<ajmitch> pkern: same files, different md5sum
<ajmitch> but I haven't checked what upstream has
<pkern> ajmitch: Right as in, who took the upstream source verbatim
<LaserJock> just a sec
<pkern> You can't change it anyway, only which a new upstream version.
<pkern> fun
<ajmitch> enough to drive you to drink
<LaserJock> orginal is a tar.bz2, maybe that is the problem
<LaserJock> but anyway, I think we should just leave the Ubuntu version and sync next time
* pkern will be back in 6 months when you say the same :p
<LaserJock> as long as there is a new upstream release there is no problem with syncing for dapper+1
<pkern> LaserJock: It requires coordination (:
<LaserJock> pkern: not really, we should sync on the next upstream release
<ajmitch> and that still requires manual intervention
<LaserJock> why?
<ajmitch> because you still have to know to request the sync then
<LaserJock> yes, but that is easier than figuring out why we did a merge in dapper ;-)
<ajmitch> not if you have a decent changelog, saying 'sync this on new upstream kthx'
<LaserJock> ok, so should I go ahead and send the merge?
<ajmitch> might as well
<LaserJock> ajmitch: ok so what do I debdiff to?
<ajmitch> debian version, and state that when you upload it :)
<ajmitch> and then I'll try & get to it eventually :)
<LaserJock> but also say that you need to use the Ubuntu .orig.tar.gz?
<ajmitch> sure
<LaserJock> k
<LaserJock> ajmitch: done
<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)
<lucas> how does it compare to ksudoku - sudoku puzzle generator/solver
<lucas> (and gnome-sudoku ?)
<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)
<OpsVentus> it dosn't solv puzzels(but I can work something out)
<OpsVentus> but I think it works better
<LaserJock> how can you find out who last changed a package?
<lucas> ksudoku and gnome-sudoku are available in ubuntu
<lucas> can you elaborate "didn't work" ?
<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)
<OpsVentus> yes, I try'd to start it, it gave a "starting gnome-sudoku" but then failed
<ogra> LaserJock, there are these things called changelogs ...
<OpsVentus> then I opened a terminal and did "gnome-sudoku", it gave a error, don't remember what
<OpsVentus> but this was Badger
<ogra> did you file a bug
<ogra> so its fixed in dapper ?
<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)
<OpsVentus> I don't know I didn't find it in Breezy
<ajmitch> gnome-sudoku works for me
<ogra> you just said you had an error
<OpsVentus> yes, in Badger
<ogra> yeah
<LaserJock> ogra: I'm trying to find all the packages I've touched
<OpsVentus> upgraded last week
<ogra> would have been nice to file a bug to make us aware of it ...
<ogra> additionally, i think your game might be a good addition, dont lock it away, OSS is about choice, lets offer it :)
<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
<lucas> OpsVentus: you could add it to https://wiki.ubuntu.com/UniverseCandidates or package it yourself in REVU
<ogra> oh, didnt we switch from UniverseCandidates to support request tickets long ago ?
<ajmitch> ogra: if we did, I didn't hear of it
<ogra> on the pre last motu meeting
<dholbach> does the support tracker support assignments to teams?
<ogra> i thought you were there
<ogra> no idea
<dholbach> if not, that's why
<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
<ogra> i only know we talked about it as alternative to set up a RT on tiber
<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
<ajmitch> I haven't seen any support tickets either
<ogra> i havent looked, i just remember the decision to use LP instead of a self maintained RT
<ogra> as U-C replacement
<Kyral> I hate C...
<ogra> you dont like candidates  ?
<LaserJock> I don't like UniverseCandidates much, something like the merge list would be great
<ogra> LaserJock, thats why we wanted RT
<Kyral> no I hate the language ;P
<LaserJock> Kyral: hmm, I'm not much of a C fan so I'm thinking of converting our data aquisition software to Python :-)
<ogra> cool idea :)#
<LaserJock> right now it uses pgplot and ncurses
<LaserJock> so I thought I could spruce it up a bit
<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?
#ubuntu-motu 2006-01-24
<ajmitch> libnotify-dev is in main, actually
<ajmitch> and you might want to file a bug on it
<Des_MM> ajmitch, Yes, I do, but I also wanted to submit a patch with the bug
<LaserJock> hi bmonty
<bmonty> hey LaserJock
<LaserJock> bmonty: how's the little one?
<Kyral> Back to work
<bmonty> LaserJock: sorry, got distracted....the baby has a cold this week
<bmonty> I'm finally getting LDAP/Kerberos single sign on to work on my network :)
<LaserJock> bmonty: how old is he?
<bmonty> LaserJock: he is almost 3 months old now
<LaserJock> bmonty: well, he better get over his cold before UVF ;-)
<LaserJock> bmonty: cause he'll start doing bug fixes before you know it
<bmonty> heh, yeah I've already showed him dpkg :)
<LaserJock> lol
<bmonty> unfortunately he was more interested in sucking on his fist, so I don't think he will be up to speed to help out on dapper :(
<dholbach> good night everybody.
<ajmitch> night dholbach
<lfittl> gn8 dholbach
<LaserJock> bmonty: hmm, I guess you could have him join in on debian-devel. He should fit in over there (just kidding of course)
<dholbach> bye lfittl, ajmitch
<LaserJock> cy dholbach
<LaserJock> cya I mean
<dholbach> bye LaserJock
<bmonty> bya dholbach
<dholbach> bye bmonty
<Kyral> C...ick
<Kyral> damn Printf
<Kyral> Why people don't use C++ is beyond me...
<ajmitch> because c++ is nasty & evil
<tseng> damn right
* bmonty agrees with ajmitch for most cases
* tseng throws cout right c out the window at Kyral 
<tseng> puts for life
<Kyral> No I'm cursing at printf :P
<LaserJock> hmm, I find for me the problem is hardly ever in the programming language but the one using it
<Kyral> lol
<Kyral> I <3 Python
<Kyral> Malone 5777
<Ubugtu> Malone bug 5777: "gpsim not installable in Dapper" Fix req. for: gpsim (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: Confirmed http://launchpad.net/bugs/5777
<Kyral> I can fix it...
<ajmitch> then do so..
<lfittl> Kyral: I started working on that, but you can do it if you want ;)
<Kyral> ajmitch: I'm at a text console lol
<Kyral> lfittl: It should be easy as changing a dep
<ajmitch> Kyral: so?
<Kyral> meh
<lfittl> Kyral: sure but there is also a new upstream version :)
<Kyral> lfittl: for gpsim?
<lfittl> Kyral: yep (http://sourceforge.net/project/showfiles.php?group_id=2341)
<Kyral> okay
<Kyral> I'll diff it
<azion> Hey all, was wondering if there's any help need at the moment?
<LaserJock> azion: lol there is always help needed
<azion> Sorry the stupid question, just wondering how abouts I go helping with motu
<LaserJock> no, it's not a stupid question
<LaserJock> it's just right now there is actually a lot going on because we have a deadline tomorrow
<sistpoty> hi folks
<azion> Ah for what?
<azion> Hi sistpoty
<LaserJock> upstream version freeze
<azion> I see
<sistpoty> did anyone request scapy sync yet?
<azion> Ye've finished the main branch?
<azion> Or is bug fixes?
<LaserJock> well, we are trying to get everything merged/synced from Debian unstable
<azion> Though job
<azion> *Tough job
<azion> LaserJock, How can I go about helping with MOTU?
<siretart> hey sistpoty
<sistpoty> huhu siretart
<siretart> sistpoty: how are you? are you feeling better?
<LaserJock> azion: well have you seen the MOTU wiki page : wiki.ubuntu.com/MOTU ?
<tseng> azion: start by reading the topic
<ajmitch> hi siretart, sistpoty, hub, et al :)
<sistpoty> siretart: still a little bit ill, but much better already :)
<siretart> hi ajmitch
<azion> LaserJock, Ya have it infront of me
<hub> hi
<siretart> sistpoty: I'm happy to hear that :)
<sistpoty> hi ajmitch
<sistpoty> hi hub
<LaserJock> azion: do you have any packaging experience?
<siretart> sistpoty: tomorrow 1400?
<sistpoty> siretart: I'll be there ;)
<siretart> same here :)
<azion> LaserJock, Only learning now really
<siretart> but I need some sleep now. gn8 folks!
<sistpoty> gn8 siretart
<lfittl> gn8 siretart
<LaserJock> azion: ok, then maybe you could look at MOTUBugFixing and DeveloperResources
<azion> LaserJock, Afraid haven't had any bug so far with Ubuntu. lol! Good thing!
<LaserJock> azion: well, then start fixing the ones other people have found ;-)
<azion> LaserJock, I would be interested in doing Developer Resources
<LaserJock> azion: just hanging out here for a while will help
<azion> LaserJock, Okay
<azion> LaserJock, Cheers
<azion> Is Azureus going to be included in Ubuntu?
<crimsun> doubtful. Does it run with gcj?
<azion> Not sure, have to check it out
<whiprush> someone from fedora blogged about how they just got it working with gcj
<azion> Must have a looksie
<sistpoty> anyone have a clue what's going on with gl/glu header packages? seems the one listed in motuglutransition point to x11-proto-gl
<sistpoty> hm... just found libgl1-mesa-swrast-dev which seems to do the trick... strange
<sistpoty> nope, fails when linking... I guess s.th. with the gl/glu-stuff is broken atm
<azion> The forums down?
* ajmitch shrugs
<ajmitch> they could be, I guess
<azion> Can't get in
<azion> Could be just busy too I guess
<lfittl> hub: New upload: http://revu.tauware.de/details.py?upid=1545
<hub> i saw
<sistpoty> hi minghua
<minghua> hi sistpoty
<minghua> are we in UVF already?
<ogra> nope, tomorrow
<ogra> or rather "in some hours"
<sistpoty> hehe
<minghua> I remember something like "one week grade period for universe packages that don't require new dependencies", is that true?
* ogra wonders why nobody thinks that *we* can be upstream for debian packages
<minghua> I am thinking what to do with my scim packages
<minghua> I have them ready now, but I need to wait for my sponsor
<minghua> if there is no grace period, should I try to get them uploaded today?
<ogra> i'd say yes
<sistpoty> minghua: that would be new to me... I only know of a later date for merges to be finished (that are still on the list)
<lfittl> hub: You finished with reviewing? :)
<minghua> okay, in that case, I should repackage the source as -0ubuntuX version, right?
<hub> nope
<ogra> minghua, if they're ready, get them in
<hub> sorry I was doing something else
<hub> done
<minghua> ogra: can you sponsor?  I think I can get the repackaging done in half an hour.
<lfittl> hub: thanks :)
<ogra> i cant sponsor debian stuff minghua
<minghua> ogra: I mean sponsoring ubuntu stuff, I am not MOTU yet
<minghua> what is the MOTU term for that... upload?
<ogra> minghua, oh, surem but not tonight anymore, send me a mail (ogra@ubuntu.com)
<ogra> (its 5am here, my GF kills me if i dont come to bed now)
<minghua> any other MOTU willing to upload two universe package for me?  otherwise I'll wait for ogra
<minghua> ogra: sure, go to bed, hurry :-)
<ogra> minghua, nah, i'll finish my glass of wine :)
<sistpoty> minghua: sorry, I should have been in bed for a long time already... (same TZ as ogra)... so I can't promise right now
* minghua goes repackaging
<sistpoty> hehe
<lfittl> I'm off to bed now (also 5am here..), gn8 all
<sistpoty> gn8 lfittl
<minghua> sweet dreams, european MOTUs :-)
<lfittl> thanks :)
<azion> Ng
<azion> Night
<sistpoty> gn8 azion
<azion> Im not gone yet
<sistpoty> oh... sleepiness in my brain already ;)
<azion> sistpoty,Do u have MSN or anything
<sistpoty> azion: nope... I used to be on icq, but now I almost exclusively use irc
<hub> azion: use jabber :-)
<azion> sistpoty, Arr ok, whats that?
<hub> azion: icq?
<azion> sistpoty, Ah IM
<sistpoty> yep
<azion> sistpoty, You have ICQ?
<sistpoty> azion: had... I didn't launch it for half a year now...
<hub> azion: what's wrong with IRC?
<azion> sistpoty, What time will you be on tomorrow at?
<LaserJock> minghua: you around?
<minghua> Hmm...
<minghua> LaserJock: yeah
<LaserJock> minghua: I was just reading your -motu email
<marcin> hello guys
<azion> Hey
<sistpoty> azion: don't know yet, if I'll be on... probably later in the evening (23 utc) or so
<azion> sistpoty, What time will you be on tomorrow at
* minghua just got the ACCEPT mail from Debian, yeah!
<azion> sistpoty, Ah, Im in GMT, got email?
<marcin> I want to send signed mail to revu - asking to add me to keyring
<minghua> LaserJock: any comments?
<LaserJock> minghua: how do we keep in good communication with Debian, I mean we touch a lot of packages so we would have to talk to a lot of DDs
<marcin> and howto says that I should send my GNUPg KeyID in this mail...
<sistpoty> azion: gmt, yes, but that's just a rough guess... and didn't get email yet
<marcin> could someone tell me what is exactly this gnupg KeyID?
<azion> sistpoty, So how do I contact you, lol!!!
<marcin> real name + comment + mail address?
<sistpoty> azion: stay around in -motu... and I'm not the only helpful motu ;)
<azion> sistpoty, True, just I need to be spoon fed this stuff
<ogra> minghua, as i said above, i disagee, if we have introduced a package,m why should we ask the debian maintainer before putting new stuff up ?
<psusi> anyone know of a debian-installer guru?  I'm trying to udebify the dmraid package and integrate it into the setup cd
<marcin> hello guys - can someone help me with this gpg stuff?
<minghua> LaserJock: I personally would (1) let the Debian maintainer know that we are modifying his/her package (2) let him/her know if we have non-ubuntu-specific changes
<ogra> minghua, i'm upstream for ltsp and ltspfs as well as ltspfsd for debian ... i wont ask them if i adopt new stuff from upstream
<sistpoty> marcin: maybe that'll explain what gnupg is better than I can: http://www.gnupg.org/(en)/documentation/faqs.html
<marcin> sistpoty: got this manual in another window
<minghua> ogra: are you talking about packages already in debian or packages that get into ubuntu first then merged into debian?
<marcin> sistpoty: but I'm just not sure what KeyID should I send to REVU
<ogra> minghua, i talk  about packages where ubuntu is upstream
<sistpoty> marcin: the one with which you sign emails
<marcin> sistpoty: because it can be just few letters and numbers I get after gpg --list-keys
<ogra> minghua, and imho debian should accept us as such
<minghua> ogra: then of course you don't need to :-)
<azion> Ok, guys, I'm off. Thanks for all your help, talk to ye tomorrow
<marcin> sistpoty: or it can be name+comment+mail
<ogra> minghua, and imho that applies to all 0ubun tu1 packages
<sistpoty> marcin: basically you don't explicitely need to state the gpg-id, just sign the message with it
<minghua> ogra: in that case I think it's the debian maintainer's responsibility to keep the communication
<marcin> sistpoty: ok thanks - sending
<minghua> ogra: I disagree (the apply to all 0ubuntuX part)
<ogra> minghua, we communicate very well .... but it think its important that debian also accepts that there are packages where *we* are upstream
<ogra> minghua, why ?
<minghua> ogra: I don't want to make a big fuss about it, but when I wrote the mail I was thinking of my own debian packages
<minghua> my scim packages got uploaded as -0ubuntu1 in dapper twice, neither of them has a prior notice to me
<ogra> minghua, sure, but 0ubuntuX packages *are* not in debian ... why shouldnt *we* be upstream for *them* ?
<minghua> I didn't even know the ubuntu uploader was planning to do that
<minghua> and I actaully explicitly expressed that I "will try to take care of the packages in ubuntu" on ubuntu-devel
<ogra> yes, thats bad ... in case a package exists in debian, debian is indeed the upstream
<minghua> and in the second case, there should be some documentation change/warning when packaging the new upstream version
<minghua> ogra: yeah, then we more or less agree
<ogra> but for 0ubuntuX packages that really deserve that versioning, i see no reason why we shouldnt be upstream
<ogra> for ltsp debian accepted that so this far, that they put a XdebianX version up ;)
<minghua> ogra: my point was that, as MOTU we shouldn't upload a new upstream version without a wishlist bug in debian just because the debian maintainer hasn't get to it yet
<minghua> unless we are quite confident about the packaging ourselves
<ogra> for existing packages i totally agree
<ogra> for new packages i dont ...
<minghua> in my case, if the ubuntu upload had asked, I can at least give him a patch that fix an important typo
<ogra> simply because i expext to be respected as a distro from debian
<ogra> *expect
<minghua> ogra: I haven't thought about new packages carefully yet, but my mail mainly refer to packages already in debian (in your words, MOTU being downstream)
<ogra> yup
<ogra> as i said, there i totally agree
<minghua> great to clear all these up :-)
<ogra> :)
<minghua> I'll probably follow up in list for more clarification
<sistpoty> minghua: take in account that ubuntu development goes a little bit other than debian. In the early phase usually the repo get's broken pretty hard, so I guess at that time waiting for response from DD wouldn't need to be necessary
<minghua> sistpoty: my personal opinion is "we should at least try"
<sistpoty> minghua: however the DD should be notified in all cases... that's at least what I think ;)
<minghua> sistpoty: a mail to the debian maintainer definitely won't hurt
<minghua> sistpoty: exactly, if the DD won't reply our notification mail, it's him/her not willing to communicate, not us :-)
<sistpoty> :)
<minghua> and I think Lucas's point on the "new upstream" wishlist bug is quite good
<sistpoty> yes, it is
<minghua> can I ask for sync from incoming?
<minghua> my scim package just got uploaded by my sponsor :-)
<LaserJock> sorry, was away for a second. So what about bugs? How do we communicate with Debian about bugs?
<LaserJock> whenever we get a bug that isn't Ubuntu specific what should we do?
<sistpoty> minghua: don't know... maybe ask elmo about it?
<sistpoty> LaserJock: if I can fix it, I do and report it back to BTS with patch
<minghua> LaserJock: I would first ask if the debian maintainer to subscribe to said package in manlone
<LaserJock> seems like we have to do the work of 2 distros :(
<minghua> LaserJock: if he is not willing to (maybe because the change in ubuntu is too large), I'll ask him if it's okay for me to forward the bug to debian BTS if I _think_ it applys to debian as well
<LaserJock> but I guess we get a lot of packaging from Debian so it evens out
<minghua> LaserJock: if he is still not happy, I'll have to try to reproduce the bug in debian and then report
<minghua> LaserJock: an important point is that the Debian maintainer may know better than we do about the package
<minghua> LaserJock: and as I've been saying these are my personal opinions
<LaserJock> but I think we could literally spend all MOTU time just communicating with Debian, or is it not that bad?
<LaserJock> minghua: I agree with what your saying, I'm just trying to figure out how I can do it in a pratical and effective way
<sistpoty> LaserJock: we could spend all motu-time with merging, if we didn't communicate back to debian
<LaserJock> sistpoty: true, true
<LaserJock> we do spend a lot of effort merging
<LaserJock> I'm just wondering if we can create some tools to help
<LaserJock> something like a button in Malone to send an email to BTS or at least a template for common things
<LaserJock> at this point I'm a bit overwhelmed and shell shocked by Debian so anything to make it easier would be nice ;-)
<sistpoty> LaserJock: with an unstable chroot, you can just use reportbug (I guess I'm faster with it, since I'm used to shell)
<minghua> not to mention reportbug adds ton of useful information for debugging as well :-)
<sistpoty> that's what I really dislike from malone... not even the version of the package installed
<LaserJock> I used reportbug to do an ITP the other day :-)
<LaserJock> but I had to get exim4 installed first
<Kyral> Emacs has an ITP Mode lol
<LaserJock> sistpoty: do I need to be in a sid chroot for reportbug? I used dapper but sent it to Debian
<minghua> LaserJock: use "reportbug -f file" then post it into your email client
<sistpoty> LaserJock: didn't look at the changes of reportbug... and I only have unstable around (even a real system, that I use for chroot)
<LaserJock> anyway, something in Malone would be nice because that is where the Ubuntu bug info is
<minghua> LaserJock: for ITP it's okay, but probably not good for a real bug
<LaserJock> oh, that makes sense
<LaserJock> it sense system info doesn't it
* sistpoty is just smoking one last cigarette for tonight
<LaserJock> ok, so does anybody know what "Request fix: + Upstream + In Distribution" are for?
<LaserJock> gotta go, cya MOTU
<sistpoty> cya LaserJock
* sistpoty is off to bed as well
<sistpoty> gn8 everyone
<LaserJock_away> cy sistpoty
<LaserJock_away> cya I mean
* freeflying is away: Away at the moment
<Kyral> The HURD is in Ubuntu now?
<bur[n] er> anyone know where to report a bug about the gnome run dialog?
<Gloubiboulga> hub, ping
<Gloubiboulga> bur[n] er, have a look at https://launchpad.net/malone
<bur[n] er> yeah, but know what package the run dialog is part of?
<Gloubiboulga> I don't know
<minghua> bur[n] er: by "run dialog", do you mean the one that pops out when you press alt-F2?
<bur[n] er> yeah
<bur[n] er> or "doesn't" ;)
<bur[n] er> hence my bug
<bur[n] er> (it stays behind any open windows for some odd reason)
<minghua> bur[n] er: then gnome-panel, I believe
<bur[n] er> danke
<minghua> I am not positive, but even if it's wrong, I don't think the maintainer will be unhappy
<minghua> should be close enough
<bur[n] er> that would make sense, that was one of the new packages I received today
<viviersf> mornin
<viviersf> yo @ ajmitch
<raphink> hub: don't get your comment on http://revu.tauware.de/details.py?upid=1482 ... There's no orig.tar.gz . How then did you review the package?
<raphink> hi viviersf
<viviersf> lo
<ajmitch> hi viviersf
<raphink> hi ajmitch
<ajmitch> hello raphink
<raphink> ajmitch: could you give me your opinion on this package ? http://revu.tauware.de/details.py?upid=1545
<raphink> if you think my remark is correct or not?
<tepsipakki> I still can't login to REVU, although I can decrypt the recover-message, duh
<raphink> tepsipakki: ping a REVU admin
<dholbach> good morning
<tepsipakki> ok, any revu-admins around?-)
<Gloubiboulga> morning dholbach
<dholbach> hey Gloubiboulga
<raphink> hi dholbach && Gloubiboulga
<dholbach> hellas raphink
<raphink> dholbach: could you give me your opinion on http://revu.tauware.de/details.py?upid=1545 please?
<Gloubiboulga> hello raphink
<raphink> dholbach: it's not a review, just an opinion on the status of the package
<dholbach> I personally don't like patchsets in the orig.tarball.
<raphink> dholbach: it's mostly about the merging stuff actually
<dholbach> It's a maintainer decision to ship patches or not, so if there'd be a bunch of patches in debian/patches (however big they are) and people are notified that it's the Nicotine DA version (or whatever), I'm fine with it.
<raphink> I'm worried we have to carry around such a huge patch
<raphink> well dholbach then it should be a new package
<raphink> and should not use the existing changelog I guess
<dholbach> If the package uses a nice build/patch system, that's 'easy' to do.
<dholbach> If it improves the package...
<raphink> hmmm
<raphink> dholbach: I found some packages that were advocated twice a long time ago and never uploaded
<raphink> could you check them?
<dholbach> I'd prefer if somebody else could do this.
<raphink> I checked there is no newer version available, so they are ready to go but I havn't got upload rights yet
<dholbach> I'm *very* busy.
<raphink> hmm ok
<raphink> sorry then :)
<dholbach> Don't worry.
<dholbach> If it's urgent, I can do it.
<raphink> well it's not urgent, but these packages have been advocated months ago for some of them
<raphink> http://revu.tauware.de/details.py?upid=1258 this one was ready to go before xmas
<raphink> and this one aswell http://revu.tauware.de/details.py?upid=1238
<dholbach> and they did not just ftbfs?
<raphink> hmmm
<raphink> where shall I check ? :s
<raphink> I don't remember the url to the buildd logs
<dholbach> http://people.ubuntu.com/~lamont/buildLogs/
<raphink> ty
<raphink> there's no entry in the build logs for these packages :s
<dholbach> Ok.
<dholbach> then it's up to elmo to ask him, if he maybe rejected them because of one reason or the other
<raphink> pretty normal since they were not uploaded
<raphink> I can check if they build on a pbuilder now
<raphink> dholbach: I think they were not uploaded, at all
<raphink> from REVU
<raphink> the comments say : ok twice
<raphink> but not uploaded
<dholbach> Hm.
<\sh> moins
<raphink> hi \sh
<raphink> dholbach: checking if they FTBFS or not
<\sh> oh well..some problems are resolving magically
<\sh> from a company employee to a freelancer in less then one month..
<ajmitch> \sh: you have some work now?
* ajmitch really really wants those requested syncs to go through
<\sh> ajmitch: not really I'll do some monitoring and sysadmin job for a company as freelancer. A friend who is doing that normally can't right now, because he has troubles with his other company, and he and I worked before that for ISH...so I step in, and earn some money for some weeks
<\sh> ajmitch: yeah..I'm just waiting for some syncs as wlel
<ajmitch> about a week I've been waiting now
* ajmitch is stuck on somewhere between 64-128Kbps until next week
<ajmitch> went over my traffic allowance
<ajmitch> sigh, 116 merge bugs still open
<ajmitch> ls -alrt
<ajmitch> EWIN
<ajmitch> :)
<\sh> dholbach: don't merge wesnoth 1.1-2, I beg you not to do it :)
<ajmitch> sigh
<ajmitch>  zope-extfile_1.4.4-1ubuntu1_source.changes REJECTED
<dholbach> \sh: It's not assigned to me, I won't do it - I have enough to do atm.
<\sh> dholbach:
<\sh> wesnoth  daniel.holbach@ubuntu.com  ASSIGNED
<\sh> whysoever :)
<ajmitch> it's probably a mistake
<\sh> yes but I'm careful :)
<dholbach> \sh: https://launchpad.net/distros/ubuntu/+source/wesnoth/+bug/6559
<Ubugtu> Malone bug 6559: "wesnoth: merge new debian version" Fix req. for: wesnoth (Ubuntu), Severity: Normal, Assigned to: Stephan Hermann, Status: Unconfirmed
<\sh> bah....sistpoty :)
<\sh> dholbach: and yes I know the bug :)
* ajmitch wonders if zope-ttwtype works with a current zope-cmf
<ajmitch> hm, last released in 2003
<siretart> hi folks
<siretart> any news about syncs?
<dholbach> \sh: It's assigned to you, man.
<ajmitch> siretart: none at all
<\sh> dholbach: I know the bug is assigned to me, I just was suprised that the list had your name :)
<siretart> ajmitch: I've seen one from infinity yesterday
<ajmitch> siretart: was it really a sync?
<ajmitch> it might have been done on the spot
<ajmitch> as elmo has done that for me before
<siretart> it looked like the sync
<ajmitch> php4, looks synced
<ajmitch> unless he faked it :)
<siretart> but mdz mentioned the last tb meeting we will be on soyuz next week anyway...
<lifeless> opensync is getting close to top
<lifeless> :[
<ajmitch> yes but we don't know if that changes sync processes
<siretart> .. perhaps thats why elmo has no time to do it. but thats just a guess :(
<ajmitch> lifeless: we can probably get it in - new packages can still get in universe until feature freeze
<ajmitch> I hope
<lifeless> heh
<siretart> I hope that results that we can request syncs directly. but thats just a hope
<ajmitch> siretart: probably not, to start with
<ajmitch> oh good
<ajmitch> my upload to debian yesterday is on the autosync list
<ajmitch> no sign of zope3 being synced
<siretart> perhaps anyone should raise this topic on #ubuntu-devel, but I'm too busy atm with work
<ajmitch> sigh, why does this install into /usr/lib/zope/Products?
<ajmitch> broken thing
<ajmitch> my bad, not broken, the package has .so files in it
<ogra> if you need it broken, just break it :P
<marcin`> hi MOTU
<marcin`> got a problem - I'm propably just dumb... but... could someone help me anyway?
<marcin`> I got gpg key that I sent to REVU
<marcin`> and it's accepted so I got mail that I can upload my packages to REVU
<marcin`> I also got package in pbuilder/results directory
<marcin`> and I would like to upload it's *.changes file to REVU
<marcin`> the problem is that it says that my package is not signed
<marcin`> could someone help me and tell how to sign *.changes file?
<\sh> marcin`: only source uploads :) so *_sources.changes has to be used for dput
<lfittl> marcin`: Create a source package by using dpkg-buildpackage -S -sa -rfakeroot
<\sh> or just shortways debuild -S -sa
<marcin`> and the same thing but with pbuilder?
<marcin`> pbuilder --debbuildopts '-S -sa' is ok?
<Nafallo> nope, but pbuilder does something like that before it starts working inside the chroot.
<lfittl> source packages are created without pbuilder, simply execute the above command in the directory where you normally call pbuilder
<marcin`> lfittl: hmm right...
<marcin`> lfittl: so anyway I hope that there will be no problem that I use breezy and want to build source packages for dapper
<Nafallo> and then debsign *_sources.changes before dput-ing them :-)
<lfittl> marcin`: as long as you test them in your dapper pbuilder, that should be no problem
<marcin`> Nafallo: woooow finally :)
<marcin`> Nafallo: thanks - now I know how to sign this stuf... that should be in wiki or something...
<Nafallo> well, I have pbuilder sign my stuff automagically ;-)
<lfittl> marcin`: Feel free to add it ;)
<marcin`> ehh troubles troubles troubles...
<marcin`> what should I do when dpkg-buildpackage says that
<marcin`> gpg: [stdin] : clearsign failed: secret key not available
<marcin`> ?
<tepsipakki> you are fakeroot?
<Nafallo> see to that the e-mailaddress you use in the changelog is a uid of your gpg-key.
<\sh> marcin`: then you have a problem with your key or the uid in the changelog doesn't match the uid of you gpg key
<marcin`> and uid is my name + mail?
<tepsipakki> ah, I remember seeing that myself, and the reason was the email
<Tonio_> hum I saw in some Riddell's REVUs that some tarball have a lot (while not all) executable files....
<Tonio_> what would you do ? rebuild tarball, cdbs patch or a series of chmod in the rules file ?
<raphink> sorry Riddell I didn't really check if the files chmod had been checked before advocating again, my fault ;)
<raphink> s/checked/changed/
<azion> Hey all
<zakame> hi azion
<azion> How do I submit an updated package version
<Kyral> morning MOTU
<zakame> heya Kyral :)
<zakame> and mhz :)
<mhz> hey all
<zakame> azion: hmm, you mean a new version of a package, or a request for updating a package to a new version?
<zakame> heya ajmitch_
<azion> zakame, Either, new version of aMSN is out
<Kyral> Is it in Debian?
<\sh> it's uvf
<zakame> azion: ah... well, its UpstreamVersionFreeze time, so unless there are critical fixes (like security ones) I don't think we'll be able to push that in dapper now :(
<Hieronymus> azion: it was synced
<Hieronymus> or well, that was requested..
<azion> Sweet, cool
<azion> Yer doing uvf today, eight?
<azion> Yer doing uvf today, right?
<Kyral> So...what does X11R7 bring...
<ogra> a shiny new version number at least :)
<dholbach> It IS UVF.
<Treenaks> dholbach: some people are special...
<\sh> And I don't like writing exception reports for uvf...which I have already for pykde
<\sh> I could have done it yesterday night, but I was sleeping and not reading the release announcement
<dholbach> \sh: I just don't want to be flooded with requests like "look at this 3.5MB diff and tell me if I can upload it" - if we all have a look at stuff, it's easier to manage.
<dholbach> We can surely be a bit more lax now still.
<dholbach> If you don't like the process I had in mind, comment on it on the mailing list and propose something else.
<\sh> dholbach: hehe I'm talking about main :) which is much more difficult because of colin/matt double :)
<ogra> lax == 7MB diff ?
<dholbach> \sh: ahh right
<dholbach> ogra: yeah :-p
<\sh> dholbach: and your proposal is absolutly ok :)
<ogra> :)
<dholbach> ogra: no, for example the lyx update looks good to me
<ogra> yup, i thought the same
<dholbach> it introduces just bug fixes.
<ogra> the argument for backwards compatibility is also convincing
<\sh> dholbach: think we have to stick with some main workflows for serious things like UVF but that's a normal workflow in my POV
<dholbach> Cool.
<dholbach> I'll mail lfittl and the list, that his update is in order.
<azion> What exactly does upstream mean?
<Hieronymus> azion: the people who develop an application, most of the time
<Kyral> The originial dev
<zakame> in most cases for Ubuntu, its Debian; for some (like Wine), its the Wine devs from WineHQ
<tseng> saying Debian is upstream is pretty misleading in this context
<tseng> upstream most always means the software author{,s}
<azion> Ok, so we'll say Windows would be microsoft, or the 2000 kernel?
<tseng> the 2000 kernel is irrelevant
<tseng> Microsoft
<tseng> but upstream is pretty irrelevant in windows, as ms does all the packaging
<azion> Ah I get you now, thanks man
<Hieronymus> azion: the people who make a program. GNU, Linux kernel hackers, Freeciv people, ..
<tseng> upstream describes the relation between an open source software developer
<tseng> and the distributor
<azion> And versionfreeze?
<tseng> uh
<azion> Is that when ye stop taking on new packages
<Hieronymus> yes
<tseng> new versions of packages
<azion> So from here until dapper's released ye'l be working on enhancements, bugs etc.
<Nafallo> new versions of upstream, not of packages :-)
<Nafallo> except the exceptions ofcourse. like gnome :-).
<Kyral> New packs *points to REVU*
<Kyral> *cough cough* ;P
<Nafallo> ajmitch: zope3.2 seems to be auto-synced :-)
<siretart> woooho
* siretart just got a sync request acknowledged from katie :)
<zakame> w00t
<hub> crap
<hub> the latest thunderbird update kills enigmail
<hub> :-(
<hub> looks like I have to rebuild it
<Nafallo> hub: changelog etc... ;-)
<hub> Nafallo: ?
<Kyral> I <3 Mutt
<\sh> hub: check the changelog of thunderbird...know issue
<\sh> known issue even
<hub> no doubt
<hub> enigmail is tied to a specific version of tbird anyway
<hub> but I don;t have the changelog
<hub> I haven't upgraded yet
<hub> upgrading
<hub> I'll fix the enigmail package
<crimsun> siretart: for ones that you just re-requested?
<Nafallo> I think enigmail is in main anyway :-)
<siretart> crimsun: sorry?
<siretart> crimsun: no, for earlier requests, too. but not for all, hence my re request
<crimsun> siretart: ah, cool :)
<hub> Nafallo: last I looked Enigmail was in universe
<Nafallo> k
<Nafallo> it's in main for dapper anyway :-)
<jeld> hello all
<jeld> is there a way to make dpkg run post/pre install scripts verbously?
<jeld> trying to debug package install and cannot seem to be able to figure out what exactly fails
<crimsun> what happens when you dpkg -i [..] ?
<jeld> it reports that post-install script failed
<crimsun> what package's postinst?
<lucas> hi
* lucas feels the heat on ubuntu-motu@ ;)
* Kyral shrugs
<Kyral> Skate time :D
<Kyral> http://yro.slashdot.org/article.pl?sid=06/01/19/1346237&from=rss <--And HOW!
<bddebian> Heya Gang
<LaserJock> hi bddebian
<bddebian> Howdy LaserJock, how goes the battle? :-)
<LaserJock> can we ask for a sync if it is a new package in Debian?
<LaserJock> oh, it's alright
<LaserJock> bddebian: you read ubuntu-motu ?
<bddebian> LaserJock: Afaik, yes, you can request a sync of a new package
<\sh> LaserJock: it's UVF
<bddebian> LaserJock: No, I need to join that
<LaserJock> \sh: but for new packages I have until FF, right?
<\sh> LaserJock: only new revisions of debian packages are allowed without an exception..but new upstream versions == no, or try to explain yourself like dholbach explained :)
<\sh> LaserJock: yes
<LaserJock> even if the new package is coming from Debian, right?
<\sh> LaserJock: if it's completly NEW?
<bddebian> Oh yeah, UVF
<\sh> LaserJock: I think thats allright as well..
* bddebian is SOOO behind :'-(
<LaserJock> ok, I think I've got it now
<LaserJock> I have two packages going into Debian NEW and I had hoped that they would make it into dapper
<lucas> LaserJock: libgnuplot-ruby should get in before FF too
<LaserJock> lucas: hmm, I wonder if that counts. I think we could make a case ;-)
<nomed> could anyone try out the example ...
<nomed> /usr/share/doc/python-gnome2-extras/examples/gtkhtml2/simple-browser.py ?
<nomed> i made a dist-upgrade to dapper ..
<nomed> and the pymozembedded modules seems to "segfault" ...
<nomed> in breezy i hadn't that problem ...
<Kyral> Ahh cleaning out the system
<Treenaks> Kyral: uh.. TMI?
<Kyral> my computer...
<Kyral> of packages I don't use anymore
<Treenaks> ah ok :)
<Kyral> like GNOME and KDE go bye bye ;P
<\sh> hehe...alice in wonderland
<Treenaks> down the rabbit hole? still TMI :)
<\sh> strange, that 1999 matrix movie still has this impact to people
<tseng> alice in wonderland is from the 1800s
<Treenaks> The Matrix just referenced it because it was convenient :)
<\sh> tseng: but not the attached string to, how did cypher said it, "alice is going bye bye" or so.
<tseng> er
<tseng> you are weird :)
<\sh> it's just like "make my day"
<\sh> or "hasta la vista, baby"
<Treenaks> \sh: he said 'Kansas is going bye-bye'
<\sh> Treenaks: right...because alice came from kansas...
<Treenaks> \sh: no, that was Dorothy from the Wizard of Oz :)
<\sh> but kansas was "the wonderland", regarding that everything was a bad dream, because she banged her head badly during a tornado
<\sh> ah come on...who cares
<Treenaks> you're confusing stuff now :)
<\sh> Treenaks: right.
<\sh> wizard of oz, alice in wonderland, \sh in lingerie, everything the same
<Treenaks> \sh: whatever turns you on man...
* Treenaks steps away
<\sh> Treenaks: a good job and a lot of money..
<Treenaks> \sh: what? being a male lingerie model?
<\sh> Treenaks: not possible..but I'm waiting for king kong 2006 movie remake...I'm playing king kong :
<\sh> )
<Treenaks> in lingerie?!
<\sh> if we substitute lingerie with "hairy chest" why not
<\sh> stop now...I can't smoke properly
<rbelem> hey people, i have one question about cdbs. can you help me?
<rbelem> is there a possibility to build a package with two different configuration? like package and package-minimal
<azeem> rbelem: yes
<azeem> rbelem: have your build target depend on two other, like build-all, build-minimal
<azeem> and then either install everything first, clean, and configure/build again, or have two seperate build dirs, if the package allows
* Kyral begins to look over KDE-APps.org in addition to GNOMEFiles
<rbelem> azeem: hum... i see
<rbelem> azeem: but is it possible with cdbs?
<azeem> no
<rbelem> ok, thx azeem
<slomo_> rbelem: look at mplayer or totem for an example how to do it
<Kyral> hmm
<rbelem> slomo_: cool!
<Kyral> nice looking
<Kyral> http://jr.falleri.free.fr/keep/wiki/Download
<Kyral> ah its already in REVU lol
<Kyral> oh hub thanks for reviewing and advocating GTKEdit </late>
<\sh> GTKedit?
<Kyral> Yah
<Kyral> Its a new package I have in REVU
<Kyral> http://revu.tauware.de/details.py?upid=1523
<Kyral> feel free to advocate ;P
<Kyral> Okay question
<Kyral> which runlevel would I enable for Fetchmail for it to start on boot?
<aa_> is there a list of packages anywhere please?
<Kyral> packages.ubuntu.com?
<aa_> no idea, I can only find wiki tips on how to become a ubuntu maintainer
<aa_> ah yes, that works, thaks
<Kyral> You have to be a member first...
<aa_> oh, nah, I am a developer. This stuffs just confuse me.
<aa_> just wanted to check some things
<Kyral> lol
<Kyral> glad to meetcha..I'm one of the dudes who makes packages ;P
<jamessan> aa_: you following me around or something?
<Kyral> lol
<jamessan> ;)
<aa_> jamessan: yes!
<Kyral> Attentive Upstreams are nice :D
<aa_> jamessan: I believe you did tell me about the existence of this channel, yes
<aa_> jamessan: are you a ubuntu maintainery-type-person?
<jamessan> aa_: nah, I just idle here
<aa_> who packages supy?
<jamessan> learning by osmosis is fun
<jamessan> me
<aa_> ah
<jamessan> someone in MOTU then syncs it for Ubuntu
<slomo_> aa_: hm, i can't find a package named supy in ubuntu
<jamessan> slomo_: supybot
<aa_> yes, that
<jamessan> aa_: there's even one in the channel  :)
<slomo_> ah ok :)
* jamessan points at Ubugtu 
<aa_> ah, nice
* Kyral groans at Debian-Devel
<jamessan> heh
<rbelem> hey slomo_
<Kyral> someone shot down GTKEdit just because it is GTK 1.2
<Kyral> I think he failed to see the target machine for this app....
<jamessan> aren't they trying to drop GTK 1.2?
<rbelem> slomo_: do you know something about libraw1394?
<slomo_> Kyral: who would it be that wants gtk 1.2? it's a nightmare imho ;) and i doubt gtk2 is much more demanding in memory/cpu
<Kyral> Target machine for GTKEdit. Pentium 166 MHz, 32MB RAM
<\sh> with 32mb i would use vi
<Kyral> lol
<\sh> not vim, plain vi :)
<\sh> real vi
<Kyral> What of those people who 1. Don't like vi 2. Don't like the commandline?
<\sh> not the newly vim...no unix vi :)
<\sh> Kyral: buy a new machine :)
* Kyral falls down
<\sh> hehe
<Kyral> jeez...
<Kyral> frankly this thing screams "Damn Small Linux" to me
<\sh> damn small linux? the usb distribution on 128MB ram sticks?
<Kyral> Its down to that now?
<\sh> dunno :)
* Kyral sighs
<Kyral> Why do I think it will be hard to get another vote?
<stratus> lucas, ping
<lightbright> hello
<LaserJock> hi
<lightbright> LaserJock: hi
<teprrr> hello there.. Riddell and \sh_away told me that I should get an account to REVU. came to ask if someone can help me with gpgkey thing.. anyone wants to help me a bit?
<LaserJock> teprrr: so I take it you don't have a key currently
<teprrr> LaserJock, correct
<teprrr> though I have tested and created a key with kgpg
<LaserJock> then you should have a key ;-)
<teprrr> but it's been a while ago and don't have the key anymore
<LaserJock> oh
<teprrr> heh :)
<LaserJock> so can you make a new key with kgpg ?
<teprrr> so I just create a new key and send public part or..?
<mbreit> teprrr: exactly
<LaserJock> well, I'm not terribly familiar with kgpg but you should be able to send your key to a key server from it
<lucas> stratus: pong
<mbreit> yeah, having that key on a keyserver would be great ;)
<LaserJock> teprrr: I would also look at https://wiki.ubuntu.com/GnuPrivacyGuardHowto
<LaserJock> teprrr: especially the the "Uploading the Key" section
<teprrr> ahh, okay, thanks
<mbreit> teprrr: but remember that you can't ever delete a key from a keyserver once you uploaded it
<stratus> lucas, oh i replied your message in -devel, i was going to talk here but i think it's better discuss there.
<lucas> okey
<stratus> lucas, are you reading utnubu-discuss too?
<LaserJock> lucas: yes, interesting email
<lucas> stratus: yes
<lucas> stratus: I prefer to go slowly with this proposal
<stratus> np, so you'll see the buxy' mail.
<lucas> first get accepted by ubuntu, then move to debian
<stratus> lucas, sure but debian has no problems with volunteers (really)
<stratus> read my reply and you'll understand
<LaserJock> lucas: so this DCT would be different than the Utnubu?
<ogra> stratus, did someone find out what happened with the ltsp package in debian ?
<stratus> i really believe that a small group of DDs and some others as a MOTU subteam (or whatever) can handle the DCT thing in universe
<stratus> ogra, i think otavio talked with ajt.
<ogra> ah, he didnt mail, i was wondering
<lucas> LaserJock: yes, utnubu is more a debian team talking to ubuntu
<stratus> ogra, i'm waiting otavio' reply to pkg-ltsp ml, but i'm gonna ask tomorrow anyway
<lucas> DCT would be an ubuntu team talking to debian
<ogra> yup
<lucas> of course, both teams would talk together
<LaserJock> lucas: oh, ok
<lucas> stratus: Raphael (buxy) reviewed the proposal before I sent it to ubuntu-devel@
<stratus> ogra, i think pere and/or vagrant are reviewing the bzr repo changes, after that the things will start to move faster. I believe that in the next month we will have the first pkg-ltsp release.
<ogra> fine
<stratus> lucas, funny because i pointed him to the proposal at utnubu-discuss
<lucas> yup, saw that :)
<ogra> in the next month most of my development will hit the ubuntu package
<stratus> ogra, following the roadmap the second step will be jump on your changes
<ogra> yup, should be half way stable and tested then, good timing ;)
<stratus> ogra, yes but i still believe that we will have even better results (as a group) for etch and dapper+1
<stratus> that's just the start up
<dholbach> Riddell: going to merge musicbrainz - to get python funkyness
<LaserJock> hmm, so what happens to the 115 packages on the tiber "Accepted" list ?
<hub> raphink: if you have time, can you review my pkg... I have a few of them without any comment
<raphink> not now hub
<raphink> I'm going to bed now
<hub> raphink: tomorrow is fine.
<raphink> ok :)
<hub> to bad at 10:30PM?
<hub> :-)
<hub> to bed I meant
<hub> :-/
<rbelem> hey raphink
<rbelem> raphink: i updated lives, can you review?
<raphink> rbelem: not right now i'm going to bed
<raphink> rbelem: send me the link to my email and I'll do it tomorrow ok?
<rbelem> raphink: ok ;-)
<raphink> hub: I go to sleep with my friend because it's nicer and she wakes up at 6
<raphink> so I review in the morning
<hub> hehe
<raphink> and there's nobody around here so i can work well ;)
<rbelem> raphink: good night
<hub> have fun :-)
<raphink> thanks
<raphink> hub: idem pour toi : tu peux m'envoyer l'url
<rbelem> hub: i updated libiec61883 too
<rbelem> hub: can you review?
<hub> rbelem: later
<hub> rbelem: at work atm
<rbelem> hub: can you review muse-streamer too?
<rbelem> ;-)
<rbelem> hub, raphink: thx ;-)
<hub> rbelem: np
<rbelem> have to go now
<rbelem> good night
<raphink> night guys
<thierry_> where can I find the date and holder of the copyright of a librairy, I can't find it for fxruby http://revu.tauware.de/revu1-incoming/libfxruby1.4-0601061255/libfxruby1.4-1.4.3/
<Kyral> is anyone working on Malone 6052?
<Ubugtu> Malone bug 6052: "Missing library dependencies" Fix req. for: dhcdbd (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: Confirmed http://launchpad.net/bugs/6052
<Kyral> Oh wait, this is Nafallo's package
<Kyral> oh well, I can still fix the bug no?
<LaserJock> hmm, new xorg took out vnc4server. bummer :(
<ajmitch> morning
<LaserJock> hi ajmitch
<Kyral> hey ajmitch
<LaserJock> anybody know of a good vnc server other than vnc4server?
<Kyral> Shoot I forgot how to close a bug lol
<LaserJock> Kyral: umm, change the status
<Kyral> yah, Attach the debdiff
<Kyral> but what do I change the status to?
<dholbach> I'll call it the day. Have a nice evening.
<LaserJock> cya dholbach
<dholbach> bye LaserJock
<Kyral> Should I change it to "In Progress"?
<Kyral> or "Fix Released"
<LaserJock> Kyral: so you added a patch?
<Kyral> yah
<Kyral> Attached it to the bug
<LaserJock> Kyral: well, unless the patch is uploaded it shouldn't be "Fix Released"
<LaserJock> Kyral: I would go with "In Progress" or "Fix Commited"
<Kyral> There should be a "Fix Attached" option...
<minghua> LaserJock: I just had time to read through the threads you initiated on debian-science
<LaserJock> minghua: lol, that was a little while ago
<Kyral> okay done
<minghua> LaserJock: yeah, that's why I tell you here
<Kyral> ping someone who can upload lol
<LaserJock> minghua: what did you think? I might be a little nieve when it comes to Debian
<minghua> LaserJock: I think I'll work on that with you soon
<LaserJock> minghua: but I'm learning
<Kyral> Malone 6052
<Ubugtu> Malone bug 6052: "Missing library dependencies" Fix req. for: dhcdbd (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: Fix Committed http://launchpad.net/bugs/6052
<Kyral> now someone just has to upload
<LaserJock> minghua: MOTUScience has some good info that I started
<LaserJock> minghua: I was going to do some sort of MOTUScience Update email to debian-science soon, after UVF
<Kyral> anyone even around?
<LaserJock> Kyral: I'm here ;-)
<Kyral> I meant who can upload the patch :P
<LaserJock> Kyral: you might also reassign it to MOTU Reviewers
<minghua> LaserJock: I think one big opportunity here is we can use MOTUScience to show how ubuntu-debian collaboration should work
<LaserJock> minghua: that was my thought
<minghua> LaserJock: and since it's an old thread, I don't think I'll reply to it, but I have a few comments about the "separation" concern about two lists you may want to hear
<minghua> LaserJock: so you can use as your defense later
<Kyral> you sure MOTUReviwers is the right reassign?
<LaserJock> minghua: right now, there are 10 packages in Ubuntu and not in Debian. 6 are from apt-get.org. 3 of the others have ITPs
<LaserJock> minghua: and of the 6 apt-get.org 1 is going into Debian and I got one fixed so that it works in Ubuntu
<Kyral> anyway I have to go to dinner
<minghua> LaserJock: 1. the MOTUScience people are more closely organized, we know each other on IRC, and can usually talk with others or upload fixed packages for others, this is not the case for Debian, so motu-science is probably going to be like sounder list a bit
<LaserJock> Kyral: MOTU Reviewers is for reviewing patches, etc. and I think it goes to the same address as the revu stuff so I think it would work
<minghua> LaserJock: 2. motu-science list also serves as the team role address on launchpad, and will receive bug reports in the future, I am sure debian-science doesn't want that
<minghua> LaserJock: So I believe as long as we keep communication back and forth, separating lists shouldn't be a problem
<LaserJock> minghua: that was my thinking
<ajmitch> dholbach: so what happens with the large number of syncs that didn't get through before UVF?
<dholbach> ajmitch: raise the issue on #ubuntu-devel
<LaserJock> minghua: btw, there are only 5 out of 452 packages that are in Ubuntu but not going to be in Debian
<minghua> LaserJock: yeah, I saw that the most clear voice in those threads is "try to get the packages only in ubuntu in debian", so I think that should be our priority
<minghua> LaserJock: however I have a fear that for the apt-get.org packages we MOTUScience people are not qualified maintainer
<LaserJock> minghua: right, and so I think Debian should be ok with leaving the apt-get.org ones out
<LaserJock> minghua: but I've done 2 ITPs, Kyral has done at least 1, and the texmaker guy also did 1
<minghua> LaserJock: yes, I think what we should do right now is identifying the package that has an active ubuntu maintainer and push it to debian
<minghua> LaserJock: like what Kyral and you have been doing
<minghua> LaserJock: I think I'll join soon
<azeem> LaserJock: talking of which, why does you packaeg only Recommends: gnuplot, is it useful without it?
<azeem> I have to admit I haven't tried it out yet, only glanced at it
<azeem> been pretty busy with Uni lately
<minghua> LaserJock: ITP and RFP are fine, we probably don't want to RFS for those apt-get.org stuff
<LaserJock> minghua: we've only ITP'd the ones we have packaged ourselves. I did get lucas to get a new ruby-gnuplot package into Debian
<LaserJock> azeem: you can use it withought gnuplot plot but it really is supposed to be used with it
<LaserJock> azeem: it was what the original packager put
<minghua> LaserJock: cool, a very good start, I would say.  Thank you for working on this front
<LaserJock> azeem: I can change it if you want
<azeem> LaserJock: ah
* minghua is just too busy with input methods these days and doesn't have much for MOTUScience, sorry
<azeem> well, whatever you think is reasonable
<LaserJock> minghua: that's ok
<ajmitch> hi azeem
<azeem> I just wondered, because from the description I thought it would be useless without
<azeem> heya Andrew!
<lucas> my package in debian Depends on gnuplot
<LaserJock> azeem: well, you can basically grep an output file with it if you don't have gnuplot, but that's about it
<LaserJock> lucas: we're talking about a package I'm having azeem sponsor.
<lucas> ah sorry
<LaserJock> lucas: np
<LaserJock> too many gnuplots running around ;-)
<lucas> thought it was about ruby-gnuplot
<lucas> yeah :)
<LaserJock> azeem: I'm going to switch it because it is just basically grep if you don't have gnuplot
<azeem> one could argue that any serious scientific workstation has gnuplot installed anyway
<azeem> but a Depends is better I think
<LaserJock> azeem: true ;-)
<LaserJock> minghua: have you seen the package lists that I made?
<hub> w00h00
<hub> key in keyring
<ajmitch> hub: great
<LaserJock> azeem: done, uploaded to same URLs. when do you think you'll have a chance to look at them?
<LaserJock> hmm, I'm starting to see "Malone as web only" as a pain, do you think we will eventually be able to do database type queries?
<ajmitch> eventually, one day
<ajmitch> via xml-rpc
<LaserJock> hmm, does eventually mean in the forseable future?
<LaserJock> or as in, "don't count on it"
<minghua> LaserJock: you mean the ones comparing the versions of packages in ubuntu and debian?
<Lathiat> its definately planned, i don't know on the timeframe its planne dfor
<ajmitch> LaserJock: in the future, not sure when
<ajmitch> morning Lathiat
<Lathiat> yo
<LaserJock> minghua: yes, I think they could be very useful
<Lathiat> i fly out tomorrow :)
<minghua> LaserJock: it's very useful for us, but I'm not sure if a debian maintainer can read it easily
<LaserJock> minghua: what do you think would be easier for DDs?
<LaserJock> minghua: maybe just a alphabetical list with versions and links?
<ajmitch> probably
<minghua> LaserJock: ideally, a list only showing the packages with differences, sorted by the name of maintainer, with only links to the ubuntu .dsc/.diff.gz and a debian bug
<minghua> LaserJock: it's a lot of work, for sure
<LaserJock> minghua: lucas's scripts are pretty good. I might be able to get something close.
<minghua> LaserJock: but I think that's the best bet if we want all DDs look at our list
<lucas> LaserJock: don't hesitate to build on them :)
<LaserJock> anyway, I think the lists I made are good for showing DDs that we aren't changing huge amounts of stuff here
<minghua> LaserJock: yeah, but we also need to identify our changes and submit debian bugs accordingly
<LaserJock> minghua: sure, but the first step is to figure out just how large and where the "problem" is
<minghua> LaserJock: well, some people in the debian-devel thread are also saying "even if the source package is the same, if you build with a different toolchain/dependency chain, it's still a different package", so you can never satify everybody.  But we try to do what we can do
<minghua> LaserJock: definitely.  that's why I said "it's very useful for us".  we can look at that list and figure out what we should do next
<LaserJock> minghua: well, I'm starting to understand that you will never please all of d-d and nor should we.
#ubuntu-motu 2006-01-25
<LaserJock> minghua: we do what we can and at least give as much info as we can
<LaserJock> minghua: most will understand, and the rest we can ignore ;-)
<minghua> LaserJock: yeah, don't even bother to think about that, just focus on what we are capable of.  my impression is that debian-science's response is generally quite positive, won't you think so?
<LaserJock> minghua: yeah, and actually debian-mentors has been good too. I had a talk with them yesterday
<minghua> LaserJock: yeah, that's my attitude for quite some time about debian work (mostly to Chinese users, but that's a different story)
<azeem> LaserJock: do you know why Li gave up on it?
<LaserJock> azeem: yes, I emailed him and asked him how it was going and he told me he had given up on Debian and I could have at it
<azeem> ugh, ok
<azeem> LaserJock: did he have a repo or something, possibly with other stuff as well?
<azeem> I wanted to get him more involved, but didn't get around really doing so
<LaserJock> azeem: I'm not sure. He had gausssum at debian-mentors
<azeem> ok
<LaserJock> azeem: well, I'm not sure if he gave up on Debian as a whole or just gausssum in Debian
<minghua> azeem, LaserJock: who is this Li you are talking about?  sounds like a chinese guy :-)
<LaserJock> LI Daobing
<minghua> Hmm, I know him :-)
<minghua> in the IRC/mailing list sense, of course
<minghua> so he gave up on debian?  that's news to me
<azeem> minghua: he did IRC?
<azeem> didn't know that
<minghua> azeem: very rare, I think.  and probably not on freenode
<LaserJock> minghua: sistpoty graciously let me have a tiber.tauware.de account so we have some space for MOTUScience stuff. If you think of more stuff please email motu-science or me
<minghua> we have a #debian-zh channel on freenode, and there are also IRC servers in China
<LaserJock> minghua: his exact quote was "How about you take this package? I have no faith for debian-mentors."
<LaserJock> so I guess it wasn't necessarily in Debian itself
<azeem> ah, ok
<minghua> LaserJock: will use motu-science.  and I see you are making good use of your account :-)
<azeem> so I shall mail him and ask whether he has some other stuff pending
<minghua> LaserJock: I see, so probably just "gave up on being a debian package maintainer, then"
<LaserJock> yeah
<minghua> azeem: I know one package he tried to get sponsored many times, but without success.  not related to science, though
<azeem> hrm
<LaserJock> My first Debian was a breeze (2 days), but I think that was because of REVU
<minghua> azeem: the most recent RFS being http://www.mail-archive.com/debian-mentors%40lists.debian.org/msg41575.html
<minghua> azeem: I think I saw at least 4 RFS on debian-mentors for this package without getting one, I can understand his disappointment
<azeem> yeah, but it is Debian now
<azeem> ah, he took it over
<ajmitch> that's because it's easy to let a sponsorship request slip by
<minghua> azeem: it is, but he is trying to get new upload in, and that is the part that sucks
<minghua> azeem: he basically shows that he is willing to continue maintaining the package and fix bugs, yet no one would sponsor him
<Kyral> hey MOTU
<azeem> minghua: I can see how this is hard without having a regular sponsor
<Kyral> anyone with upload right around who would upload a bugfix for me?
<crimsun> debdiff url?
<Kyral> Malone 6052
<Ubugtu> Malone bug 6052: "Missing library dependencies" Fix req. for: dhcdbd (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: Fix Committed http://launchpad.net/bugs/6052
<Kyral> I attached it
<minghua> azeem: exactly.  that's why MOTUScience people are lucky, they have the support of DDs in the MOTU :-)
<crimsun> Kyral: pbuilder's updating, I'll wget in a sec
<LaserJock> minghua: well, that's actuall something I've been thinking about as well
<LaserJock> minghua: so far MOTUScience only has one MOTU
* Kyral wishes there was a "Fix Attached" option in LP
<ajmitch> why?
<Kyral> Because I look at the Status options and I knwo that "Fix Released" doesn't work, so I have to choose betwenn "In Progress" and "Fix Confirmed"
<minghua> LaserJock: things are going to become better, I am sure :-)
<Kyral> and neither of those sound right lol
<minghua> LaserJock: will you apply for MOTU soon?
<ajmitch> ah, good to see those 25 zope syncs done
<LaserJock> minghua: I'm feeling the water ;-)
<Kyral> LJ Should become MOTU
<Kyral> At least before me lol
* minghua will apply for membership on 24th's CC meeting :-)
<minghua> let's see if that goes well
<ajmitch> LaserJock: it's probably worth it, depending on what others say
<Kyral> Actually...
<LaserJock> the thing is I feel I do more organizational work than technical work
* ajmitch wonders what he should apply for 
* Kyral wonders if he should raise an issue at the CC Meeting
<ajmitch> Kyral: what issue?
<LaserJock> ajmitch: AjmitchIsGod wiki page
<ajmitch> LaserJock: don't be stupid
<Kyral> I was thinking about making a spec to deal with low performance systems
<ajmitch> why would you need to take something to the CC?
* Kyral shrugs
<LaserJock> Kyral: lol, just so you can get GTKEdit into universe? ;p
<Kyral> LaserJock: no actyallu
<Kyral> I ran into this with my laptop
<crimsun> Kyral: built, uploaded.
<Kyral> GNOME is sluggish on it
<minghua> GTKEdit?  the notepad clone with gtk 1.x?
<LaserJock> Kyral: how about xubuntu?
<crimsun> Kyral: that's pretty much what Jani's doing with Xubuntu
<Kyral> crimsun: I mean like LOW performance machines
* ajmitch found gnome slow also, until the new laptop arrived ;)
<crimsun> Kyral: low being < 64 MB RAM?
<LaserJock> minghua: right, he packaged it. It's on REVU
<ajmitch> the p2-400 I was using at UDU was a bit of a clunker
<Kyral> crimsun: yah
<crimsun> Kyral: I hope you're thinking of directFB or something, because anything with that little RAM will have a beast of a time running X Window System.
<minghua> Kyral: do you have gtk 2.x at all?  what desktop/window manager do you use?
<minghua> honestly I don't see the advantage of gtkedit over leafpad, unless you still run GNOME 1.x
<ajmitch> looks like I need a new apt-proxy
<Kyral> minghua: my production box (this desktop) is a Athlon XP 2700+ at 2.3GHz w/512 MB RAM
<Kyral> yet I run Flux lol
<LaserJock> Kyral: at least do Openbox instead of Flux ;-)
<Kyral> but my laptop is a 3 year old thing that is 256 MB Ram and Celeron
<tseng> LaserJock++
<Kyral> eh?
<tseng> LaserJock: david.chalkskeletons.com/openbox.html
<Kyral> why Openbox?
<minghua> Kyral: have you tried leafpad?  I suppose loading gtk 2.x won't slow fluxbox significantly
<LaserJock> cause it's better
<Kyral> howso?
<LaserJock> tseng: oh, that's nice ;-)
<LaserJock> Kyral: cause
<tseng> Kyral: 100% less blackbox?
<Kyral> ??????
<tseng> openbox is all the way about freedesktop stuff
<LaserJock> Kyral: I used to run Flux a lot in my Gentoo days but Openbox was faster, and works with everything
* Kyral falls down
<tseng> fluxbox was closer to blackbox for a long time
<tseng> its gotten more modern
<Kyral> Nokiddin
<tseng> what im saying is, running fluxbox in gnome was pretty crappy
<LaserJock> it's easy to use Openbox in Gnome too
<tseng> among other non standardness
<Kyral> tseng: then don't run it with GNOME
<Kyral> I run it streight up
<LaserJock> Kyral: straight up it's better ;-)
<crimsun> it was good to sync rxvt-unicode (urxvt) v7.0 - released: 2006-01-13
<minghua> crimsun: did you get any words about the octave2.1 sync?
<Kyral> so GTK2 Themes work streight up with OpenBox?
<crimsun> minghua: no, among many many others I requested, but I understand he's swamped
<tseng> no
<minghua> crimsun: no problem.  I just want to make sure it's not some problem specific to octave2.1
<minghua> crimsun: I know many other MOTUs have pending syncs too
<ajmitch> elmo said to ask him about any pending syncs
<LaserJock> Kyral: just try it. I like openbox+pypanel. I use it for my vnc server
<ajmitch> since he believes he has caught up on them all
<tseng> pypanel takes forever to configure
<Kyral> Can I use my Dockapps with it?
<crimsun> ajmitch: ah
<LaserJock> Kyral: not sure
<Kyral> yanno
<Kyral> I would
<Kyral> but when I just quit from Fluxbox
<Kyral> X is dead
<LaserJock> how dead? just mostly dead?
<tseng> because it was the last thing in xinitrc
<tseng> after the last process in the list dies
<tseng> X is done
<Kyral> no
<Kyral> I mean not coming up period
<Kyral> no GDM
<LaserJock> did you dist-upgrade today?
<Kyral> yes
<LaserJock> so it could be the new Xorg
<crimsun> it's just the dangling symlink
<Kyral> okay
<crimsun> make /usr/bin/X11/X actually point to something valid, like oh /usr/bin/X11/Xorg
* Kyral nods
<LaserJock> ajmitch: I just say zope-* go by in dapper-changes :-)
<LaserJock> s/say/saw/ my typing sucks today. Oh, yeah. I'm using a new keyboard
<ajmitch> LaserJock: that's because I asked him an hour or so ago
<LaserJock> hmm, I wonder when he will get to my RT ticket :(
<ajmitch> what's the ticket about?
<LaserJock> svn access for the docteam, mdke has been bugging him quite a bit about it. I hope he doesn't get mad ;-)
<ajmitch> ah
<LaserJock> it's been over two weeks now I think
<azeem> LaserJock: the gaussum.1 manpage is not being installde
<azeem> eh, installed
<azeem> probably easiest to pass debian/gaussum.1 to dh_installmanpages or what's it called
<LaserJock> I call dh_installman, do I need to tell it explicitly which man page?
<azeem> yes, I think so
<azeem> either in debian/foo.manpages
<azeem> or by passing it as option to dh_installman
<LaserJock> doh, I see it now. just a sec
<Kyral> crimsun:
<Kyral> I had to symlink /usr/X11R6/bin/X to /usr/bin/Xorg
<ajmitch> or you could have just waited & dist-upgraded once fixed :)
<Kyral> nah
<Kyral> I use Dapper because when shit breaks it gives me an opportunity to learn by fixing :D
<LaserJock> I thought that was what Gentoo was for ;-)
<Kyral> No, Gentoo is learning how to entertain yourself while waiting for crap to compile :D
<LaserJock> or learning what a nice value is all about
<crimsun> Kyral: I sidestepped the entire issue, since I don't know what symlink is going to do what, by editing /etc/gdm/gdm.conf
<Kyral> lol
<LaserJock> ok, so what happens when the new Xorg stuff breaks other packages? I can't install vnc4server because it depends on xserver-common
<Kyral> and yah
<Kyral> Openbox.
<Kyral> Looks okay
<Kyral> but I like Flux for how easy the config files are to understand :P
<LaserJock> azeem: ok, fixed
<tseng> use obconf
<tseng> and be happy
<LaserJock> lol, +1
<Kyral> tseng: obconf no writes menus for me ;P
<LaserJock> Kyral: tseng just gave me a great URL: http://david.chalkskeletons.com/openbox.html
<LaserJock> http://obmenu.sourceforge.net/
<Kyral> fine fine
<LaserJock> Kyral: no pressure, but if you don't like Openbox your off MOTUScience ;-) *just kidding*
<Kyral> *STAB*
<Kyral> obmenu no work
<ajmitch> sigh
<ajmitch> 270 upgraded, 8 newly installed, 6 to remove and 1 not upgraded.
<ajmitch> Need to get 182MB of archives.
<ajmitch> and I'm restricted to ~64Kbps at the moment
* Kyral sighs and goes back to Flux
* ajmitch should upgrade the sarge box downstairs to breezy or something
<Kyral> crimsun: did you close the bug?
<crimsun> Kyral: for which?
<Kyral> the thing you uploaded for me..dh whatever
<crimsun> Kyral: no
<Kyral> Okay I'll close it
<crimsun> dhcdbd iirc
<Kyral> okay done
<crimsun> LaserJock: whew, I almost thought I was going mad there
<LaserJock> somebody's got to keep track of him ;-)
<azeem> LaserJock: I've uploaded it
<LaserJock> azeem: oh, thank you so much.
<Kyral> azeem: how does EasyChem progress?
<LaserJock> Kyral: http://ftp-master.debian.org/new.html
<ajmitch> the debian NEW queue has stalled a little lately
<Kyral> ah
<bmonty> anyone used gq lately (GTK LDAP browser)?
<ajmitch> nope, not lately
<LaserJock> hmm, is it OK to unplug a PS2 keyboard while your comp is still running?
<bmonty> I'm working on Malone #6629, and I wondering about enabling the SSL and SASL features
<Ubugtu> Malone bug 6629: "userPassword Support not available, because it is not build with libssl-dev" Fix req. for: gq (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: In Progress http://launchpad.net/bugs/6629
<minghua> LaserJock: if you don't want to use keyboard anymore, yes :-)
<bmonty> I have a package that depends on libssl-dev and libsasl2-dev and they seem to work correctly, but the debian maintainer has some info in the BTS saying there are bugs, but no details
<LaserJock> minghua: so will it fry it?
<LaserJock> minghua: I just want to use a different keyboard
<crimsun> LaserJock: it won't fry it, you'll just need to reset state, generally via a reboot
<bmonty> LaserJock: I don't think you would fry anything, but some motherboards won't bring up the keyboard without a reset when you reconnect it
<minghua> LaserJock: I've done it once or twice before, no harm done, except you need to ssh into it to reboot it
<LaserJock> darn
<LaserJock> ok, I'll stay with this one for a while then. darn cider :(
<ajmitch> bmonty: is gq under the GPL?
<bmonty> so with gq, I can verify that SASL works with my setup, so I'm wondering if we should enable the feature in the ubuntu package
<ajmitch> bmonty: would you try & link gq with openssl or with gnutls?
<ajmitch> gpl+openssl don't mix without a gpl exception
<bmonty> ajmitch: gq is GPL, and yes my local packge is linked with OpenSSL
<bmonty> your point is taken though
<ajmitch> well they mix
<ajmitch> but we can't distribute in that case :)
<bmonty> well the SASL part that I care about works :)
<bmonty> I'll have to try it with gnutls and see what happens
<LaserJock> brb, swaping keyboards, stupid memory leak is eating all my RAM
* bmonty is wondering how keyboards relate to memory leaks
<LaserJock> cause I can get rid of both with a reboot ;-)
<bmonty> ah :)
<LaserJock> ahh, better
<LaserJock> keyboard works and and I gained 300MB of RAM
<Kyral> eh?
<Kyral> WTF did you do?
<LaserJock> rebooted
<Kyral> ......
<LaserJock> cider spill from yesterday and some sort of memory leak
<Kyral> lol
<LaserJock> spacebar is a little stiff though :(
<Kyral> lol
<LaserJock> oh well, in a week or so I'll have a new iMac to use
<LaserJock> new keyboard
<Kyral> em
<LaserJock> only stupid 1-button mouse
<Kyral> ICK
<LaserJock> that'l go real quick
<Kyral> I cannot live without a 3 button + scroll wheel
<LaserJock> well, actually I'll have a MightyMouse so it has a scroll ball and side buttons
<Kyral> hub ty for voting on GTKEdit
<bmonty> ajmitch: if the copying file allows OpenSSL can we package it in ubuntu?
<hub> bmonty: why do they still use it?
<hub> :-/
<bmonty> hub: gq...its an old program
<hub> ah
<ajmitch> bmonty: if the source says it can, then debian/copyright needs clarified
<hub> if I had time I would port netatalk to libnss
<Kyral> guys, stupid question, but when did Multiverse go official?
<tseng> when?
<tseng> official?
<bmonty> source and the package COPYING say it is ok
<ajmitch> Kyral: at the beginning?
<crimsun> with Warty.
<Kyral> yah just makin' sure
<Kyral> someone thought that it wasn't lol
<azeem> I would've thought it was between warty and hoary
<ajmitch> azeem: I think it was in place at the start, but I didn't install warty on my systems
* ajmitch was still running sid
<azeem> indeed, it was
<Kyral> I've been thinking about doing a Debian install
<ajmitch> I wonder why there seems to be a long delay between incoming & packages hitting the pool in sid at the moment
<LaserJock> my other package has been in NEW for a week
<azeem> ajmitch: they hit the pool fine I guess, it's just the mirroring which takes agaes
<azeem> running apt-ftparchive rather, I heard
<ajmitch> right
<ajmitch> I frequently look on http.us.d.o & see my packages still aren't there
<ajmitch> same on ftp.d.o
<LaserJock> I don't use *.us.* for anything anymore :(
<azeem> ajmitch: maybe packages.qa.d.o/<package> has better information, is displays the version for unstable/testing
<ajmitch> sure, it says the package was ACCEPTED
<azeem> unless you want the .deb itself of course, d'oh
<ajmitch> yeah
* Kyral sighs to himself
<ajmitch> having the deb available is nice
<azeem> ajmitch: well, ACCEPTED is from -devel-changes, so that's when it hits incoming
<ajmitch> especially when the upload was done to make it installable again
<LaserJock> Kyral: what's wrong?
<azeem> ajmitch: tell your users to get from incoming
* Kyral shakes his head
<Kyral> Nah just got depressed for a sec
<azeem> "Three words for you: Fixed in incoming. Kthxbye"
<ajmitch> azeem: that's what I mean - it disappeared from incoming, and hasn't shown up yet
<Kyral> Oh well, one new changelog entry for me :D
<ajmitch> it's happened for the 8 or so packages I've uploaded lately :)
<ajmitch> there's a black hole somewhere in the process
* Kyral is just trying to figure out when to go for MOTUness
<ajmitch> when you're ready
<Kyral> yah tryin' to figure that out lol
<bmonty> ajmitch: is this a good description of the openssl license issue? http://www.gnome.org/~markmc/openssl-and-the-gpl.html
<Kyral> Right now I'm thinkin' sometime in Dapper + 1
<ajmitch> bmonty: yes
<ajmitch> bmonty: and debian takes the position that they can't use the 'distributed with a system' loophole because they are distributing that system
<Kyral> hmmm
<Kyral> how would the idea of a GUI for PBuilder sound?
<bmonty> ajmitch: is that documented in the policy manual (I looked real quick but didn't see it)
<bmonty> Kyral: for what purpose?
<ajmitch> no, I doubt it'd be part of policy
<ajmitch> possible though
<bmonty> ajmitch: ok, thanks
<bmonty> probably a discussion on debian-legal or something?
<Kyral> bmonty: for those Devs who are GUI oriented, and for ease of managing multiple pbuilders
<tseng> devs
<tseng> gui oriented
<tseng> ?
<Kyral> Yes they exist...
<bmonty> Kyral: I could see the multi-pbuilder case, but I think the pbuilder CLI is nicely done
* Kyral shrugs
<bmonty> very efficient
<Kyral> Just an idea
<LaserJock> I use pbuilder from within other scripts
<Kyral> I mean Apt-Get is all you need, but people still prefer Synaptic
<Kyral> ^some
<LaserJock> Kyral: I think some sort of multiple pbuilder manager would be nice
<bmonty> Kyral: I'm just interested in what a GUI for pbuilder would provide, not knocking the idea
<Kyral> well, like Cache management, Result management, PBuilder management, etc
<LaserJock> Kyral: it would be easier if you came up with use cases or something
* Kyral shrugs
<Kyral> I guess its for me more lol
<LaserJock> Kyral: well, I would be interested but I'm not sure what I would do with it
* Kyral shrugs
<Kyral> I have to learn PyGTK first ;P
<ajmitch> those use cases aren't ones that are done often
<bmonty> pygtk is fairly straightforward :)
<Kyral> yah,. but I don't even know much Python yet ;P
* Kyral shrugs
<bmonty> I have a gtktreeview working in python, and I was never able to get one to do what I wanted in C
<ajmitch> your choice as to whether it's a good use of time
<Kyral> People ether think in terms of the commandline or GUI
<ajmitch> and pbuilder is generally a commandline tool
<Kyral> yah, so was Apt, until Synaptic
<ajmitch> as nearly all package building is
<bmonty> Kyral: I think in terms of which is the most efficient interface
<ajmitch> they're different
<Kyral> bmonty: *shrug*
<ajmitch> you can't compare pbuilder & apt in that way
<Kyral> sorry
<LaserJock> Kyral: I understand what your trying to do but you need more motivation than "lets GUIify a CLI app". Just think about ways in which your GUI app could be more efficient than the CLI one
<Kyral> I personally think a CLI is always more efficient, but I knwo there are peopel out there who cannot stand the CLI
<minghua> Kyral: why would those people want to play with pbuilder, then?
<ajmitch> and those people are very unlikely to be building packages
<LaserJock> Kyral: not so much cannot stand CLI as find GUI to be more efficient for them
<bmonty> I don't think the CLI is always more efficient...f-spot is much better than "ls *.jpg"
<LaserJock> exactly
<Kyral> minghua: I have a friend who is a wizard with Webcoding, yet she loves the GUI. She prefers Synaptic over Apt
<LaserJock> Kyral: but that isn't necessarily the point. It's not all GUI or all CLI, it's what is most efficient and easy to use for the task
<minghua> Kyral: no problem with that, I've seen many of those people too.  The question still is: why the hell do they want to touch pbuilder?
<azeem> Kyral: good GUI design is hard
<azeem> even more so when doing it on top of a CLI app I guess
<ajmitch> why do you keep comparing synaptic & apt?
<Kyral> fine
<Kyral> GParted and Parted
<azeem> there is libparted
<ajmitch> and pbuilder is designed to give you a lot of text output that cannot easily be put into a GUI, without just throwing in a big textarea
* Kyral isghs
<Kyral> I knew it would be blasted apart
<LaserJock> although something like an IDE for packaging would be kinda cool
<minghua> and in my opinion, even if pbuilder is GUIfied, those people still can't use it efficiently, what about editing debian/control and debian/changelog?  what about checking dependencies?  what about make? :-P
<Kyral> actually LJ has a good idea....
<ajmitch> LaserJock: we call it emacs :)
<Kyral> lol
<LaserJock> lol
<LaserJock> I still haven't used emacs for packaging
<ajmitch> it has somem useful modes for editing changelogs & control files
<LaserJock> I'll have to look into it. I just find vim easier for editing
<bmonty> I call it vim
<Kyral> I dunno
<bmonty> death to all you emacs zealots! :)
<ajmitch> especially when it's used for actual debian packaging, when you can see the list of open bugs in the emacs menu, etc
<Kyral> Maybe I'll just write this thing for myself and if I think its very good...
<ajmitch> Kyral: sure, someone might use it
<ajmitch> Kyral: we're just making sure you consider wisely if it's a good use of time :)
<ajmitch> since we've got all these dapper bugs to fix
<Kyral> ajmitch: this will prolly be like a summer project or something in my idle time
<LaserJock> Kyral: you might also think of other packaging related apps that maybe are more appropriate for GUIfication
<Kyral> lintian?
<ajmitch> how would lintian work with a GUI?
<Kyral> Instead of just telling you to read Section foobar of the Policy Manual you could click on it and have <insert webbrowser here> open to the section ;P
<LaserJock> I was thinking more like a gui for looking at large amounts of apt-cache type stuff
<Kyral> or that
<LaserJock> like gimme a list of ubuntuX packages w
* ajmitch spots 2 sessions on debian & ubuntu at LCA next week
<LaserJock> you could interface with lucas's mdt or something
<Kyral> LCA?
<ajmitch> linux.conf.au
<LaserJock_away> dinner time, bbl
* ajmitch ought to go out & do stuff now anyway, bbl
<ajmitch> Lathiat: how'd you get hooked into doing talks about debian & ubuntu now?
<minghua> crimsun: thank you so much for the octave2.1 sync
<Lathiat> ajmitch: someone asked and i sillily volunteered? :)
<ajmitch> Lathiat: they looked at the list of active uploaders? ;)
<ajmitch> Lathiat: I'll have to sit in the front row & heckle away
<ajmitch> ah, it's in castle 2, a decent sized lecture theatre
<Lathiat> ajmitch: got a spare flame retardent suit? :)
<ajmitch> sure, I've got an ubuntu tshirt sitting around here :)
<Lathiat> hahaha
<Lathiat> i dont have one of those
* ajmitch has 2
<ajmitch> I'm sure you won't mind corrections from the audience ;)
<ajmitch> reminds me, I should wear my ubuntu tshirt to the debian miniconf
<ajmitch> ok, time for me to go
<ajmitch> if I don't see you beforehand, I'll talk to you on monday :)
<\sh> moins
<bmonty> hi \sh
<\sh> gnarf..12h ISP forced disconnect
<\sh> building wine 0.9.6
<bmonty> good luck :)
<\sh> I was just announced :) and I can't sleep anymore...same luck as with python-kde3...2 UVF exception reports in less then 2 days...fun
<bmonty> I understand the concept behind UVF, but it seems to be impractical in a lot of cases
<\sh> no...but regarding some packages it can be quite good to have new upstream versions for the new release. regarding python-kde3, it fixed a lot of issues we had with this package, and I can drop now some serious patches from our packages.
<\sh> the same applies for wine. since 0.9.4 wine is more stable then ever. So it's good to have it. But after FF, there is no way to do that anymore. Because we don't have much time to test anymore...
<\sh> and why the heck is libqt3-mt-dev not installable
<hub> hugin uploaded.
<hub> uploading autopano-sift
<bmonty> good night everyone
<Kyral> jeez Hub you are on a roll
<hub> Kyral: my packages where waiting for upload
<Kyral> lol
<hub> I'll purge the list top to bottom
<Kyral> one more vote for GTKEdit...
<hub> but upload is fscking slow.
<hub> I blame my modem
<hub> I need to find a new one. this one is crashing all the time
<\sh> hub: are you motu now?
<hub> \sh: yeah. and I have upload rights
<\sh> hub: congrats..since when? I think I missed your advocation somehow...sadly
<hub> tuesday
<hub> it was the CC
<hub> TB
<hub> i meant
<\sh> hub: cool :)
<hub> so how is life?
<\sh> hub: could be better...
<hub> btw, since we are in UVF, what is the point with new universe packages
<hub> can they go in?
<\sh> new universe packages, if they do not need new libs in main can go in until FF
<hub> okay
<hub> so UVF is only for main?
<\sh> no.
<\sh> see #ubuntu-devel just now :)
<Kyral> It means that no new Upstream versions
<Kyral> unless its like a major security thing
<Kyral> right?
<\sh> Kyral: if it's a major security thing, we have to decide if we backport the security fix, or introduce the new version..this depends what is a much better solution
<ajmitch> hey \sh
<\sh> good morning ajmitch :)
<hub> how to I make a signed .changes?
<hub> when I'm not the last in the changelog
<\sh> debuild -S [-sa]  -k<your gpg uid>
<hub> ah
<\sh> -sa if it will be a source upload
<\sh> ajmitch: preparing wine 0.9.6
<hub> debsign -k works
<\sh> hub: think about *_source.changes :)
<\sh> not the .changes file for the binaries :)
<hub> yeah
<hub> only the _source.changes
<hub> I don't even debuild there
<hub> I pbuild directly
<ajmitch> \sh: how many regressions this time? ;)
<\sh> there shouldn't be any, but I can be wrong...
<ajmitch> hub: right, why would you sign something that you haven't changed? :)
<\sh> problem is, I don't have much for testing wine :)
<hub> ajmitch: upload?
<hub> or I messed up something
<ajmitch> hub: your entry should be at the top of the changelog
<ajmitch> you should only need -k if your email address in the changelog isn't on your gpg keyring
<hub> ajmitch: upload stuff from REVU
<ajmitch> ah right
<ajmitch> that's fine then :)
<hub> so -k
<hub> thx
<hub> that all I wanted to hear :-)
* ajmitch assumed you were uploading your own stuff, or your own fixes
<hub> ajmitch: mine have been uploaded
<hub> the one advocated
<ajmitch> ok
<ajmitch> what packages?
<hub> ajmitch: hugin, autopano-sift
<ajmitch> great
<ajmitch> I noticed they have been packaged in debian recently
<ajmitch> at least autopano-sift is still in debian NEW
<crimsun> minghua: np :)
<hub> oh
<hub> ajmitch: 'cause these are "my" packages. I'll check debian. they have been waiting there for some time
<hub> ajmitch: where do I find the incoming of Debian?
<minghua> hub: are you talking about incoming or NEW?
<hub> minghua: NEW I mean
<ajmitch> incoming is incoming.debian.org
<minghua> hub: incoming is incoming.debian.org
<ajmitch> http://ftp-master.debian.org/new.html
<hub> thx
<minghua> ajmitch is faster than I :-)
<hub> that is my package they ported to Debian
<hub> cool
<ajmitch> ok :)
<ajmitch> minghua: I have it in my browser history, I check it every day or two at the moment ;)
<hub> I should file a RFP for hugin now :-)
<ajmitch> yeah
<ajmitch> or ITP if you want to maintain it yourself
<Burgundavia> ajmitch, does ubuntu have something similar to that new page?
<ajmitch> have you talked to the new autopano-sift debian maintainer?
<Burgundavia> ajmitch, why does a package languish in new?
<ajmitch> Burgundavia: no
<ajmitch> Burgundavia: because ftp-master has to check every package for licensing and various other criteria
<Burgundavia> ajmitch, oh joy
<ajmitch> it's essential
<Burgundavia> ajmitch, is this what elmo does for Ubuntu?
<ajmitch> yes
<ajmitch> packages that have undistributable files can't slip into debian
<minghua> according to what I heard here, ubuntu is fast enough so we don't need a NEW web interface :-)
<ajmitch> minghua: pretty much
<ajmitch> we also have far fewer NEW packages
<Burgundavia> what does infinity mean when he has to work on the buildds? Is that seperate?
<ajmitch> Burgundavia: quite separate
<ajmitch> this is about accepting new source packages (which can build new binary packages also) into the archive
<Burgundavia> ajmitch, what sort of work does he have to do? (sorry about all the questions, but never pigeon-holed someone and asked thses questions)
<ajmitch> after that the buildds take them
<whiprush> ftpmaster has to be one of the shittiest jobs in all of oss, talk about thankless.
<ajmitch> infinity has to manage the build chroots, sometimes manually kicking things to get things building
<Burgundavia> whiprush, I can see why elmo makes himself invisible in debian
<whiprush> heh
<ajmitch> eg a circular build-dependency has to be broken, or a broken package kills the chroot
<Burgundavia> ajmitch, sometimes the builds break the chroots and they need to be fixed?
<ajmitch> yep
<ajmitch> and that's irritating
<ajmitch> they don't clean the chroots after every build
<ajmitch> sometimes a broken binary enters the archive & kills other builds as well :)
<Burgundavia> ajmitch, is this worse in debian or ubuntu?
<ajmitch> hard to say
<ajmitch> I don't hear much of what goes on in that area
<Burgundavia> about the buildds, they are all controlled by canonical right?
<\sh> dude where is my life...just not one day of UVF, and I wrote my second exception report....THIS CAN'T BE TRUE
* Burgundavia pats \sh for the good work
<ajmitch> \sh: don't worry, I've got a stack to write up soon
<ajmitch> zope3 is uninstallable because its dependency is still in debian NEW
<ajmitch> so that new dependency will have to get into main
<\sh> "When reading any modern physics book the average person may be surprised to 
<\sh>  find that time is not constant in the universe."
<\sh> -- Guy Cramer (http://www.direct.ca/trinity/y3nf.html)
<ajmitch> (yes doko, I filed a bug :) )
<\sh> actually I found the truth about the universe :)
<ajmitch> hehe
<\sh> ajmitch: the cleaning of the chroot should be introduced when Soyuz lands, I think
<ajmitch> I'm not sure if they are or not
<ajmitch> kinnison would probably know
<psusi> is time not constant in the universe?  or is it meerly our perception of time that differs? ;)
<Burgundavia> ajmitch, how does debian deal with the issue of buildds under the control of random people/companies?
* psusi thinks he is emacs' psycotherapist
<ajmitch> Burgundavia: they aren't
<\sh> psusi: the fact is, the universe doesn't expand, it implodes :)
<ajmitch> Burgundavia: all buildds are under debian administration
<Burgundavia> ajmitch, ah, is there is a buildd team?
<ajmitch> yes
<psusi> \sh, naw... it expands under the influence of either dark energy, or electricity depending on your religion
<psusi> ;)
<Burgundavia> but they are not hosted centrally?
<ajmitch> there can be unofficial buildds, but every upload has to be signed by a debian developer
* psusi gets a hoot out of those electric universe guys
<ajmitch> nope, too many archs in debian to have a central buildd hosting
<\sh> psusi: hhe
<Burgundavia> ajmitch, ah
<psusi> I heard a great joke today...
<psusi> A guy walks into a bar and has a monkey... the bar tender says hey, you can't bring that in here
<psusi> the guy says relax man, he's tame... he won't cause trouble...
<psusi> bar tender says ok, fine
<psusi> so the monkey starts doing things like playing with the bar nuts, drinking other people's beer
<psusi> finally the monkey eats the pool queue, and the bar tender says that's it man, get that monkey out of here!
<ajmitch> Burgundavia: a more experience DD can probably correct mistakes of mine :)
<psusi> nobody sees the guy for 3 weeks, then he finally comes back, and tells the bar tender, relax man.. he learned his lesson last time, he's fine now
<ajmitch> hub: have you archived your uploads on revu?
<psusi> so a while later, the monkey sees some cherries on the bar and shoves one up his ass
<psusi> the bar tender asks the guy why the hell did your monkey shoave that cherry up his ass?
<hub> ajmitch: I did
<ajmitch> thanks
<psusi> the guy says "ever since he ate that queue ball, he measures everything first"
<hub> commented as uploaded and archived
<\sh> lol
<psusi> ;)
<\sh> argl
<Burgundavia> ajmitch, so in general, the debian and ubuntu upload/build dark-magic machines are similar?
<\sh> Your mail to 'Ubuntu-motu' with the subject
<\sh>   [UVF Exception Report]  wine 0.9.6
<\sh> Is being held until the list moderator can review it for approval.
<psusi> btw... now that I understand it... the zsync look inside algorithm rocks
<\sh> The reason it is being held:
<\sh>   Message body is too big: 73509 bytes with a limit of 40 KB
<Burgundavia> \sh, you prewriting the wine report?
<\sh> 70k is nothing
<psusi> what's it got attached that makes it that big?
<\sh> psusi: diffstat and ChangeLog diff
<psusi> hrm...
<crimsun> anyone running Dapper with a usb dvd device?
<\sh> Burgundavia: it's written and send to ubuntu-motu...but somehow the listserver is somehow to stupid..ok 1MB is much for a mail but 70k is just like 40k to me
<ajmitch> Burgundavia: currently they are quite similar
<psusi> yea... that is a rather low limit
<ajmitch> Burgundavia: when we switch to soyuz (like we were meant to > 6 months ago), they will be very different
<psusi> should be upped to 100k or so
<\sh> crimsun: I have to burn flight 3 tomorrow, then I have a usb dvd burner on this laptop running dapper
<Burgundavia> \sh, hmm
<ajmitch> \sh: who's admin of ubuntu-motu?
<\sh> ajmitch: dholbach i think
<ajmitch> \sh: that's the problem with sending diffs, many UVF requests are going to be big
<psusi> I burned flight 3 the other night... tried to modify it to include my udebified dmraid package... d-i bitches though and refuses to continue... I don't know what's wrong
<ajmitch> and every subscribed motu or otherwise will be spammed with them
<\sh> Burgundavia: for universe we decide as a team for UVF exceptions and dholbach collects them and send them to kamion/mdz for approval
<\sh> Burgundavia: for main packages I'm writing uvf reports directly to kamion/mdz
<Burgundavia> \sh, yep (I am subscribed for -motu for some crazy reason)
<\sh> well, to be honest, for wine I would deal with kamion or mdz directly, because we will have a lot of bug reports why we don't include at least the latest version of wine...but I think 0.9.6 will be the last exception
<\sh> for wine actually
<minghua> sync from debian with the same upstream version doesn't count as breaking UVF, right?
<\sh> but if 1.0.0 is still in time for dapper...I would like to include it somehow :)
<psusi> so anyone feel like reviewing my latest dmraid package on revu and see if the udeb version looks ok? just contains /sbin/dmraid and a postinst that runs it... as long as that is run before the installer looks for disks, should be fine
<\sh> minghua: no...new revisions of debian packages are not counting as UVF breakage
<psusi> huh?  UVF freeze = no more auto syncs from debian
<\sh> psusi: that's right...
<\sh> psusi: or elmo adjusted the auto-sync script
<psusi> so a new debian package version that is not from a new upstream release isn't allowed without an exception
<\sh> psusi: but more likely we have to check manually for new revisions of debian packages
<\sh> psusi: wine_0.9.5-2 would be ok, wine_0.9.6-1 only with exception report
<minghua> well, I don't mind requesting for sync, as long as I don't need to write report
<minghua> :-)
<\sh> minghua: if there is a rational and a risk analysis, you can write it to ubuntu-motu, as proposed by dholbach.
<Burgundavia> \sh, rationale, not rational. The latter is a state of being
<\sh> minghua: when we find a general agreement, that it's worth to include the new version of a software, then to stick with the old one, we have the right arguments for our release managers :)
* psusi hopes he can get dmraid-udeb included in dapper
<Burgundavia> \sh, the former is an argument for said existent
<Burgundavia> ce
<\sh> Burgundavia: thx :) will fix my spelling :)
<\sh> patch -p1 < \\sh_spelling_fix.patch
<\sh> hehe :)
<Burgundavia> \sh, one hopes you are the latter, as its opposite meaning is that you are insane
<psusi> no... the opposite of rational is irrational, which is not the same thing as insane
<Burgundavia> psusi, true
<\sh> Burgundavia: hmmm..I thought I am ;)
<minghua> \sh: thanks, I think I'll write exception report for one of my debian package soon
<Burgundavia> psusi, in common usage, irrational and insane are similar
<psusi> I think I used to be someone, now I just stare into the sun
<minghua> (after it's uploaded by my sponsor, that is)
<psusi> Burgundavia, there's a lot of stupididity in common usage ;)
<Burgundavia> psusi, yes, but is works for ESL people
<Burgundavia> s/is/it
<psusi> a lot of people also believe you get fat from genetics or other things outside your control, not from eating too much and excercizing too little... which is why there are so many fat people... heh
<Burgundavia> psusi, it is scary how much difference 50 km makes. That is how close I live to the US border and the people in the states are much much bigger
<psusi> Burgundavia, ahh, Canadian?
<Burgundavia> psusi, yep, west coast
<psusi> you see that movie "Supersize me"?
<psusi> scarry shit... even moreso because it's true
<Burgundavia> psusi, yep
<ajmitch> Burgundavia: ESL? doesn't that describe much of the US? :)
<Burgundavia> ajmitch, point taken
<psusi> it's been 10 years now since I swore to God I would never eat at McDonald's again if I survived that time.... and I don't even believe in God
<psusi> ESL?
<ajmitch> english as a second language
<ajmitch> (at least that's a common abbreviation)
<psusi> I did a lab in 8th grade on Mcdonald's food and count it to me 20% lard, 80% starch, 0 protien
<psusi> lol
<ajmitch> mmm, highly processed carbs
<psusi> s/count/found
<\sh> actually I like to eat burgers from burger king......
<psusi> that last time I ate there I swear it felt like it was coming out of me sideways... I doubt a spinal tap would have been more painfull
<psusi> I used to prefer them at least to McDonalds... but I haven't even eaten there in a year or two
<\sh> but I'm smoking, so I'm avoiding to increase my weight
<psusi> I quit smoking thanksgiving ;)
<ajmitch> \sh: I was eating that sort of thing last year
<psusi> went out the night before thanksgiving and got smashed and smoked too much
<ajmitch> as you could probably tell by seeing me at UBZ
<psusi> got walking pnemonia from it that hung on for 4 weeks
<psusi> not fun
<ajmitch> so far I've lost nearly 10kg this year
<psusi> decided that was it... no more smoking
<\sh> ajmitch: well...but you don't smoke...you can eat burger king or mcdonalds when you smoke ;)
<psusi> but... I've still got my 10 cases of special seaonal Tucher I got thanksgiving
<ajmitch> 3 hour walks up & down hills around here helps a lot ;)
<psusi> damn that is some fine ass beer
<ajmitch> mm
* ajmitch wonders if he should pester mjg59 with his laptop next week :)
<\sh> ajmitch: well, I don't drive a car, so I'm fortunate to use my legs for reaching point b from point a :)
* psusi just runs 2.5 miles 3 days a week at the gym
<ajmitch> yeah, I don't drive either
<ajmitch> psusi: that's not too bad
<psusi> trying to get places without a car doesn't work... don't have 3 hours to walk 8 miles
<ajmitch> dunedin is small enough that I can get to the main places in 10-15 minutes that I care about
* psusi is getting sick and tired of getting 13 miles to the gallon on gas though
<\sh> ok..it's 4:55 UTC...time to hit the bed again for a couple of hours...and then getting ready for some freelance job meeting
<psusi> "what if everything around you isn't quite what it seems? what if all the world you think you know is an elaborate dream"
<ajmitch> night \sh  :)
<psusi> "and if you look at your reflection, is that all you want to be?"
<psusi> "what if you could look right through the cracks?  would you find yourself, find yourself afriad to see?"
<\sh> g'night cu later today :)
<psusi> "what if all the world's inside of your head?  just creations of your own?"
<psusi> "your devils and your gods, all the living and the dead, and you really ought to know"
<psusi> "you can live in this illusion, you can choose to believe"
<psusi> "you keep looking but you can't find the words, are you hiding in the trees?"
<Burgundavia> ajmitch, how does one properly refer to the entire debian package management system? apt? dpkg?
<ajmitch> dunno :)
<Burgundavia> too much blood in yer head, from hangin upside down
<psusi> I just knew it as dselect several years ago when I ran debian... ;)
<Burgundavia> ok, this is just stupid --> http://developer.mozilla.org/devnews/index.php/2006/01/19/what-the-heck-is-with-this-1501-update/
* Burgundavia kicks mozilla
<minghua> dselect is the only user tool in Debian's package management system that I am afraid of :-)
* Burgundavia has never used dselect
<psusi> what's wron with that?
<psusi> ( both the firefox thing and dselect )
<minghua> I don't see anything wrong with the firefox thing either
<Burgundavia> they are inflicting a beta on people who didn't ask for it
<minghua> as for dselect, it's not wrong, it's just I had bad experience with it as a newbie, and hasn't used that since I discovered aptitude
<minghua> fear because of ignorance, perhaps :-)
* minghua sees that he has bad grammar :-(
<psusi> they DID ask for it... by installing the last beta
<Burgundavia> psusi, I disagree
<Burgundavia> psusi, they agreed to install the LAST beta, not this one
<psusi> you agreed to be a beta tester... you didn't say otherwise since then by auto upgrading to the stable release ;)
<Burgundavia> psusi, so because i installing breezy before it was stable my machine should magically start upgrading me through dapper? I don't think so
<psusi> possibly
<psusi> if you wanted stable, you would have waited for breezy to go stable ;)
<Burgundavia> note that debian also has this problem
<psusi> even if it doesn't upgrade beyond that, starting with an unstable prerlease, I expect problems
<raphink> hi zakame
<zakame> heya raphink :) what's up?
<raphink> not much :)
<raphink> reviewing, reviewing, reviewing :)
<raphink> hmm and reviewing too :)
<raphink> you?
<zakame> still feeling tired, I got back home yesterday from Manila, it was enjoyable but tiring
<raphink> oh nice :)
<raphink> where are you now?
<zakame> in Daet, about 9 hours away from Manila
<zakame> my second home ;)
<raphink> ok :)
<raphink> pfiew
<raphink> LiVEs package is having me write whole novels of comments ;)
<zakame> whoa
<raphink> ;)
<raphink> at least this guy will learn a lot about packaging with this package ;)
<zakame> w00t :)
<raphink> zakame: http://revu.tauware.de/details.py?upid=1561 when I say lots, I mean it ;)
* zakame looks
* zakame hugs raphink for being such a rocking REVU-er :)
* raphink hugs zakame back :)
<minghua> raphink: are you sure debian/control has 80 char/line limit?
<raphink> yep,the description field has
<raphink> not the dependencies though
<raphink> the dependencies adapt to the width of the screen
<raphink> but the long description doesn't
<minghua> ah, description field, that makes sense
<raphink> and the rule for _all_ files is that it can be seen on a 80-lines-wide console
<raphink> that theorically include changelog, too
<raphink> the logs should be readable in a 80-lines-wide console too
<raphink> which is pretty logical
<raphink> you don't want to have to guess half of the changelogs just because you logged in a tty, right?
<minghua> My vim debchangelog set the text width to 78 chars
<raphink> nice :)
<raphink> I do it manually
<zakame> there is a move to get the {,Build-}Depends{,-Indep} and similar fields to have that limit as well, for readability
<raphink> how do you mean zakame ?
<zakame> raphink: instead of having all those dependencies in one line, the proposal allows for putting dependencies in multiple lines
<raphink> ok
<raphink> can be nice
<zakame> yeah, but it's not getting any ground in debian-policy atm
<raphink> mhm
<raphink> hmm
<raphink> I uploaded a package about an hour ago and had no feedback yet :s
<raphink> hope it worked
<raphink> ogra__: are you there?
<zakame> raphink: question on copyright: if I debianize/ubuntize some free software that isn't GPL, can I release my changes under GPL, or should I follow with what upstream uses?
<raphink> hmm
<janm> zakame: what's the license upstream uses>
<raphink> it depends on the license I guess
<raphink> but if the license is not GPL-compatible, you won't get the package in universe anyway
<zakame> janm: libmemcache, for example, uses BSD
<raphink> BSD is a lesser license iirc
<zakame> raphink: true
<raphink> it allows almost everything
<raphink> including changing the licence of derived products IIRC
<raphink> check it though
<raphink> zakame: and let me know if you get the info, I'm interested in it ;)
<zakame> raphink: sure :)
<zakame> I'll ask in #d-devel :)
<raphink> ok :)
<raphink> #d-mentors could be a good idea, too
<minghua> zakame: you can release your change as GPL, but in my opinion it's polite to use the upstream's license
<minghua> as long as the upstream license is compatible with GPL, I don't see anything forbidding anyone to release his/her patch under GPL
<raphink> hi slomo
<slomo> hi raphink
<zakame> heya slomo :)
<zakame> indeed minghua :)
<raphink> hi dholbach
<dholbach> good morning
<raphink> dholbach: I uploaded a package this morning and got no news
<raphink> do you know how I can be sure it was uploaded
<raphink> ?
<ajmitch> raphink: using what email address in the changelog?
<raphink> hmm
<raphink> I didn't change the changelog
<raphink> but I ran debuild -S -k with my ID
<raphink> so that I signed the files myself
<raphink> and my key is up now
<ajmitch> ok, but the address in the changelog is what is used for katie to send mail to
<raphink> oooh ok
<raphink> :)
<ajmitch> and if it's not whitelisted, they won't get mail
<raphink> yep
<raphink> so it was only sent to tonio and he's not whitelisted
<raphink> so no matter what, I won't get katie's news about it ;)
<ajmitch> so it was sent to noone
<raphink> ok
<ajmitch> it'll still show on dapper-changes when accepted
<raphink> yes
<raphink> :)
<raphink> if accepted
<ajmitch> if it's new, it'll have to be elmo-blessed first
<raphink> yes
<raphink> :)
<raphink> this is my first update to universe, so I care about it :)
<raphink> + it's an upload of one of my mentors in a way ;)
<raphink> ajmitch: how did you tell me I had to do to be added to MOTU on LP again?
<raphink> :s
<ajmitch> you need to join the team
<raphink> I can't
<ajmitch> and an admin will see that & approve you for membership
<ajmitch> why not?
<raphink> MOTU is a restricted team. Only a team administrator can add new members.
<raphink> it's not a moderate team, it's a restricted one
<ajmitch> joy
<ajmitch> I'll try & add you
<raphink> thanks
<ajmitch> what's your lp username?
<raphink> raphink
<raphink> ;)
* ajmitch is still waiting for launchpad to load...
<raphink> hehe
<ajmitch> it is great pain
<raphink> oh it's pretty fast here
<raphink> or is it your ISP that is a pain?
* ajmitch is on severely throttled dsl until tuesday
<ajmitch> 10GB monthly quota
<raphink> :s
<raphink> ouch all kde apps fail to build in Dapper today
<raphink> there's an issue with kdelibs4-dev
<raphink> we need to fix that soon, that's making all buildd builds fail on kde apps, too :(
<ajmitch> bug Riddell or \sh_away :)
<raphink> yes
<raphink> that's what I'm doing
<Burgundavia> dholbach, do you need help with moderating -motu ?
<dholbach> Burgundavia: I shouldn't think so. The moderation mails are pretty low traffic, but thanks for the offer.
<Burgundavia> dholbach, if you need help, give me a shout
<dholbach> Ok, thanks.
<raphink> dholbach: oh I just sent a spam  to it, work for you ;)
<dholbach> raphink: Yeah, I was afraid I didn't have anything to do today.
<raphink> haha
<raphink> :)
<raphink> dholbach: are we supposed to keep documenting our work on the wiki when we are MOTUs ?
<raphink> I mean just as much as before?
* ajmitch never has
<ajmitch> you can if you want
<raphink> hehe ok
<raphink> well it takes a lot of time
<ajmitch> since it might be helpful if you apply for main upload rights some day in the future :)
<raphink> I've stopped documenting my reviews two days ago
<raphink> hmm ic
<raphink> but then I leave my track on the servers though
<raphink> and the contributions can be grepped from the db, no?
<ajmitch> yeah
<ajmitch> and we can have a record of any wiki changes, any uploads, bug reports & comments
<raphink> haha
<raphink> yes
<raphink> and then we need to document the changes in this record aswell
<raphink> :p
<Yagisan> raphink: your reply missed the mailing list
<raphink> Yagisan: my reply?
<Yagisan> raphink: to my suggestions for motu apprentices
<ajmitch> suggestions?
<raphink> oh I thought I had CCed it
<raphink> thanks Yagisan I will forward it
* ajmitch re-reads the motu list
<Yagisan> raphink: I'm subscribed so no need to CC me
<raphink> sure Yagisan just to the ML
<ajmitch> Yagisan: you want this run as formal irc sessions, or something on the wiki?
<raphink> oops it was sent as forwarded text of course
<raphink> was it sent this time Yagisan ?
<raphink> dunno if you got it yet
<Yagisan> ajmitch: probably as an irc session, with a writeup on the wiki when done, for those that miss the lesson
<Yagisan> ajmitch: raphink: as I said, just a few suggestions
<raphink> sure Yagisan
<ajmitch> sounds good, if we can find the time :)
<raphink> I think ajmitch's lecture was appreciated last time
<raphink> exactly
<raphink> if we can find the time in the master thing
<Yagisan> raphink: ajmitch: I personally have found time spent on training is always well spent
<raphink> apart from that it would surely be cool
<raphink> yes Yagisan
<ajmitch> Yagisan: yeah, we have to find the right balance between doing the work & trying to guide others to help out
<raphink> as said in my answer, I'd be find lecturing on rewiewing if someone wants of it ;)
<raphink> s/find/fine/
<Yagisan> raphink: still don't see your message yet
* raphink needs to take a pause
<raphink> Yagisan: ok
<raphink> Yagisan: the list if moderated
<raphink> hmm
<raphink> or is it moderated only for non members?
<raphink> :s
<ajmitch> there are times when 2 MOTUs advocating still isn't enough, really :)
<raphink> yes ajmitch
* ajmitch has seen some things sneak through that shouldn't have
<raphink> I pinged hub yesterday about his reviews
<ajmitch> it's something I should do more of
<raphink> and suggested him some readings :)
<ajmitch> I have a tendency to be overly picky about some things & miss others :)
<raphink> hehe
<ajmitch> such as?
<raphink> that's why it's great to require several MOTUs to advocate
<raphink> ajmitch: the ReviewingTips on the wiki + the reject FAQ on ftp-master and Mathew Palmer's checklist for sponsors
<raphink> ;)
<raphink> I think that's a good start :)
<raphink> lol
<ajmitch> it's a basic start
<ajmitch> but I've still found a number of things that aren't on checklists
<raphink> yes, and good documentation
<raphink> mhm
<ajmitch> things that other motus have approved :)
<raphink> I think lecturing and getting questions about this could help getting up questions onthe subject
<raphink> gathering them
<ajmitch> yeah
<raphink> finding typical examples for documentation on REVU
<raphink> and writing something rather complete and readable ;)
<raphink> hopefully
* ajmitch should probably sit down for some reviews in a week or two
<Yagisan> raphink: just got your message to the list
<raphink> ajmitch: I have been reviewing since two days ago, almost non-stop ;)
<ajmitch> raphink: good
<raphink> the list is getting smaller
<raphink> :)
<raphink> Yagisan: great :)
<ajmitch> I see no reason why we can't hold everyone to the standards that debian expects
<raphink> sure
<raphink> well Debian expects these standards but they are often not met in debian itself ;)
<raphink> which is not a reason good enough to not expect them ourselves
<raphink> all the more that REVU gives us a great way to get sure we follow these standards
<raphink> if reviewers get a good education in this field
<ajmitch> hm
<ajmitch> thunar should have been archived
<raphink> ok
<Yagisan> ajmitch: I don't understand you here - is that in regard to package quality ?
<ajmitch> Yagisan: yes
<dholbach> anyone who would like to fix multisync?
<dholbach> make it rebuild with newest evolution-data-server again?
<ajmitch> Yagisan: what other things would there be?
<ajmitch> dholbach: 0.8.x?
<dholbach> ajmitch: no, just the current
<Yagisan> ajmitch: quality I agree with - I was concerned it was more on the dfsg standards
<dholbach> so the rdepends of evolution-data-server are all installble again
<ajmitch> Yagisan: we should hold to those as well, where possible
<Mithrandir> dholbach: yay you (and seb). :-)
<ajmitch> dholbach: right, 0.82 is current :)
<ajmitch> hm
<ajmitch> why does hub have g-p-m on revu?
<raphink> because he's a MOTu
<raphink> since tuesday
<Yagisan> ajmitch: I like the where possible, as I believe I mentioned my concerns in my mail
<raphink> got a MOTU at the same time as lucas and I
<ajmitch> yes, but mvo has been handling g-p-m lately, I think
<dholbach> Didn't ogra and mjg59?
<dholbach> I think it was mvo just for libnotify stuff
<ajmitch> dholbach: possibly
<ajmitch> it's still universe, I see
<ajmitch> dholbach: what's the multisync problem?
<dholbach> a rebuild and it wasnt happy, when i removed automake-1.6 as a build-dep (we don't have it any more)
<dholbach> it's surely not a 'huge problem'
<dholbach> but I thought if you're all just sitting around... :-ppp
* ajmitch sees a few uploads to revu of new upstream versions of existing debian packages
<ajmitch> dholbach: of course, we all have *nothing* better to do
<ajmitch> I'm attempting to fetch the source
<ajmitch> this will be a painful experience
* dholbach hugs ajmitch :)
<raphink> dholbach: yeah I think there are quite a bit of FTBFS around dur to automake1.6
<raphink> we should list the packages that build-depends on it
<raphink> since it's a major cause of FTBFS lately
<Yagisan> ajmitch: you could mark in revu that a wishlist bug could be filed at debian for those
<ajmitch> Yagisan: I will
<raphink> s/dur/due/
<dholbach> Cool.
<ajmitch> I haven't seen the maintainer that I know of haunting these channels lately
<raphink> is there a rdepends tool for build-depends ?
<ajmitch> Kyral: sorry, archived spe
<ajmitch> raphink: easy enough to do with grep-dctrl :)
<raphink> let's see
* raphink reads man grep-dctrl
<ajmitch> grep-dctrl -FBuild-Depends $1 | grep 'Package:' |sed s/Package://g | xargs apt-cache showsrc | grep 'Package:' |sed s/Package://g | sort -u
<ajmitch> that's what I had in a script :)
<ajmitch> you probably don't need all that
<raphink> well no that seems fine
<raphink> :)
<raphink> I'll try it thanks ajmitch :)
<ajmitch> rebuilding this pbuilder base is taking an age
<raphink> :s
<ajmitch> argh
<ajmitch> can't believe I managed to fill up all my ubuntu development work area
<ajmitch> that's a 60GB LVM volume
<raphink> wow
<ajmitch> it has a few other things but most of it is ubuntu & debian work
<raphink> mhm
<raphink> calculating mine
<ajmitch> it has some debian chroots there
* ajmitch runs apt-get autoclean in them
<Yagisan> ajmitch: only 60GB ?
<raphink> oh, you count the chroots ;)
<raphink> heh
<ajmitch> Yagisan: I've got 55GB unallocated
<raphink> I've got a dapper pbuilder, a dapper chroot and a sid chroot
<raphink> that's about 20 GB already
<raphink> ;)
<ajmitch> raphink: yes, I've still got hoary, breezy, dapper, sid, & experimental
<raphink> so heh
<raphink> that's what takes place
<ajmitch> I do all of my ubuntu work outside chroots
<raphink> I don't count that as ubuntu && debian work really
<ajmitch> and my debian stuff is only bind-mounted into the chroots
<raphink> yes same here
<raphink> well I bind-mount my /home in the chroots
<ajmitch> so they don't take up a lot of space by themselves
<raphink> and my debian suff is in ~/debs
* ajmitch bind-mounts ~/debian
<raphink> ajmitch: ;)
<ajmitch> and I have ~/debian/ubuntu :)
<raphink> hmm
<raphink> so far I put an ubuntu/ and a debian/ folders in each package folder
<raphink> which is not very convenient
<Yagisan> please, lets not have pissing contests over who has the most chroots and distros stuff
<raphink> but I don't have packages in debian yet
<ajmitch> Yagisan: it's not
<raphink> Yagisan: :p
<raphink> we're not, Yagisan
* ajmitch has no real order to his layout at times
<raphink> just sharing our organization stuff :)
* Yagisan has hoary, breezy, dapper, sarge, sid both amd64 and i386
<raphink> oh nice :)
<dholbach> You all get a golden star.
<raphink> dholbach: lol
<ajmitch> yay!
<dholbach> Now go and fix stuff! :-p
<ajmitch> dholbach: you get a gold medal then
<dholbach> Yooohooo!
<raphink> :)
* Yagisan wins yay!
* raphink hugs dholbach 
<dholbach> *happy*
<ajmitch> ok, cleared up 3 GB, enough to fix multisync ;)
<dholbach> ROCK ON
<dholbach> That's the spirit :)
<raphink> lol
<raphink> :)
<ajmitch> some people have far too much energy
<raphink> hehe
<raphink> hey well we better
<Yagisan> who ???
<raphink> since they say the entropy in universe is growing fast
<dholbach> I'll have a dogwalk and then catch up with 243679246 bug mails and 2943769426 apt-get.org reviews.
* dholbach looks forward to it.
<raphink> and our task is to keep it in good order
<Yagisan> go dholbach go ! you can do it !
<dholbach> Sure. :-)
<raphink> apt-get.org reviews ?
<ajmitch> raphink: MASS CRACK IMPORT!
<dholbach> http://wiki.ubuntu.com/AptGetOrg
<raphink> great :)
<dholbach> ajmitch: don't be so mean.
<raphink> do you need volunteers ?
<ajmitch> sorry :)
<Yagisan> raphink: ajmitch: how we import my stuff ;)
<ajmitch> raphink: YES!
<ajmitch> Yagisan: it does get a *brief* review
<dholbach> Yagisan: I'd prefer MOTUs to get it through REVU
<raphink> i'll throw an eye on it
<raphink> :)
<raphink> that'll change me from reviewing for a while :)
<dholbach> AptGetOrg has two purposes.
<Yagisan> dholbach: sorry it was missing <humor> </humor> tags
<dholbach> 1) Stop users from messing with /etc/apt/sources.list
<dholbach> 2) Invite other developers into the MOTU world.
<dholbach> Yagisan: ah, right.
<ajmitch> Yagisan: don't worry, I sneak my packages in the other way, so no motu has to review them :)
<dholbach> I'd prefer it, if we could REVU cleaned up.
<raphink> dholbach: do I understand that apt-get.org was created for ubuntu?
<dholbach> If it's all fine, you can still assist me with apt-get.org
<dholbach> raphink: no, for Debian initially.
<ajmitch> raphink: nope, it's originally debian crack
<raphink> ok
<raphink> that's what I thought
<dholbach> But lots of users install random crack from there.
<raphink> used to use it on Debian
<raphink> yes
<dholbach> And it's better, if we rebuild it on our servers and people get it through us.
<raphink> dholbach: so cleaning REVU is #1 priority now?
<ajmitch> raphink: yes, we have until feature freeze for new packages
<dholbach> Apart from fixing bugs, yes.
<raphink> ok
<ajmitch> raphink: after that it's straight bug-fixing
<raphink> yep
<dholbach> So I'll have to review some 450 apt-get.org packages.
<ajmitch> so we use this chance where we can
* ajmitch even did a review tonight
<raphink> I think I'll focus on REVU then
<raphink> I'll deal with bugs when it's time for bugs
<dholbach> raphink: Thanks for that - I appreciate your efforts.
<ajmitch> dholbach: do you want me to focus every waking hour on reviewing & educating packagers? ;)
<dholbach> ajmitch: Whatever your like - but it sounds great to me.
<raphink> :)
* Yagisan adopts self-righteous tone <tongue-in-cheek of course> - I demand you change the Maintainer field of any of my packages you import from apt-get.org. I refuse to be associated with any packages that may be imported, and rebuilt with a different toolchain
<dholbach> If we have new people in here, we should always be quick to give them something we can upload for them after they did a few tweaks
<ajmitch> Yagisan: certainly ;)
<Yagisan> :-P
<dholbach> Yagisan: I mail those guys, so they can object.
<ajmitch> Yagisan: and I demand that my name be taken off my packages already in ubuntu :)
* ajmitch has managed to switch 2/3 of his packages to the debian.org address
<raphink> there are about 50 packages on REVU, each review takes from 10 to 40 minutes
<Yagisan> ajmitch: and removed from changelogs, in case someone somewhere decides to email me :-P
<ajmitch> I think I'll try & get pqm done & uploaded - shall I pass it via REVU, or via debian?
<ajmitch> raphink: if not more
<raphink> yes that's a minimum
<raphink> so the minimum manpower time we need is about 10 hours imo
<raphink> to review them only once
<ajmitch> raphink: I also like to login to tiber & get a build done so that I can get proper reports on REVU
<Yagisan> dholbach: so, is their script importing sarge repos now ?
<raphink> but most of them need to be reviewed 3 times or so
<ajmitch> I know
<raphink> ajmitch: can I log to tiber, too?
<ajmitch> raphink: not at the moment, I can probably arrange an account
<raphink> ok :)
<ajmitch> since I have root
<ajmitch> you just need to be in the pbuilder group to run revu-build
<ajmitch> eg:
<ajmitch> cd /var/revu/revu1-incoming/gnomecatalog-0601191630/gnomecatalog-0.2.3/
<ajmitch> well
<ajmitch> cd /var/revu/revu1-incoming/gnomecatalog-0601191630/
<ajmitch> revu-build gnomecatalog_0.2.3-ubuntu1.dsc
<ajmitch> that sort of thing
<ajmitch> raphink: I'll send you an email with username & password
<dholbach> Yagisan: their script? importing? sarge?
<ajmitch> raphink: since I don't know how to set it to your existing revu password :)
<raphink> ok
<raphink> sure
<Yagisan> dholbach: the apt-get.org import script - I believe it skipped mine, as mine has sarge in it
* Yagisan leaves for dinner - bbl
<dholbach> Yagisan: oh yes.
<dholbach> Yagisan: I have a blacklist
<ajmitch> siretart: ping
<siretart> ajmitch: pong
<siretart> :)
<dholbach> raphink: Doesn't hurt to upload KDE stuff.
<dholbach> raphink: They will be retried.
<raphink> oh?
<raphink> I thought you had to request another build
<raphink> with a build1
<raphink> or is it when a package has become FTBFS after being added ?
<raphink> like the automake1.6 ones
<dholbach> You ask the buildd admins to give back.
<dholbach> infinity and lamont
<raphink> dholbach: well then can I cancel an upload that hasn't been built yet?
<dholbach> "cancel"?
<raphink> I uploaded a 0.2beta1 version
<raphink> hopefully it failed to build
<raphink> should have been 0.1.99+0.2beta1 and I saw it after uploading only :s
<dholbach> If it's in the archive and was ACCEPTED you will have to upload a version which is 'bigger'
<ajmitch> once the source is in the archive, you cannot go back
<ajmitch> 0.2beta can become 0.2final or 0.2release
<ajmitch> or something similar
<dholbach> I once was fast enough that elmo intercepted and removed it.
<ajmitch> that must have been quick
<raphink> lol
<dholbach> But in general you have 4m30s minutes at best to scream and shout and elmo 30s to remove it.
<raphink> well then I think he rejected it
<raphink> I don't have Katie's output though
<raphink> since it's not my package
<dholbach> sudo apt-get update; apt-get source <package> will tell you what's in the archive. :-)
<ajmitch> is it a new package?
<raphink> yes
<raphink> dholbach: well if it hasn't been announced on dapper-changes it's not in the archive, right?
<dholbach> raphink: ask elmo.
<raphink> ok
<raphink> I will
<Yagisan> re
<Yagisan> wow, there is an ubuntu forum for one of my non-in-ubuntu packages
<Yagisan> :)
<rbelem> morning people
<Yagisan> rbelem: morning
<rbelem> hey Yagisan ;-)
<Yagisan> rbelem: don't you need x264 for your packages ?
<rbelem> Yagisan: yep, cinelerra mainly
<ajmitch> night all
<Yagisan> night ajmitch
<rbelem> gnight ajmitch
<raphink> night ajmitch
<rbelem> hey raphink
<raphink> hi rbelem
<Yagisan> rbelem: x264 won't go in unless we convert it to shared libs. Need to check why it isn't shared libs with upstream, and to see if marillat has already converted it
<rbelem> Yagisan: i didnt realized about that
<teprrr> hmm, pbuilderhowto points me to use distribution breezy.. shouldn't it be dapper now?
<teprrr> ah, yes.. :)
<Yagisan> rbelem: yes - slomo pointed it out to me a few days ago
<rbelem> Yagisan: another package that cinelerra and other package need is libraw1394
<rbelem> Yagisan: but its main area
<Yagisan> rbelem: ok - what is cinerella actually ?
<rbelem> Yagisan: cinelerra is a powerfull video editor
<rbelem> Yagisan: cvs.cinelerra.org
<rbelem> Yagisan: the most complete opensource video editor
<raphink> rbelem: there's more work to do on lives, I think you noticed ;)
<raphink> teprrr: no
<raphink> teprrr: build your pbuilder with breezy, then upgrade it
<raphink> teprrr: it's safer
<rbelem> raphink: yep
<raphink> rbelem: i'm giving you a lot of work, but this package will be nice in the end :)
<rbelem> thanks raphink for your review ;-)
<raphink> open-source : the only working environment where people thank you for voluntarily reviewing your work and giving you 2 more hours of it
<rbelem> raphink: i learning a lot with these fixes
<raphink> rbelem: I'm thinking of making a lecture on package reviewing and lives might be a great example of small yet important points to check
<rbelem> raphink: cool! where? is lecture something like a talk?
<raphink> ajmitch gave a lecture a month ago or (or was it two months ?) on #ubuntu-motu-school
<lucas> raphink: is there a wiki page that lists common points to check ?
<raphink> since there was UVF coming and we didn't have much we didn't plan another one
<raphink> lucas: there's ReviewingTips on the wiki
<raphink> but mostly there's Debian references
<raphink> http://ftp-master.debian.org/REJECT-FAQ.html is the most ones
<raphink> oops
<raphink> s/most ones/main one/
<raphink> then http://people.debian.org/~mpalmer/sponsorship_checklist.html is a good reference
<raphink> and finally reading revues on REVU helps a lot :)
<raphink> well and I'd say it's a good thing for a reviewer to read documentation on policy
<raphink> like debian/control writing documents and so on
<raphink> and refer to policy when in doubt
<Yagisan> raphink: please document this - seems useful ;)
<raphink> Yagisan: you can do it :)
<raphink> hehe
<raphink> like add it as a reference to ReviewingTips :)
<Yagisan> raphink: I *could* yes, but lack the time. I'll assist where possible, eg by checking your fabulous work
<raphink> lol
<raphink> and I don't lack time ;)
<raphink> doens't take that long to paste two urls on a wiki page really
<rbelem> raphink: pasted many urls in MOTUDocumentationDraft
<raphink> :)
<rbelem> it needs some love. maybe these days ill finish it
<raphink> good :)
<raphink> yeah :)
<raphink> hmmf
<pappan> hi everybody
<teprrr> raptoid, oops. build with dapper already :/
<teprrr> btw, do I have to take care of the dependencies of the dependencies?
<teprrr> kdelibs4-dev: Depends: libarts1-dev (>= 1.5-rc1) but it is not going to be installed
<rraphink> hmmpf ... not kicked out yet ... crossing fingers
<teprrr> :)
<teprrr> having problems? ;)
<raphink> it seems
<raphink> it's not funny
<raphink> I just log
<raphink> and then I get excess flood
<raphink> and it closes the connection
<teprrr> ouch
<teprrr> hmm, should I use cdbs at all for packages?
<crimsun> teprrr: you're not getting that under current dapper, are you? Both are installable on current i386.
<crimsun> teprrr: that's your decision for your own packages.
<teprrr> crimsun, seemed to work now.. don't know what was wrong in there.
<teprrr> added cdbs version requirement similar to katapult, hope it's okay
<raphink> hmmpf
<raphink> I can't join 10 channels it seems !!
<raphink> I get an excess flood
<crimsun> it depends on the channels
<crimsun> I'm in 19 on freenode
<teprrr> or maybe it's your client which causes it by handling things unproperly
<teprrr> hmm, how can I know if the dbuilder was successfully ended? should it display something?
<crimsun> you mean pbuilder?
<teprrr> yes
<crimsun> if it's successful, the files are generated in /var/cache/pbuilder/result/
<crimsun> you can also have pbuilder redirect output to a log file; see --logfile
<teprrr> yup, got the package :p
<crimsun> it's usually pretty straightforward. If pbuilder fails, you get a nasty error.
<teprrr> hmm, kboggle can use dictionaries for its words to check if they're right.. should I suggest or recommend ispell, aspell and hspell?
<crimsun> that's up to you
<crimsun> it would make sense to at least Suggest one or more as alternates
<teprrr> now they're in Recommended
<teprrr> Recommends: aspell, ispell, hspell
<teprrr> just thinking which is better, recommends or suggests for those
<crimsun> erm, is that the line verbatim?
<crimsun> does it really make sense to recommend all three?
<crimsun> for instance, aspell is an ispell replacement...
<teprrr> ah, didn't know how I should put them there :)
<crimsun> use alternates syntax: aspell | ispell | hspell
<crimsun> I haven't looked closely at their package statuses, so I don't know offhand if one or more provides a virtual
<teprrr> yup, changed. thanks.
<teprrr> dput kboggle_0.4.1-0ubuntu1_source.changes
<teprrr> so that's the right way to dput? :)
<Nafallo> not if you aren't a MOTU and are using the default dput settings.
<teprrr> Nafallo, I changed my dput.cf like REVU page said. default_host_main = revu and so on
<Nafallo> ah, never looked at that page myself :-)
<crimsun> it's always a good idea to specify the host explicitly
<teprrr> but that should be correct, right? :)
<zakame> heya all :D
<teprrr> hello
<zakame> what's up teprrr :)
<teprrr> trying to upload my first package to REVU :P
<Yagisan> G'day zakame, crimsun, Nafallo, teprrr and any lurkers not mentioned
<zakame> ooh, kewl! :D
<zakame> heya Yagisan , crimsun , Nafallo and the crew :D
<teprrr> same to you Yagisan
<teprrr> hmm
<teprrr> Checksum doesn't match for /home/tpr/storage/kubuntu-packages/kboggle/kboggle_0.4.1-0ubuntu1.dsc
<teprrr> okay, there we go now.. uploaded :)
<Nafallo> hello to those who wants to be "hellod" :-)
* Yagisan uploads 2.6GB to his unofficial debian repo and waits for his connection to get hammered
<crimsun> hi Yagisan, zakame :)
<crimsun> & Nafallo
<Nafallo> :-)
<zakame> ZOMG
<Yagisan> zakame: english thanks :)
* Nafallo HATES this weather!
<zakame> haha
<Nafallo> -8 Celsius :-/
<zakame> Yagisan: I can only dream of doing that thru dial-up
<teprrr> -27C ..
<Yagisan> zakame: well - it's on my adsl line, and within the next few days approx 20 or so debian users are going to hit it and find they need to upgrade the lot
<teprrr> was -31C or so yesterday
<teprrr> it's getting hot in here :)
<Yagisan> teprrr: Moscow ??
<teprrr> Yagisan, rovaniemi, finland
<teprrr> I think it's colder in moscow
<Yagisan> Nafallo: I just received a uuencoded windows virus in my email - that's very funny
<Yagisan> teprrr: I'd be scared to do a piss in that weather, probably freeze before it hits the ground
<azeem> Yagisan: depends on how much alcohol you drank I guess ;)
<teprrr> hmm, in which order REVU shows the uploaded packages?
<teprrr> http://revu.tauware.de/details.py?upid=1568 -- though now it's there :)
<teprrr> hmm, what's this linda whine? shouldn't source have only po files, not mos..
<Yagisan> azeem: hmm, that idea may have merit. how soon after pissing does it freeze.
<Nafallo> Yagisan: hehe, atleast you didn't get infected ;-)
<Yagisan> Nafallo: it's hard to get infected - wine needs to get better at running viruses
<Nafallo> :-)
<siretart> launchpad.net dead?
<Mithrandir> siretart: admins already working on it
<siretart> Mithrandir: great. I wanted to close a bug just before it died
* Nafallo blames siretart for killing launchpad then ;-)
<Mithrandir> siretart: fixed now
<siretart> :) - thank the admin!
<zakame> heh, weird
<Yagisan> yep
<Kyral> Morning
<Yagisan> night all
<zakame> heya Kyral
<zakame> gn8 Yagisan
<Kyral> hmm
<Kyral> what is debian/dirs used for?
<azeem> dh_mkinstalldir will create those
<zakame> to create additional dirs not made by `make install'
<Kyral> okay...
<Kyral> then why did raphink mention that it wasn't needed in GTKEdit/
<azeem> what's in it?
<azeem>  /usr/bin and /usr/sbin?
<Kyral> no I killed sbin
<Kyral> I should add /usr/share
<azeem> nah
<Kyral> so kill dirs?
<azeem> those should be made by the upstream Makefile
<zakame> yep
<Kyral> dhinstall takes care of them?
<azeem> make install should
<Kyral> azeem this thing has no install rule ;P
<azeem> then ok
<Kyral> http://revu.tauware.de/revu1-incoming/gtkedit-0601171815/gtkedit-0.1/Makefile
<azeem> Kyral: you could automakeify it
<azeem> as an exercise
<Kyral> I'm installing the files through dh_install
<Kyral> azeem: Upstream is thinking about it'
<azeem> that's fine, then you should leave the dirs
<zakame> yeah, rebuild the autotools
<azeem> Kyral: or just try without, and see whether it FTBFS
<azeem> zakame: "it doesn't have a Makefile"
<Kyral> its okay without
<azeem> as in, nothing
<Kyral> It doesn't need Autotools lol
<Kyral> and since when do we put homepage entries in debian/control?
<azeem> many do it
<azeem> at the end of the long description
<Kyral> oh...
<Kyral> okay I'll modify and reupload it
<zakame> Kyral: I do that, for one
<Kyral> those are the only things that raphink had a problem
<zakame> raphink, master REVU-er :)
<xerxas> hi guys
<nlindblad> hi
<xerxas> slomo: do you plan to package banshee 0.10.4 ?
<xerxas> is there a place to do package request ?
<xerxas> within the launchpad ? or anywhere else ?
<persia> xerxas: https://wiki.ubuntu.com/UniverseCandidates
<xerxas> persia: thanks
<xerxas> persia: there's nothing within the launchpad ?
<lfittl> xerxas: we are working on that ;)
<xerxas> lfittl: cool
<marcin`> hello MOTU
<marcin`> I finally uploaded my first package to REVU and my gpg keys seems to be ok
<marcin`> but I got few questions and hope that someone here could help me
<marcin`> to remove mess in my gpg keys I just removed everything from my ~/.gnupg directory
<marcin`> and I generated new key as normal user
<marcin`> and this key was added automagically to my keyring in my user account
<marcin`> but not into super user keyring
<marcin`> so I had to import key as secret key on my root account
<marcin`> now I can build and sign my packages
<marcin`> unfortunately now dpkg-buildpackage keeps asking me for my passphrase to unlock key
<Hieronymus> marcin`: what package?
<marcin`> and I neet to input this twice every time I build package
<marcin`> s/neet/need
<Hieronymus> marcin`: you need to sign two things
<marcin`> and that's just annoying
<Hieronymus> change your config so that it remembers your password for x minutes
<marcin`> Hieronymus: could you tell me where can I set this?
<marcin`> another thing is that previously I also could build deb packages and never had to input passphrase
<marcin`> (to be honest I don't remember if these packages were signed)
<Hieronymus> marcin`: did you use -us -uc?
<marcin`> anyway - currently when I build package I have to input passphrase twice and then again in debsign...
<marcin`> Hieronymus: -us -uc with which command?
<Hieronymus> marcin`: it's somewhere in the configuration. I'll fetch my keys, brb
<marcin`> ok
<azeem> marcin`: dpkg-buildpackage, probably
<marcin`> right it's in dpkg-buildpackage manual
<marcin`> -us -uc Do not sign the source package or the .changes file, respectively.
<marcin`> hmm so, do I need to sign packages for REVU or not?
<azeem> you can sign them later on with debsign
<Hieronymus> marcin`: yes
<azeem> debsign <foo>.changes
<marcin`> hmmmm but it seems that pbuilder doesn't sign packages by default while dpkg-buildpackage signs
<azeem> then pbuilder probably calls dpkg-buildpackage with -us -uc
<marcin`> (I use dpkg-buildpackage to build packages for my current breezy and then pbuilder to generate dapper packages)
<Hieronymus> marcin`: I think you can set use-agent in ~/.gnupg/gpg.conf
<Hieronymus> See https://wiki.ubuntu.com/GnuPrivacyGuardHowto section Tips and Tricks
* Kyral goes over the Bounty List
<zakame> !seen sistpoty
<marcin`> Hieronymus: ok, thank you very much
<siretart> zakame: I've seen him yesterday
<Kyral> has anyone actually claimed a bounty here?
<marcin`> Hieronymus: hmm the only problem is that there is no gpg-agent package in breezy
<zakame> siretart: well I just saw ChangingTheOrigTarball
<zakame> I wanted to suggest a DBS-style repackaging of bzip2 tarballs
<zakame> (which one can do with cdbs' tarball.mk)
<Hieronymus> marcin`: gpa
<siretart> zakame: I don't think this is a common packaging practice and not the widely used, no?
<zakame> siretart: true... must be tiredness setting in :P
<zakame> anyhow, gn8 all :D
<slomo> xerxas: it's already packaged and in universe ;)
<siretart> hi slomo
<siretart> slomo: did siggi respond to you?
<Yagisan> dholbach: just browsing https://wiki.edubuntu.org/AptGetOrg and noticed something interesting
<dholbach> fire away
<Yagisan> dholbach: you a) actually did pick up my ubuntu repo, and b) more importantly for me it all FTBFS
<Yagisan> dholbach: the fact that all of it FTBFS concerns me
<dholbach> Nice :-)
<slomo> siretart: nope :(
<dholbach> Which one is it?
<Yagisan> dholbach: http://eyagi.bpa.nu/~jamie/ubuntucurrentmainrestricteduniversemultiverse
<Yagisan> dholbach: I know that built in breezy
<dholbach> Yagisan: I will have a look what goes wrong and tell you.
<Yagisan> dholbach: do you have the logs ? I'd like to fix whatever is broken
<siretart> slomo: perhaps I was too rude in my mail :(
<dholbach> Yagisan: no, the script doesn't keep them
<slomo> siretart: hm, imho not... let's wait, maybe he responds this weekend :)
<Yagisan> dholbach: and I think I have the distinction of being in the blacklist no files from deng-jdoom-addons are there
<dholbach> Yes.
<dholbach> mvo added it to the black list
<dholbach> Dunno what went wrong.
<dholbach> We had some builds which *never* ended.
<Yagisan> dholbach: why ? (it is a huge file though, and I have a slow connection)
<dholbach> Yeah, might be that this was the case.
<Yagisan> dholbach: almost 400MB .orig for it
<dholbach> Might have been a reason, yes.
<Yagisan> dholbach: thanks for double checking why they FTBFS.
<persia> Hieronymus: Just FYI, all the "Missing .desktop file" bugs use autogenerated .desktop files.  I'd welcome suggestions to the script at the bottom of https://wiki.ubuntu.com/UniversePackageWithoutDesktopFile
<Hieronymus> persia: oh, okay
<\sh> moins
<Se7h> hi
<\sh> the only way is up...freelancing for 2 weeks...I had a good day :)
<\sh> siretart: ping
<xerxas> hi
<xerxas> slomo, do you plan on packaging latest banshee ?
<tseng> xerxas: erm
<slomo> xerxas: it's already packaged and in debian and ubuntu
<Gloubiboulga> evening
<\sh> evening lamont__
<lamont__> \sh: morning
<\sh> lamont__: dunno if I should ask you or kinnison, but do you know, if the buildd chroots for the soyuz buildd engines are always clean? means, are they always be newly created?
<lamont__> \sh: technically, that's a Kinnison question, however: soyuz untar's a chroot, dist-upgrades it and then does the build
<lamont__> then nukes the chroot, and goes on to the next package
<\sh> nukes means, it will be thrown away, and the system is untaring a new chroot and so on?
<\sh> but I will ask kinnison :)
<lamont__> yes
<lamont__> that is, that's my understanding of the process
<lamont__> alias nuke="rm -rf"
<lamont__> "because once you have tac-nukes, everything begins to look like a small city"
<\sh> hehe :)
<\sh> ok..thx for the info so far :)
<\sh> looks like I have to learn java
<siretart> \sh: pong
<\sh> siretart: 5mins..will query u
<LaserJock> morning everybody!
<siretart> \sh: regarding your clean buildd chroots: sbuild (the one in the sbuild package, not from wanna-build) has some preliminary support for sbuild, which supports chroots on lvm snapshots. once sbuild supports that, then you can guarantee clean chroots :)
<azeem> siretart: you mean schroot somewhere in there, I assume
<azeem> s/support for sbuild/support for schroot/
<siretart> azeem: excatly, my bad
<siretart> schroot really rocks. I love it
<LaserJock> siretart: what's the difference between dchroot and schroot?
<siretart> LaserJock: I think azeem or rleigh can answer this question better than I could. schroot is a reimplementation of dchroot with security in mind. It adds cool features like a hook dir where script which bind-mounts /home and stuff
<LaserJock> siretart: ok, so is it usable and everything. I accidently found it on packages.u.c yesterday when I was looking for dchroot (s and d being so close together on the keyboard ;-) )
<azeem> I have to admit I never tried schroot
<siretart> LaserJock: I use schroot on my laptop. the lvm snapshot feature is really neat: I can satisfy build dependencies on a real clean chroot and can play as much as I want, without the need from pbuilder. Great stuff for playing and experimenting :)
<siretart> drawback: you need lvm
<LaserJock> hmm, I don't know a thing about lvm
<stratus> LaserJock, read the lvm howto.
<LaserJock> oh, that's cool
<stratus> LaserJock, there's a little overhead (of course) but it provides useful flexibility
<LaserJock> is it safe?
<stratus> LaserJock, i use it since 2002 (including some servers) without notice any bug on the code.
<stratus> LaserJock, i've some really weird stuff with both software raid and lvm, nothing new but no fs corruptions (2.4 kernels).
<stratus> LaserJock, i even resize xfs logical volumes online without problems. I've backups but they weren't necessary yet. :)
<LaserJock> stratus: hmm, but you need to start from scratch to create them?
<stratus> LaserJock, not if you've spare partitions and/or harddisks on a machine.
<LaserJock> stratus: interesting, maybe it's time rearranging ;-)
<LaserJock> *for some rearranging
<stratus> LaserJock, you don't need to put your root (/) on top of lvm. I usually use let / sit over software raid on servers and do the lvm thing over raid with key directories (it depends for each server family)
<stratus> LaserJock, my file server at home contains two harddisks one with 13gb and other with 120gb. I've the / over software raid (mirror) on the two disks and other array (stripe, not mirror) with lvm on top.
<LaserJock> hmm, I'm thinking of reinstalling my system soon, I think I will try LVM out then.
<stratus> LaserJock, cool.
<LaserJock> hmm, somehow I need to make a list of apps I need to install once I get Ubuntu back on
<xerxas> tseng,  ?
<azeem> LaserJock: dpkg --get-selections
<stratus> LaserJock, hacks on ubuntu-meta and do your own metapackage.
<LaserJock> azeem: oh, that helps. thanks
<LaserJock> stratus: I've been thinking about doing that
<azeem> LaserJock: and dpkg --set-selections, later on
<stratus> LaserJock, i did.
<jamessan> is there something like that with aptitude that will maintain your "autoinstall" flags?
<LaserJock> azeem: oh my gosh, you are my hero!
<dholbach> Have a nice evening and weekend.
<\sh> dholbach: you spamed the planet :)
<\sh> and treenaks too
<dholbach> Nafallo too
<\sh> no not treenaks, nafallo :)
<dholbach> and it wasn't me
<dholbach> It was Planet.
<\sh> dholbach: you see, planet is heavily broken...but no one believes me
<dholbach> I doubt that LiveJournal sent updates?
<dholbach> Oh well.
<dholbach> Anyway
<dholbach> See you guys.
<\sh> it's planet :) have a nice weekend :)
<jamessan> LJ change their URLs so planet thinks everything is new
<\sh> argls
<\sh> don't use LJ
<hub> gah, hugin rejected for license issues
<hub> VIGRA license
<hub> I'll have to study that more closely
<hub> jamessan: LJ suck
<hub> \sh: LJ is broken, not planet
<\sh> hub: planet is broken too
<hub> \sh: LJ decide to change the URL of the articles
<jamessan> hub: I'm not disputing that :)
<hub> \sh: <id> changed
<\sh> hub: well...a check of similarity could be done by planet...title and content check..if planet would use a real db backend
<hub> \sh: planet check the one he has seen
<lucas> hey all
<Treenaks> \sh: I upgraded my blog without spamming planet ;)
<\sh> Treenaks: mea culpa...I corrected myself :)
<Treenaks> \sh: np :)
* Treenaks gone
<\sh> so from next week on I have home office, I'll get 300 bucks per day after taxes and first of all limited to 2 weeks...after those 2 weeks it will be decided, if I can have a employee contract, or at least freelancer contract for 6 months first...this helps a lot somehow
<lucas> working for whom ?
<hub> that's cool
<stratus> lucas, are  yout at lp, right? maybe you're interestd in subscribe to ajmitch specification about MOTUs and Debian.
<stratus> s/interestd/interested/
<lucas> the not-updated one ?
<stratus> i dunno
<lucas> I am not aware of a recent spec by ajmitch on the topic
<lucas> so it must be the one written in october/november, we was never finished
<lucas> s/we/which/
<stratus> checking...
<stratus> lucas, you're right. the spec itself needs to be finished
<stratus> ajmitch, wake up.
<\sh> going to bed...
<ajmitch> morning
<ajmitch> stratus: I am awake
<stratus> ajmitch, morning. What's up with that old ubuntu x debian spec that you started ?
<ajmitch> stratus: it was intended as a discussion item at UBZ
<ajmitch> but didn't get onto the list of topics to talk about
<ajmitch> it could probably be updated & filled in with some info
<stratus> ajmitch, yes i think we should update the spec.
<ajmitch> since I think we've agreed on a number of things in MOTU meetings that haven't been written down properly
<stratus> sounds good, can you do that? i'm a newcomer so i haven't been in any MOTU meeting yet
<ajmitch> but I'm sure you've got some good ideas from the debian side :)
<Kyral> raphink
<stratus> ajmitch, yes i've.
<raphink> someone _really_ has to explain me
<Kyral> explain what?
<jpatrick> pardon?
<raphink> why since I got my cloak on here I can't join 10 channels without being thrown away for excess flood
<raphink> by the server
<raphink> this is horrible
<raphink> I'm getting crazy
<stratus> you should ask freenode staff
<Kyral> which server?
<raphink> I used to be on 20 channels all the time
<raphink> then I got my cloack today
<raphink> set it as suitable, with a second nick linked to my main one and all
<raphink> and now when I join with all my channels
<raphink> after 1 minute I get a "[error]  excess flood" message and get thrown out
<raphink> I spammed all my chans with this this afternoon
<raphink> got banned from #debian-devel because of this
<raphink> that gets me ... hmm ... nervous
<ajmitch> raphink: it was hugely irritating for those of us in there :)
<raphink> I guess so ajmitch I guess so
<raphink> but imagine how irritating it is to me
<ajmitch> it was temporary
<jamessan> ajmitch: yeah, but that's no reason to ban. /ignore raphink JOINS PARTS QUITS
<raphink> to not be able to log to IRC
<ajmitch> jamessan: then everyone has to do that just because of 1 user
<raphink> ajmitch: I'm still banned on #debian-devel
<raphink> and I still have this pb
<raphink> right now I'm only on #ubuntu-motu
<raphink> cause if I log on more channels I might be thrown out
<raphink> and then I get a 3 minutes lag
<ajmitch> what broken irc client?
<raphink> ajmitch: no
<raphink> it began to do that ever since I got my cloack today
<raphink> konversation works great
<raphink> at least it has always worked great
<raphink> wasn't updated lately
<ajmitch> time for a change :)
<jamessan> raphink: your irc client might not gracefully handle having your hostmask changed on it
<raphink> and I see no reason why it wouldn't work great
<raphink> apart from getting a new vhost
<raphink> hmm
* ajmitch suggests irssi for a good time
<jamessan> although I'd be surprised if that was the case
<raphink> I already had a vhost
<raphink> that I had set myself
<aa_> well, none of my business, but really join and part are part of the IRC protocol
<raphink> aa_: so?
<Kyral> Malone 29053
<Ubugtu> Malone bug 29053: "beagle binary is uninstallable" Fix req. for: beagle (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: Confirmed http://launchpad.net/bugs/29053
<ajmitch> Kyral: and?
<aa_> so whoever is whining (yes I know he is the big boss) should suck it in
<ajmitch> aa_: huh?
<jamessan> aa_: PRIVMSG is part of the protocol too and people get banned for using that all the time
<Kyral> just making sure it took ;P Had to link it to a Debian bug
<tseng> Kyral: sorry to hear that, im accepting patches for FTBFS
<Kyral> huh?
<tseng> why is it linked to a debian bug
<aa_> jamessan: but that is a politeness issue. And I disagree with that too.
<Kyral> because the Debian bug is the exact same thing
<ajmitch> aa_: when someone joins & parts several times a minute, it is very irritating
<Kyral> 348123
<aa_> ajmitch: you should ignore it, really.
* Kyral sighs
<raphink> ok were shall I reach freenode staff ?
<Kyral> Debian #348123
<Ubugtu> Error: Could not parse data returned by Debian bugtracker: need more than 1 value to unpack
<aa_> anyway, how did I get involved in this? Have a nice evening all.
<ajmitch> aa_: and you expect 400 people in a channel to ignore it, just because of 1 user?
<tseng> Kyral: gmime actually breaks the build
<Kyral> oh
<aa_> ajmitch: oh yikes, no, not 400 people. I only heard one person whining. :) Anyway, I am wrng, blah blah blah.
<tseng> cvs builds because thye moved off of gmime
<Kyral> sorry...I should have checked
* aa_ hides
* Kyral is just trying do some triage
<Kyral> hmm
<Kyral> if they already give the Debian BTS number in the Report should i just link it there?
* Kyral shrugs and goes back to confirming or unconfirming bugs
<Kyral> wb
<Hieronymus> Why is there a pre-release of make in dapper?
<Kyral> Because Dapper is Devel?
<Kyral> I dunno actually
<raphink> hmm
<raphink> not thrown yet
<raphink> let's wait a see
<Kyral> lol
<crimsun> Hieronymus: synced from Sid
<thierry_> does anyone have time to review my package? I just reuploaded to fix some stuff http://revu.tauware.de/details.py?upid=1571
<thierry_> siretart : does you have the time to check my package?
<thierry_> do*
<phanatic> hi people
<thierry_> hi
<Hieronymus> Can I remove requires in upstreams Makefile?
<JohnnyMast> Hieronymus you need to patch them
<thierry_> JohnnyMast : can you review my package?
<JohnnyMast> you can do what you want besides changing the source .. but if you need to patch stuff
<JohnnyMast> thierry_ whats that ?
<thierry_> http://revu.tauware.de/details.py?upid=1571
<thierry_> just reuploaded and I want to know if it seems ok
<JohnnyMast> ok but i cant advocate i cant just look at it
<JohnnyMast> im impressed thierry_
<Hieronymus> JohnnyMast: offcourse
<JohnnyMast> but files installed into /usr/bin /usr/sbin need man pages
<Hieronymus> thierry_: why do you have "Initial packaging from scratch"?
<JohnnyMast> it would be a good thing to add them via docbook thierry_ from there it should be find
<JohnnyMast> Hieronymus that doesnt mether
<JohnnyMast> its just 2 word extra
<JohnnyMast> from scratch that is
<thierry_> JohnnyMast : how to I add them via docbook? any howto to propose me?
<JohnnyMast> check out ttb on revu (my old package)
<JohnnyMast> hold on
<JohnnyMast> example of a dockbook man page http://revu.tauware.de/revu1-incoming/ttb-0512220710/ttb-0.9.4/debian/ttb.1.docbook
<JohnnyMast> build/ttb::
<JohnnyMast> 	docbook2x-man debian/ttb.1.docbook
<JohnnyMast> ^^ in rules file
<JohnnyMast> and add dockbook2x to depends
<JohnnyMast> thats all
<JohnnyMast> and dont forget to check every build with pbuilder
<JohnnyMast> a double check doesnt do harm
<Hieronymus> thierry_: "from scratch" confuses me. Was this package in Ubuntu before? If so, you should save the Changelog
<JohnnyMast> yes thats true
<Hieronymus> if not, why not use what everbody uses - "Initial Release."
<JohnnyMast> Kyral hey m8
<JohnnyMast> long time noo see
<Kyral> hey
<Kyral> I'e been here
<JohnnyMast> same here
<thierry_> JohnnyMast : ajmitch used it in a presentation at motu-school, I tough this was ok
<JohnnyMast> but i was on vacaction :)
<JohnnyMast> thierry_ well he should mention that /usr/bin and /usr/sbin binarys need man pages
<JohnnyMast> but he was talking more about the packing then the strickt rules we have
<thierry_> k
<JohnnyMast> ubuntu is more strickt then debian on packages
<tseng> JohnnyMast: eh?
<Hieronymus> it's not
<JohnnyMast> Hieronymus explain why not ?
<JohnnyMast> i dont know what you have heared then ??
<thierry_>     </author>
<thierry_>     <copyright>
<thierry_>       <year>2005</year>
<thierry_>       <holder>Johnny Mast</holder> is it the librairy author or me?
<JohnnyMast> we follow the rules more strickt
<JohnnyMast> thierry_ depends on the agreement with upstream
<JohnnyMast> if they told you .. your maintainer meaning you fix the box we fix on ubuntu then your the holder/maintainer
<JohnnyMast> like im maintainer for ttb this means im alone are allowed to fix box for this packege in ubuntu
<crimsun> that's not true
<JohnnyMast> if the name + email is in there the developer can fix bugs or any hopefull
<crimsun> that means you're the primary contact, and you are assumed to have primary maintenance over it, but we maintain universe and multiverse packages as a team
<Hieronymus> JohnnyMast: I think Ubuntu is less strict on packages
<Hieronymus> thierry_: isn't it a library? Libraries don't need manpages AFAIK
<JohnnyMast> Hieronymus hmm nope
<crimsun> there is no sense of ownership over Ubuntu packages.
<JohnnyMast> crimsun yes well thats what i ment .. sorry thierry_ to confuse you there
<thierry_> JohnnyMast : so I do need a manpage right?
<JohnnyMast> yes you do
<thierry_> k
<JohnnyMast> ubuntu follows the rules of litnian
<JohnnyMast> ubuntu says 0 litnian errors / warnings are allowed
<Hieronymus> incorrect
<JohnnyMast> it should be clean
<Hieronymus> Ubuntu and Debian follow the Debian policy
<tseng> you are totally making stuff up
<Hieronymus> lintian checks for Debian policy errors
<Hieronymus> Warnings are allowed, errors are not, in both Debian and Ubuntu
<JohnnyMast> wicjh ubuntu follows
<JohnnyMast> nope
<JohnnyMast> you wont get votes with man page warnings im sory to report that but its true
<Hieronymus> JohnnyMast: not everything needs a manpage
<JohnnyMast> thierry_: it would be a good thing to read the debian new maintainer manual
<JohnnyMast> Hieronymus it should
<Hieronymus> JohnnyMast: no
<JohnnyMast> i dont want to release a package that  doestn follow the rules
<JohnnyMast> Hieronymus i hope you have read the debian new maintainer manual
<JohnnyMast> you should have
<Hieronymus> JohnnyMast: I have
<JohnnyMast> it has a list of does and donts
<JohnnyMast> then you know one could not be added without manuals
<JohnnyMast> in /usr/bin /usr/sbin
<Hieronymus> JohnnyMast: only programs and config files need manpages
<JohnnyMast> or anything above /usr ex /usr/local ...
<JohnnyMast> yep
<JohnnyMast> and that is just what we are talking about now aint we
<thierry_> JohnnyMast : ok, anything else wrong with my package?
<JohnnyMast> libfxruby looks like software to me
<thierry_> JohnnyMast : it's only bindings
<JohnnyMast> thierry_ no my compliments it looks okey even the copyright file wich is a common made mistake but it looks okey :)
<thierry_> :D great, now are you a MOTU?
<JohnnyMast> now im sorry
<JohnnyMast> but i can see if i see one on my contact list being online
<thierry_> JohnyMast, ok thanks anyway for the reviewing...
<allee> someone have sometime to have a look at codeine (KDE vidio player)? http://revu.tauware.de/details.py?upid=1544
<JohnnyMast> (just checking but i dont thing so)
<JohnnyMast> thierry_ nope contact me tomorrow i will be glad to forward ur package to some motu
<JohnnyMast> slomo are you here ?
<JohnnyMast> slomo thierry_ here made a great package its urs to vote
<JohnnyMast> thierry_ dont wurry i will get you some one tomorrow pm me and ule be fine
<JohnnyMast> but it seems that Hieronymus and tseng disagree somewhere so im gonna read somethings again
<thierry_> JohnnyMast : k thanks :)
<Hieronymus> JohnnyMast: Ubuntu is not more strict about packages; look at quake3 which had 2 advocates
<JohnnyMast> no problem
<JohnnyMast> Hieronymus its experiance
<JohnnyMast> btw debian sucks ass
<tseng> erm
<crimsun> let's not disparage our parent distro.
<tseng> crimsun++
<JohnnyMast> dont wurry i still use debian :)
<thierry_> JohnnyMast : do I have something to add in the copyright file for my man page?
<Hieronymus> JohnnyMast: it doesn't
<JohnnyMast> hmm nope
<Hieronymus> thierry_: you might want to indent the actual license information
<JohnnyMast> Hieronymus yes the discriminate
<Hieronymus> (with two spaces)
<JohnnyMast> that all the *** diff there iss
<JohnnyMast> Hieronymus dont tell me that aint true because it is
<phanatic> what's the best way to remove config.{sub,guess} stuff from a diff?
<JohnnyMast> because if im disabled but the best developer around  could never be a debian member
<thierry_> Hieronymus : like  http://revu.tauware.de/revu1-incoming/codeine-0601182140/codeine-1.0/debian/copyright ?
<JohnnyMast> sooooo there for they suck
<Hieronymus> thierry_: yes, that indentation
<JohnnyMast> i have to agree i like it
<JohnnyMast> Hieronymus debiaan has a thing with invalid ppl
<JohnnyMast> they could not get there key signed even if there name was bill gates
<JohnnyMast> i hate there new policy
<Hieronymus> why do you hate Debian?
<JohnnyMast> because of that yes
<tseng> what are "invalid people"
<tseng> i have had several debian developers sign my key
<JohnnyMast> not the os but the way they are thinking
<JohnnyMast> ivalid ppl == disabled ppl
<JohnnyMast> developers in a wheel chair
<JohnnyMast> god bless ubuntu for being open
<crimsun> well, differences of opinion aside, we owe a lot to Debian, and we strive to maintain a good working relationship with the maintainers
<tseng> sorry to hear that, but if you try you can understand why people dont sign keys if you cant have personal contact
<JohnnyMast> tseng look
<JohnnyMast> tseng trust dont come in a sign
<JohnnyMast> trust comes in what some one does
<JohnnyMast> thats lame for starters
<tseng> see thats the problem
<tseng> you cant trust what someone does if you cant trust who they are
<Hieronymus> JohnnyMast: ever heard of the Web of Trust?
<JohnnyMast> i trust some one on irc more then the fag who shows me me hers /his passport
<tseng> without a web of trust validated by something like GPG there is no saying that JohnnyMast doing good one day is the same JohnnyMast doing bad the next
<JohnnyMast> because for example Hieronymus here
<JohnnyMast> i know hes a hard worker
<JohnnyMast> i know what he does for ubuntu
<JohnnyMast> i know how hes like
<tseng> and when he leaves i can change my nick to Hieronymus
<JohnnyMast> you dont get that from a passport like debian claims
<JohnnyMast> no need because its registered
<tseng> by a really weak password passed in clear text
<JohnnyMast> plus i remember hosts
<allee> JohnnyMast: signing does not say he is great/bad.  Just says I confirm that he is how he claims to be.  Not less, not more
<JohnnyMast> its still bad
<JohnnyMast> signing is just going in blind
<allee> JohnnyMast: no.  That's what the web of trust is about
<JohnnyMast> and thats a fact !!
<JohnnyMast> my passpot doesnt say my nick
<LaserJock> you still have to have a signed key for uploading in Ubuntu
<JohnnyMast> look
<JohnnyMast> i signed the code
<JohnnyMast> i am my self
<LaserJock> but how do we know that?
<Hieronymus> LaserJock: Web of Trust
<Hieronymus> signing keys
<Hieronymus> but he doesn't want to :/
<JohnnyMast> by checking my public key
<JohnnyMast> the only thing you need is your email and your gpg key
<JohnnyMast> no fake debian rasist polecy
<LaserJock> but that only works if you know that that email and key belong to the right person
<JohnnyMast> ow and you know that by seeing the pasport ??
<tseng> there is more to it than that
<JohnnyMast> no you dont
<tseng> i see your passport, you gpg id, and your email
<Mithrandir> hi tseng
<tseng> i mail to that email your key
<tseng> hi Mithrandir :)
<JohnnyMast> neeh thats not how it should be
<JohnnyMast> that not being a communty
<JohnnyMast> thats checking trust
<tseng> neeh well stop calling debian ass and racist please
<JohnnyMast> a community is trusting
<LaserJock> well, for uploading you need trust
<tseng> I am going to have to ask this to close here.
<tseng> thanks :)
<JohnnyMast> tseng im sorry but thats just how i feel it .. i stop it from now on ...
<tseng> JohnnyMast: using inflamatory language to get your point across usually just invites opposition instead of symapathy for your cause
<tseng> JohnnyMast: (for better leverage in future debate :)
<JohnnyMast> but this is why i love ubuntu ppl
<tseng> Mithrandir: beagle is all kinds of broken :/
<JohnnyMast> trust is in what you do
<JohnnyMast> not in who you are
<JohnnyMast> or what you are
<Mithrandir> tseng: suckage.  why?
<tseng> Mithrandir: hm, gmime update
<tseng> cvs fixes the issue conveniently
<Mithrandir> tseng: it's been broken in dapper for a while 'cause of some other -cil package update.
<tseng> by dumping in a whole new bit of code xdg-sharp and changing all the calls
<tseng> er, xdgmime
<JohnnyMast> anyways
<JohnnyMast> im off to bed i got a few merges to do in the morning wich i should have done ages ago
<tseng> g'night
<JohnnyMast> for that im sorry but i just came back from vacation
<JohnnyMast> tseng gnight my friend :)
<Mithrandir> tseng: so you'll have a fix in RSN, then?
<tseng> Mithrandir: cvs also has Holmes, a whole new UI
<tseng> joe said he would release 0.1.5 off of 0.1.4, not cvs
<Mithrandir> we're in UVF, though
<tseng> which may or may not work
<tseng> 0.2.0 will have Holmes
<tseng> Mithrandir: every way is pretty ugly :)
<Mithrandir> tseng: 3 year support.  So, yes.
<tseng> hm beagle is not in main
<tseng> for dapper
<Mithrandir> true, but still
#ubuntu-motu 2006-01-26
<lamont__> anyone complain if I fix lablgtk by syncing lablgl?  (which would have synced 2 weeks ago if I hadn't uploaded it in december...
* lamont__ requests the sync
* Kyral wonders if he is like betraying Ubuntu by trying other Distros
<crimsun> of course not
<Kyral> cool
<Kyral> its only in a VM Image anyway
<LaserJock> Kyral: what are you going to try
<Kyral> EVERYTHIGN!
<Kyral> SuSE, Fedora, Debian, VLOS, the BSDs
<Kyral> HURD
<LaserJock> I see
<Kyral> Heheh
<Kyral> I want to know the strengths and weaknesses of every major distro
<LaserJock> you haven't done that before?
<Kyral> nope
<Kyral> I mean I know Gentoo and Slack
<Kyral> and of course Ubuntu
<phanatic> you have a lot of time, man :)
<LaserJock> I've never done Slack, but I did Red Hat, Fedora, Mandrake, SuSE, Gentoo, little bit of Debian, and Vector
<Kyral> its more like I have a lot of diskspace ;p
<ompaul> Kyral, how many distros do you think are major?
<Kyral> I started on Slack
<Kyral> ompaul: dunno
<Kyral> maybe the Top20 on DW?
<LaserJock> I'd go top 15 maybe
<ompaul> Kyral, supposing one you like is not there maybe DSL ( now I don't know what number that is)
<Kyral> DSL I know
<Kyral> hehe
<Kyral> When I saw GTKEdit for the first time, the first thing I thought was "Damn Small Linux!"
<ompaul> Kyral, knowing a good bit about the main packaging systems would be better for you imho
<Kyral> yah
<Kyral> RPM, Portage, Slackpack
<Kyral> I already know about Debpack :P
<LaserJock> I like Portage quite a bit
<Kyral> I used to be a Portage Junkie
<Kyral> I heard VLOS is good
<Kyral> Gentoo for people who don't wanna wait ;P
<LaserJock> Portage is why I'm using Ubuntu ;-)
<Kyral> lol
<Kyral> I heard its written in Python
<LaserJock> yeah, I think so
<Kyral> I also find it amusing that there is a gentoo package ;P
<LaserJock> the file manager?
<Kyral> yah
<Kyral> hmm
<Kyral> SuSE has a nice installer and a massive package selection on install, BUT its over 5 CDs...
<LaserJock> yah, DVDs help
<Kyral> yah..
<Kyral> but not everyone has a DVD Burner
<LaserJock> that is one thing I like about Ubuntu, 1 CD
<Kyral> yah
<LaserJock> but if you have .isos and use vmware-player...
<Kyral> I meant for normal people ;P
<lifeless> is anyone interested in packaging kiax
<lifeless> ?
<Kyral> linky?
<lifeless> kiaz.sf.net
<lifeless> erm
<lifeless> kiax.sf.net
<lifeless> linux softphone, talks IAX
<Kyral> I'll look in a sec
<Kyral> SuSE is installing in a VM, and my computer is a little slow...
<Kyral> right now ;P
<lifeless> and as we're bring up asterix very soon, having that would rock
<Kyral> ?
<lifeless> for canonical/ubuntu - we're doing an asterix conference server
<Kyral> oh
<Kyral> wazzat?
<lifeless> asterix - apt-cache should tell ya :)
<azeem> lifeless: it's asterisk
<lifeless> azeem: lol, right
<Burgundavia> lifeless, this going to be accessible to non-canonical employees?
<lifeless> Burgundavia: yes
<Burgundavia> can ekiga/gnomemeeting do IAX?
<lifeless> AFIAK no
<lifeless> we'll have sip as well
<lifeless> but IAX is nicer
<Burgundavia> yep
<tseng> opal has iax support
<tseng> but i have to disable to build atm
<Kyral> Okay
<Kyral> we need to beat SuSE's installer
<Kyral> and I think I know how to
<Burgundavia> Kyral, what does it do better?
<Kyral> Let them play Tetris or Space Invaders while the install is going :D
<tseng> Kyral: erm
<Burgundavia> Kyral, espresso will let people play or surf, etc.
<tseng> Kyral: UbuntuExpress, play any game you want
<Kyral> oh
<tseng> its a livecd installer
<Kyral> *sheepish look*
<Burgundavia> lifeless, ick kiax is qt/kde
<Kyral> yah and I gotta write the guide on it for the DocTeam :D
<Burgundavia> Kyral, the UI had better land soon. I understand that the dev sprint is likely to finish the major bits of it
<Kyral> I knwo I knwo lol
<Kyral> Prolly by Flight 4
<Kyral> I am interested in seeing what they come up with
<Kyral> like what it looks like
<shreddr> must go TODAY.  MESSAGE ME ONLY ON MSN AT MCSLTD2@HOTMAIL.COM, AIM AT OGD443 or YAHOO at MCSLTD2 IF INTERESTED! 1 alienware desktop computer price $550, one alienware area51-m 5700 notebook price $550.  prices include sameday shipping, case, wireless router.
* mode/#ubuntu-motu [+o tseng]  by ChanServ
* mode/#ubuntu-motu [+b *!*209.91.1*@*]  by tseng
<tseng> erg
<tseng> better.
* mode/#ubuntu-motu [-o tseng]  by tseng
<tseng> irssi is too smart for my own good
<minghua> well done tseng :-)
<tseng> wasnt me
<tseng> freenode ircop
<minghua> oh I see
<Kyral> I am beginning to like SuSE lol
<Kyral> enough to Dual Boot it
<ajmitch> afternoon
<SEJeff> Kyral, Are you serious? I have to fix the suse desktops of other admins at work with it's broken gnome implementation
<Kyral> lol
<Kyral> Its fun...
<Kyral> I mean the Server thing
<SEJeff> ACPI in SUSE is also crap compared to ubuntu
<Kyral> and Xen :D
<SEJeff> SLES and SUSE are different... SLES (What we run at work) is pretty sweet
<SEJeff> I agree with you about xen
<SEJeff> And Apparmor
<Kyral> Xen Xen Xen...
<sistpoty> hi folks
<ajmitch> hi sistpoty
<sistpoty> hi ajmitch
<ajmitch> typical, just after I do a bunch of zope merges/syncs, more are uploaded to debian ;)
<ajmitch> not new upstreams though, so I might ask for syncs
<sistpoty> hehe
* sistpoty is just to fix mythplugins ftbfs on non-i386
<poningru> r
<phlaegel> apparently mythtv .19 is coming out very soon (ie. about a week). any chance it'll get in to dapper?
<ajmitch> it would require a freeze exception
<ajmitch> got good reasons for it to go in?
<Yagisan> ajmitch: is mythtv still maintained ? IIRC it was mdz's but not anymore
<ajmitch> I don't know who cares for it now - I think some of the MOTUs do
<ajmitch> I don't have the hardware, otherwise I'd use it
<Yagisan> ajmitch: I have the hardware - but no tv reception, so I can't use it :(
<Yagisan> ajmitch: I miss Iron Chef on SBS
<Yagisan> ajmitch: much better quality then you can get from, well you know where
<ajmitch> I get poor tv reception here, and few chanels
<ajmitch> s/chanels/channels/
<sistpoty> Yagisan: iirc crimsun is working on mythtv
<Yagisan> thanks sistpoty
<Yagisan> ajmitch: All I want is Iron Chef for me, and Play School for Kate and Eric
<Yagisan> ajmitch: and I can't even get that :(
<phlaegel> ajmitch: I don't know the specifics, but I know they've done a lot of work on it... some new features, reworked livetv, etc... without it, I'd have to resort to building from source myself ;-)
<ajmitch> we hit upstream version freeze last week, so all exceptions need to have reasons :)
<phlaegel> I've only been using mythtv for the last couple of versions, but the releases seem to be pretty solid
<tseng> like
<tseng> beagle 0.2.0
<phlaegel> ajmitch: yeah, I know
<tseng> my reson?
<tseng> it builds
<ajmitch> f-spot 0.1.8 (when it's there) - because it fixes a few of the debian bugs
<stratus> ajmitch, cool that you wrote f-spot
<tseng> he did?
<tseng> that is cool
<stratus> ajmitch, they implemented flickrnet or not yet?
<stratus> tseng, lol he wrote the word f-spot and not the software
<tseng> well then
<ajmitch> stratus: not that I know of
<tseng> f-spot f-spot f-spot
<tseng> go me
<ajmitch> stratus: might be worth integrating
<ajmitch> stratus: why is saying f-spot cool?
<stratus> because it reminded me about the flickrnet thing.
<stratus> ajmitch, i see someone rewriting the flickr support since it's ugly and only support old accounts
<ajmitch> stratus: yes, it doesn't work with my flickr account
<ajmitch> I had looked at it very briefly
<ajmitch> but someone else was working on it I think
<stratus> ajmitch, i've a new account too.
<stratus> ajmitch, i see
<stratus> btw, i'm working on a new (unrelated) toy right now, it's under tests
<stratus> i call that piupartme.
<stratus> piupartme goal is pass each universe package through piuparts
<ajmitch> ok
<ajmitch> that can be done in a few lines of shell, I've already got such a script
<stratus> ajmitch, but you wrote a heavily hardcoded script, no?
<ajmitch> sure, it's just something to run on my box at the moment
<stratus> oh, i see
<stratus> ajmitch, piupartme has 54 lines of python code atm
<stratus> ajmitch, with it you can do the same against ubuntu main, debian sid, whatever.
<ajmitch> ok
<ajmitch> where will you publish it?
* ajmitch needs to dist-upgrade, but doesn't have the bandwidth
* psusi steps on bug buddy
<stratus> ajmitch, i'm testing it on my laptop right now (but i won't run against the entire universe)...
<ajmitch> my laptop is now my fastest box now, it seems
<stratus> ajmitch, after the tests i'll change the needed bits to run it inside debian but against ubuntu universe.
<stratus> ajmitch, i've some servers (p4 3g ht, 2gb ram) running debian but nothing so good running ubuntu.
<ajmitch> stratus: I notice that it can give very detailed reports, including about other packages that are dependencies of the ones you are testing
<ajmitch> nearly all of my packages had some cruft left behind due to deps
<stratus> ajmitch, sure i plan to do the update things too, but i'll need more cpu power
<sistpoty> btw ajmitch: do you have anything for unmet deps yet?
<ajmitch> sistpoty: no
<stratus> packages with unmet deps where? universe?
<ajmitch> sistpoty: I've hardly started working on it, I had a brief post-UVF break
<ajmitch> stratus: yes
<sistpoty> stratus: sure, usually lots of them
<ajmitch> stratus: looking at using britney to get a report
<sistpoty> ajmitch: I guess I'll do a branch of the merge list-tool to have a similar list. I only need some input which packages are affected yet :)
<sistpoty> (maybe I'll start with siretarts list)
<ajmitch> sistpoty: ok, I planned something a bit more than a simple list
<sistpoty> ajmitch: what do you have in mind?
<ajmitch> sistpoty: since it ends up being a set of interconnected packages
<ajmitch> so you identify which one really needs fixed to give the most benefit
<ajmitch> ie, dependants & dependencies
<ajmitch> hm, bzr diff is taking a lot of cpu
<sistpoty> hm... but for workflow this basically means a list with packages to work on?
<ajmitch> sistpoty: yes
<sistpoty> ajmitch: good... then this should be pretty trivial to branch from the merge-list. what packages are listed depends on the input then ;)
<ajmitch> hm
<ajmitch> I wonder why my dapper base tarball is so very very large
<ajmitch> 1.7GB is just excessive
<minghua> package cache?
<ajmitch> yeah
<ajmitch> the base tarball has /var/cache/apt/archives
<ajmitch> it shouldn't have all those
<ajmitch> most dating back to august or so
<ajmitch> ah that's better, 63MB, not 1.7GB
<ajmitch> pbuilder login --save-after-login is not safe when it hardlinks in all the apt cache
<minghua> yeah, I was bitten by that once as well
<minghua> I think it only happen if you use the APTCACHE out of chroot
<minghua> it either hardlink it, or bindmount it, I don't remember
<ajmitch> yeah
<ajmitch> both are far faster than copying it in
* psusi can't believe he has been waiting 7 years now for the linux kernel to support O_DIRECT on sockets, and it still doesn't
<sistpoty> what does O_DIRECT do?
<psusi> sistpoty, tells the kernel not to buffer the data... just directly transfer to/from the hardware
<psusi> saves memory and cpu time since two copies of the data are't made... it's very nice
<sistpoty> but how could this been done for sockets?
<psusi> same way it's done for anything else... don't copy to kernel buffers.. instead have the hardware directly dma to/from the user buffers
<sistpoty> dunno about the internals, but don't you need to put some network protocol in there for sockets?
<psusi> you mean slap on some packet headers?  yea
<sistpoty> exactly... at least for nic's which don't do this in hw... but I have no clue how networking inside the kernel works, though ;)
<psusi> the nic has to support scatter/gather dma so the kenrel can program it to grab the packet headers from kernel space, and the body from the user buffers
<psusi> I wrote an ftp server on NT back in 1998/99 using this technique.... it was able to push 11,820 KB/s over a single connection on a fast ethernet network...
<psusi> plugged in a second nic and saturated them both... with less than 1% of the cpu on a PII-233
<ajmitch> sistpoty: great, you got mythplugins uploaded :)
<sistpoty> ajmitch: yes, I really ruined mdz's packaging now *G*
<sistpoty> (it's a bit horrible now, but I hope it works)
<ajmitch> heh
<sistpoty> eeks... I really should have run lintian... setting compat to 5 and forgetting to adjust debhelper b-d :(
<ajmitch> oops
<ajmitch> naughty
<psusi> so... anyone here ever udebified a package before?  I think I've managed to udebify dmraid, but I'd like someone to take a look at it on revu
<bmonty> ajmitch: on the openssl issue I asked you about yesterday, do I put the openssl acknowledgement in the copyright file?
<ajmitch> if it's really in the source's copyright
<ajmitch> maybe something to clarify with the debian maintainer
<bmonty> it is in the source's copyright, but checking with the maintainer probably isn't a bad idea
* Yagisan feels odd - my copyright file in /debian is more current then what is in the source, infact some of the source has no copyright notices
<Amaranth> does the source at least have a LICENSE file?
<Amaranth> or have a note in every file saying the license?
<Yagisan> Amaranth: it's from a package that was rejected because upstream has mixed licenses which no longer pass the dfsg tests, but can be distributed non-commercially
<Amaranth> Yagisan: multiverse, if it gets in at all
<Amaranth> what is it?
<Yagisan> Amaranth: a doom source port
<Amaranth> also, the non-commercially thing would probably keep it out of multiverse too
<sistpoty> hooray... mythplugins all built
<Yagisan> Amaranth: my 3rd party repo page http://eyagi.bpa.nu/eyagi/community-projects/yagisan-s-doomsday-for-debian-ubuntu/
<Amaranth> ah
<Yagisan> Amaranth: what is annoying is that one of the raven programmers later stated heretic/hexen are now public domain
<Amaranth> not good enough
<Yagisan> Amaranth: in a doomworld forum, but I can't find the post now :(, and there is no mention @ raven software :(
<Amaranth> everyone who touched the code has to have something publicly verifiable
<sistpoty> Yagisan: just the engine or data as well?
<Yagisan> sistpoty: just the engine, actually only two source directorys - easy to delete if you don't want heretic or hexen
<Yagisan> sistpoty: you'd need to either buy the data, or use freedoom + a megawad to play
<sistpoty> would have been so cool, if they made data available as well...
<Yagisan> sistpoty: I agree - but they still actually sell it !!!
<sistpoty> heretic and hexen? wow... didn't know that
<sistpoty> anyway, I'm off to bed now... gn8 everyone
<minghua> good night sistpoty
* minghua is intrigued to see a mail about Gaussian support on ubuntu-devel list
* Kyral is intruiged to try PCBSD
* Yagisan is waiting for Ubuntu/kfreebsd :-P
<Kyral> lol
<Kyral> HURD!
* Kyral would laugh if GNUBuntu turned out to be Ubuntu/HURD
* Yagisan thinks that sounds perfect
* psusi wonders WTF a WWII submarine simulation game needs to compute fast fourier transforms for
<persia> psusi: Realistic sonar?
<ajmitch> psusi: what game?
<psusi> dangers of the deep
<psusi> I'm trying to package it
<ajmitch> fun
<psusi> any idea WTF debuild would say it is ignoring deletion of (every god damned file in the orig tarball)?
<psusi> heh
<zakame> hello all
<minghua> hi zakame
<zakame> heya minghua :)
<tepsipakki> hello all
<tepsipakki> I made a new upload of gtkpod-aac yesterday
<tepsipakki> to REVU of course
<Mez> ajmitch: do you think it would be a good thing for me to go through a load of apps in ubuntu and re-make them so that they like - hae tighter depends (fix the whole libtool thing!)
<ajmitch> such as?
<minghua> hi Mez, I remember you asking the Qt immodule thing on debian-devel list
<minghua> Mez: did you get any answer for that?  AFAIK debian's qt3 doesn't has the immodule patch applied
<Mez> ajmitch: well put it this way
<Mez> minghua - nope - no answer - though we submitted a patch for it anyays
<minghua> Mez: to qt-x11-free?  I think I want to subscribe to that bug
<lifeless> twelth from the top of NEW
<Mez> http://ubuntu.pastebin.com/515823
<Mez> ajmitch:
<Mez> http://ubuntu.pastebin.com/515823
<Mez> minghua, 347377
<minghua> Mez: thanks
<ajmitch> Mez: and how much divergence from debian do you want to introduce now?
<Mez> ajmitch: I would only modify *ubuntu* packages
<Mez> and would submit patch upstream and stuff
<Mez> + It's being asked for in debian :P
<Mez> http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html
<ajmitch> ok,, do it if you want :)
<Mez> hmm
* minghua knows his debian package is probably not libtoolized correctly :-P
<Mez> minghua: lol
<Mez> mine is (well will be)
<Mez> and I only asked casue I've just updated yakuake to fix it (talking to the DD regarding it!)
<minghua> Mez: I think I'll learn from you how to do it properly
<Mez> minghua: It's really really easy
<Mez> lol - well for KDE stuff anyways
<minghua> Mez: I didn't fix my packages because I don't understand autotools at all, and since my upstream uses resonably recent autotools + libtool, and they compile on all arches, I didn't bother
<Mez> minghua: thing is - does it use DEBIAN's libtool?
<minghua> Mez: no
<Mez> minghua: there comes the problem - the libtool stuff is in debian only
<Mez> have a read of that link above
<Mez> it tells you a lot
<minghua> I only use the new config.{sub,guess}, but didn't relibtoolize it
<Mez> minghua, http://people.debian.org/~keybuk/libtool-updating.html
<minghua> Mez: thanks for the links, reading
<Mez> minghua, no probs
<minghua> I read d-d-a, but didn't follow all the links in that mail
<Mez> when ever someone mentions d-d-a I always think ddr
<phanatic> hi people
<spiritz> hi
<Gloubiboulga> hello phanatic
<phanatic> hi Gloubiboulga
<phanatic> i fixed the package
<phanatic> uploaded to revu yesterday
* minghua wonders why his package depends on libfreetype6 (incorrectly) in dapper, but doesn't in sid
<Gloubiboulga> phanatic, cool
<phanatic> Gloubiboulga: if you have a little time, could you have a look at it pls?
<minghua> relibtoolizing fixed that, though
<Gloubiboulga> phanatic, I'm looking at it... but I am not a MOTU
<nlindblad> hello masters
<Fuddl> ... eeeehm..... would somebody like to take a look at the quake3 package i uploaded to revu.tauware.de? *smiiiiiiiile*
<siretart> link?
<siretart> http://revu.tauware.de/details.py?upid=1570
<phanatic> i also uploaded a new version of gnome-rdp, if any of the masters have time for it: http://revu.tauware.de/details.py?upid=1576
<siretart> phlaegel: advocated
<teprrr> Fuddl, hmm. why there is those quke3-server*.preinst, prerm, postinst, postrm and shlibs if they're empty?
<teprrr> and there quake3_*.preinst, prerm and shlibs which seem to be empty too
<teprrr> I don't know the policy, just thinking :)
<siretart> teprrr: they are not available in the package
<teprrr> hmm
<siretart> teprrr: it is just the script, which creates them. if they have size 0, then the package does not have them
<Fuddl> teprrr: yepp, no pre* or post* stuff is in the source package
<teprrr> oh, okay.. the package of mine doesn't have those though: http://revu.tauware.de/details.py?upid=1568
<ajmitch> morning \sh
<\sh> moins
<siretart> hi ajmitch, hi \sh
<ajmitch> hello siretart
<\sh> moins siretart
<\sh> oergs mail time :)
<ajmitch> night all
<tseng> bye ajmitch
<jpatrick> ajmitch: night
<siretart> gn8 ajmitch
<\sh> ajmitch: sleep well :)
<marcin`> hello MOTU
<marcin`> got a question
<Yagisan> night ajmitch
<marcin`> what you guys do when you want to change name of package?
<Yagisan> marcin`: first - why do you want to change the name of a package ?
<tseng> a source package or a binary?
<marcin`> how you count releases? what about changelog?
<marcin`> Yagisan: hmm for example to use different name convention
<marcin`> tseng: both
<Yagisan> marcin`: is this package from debian ?
<marcin`> Yagisan: kind of...
<marcin`> Yagisan: there are packages that are available in debian and some new packages
<Yagisan> marcin`: wishlist bug + very good reason @ debian bts
<Yagisan> marcin`: new packages - not in ubuntu already ?
<marcin`> I'm just going to upload a bunch of packages to REVU...
<marcin`> Yagisan: yes not in ubuntu and not in debian
<marcin`> Yagisan: but related to some infrastructure that is already available in debian and ubuntu
<Yagisan> marcin`: the new packages - different source to the debian packages ?
<marcin`> Yagisan: it's about Emacs
<marcin`> Yagisan: I would like to package some *.el files and tools for Emacs
<marcin`> Yagisan: but also repackage some existing debs
<Yagisan> marcin`: name the new packages consistently with existing package names if possible
<marcin`> Yagisan: and that the problem
<Yagisan> marcin`: why repackage ?
<marcin`> Yagisan: because in fact I don't see any naming convention for emacs packages
<marcin`> Yagisan: it's just chaos and mess
<marcin`> Yagisan: this is why I would like to change names of some existing packages
<Yagisan> marcin`: repackaging that sounds like unnecessarily divergence from upstream
* minghua heard there is an emacs policy
<minghua> never read it though
<Yagisan> marcin`: wishlist bug + very good reason @ debian bts + patch may help
<marcin`> minghua: there is emacs policy - but it's related to how emacs packages install and uninstall libraries
<marcin`> minghua: and about emacsen-common scrpits
<minghua> marcin`: okay.  I am really not familar with that part at all
<marcin`> Yagisan: why repackage: 1. because I want to use cdbs in rules
<marcin`> Yagisan: 2. because there is a lot of things in emacs packages that just don't work at all
<Yagisan> marcin`: so what - upstream will eat you for eat - it becomes your baby for life
<Yagisan> s/for eat/for that
<Yagisan> marcin`: fixing is good, changing upstreams build system without discussing it with them is bad
<Yagisan> marcin`: they have already complained about it
<marcin`> Yagisan: 3. bacause there is a big mess in emacs packages especially in names
<marcin`> Yagisan: for example you got pretty simple naming convention for libs*, python2.*-*, perl*-* etc....
<marcin`> Yagisan: but emacs is just mess
<marcin`> Yagisan: anyway - this is why I want to upload this to REVU - to start discussion - right?
<Yagisan> marcin`: no doubt, but because we are taking this from debian, it is much much much easier for us, if we can get debian to do the renaming
<Yagisan> marcin`: are you on the ubuntu-motu mailing list ?
<Yagisan> marcin`: an email there will get you responses from real MOTU's not an apprentice like me
<Yagisan> marcin`: but as I said, name your new packages as you like
<marcin`> Yagisan: ok, I'll do
<marcin`> Yagisan: but my question was - what you do when you want to change name
<marcin`> Yagisan: what you do with changelog
<Yagisan> marcin`: yes, I know - but the why is important
<Yagisan> marcin`: I only know how to change binary names
<marcin`> Yagisan: and what you do with release numbers...
<Yagisan> marcin`: I kept the changelog intact
<Yagisan> marcin`: new binary name = new number
<Yagisan> marcin`: I changed the name of the binary in control
<Yagisan> marcin`: and added a Replaces: Oldname
<Yagisan> marcin`: line to the control file
<Yagisan> marcin`: someone like tseng most likely knows if I forgot something, and how to do it for a source package
<marcin`> Yagisan: so, for example: we got erc-5.0.2-5 and I would like to change it's name to emacs-erc-5.0.2
<marcin`> Yagisan: then release number counts from 1 right?
<marcin`> Yagisan: emacs-erc-5.0.2-1 right?
<Yagisan> marcin`: I think you could do that
<marcin`> Yagisan: and you just continue changelog but with new entries starting with new name?
<phanatic> hi people
<marcin`> Yagisan: anyway sorry I have to leave now... thanks
<Yagisan> marcin`: in my case the source package didn't change, so I did nothing to the changelog
<Yagisan> marcin`: no worries - hope I was helpful
<zakame> hi MOTUs :)
<Yagisan> G'day zakame
<zakame> heya Yagisan :)
<Yagisan> zakame: adopting a few debian packages ? Seems every time I check I see you looking for sponsers
<zakame> Yagisan: no actually I was just updating packages adopted from Clint
<zakame> Yagisan: it was only now that Clint (or someone else iirc) filed O bugs, which I promptly ITA'd
* Yagisan will brb - food
<phanatic> if any of the MOTUs have some time, please have a look at this upload: http://revu.tauware.de/details.py?upid=1577
<phanatic> thanks in advance
<Hieronymus> Someone who can post comments on REVU, please copy my mailinglist comment for quake3-data of 18 january to REVU
<zakame> wb rbelem , raphink :)
<rbelem> morning zakame, raphink
<rbelem> morning all ;-)
<siretart> Hieronymus: you could talk directly to Fuddl :)
<siretart> Hieronymus: I don't know if OpenArena works with q3 yet
<Hieronymus> siretart: it does
<Hieronymus> I'm running it
<Hieronymus> but I needed to bypass his data file checks
<siretart> oh
<siretart> Hieronymus: IIRC the idea of the package was that there could be other packages, which replace/enhance it
<siretart> Hieronymus: so you would 'just' need to package OpenArena as well
<Hieronymus> siretart: yeah
<Hieronymus> it's in the README.Debian
<Yagisan> Hieronymus: you have free data for quake3 ??
<Hieronymus> Yagisan: http://planetgargoyle.com/openarena
<Hieronymus> Yagisan: it has 2-3 levels, 1-2 characters and ~6 weapons
<Hieronymus> but it's playable
<Hieronymus> no bots
* Yagisan would very much like some more games to play, Hieronymus, can't wait for your package ;)
<Hieronymus> Yagisan: I'm not going to package it
<Hieronymus> it's too pre-alpha for that, and the copyright/license information isn't clearly stated
<siretart> Hieronymus: so what do you actually ask fuddl?
<Hieronymus> siretart: shall I just write it down more clearly?
<Yagisan> Hieronymus: I see - I've been beating my upstreams with cluebats for their data files - didn't help that someone copied it and was selling it on ebay though :(
<Hieronymus> I don't have a quake III CD, but I should be able to use the package anyway, without modifying his quake3 script
<Hieronymus> Yagisan: what do you mean?
<Hieronymus> What do I do when my debian/watch file doesn't work, and I don't know why?
<Yagisan> Hieronymus: literally someone copied their data, stripped the copyright notices, packaged Id software iwads, and a windows port of the engine, and was selling it on ebay as Doom 3
<Hieronymus> sue!
<Yagisan> Hieronymus: if they catch the guy, I'm sure they will. But they have been more restrictive with the data since then.
<Fuddl> perhaps i should write a note to the quake3 control file it will pull quake3-data which will need the cd
<Fuddl> oh yes, i should do that, the quake2 package also does it
<Fuddl> Hieronymus: installing the demo-data doesn't work 100%, a lot of textures get scrambled, sounds are missing, and, and, and - that's why i didn't give the option to install the data files from the demo in the postinst script of quake3-data
<Hieronymus> Fuddl: I don't want to install the demo data
<Hieronymus> but it should be very easy to make an openarena package once that gets past pre-alpha stage
<Hieronymus> and right now quake3 won't run even if I put a pak0.pk3 in the baseq3 folder
<Kyral> Morning
<phanatic> hi Kyral
<Yagisan> Kyral: damm, your right it is morning
<thierry_> JohnyMast : you told me yesterday to ping you about my package
* Kyral falls down
* raphink is sorry for the spam yesterday. My connection is back to a normal state now.
<Kyral> raphink, no offense, but you are picky...
<raphink> Kyral: what do you mean?
<Kyral> your last comment on GTKEdit reminded me of the "No newline at end of file" warnings in Lintian ;P
<raphink> Kyral: look at all the debian/control you can find ;)
<raphink> Kyral: it's just a very small detail I know ;)
<Kyral> Oh well, at least you like it...
<raphink> I almost advocated it
<Kyral> the Debian Devs flat out don't
<ajmitch> that
<raphink> they don't like the package?
<Kyral> yah
<ajmitch> there's been talk of even removing gtk+ 1.2 stuff in the future
<Kyral> mostly along the lines of "Ick its GTK 1"
<ajmitch> at least gnome 1.x
<Kyral> Well, if you read the webpage, you will see the reason why its GTK 1
<ajmitch> I know
<Kyral> raphink: reuploaded
<Kyral> whenever the next REVU cycle is, it will show up
<Kyral> your vote will make two votes, so feel free for upload (you are MOTU now aren't you?)
<ajmitch> raphink: I see you're requiring a Homepage entry in debian/control, why is that?
* ajmitch tries to sleep again, got to get up in ~4 hrs
<Yagisan> night ajmitch (again)
<ajmitch> :)
<Hieronymus> Can anyone tell me why uscan doesn't like my debian/watch (http://paste.ubuntu-nl.org/7454) with uscan output (http://paste.ubuntu-nl.org/7453)?
<teprrr> hmm, how should I proceed after accidentally uploading a package without original source? after I fixed the problem dput doesn't want to upload the package..
<teprrr> should I bump the version or..?
<Mithrandir> rm the $pkg_$version.upload file
<teprrr> Mithrandir, ah. thanks.
<raphink> ajmitch: yeah it's surely not policy, but it's a very common habbit, that it's nice
<raphink> ajmitch: but I reckon it shouldn't be a requirement
<phanatic> raphink: could you have a look at this one: http://revu.tauware.de/details.py?upid=1576 ?
<teprrr> http://revu.tauware.de/details.py?upid=1578 -- umh, I still can't see the .orig.tar.gz there..
<teprrr> but at least dput said it's uploaded there.. and the page shows that there's been a change
<phanatic> teprrr: there's a .tar.gz
<phanatic> including the debian dir
<teprrr> phanatic, yes. but it isn't the orig one.
<Gloubiboulga> is there a lib specialist around? it's about http://revu.tauware.de/details.py?upid=1536
<phanatic> teprrr: check the package building process
<Gloubiboulga> I'd like to avoid a fight between sistpoty and hub ;)
<teprrr> phanatic, hmm?
<phanatic> teprrr: your package seems to be built as a native package
<teprrr> phanatic, you mean without the orig. source? yup, that happened accidentally and I've fixed it locally
<teprrr> was -<version>.orig instead of _<version>.orig and it failed :/
<thierry_> JohnyMast : ping
<teprrr> ok, solved, thanks to phanatic :)
<raphink> phanatic: I'm hesitating to upload gnome-rdp
<raphink> phanatic: it's very good technically, nothing to say
<raphink> now the point where I struggle is a licensing one
<\sh> grmpf...need to update 5 gentoo servers
<raphink> since the upstream didn't put any reference to a license in any of their source files
<\sh> raphink: raise the issue to ubuntu-devel, so elmo can have a look (cc to james)
<raphink> not even a reference to COPYING
<raphink> ok
<raphink> \sh: well i'd say phanatic could ping upstream to get them add the 3 paragraphs for GPL in each source file
<raphink> and that would do
<phanatic> raphink: should i ask upstream about licensing?
<phanatic> ok :)
<raphink> phanatic: yes I think so
<\sh> or put the whole gpl license into the source
<phanatic> i'll write an email now
<raphink> \sh: the whole GPL is present in COPYING
<raphink> this is not the issue
<raphink> Debian policy states that each source file should either clearly state the license it falls under
<raphink> or link to COPYING
<raphink> which is not the case
<raphink> I don't consider `// project created on 09/20/2005 at 20:33` a proper licensing header ;)
<siretart> phanatic: tell your upstream to read the gpl
<siretart> phanatic: espc. the 'how to apply the gpl' part
<raphink> yep
<raphink> http://www.gnu.org/copyleft/gpl.html#SEC4
<raphink> :)
<phanatic> okay :)
<thierry_> siretart : could you review my package? http://revu.tauware.de/details.py?upid=1572 JohnyMast said yesterday he would find someone to do it this morning but he doesn't respond since 3 hours...
<thierry_> JohnyMast also said it looked good :)
<phanatic> raphink: i mailed upstream. if everything will be okay, he'll release a new version tomorrow (containing the Makefile patch too)
<phanatic> and thanks for the review
<raphink> phanatic: great, I'll be happy to upload it if there's not too many changes
<phanatic> i have another package uploaded as well, and i don't fully agree with zakame about his complaints: http://revu.tauware.de/details.py?upid=1579
<Mithrandir> is Danilo Piazzalunga a MOTU?
<\sh> not that I know of
<\sh> what's his nick?
<Mithrandir> I don't know, that's why I'm asking.
<\sh> to be honest, I don't know the realname..
<hub> Gloubiboulga: there won't be any fight
<hub> Gloubiboulga: he has seniority
<Gloubiboulga> hub, I was just kidding :)
<thierry_> JohnyMast : ping
<thierry_> JohnnyMast : ping
<JohnnyMast> thierry_ pong
<thierry_> JohnnyMast : you said yesterday you would find someone to review my package...
<JohnnyMast> aah right hold on
<JohnnyMast> slomo_, are you here ?
<thierry_> siretart : could you review my package?
<mxpxpod> is anyone having problems with spamassassin?
<crimsun> mxpxpod: did you ping benc (or file a bug in malone) about your ppc sound issue(s)?
<mxpxpod> crimsun: not yet.. I haven't gotten to it ;)
<crimsun> mxpxpod: ok
<mxpxpod> crimsun: I think it has something to do with the suspend bug in malone
<mxpxpod> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/29268
<crimsun> mxpxpod: k, ppc isn't my arena, just trying to keep abreast of the sound bugs
<Ubugtu> Malone bug 29268: "linux-image-2.6.15-13-powerpc breaks sleep on ibook g4" Fix req. for: linux-source-2.6.15 (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed
<mxpxpod> crimsun: I still have to get a launchpad.net account ;)
<mxpxpod> oh, wait
<mxpxpod> looks like I have one...
<tseng> anyone have a problem with gnome-power-manager
<mxpxpod> tseng: yup
<crimsun> tseng: ogra mentioned not having merged the new version yet
<tseng> mxpxpod: child exits?
<crimsun> said it was blocked on a glib issue
<mxpxpod> tseng: keeps telling me that hal doesn't have powermanagement enabled
<tseng> mxpxpod: nope.
<teprrr> hmm, can I somehow get a package into universe when the author of the app has made the package? looks like for debian though
<mxpxpod> tseng: strange... that's what it's telling me :(
<tseng> mine just exits with no output
<mxpxpod> tseng: do a gnome-power-manager --no-daemon
<crimsun> mxpxpod: that's the issue that mjg59 asked about yesterday (to which ogra referred)
<mxpxpod> crimsun: ah, ok
<teprrr> and how long it usually takes that someone will review the package on revu?
<mxpxpod> tseng: are you having a problem with spamassassin?
<phanatic> hi people
<phanatic> raphink: the package is under way
<teprrr> hello
<Kyral> uo LJ
<ajmitch> crimsun: you're doing some work on alsa upstream at the moment?
<phanatic> raphink: http://revu.tauware.de/details.py?upid=1583 (licensing info added + patch applied by upstream)
<crimsun> ajmitch: in a bit, yes (your issue is noted)
<ajmitch> crimsun: oh I know someone is assigned to the issue I care about :)
<LaserJock> Hi Kyral
<stratus> root@trinity:/var/log/piupartme# cat 1-21-2006/kerneltop/piupartme-kerneltop.log
<stratus> piupartme: package [kerneltop]  - version [unknown]  - build attempt at: 1-21-2006
<stratus> piupartme: package [kerneltop]  - version [unknown]  - maybe-successful
<stratus> nice!
<stratus> ajmitch, my little toy is just a step (or two) since its first run through each universe package
<stratus> ajmitch, it lacks some speed optimizations and a small db containing a hash with the last package and the version tested (to avoid run the same tests over a package two times)
<stratus> everything else looks good and is customizable
<\sh> grrr..mysql upgrade from 4.0 to 4.1 on gentoo is a pain
<teprrr> can anyone help me?
<teprrr> with those things I mentioned earlier :)
<\sh> why, in gods almighty name, has cacti a dependency on lighttpd on gentoo?
<\sh> now I have to bloddy webservers
<Hieronymus> Can debian/watch handle XML?
<Hieronymus> It's not working right with http://taschenorakel.de/svn/repos/bulldozer/releases/
<VelvetElvis> is this where I go to ask about an afterstep 2.2.0 package for dapper?  It's in sid
<ajmitch> yes, we'll need to have good reasons to get a new version in though
<ajmitch> upstream version freeze was a few days ago :)
<VelvetElvis> it's a new major version that you didn't get to before?
<VelvetElvis> it's been in sid for weeks
<ajmitch> weeks?
<ajmitch> no, it was uploaded only a week ago
<VelvetElvis> ok, my bad
<VelvetElvis> anyway, any chance of that happening or should I break down and try and build my own?
<ajmitch> upstream version freeze means we don't put in new major versions without reasons
<ajmitch> sure, there's a chance
<Hieronymus> VelvetElvis: if you think there's a good reason to include the new version, write a UVF exception report
<ajmitch> the way of doing those reports has to be documented properly
<VelvetElvis> right. ok to post changelog?  support for fullscreen is the main reason i'm wanting it
<VelvetElvis> Hieronymus: where/how do I do that?
<VelvetElvis> er, url to changelong?
<Hieronymus> VelvetElvis: look in the archives of devel
<VelvetElvis> ok, thanks
#ubuntu-motu 2006-01-27
<Kyral> ...Portage...it..is...horribly inefficient...
<Kyral> not the compiling thing...but the thing for when you emerge sync, it downloads every file in the Portage tree...
<tseng> no it doesnt
<tseng> it rsyncs it
* Kyral falls down
<Kyral> still ineffiecent...
* Kyral goes to load GoboLinux in a VM
<minghua> if you do it every day, rsync should be quite efficient
<minghua> debian/ubuntu still downloads the whole Packages.gz, so it's not necessarily better
<Kyral> Packages.gz tends to be smaller...
<thierry_> slomo_ : are you there?
<thierry_> any MOTU who could review my package?
<crimsun> url?
<thierry_> http://revu.tauware.de/details.py?upid=1572
<crimsun> note that I can't log in to comment due to gpg key issues, but I can certainly note comments
<thierry_> k thanks, anyway you did the last comments and I uploaded next to that
<crimsun> thierry_: few minor misspellings in debian/libfxruby1.4.1.docbook
<crimsun> ("library")
<thierry_> k... like what?
<thierry_> ho...
<thierry_> must be my french side who has difficulty to right english properly :)
<crimsun> ;)
<thierry_> anything other errors like that?
<crimsun> also, try to be consistent with the URIs
<thierry_> ?
<crimsun> For more information about Ruby, see http://www.ruby-lang.org/ .
<crimsun> For more information about FOX, see http://fox-toolkit.org/ .
<thierry_> what more could I say?
<crimsun> the issue is the missing "http://" for the Ruby line
<crimsun> (consistency)
<crimsun> in debian/copyright, there's a stray ` on line referring to /usr/share/common-licenses/LGPL
<crimsun> you'll need to make the same adjustments to debian/control's Descriptions (as far as the URI consistency issue is concerned)
<thierry_> k
<thierry_> that's all?
<thierry_> coming back in 10 minutes
<crimsun> it ftbfs in a current dapper pbuilder
<crimsun> it dies trying to compile core_wrap.cpp with: include/FXRuby.h:197: error: redefinition of 'VALUE to_ruby(long unsigned int)'
<crimsun> (this is on amd64)
<crimsun> otherwise the packaging looks fine
* crimsun leaves for the evening
<marcin`> hi MOTU
<marcin`> I got few questions about REVU
<marcin`> could someone tell me where can I find my uploads to REVU?
<marcin`> I uploaded package.. and have no idea why it doesn't show on tauware.de
<Kyral> hmm
<LaserJock_away> marcin`: what's the name of the package?
<marcin`> LaserJock_away: emacs-circe
<marcin`> another thing is that I have no idea how to.... log into revu.tauware.de...
<LaserJock> marcin`: you can after your first upload
<LaserJock> marcin`: did you upload a source package?
<marcin`> LaserJock: yes
<marcin`> LaserJock: you mean *_source.changes file?
<LaserJock> marcin`: and you sent your gpg key?
<marcin`> LaserJock: yup
<marcin`> LaserJock: it's required for upload
<LaserJock> but you sent it to keyring@tiber.tauware.de ?
<LaserJock> marcin`: ^^ ?
<marcin`> LaserJock: I got mail from Stefan Potyra
<LaserJock> ok
<marcin`> LaserJock: and he says that he added my key to keyring
<marcin`> LaserJock: and I should be able to make uploads and that's true
<marcin`> LaserJock: because I really could upload signed package to revu with dput
<LaserJock> ok, so did dput give you any errors?
<marcin`> LaserJock: hmm I don't remember, I don't think so
<marcin`> LaserJock: result was successfull
<marcin`> LaserJock: I can upload this package again...
<LaserJock> marcin`: how long has it been?
<marcin`> LaserJock: well dput emacs-circe*_source.changes
<marcin`> LaserJock: says
<marcin`> LaserJock: Already uploaded to upload.ubuntu.com
<LaserJock> oh, you sent it to Ubuntu
<LaserJock> you need to do something like "dput revu *.changes"
<LaserJock> note the "revu" part
<LaserJock> marcin`: does that make sense?
<marcin`> LaserJock: hmm ok
<marcin`> LaserJock: ehh it wat my fault
<marcin`> LaserJock: I forgot to configure /etc/dput.cf correctly
<marcin`> LaserJock: sorry and thanks for help
<LaserJock> well, at least you found the problem
<LaserJock> marcin`: I see it on REVU now :-)
<Kyral> hmm
* Kyral might have to use SuSE for a server soon...
<marcin`> LaserJock: yes I do too
<marcin`> LaserJock: and now I got password for revu...
<LaserJock> great
<LaserJock> marcin`: you should check out the lintian output
<marcin`> LaserJock: I just did it
<marcin`> ok, I need to go to bed now... I'm pretty tired
<LaserJock> marcin`: I think the address for the FSF has changed in debian/copyright
<LaserJock> marcin`: ok, np
<marcin`> but maybe tomorrow I'll try to upload my entire emacs infrastructure... and of course
<marcin`> I'll upload emacs-circe*0ubuntu4 with changes to make lintian happy ;)
<LaserJock> so I just used a Christmas Barnes and Noble gift card to by "Python Cookbook". I looks pretty useful
<Kyral> It is :D
<LaserJock> it's got some stuff on xml-rpc which is cool
<LaserJock> maybe eventually I'll be able to write some stuff to interact with launchpad
<Kyral> hehe
<Kyral> LP++
<LaserJock> so what happens if a Universe package's deps are messed up? We can fix it now right?
<Kyral> Bug?
<LaserJock> is that a bug?
<Kyral> is it filed?
<LaserJock> hmm, I didn't even check. just a sec
<Kyral> What package?
<LaserJock> oh, yeah, there is a bug
<LaserJock> Malone bug 29220
<Ubugtu> Malone bug 29220: "vncserver not installable because it depends on xserver-common" Fix req. for: vnc (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/29220
<LaserJock> it's really messing me up because I use vnc a lot
<StevenK> Oh, I so want to fix it.
<Kyral> that package exists
<Kyral> xserver-common
<LaserJock> no it doesn't
<StevenK> Then I get to use my new @u.c address and upload privs.
<Kyral> yah it does
<LaserJock> Kyral: I don't have it
<LaserJock> Kyral: it was replaced with the lates Xorg update
<StevenK> xserver-common doesn't exist in dapper, according to packages.u.c
<Kyral> oh I haven't sync'd since this morning
<LaserJock> it is now something like x-common or xorg-common
<LaserJock> well, it's been that way for a few days
<Kyral> Tell that to my AptCache
<LaserJock> Kyral's apt cache: your full of crap!
<Kyral> ...
<LaserJock> x-common exists but no xserver-common
<LaserJock> so maybe I should fix it
<StevenK> I wanna!
<Kyral> yh just increment the Ubuntu Revision
<StevenK> LaserJock: I got upload privs, I'd like to test them out. :-)
<Yagisan> G'day All
<LaserJock> StevenK: sure, I don't have upload privs. so you will get it done faster ;-)
<StevenK> Ah
<LaserJock> Kyral: no ubuntu version, so we get to diverge
<StevenK> For vnc?
<StevenK> Get:1 http://archive.ubuntu.com dapper/main vnc 3.3.7-8ubuntu1 (dsc) [696B] 
<LaserJock> vnc4
<LaserJock> although vnc might have the same problem
<StevenK> It does.
<LaserJock> StevenK: try apt-cache rdepends xserver-common . What do you get?
* StevenK chroots into dapper.
<StevenK> root@broken:/# apt-cache rdepends xserver-common
<StevenK> <xserver-common>
<LaserJock> I don't quite get that
<LaserJock> that's what I get too, but somebody in -devel the other day got a list of ~ 4 packages
<LaserJock> StevenK: are you looking at -devel?
<StevenK> root@broken:/# grep-dctrl -sPackage -FDepends 'xserver-common' < /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_dapper_universe_binary-i386_Packages
<StevenK> Package: meta-ul-desktop-base
<StevenK> Package: meta-ul-server-gui
<StevenK> Package: tightvncserver
<StevenK> Package: vnc4server
<StevenK> Package: vncserver
<StevenK> And yes, I saw that.
<LaserJock> ok, cool
<StevenK> I don't know anything about meta-ul-{desktop-base,server-gui}
<LaserJock> I wonder why apt-cache rdepends doesn't work
<StevenK> But I can certainly fix the three bottom packages.
<LaserJock> well that's all I care about ;-)
<LaserJock> hmm, stupid memory leak is really bugging me
<LaserJock> I wonder if I do a fresh install with Flight3 would help
<LaserJock> Kyral: ping?
<Kyral> ping?
<LaserJock> Kyral: how did you figure out how to use the debian stuff from emacs?
<Kyral> Like Debian-Utils?
<LaserJock> yeah
<Kyral> M-x deb<tabcomplete from here>
<LaserJock> oh, thats pretty easy
<LaserJock> I was thinking about an having an excursion into the dark side ;-)
<Kyral> ...
<LaserJock> hmm, I seem to have a pretty stupid .emacs from somewhere
<Kyral> lol
<LaserJock> everything is bright blue
<Kyral> lol
<Kyral> rm .emacs ;P
<LaserJock> yeah, I think I have another (or 2)  .emacs I can try :-)
<LaserJock> Kyral: are you using the emacs snapshot?
<Kyral> I dunno
<Kyral> lol
<Kyral> last I knew I had emacs21-nox installed
<StevenK> Blah, my upload was REJECTed.
<Kyral> hah
<StevenK> Due to no key, so now I need to bug elmo again.
<LaserJock> dang, my aptitude seems to be really messed up
<Kyral> lol
<LaserJock> StevenK: you gotta get vnc working again, all of my console apps are in bad shape :-(
<Kyral> lol
<Kyral> FreeNX
<LaserJock> does that work well?
<Kyral> yah
<LaserJock> better than VNC?
<Kyral> yah
<Kyral> and SECURE
<Yagisan> Kyral: amd64 ??
<Kyral> x86
* Yagisan cries
<LaserJock> Kyral: where do you get it from?
<Yagisan> Kyral: why no amd64 ?
<Kyral> wiki.ubuntu.com/FreeNX
<LaserJock> doh
<psusi> does freenx support ssl?
<Yagisan> psusi: AFAIK it runs on SSH only
<psusi> bah
<LaserJock> well, I'll see how it goes
<LaserJock> hmm, I can't seem to get nx to go through my ssh tunnel (or I'm doing it wrong).
<LaserJock> grr, freenx hates me
<ajmitch> afternoon
<Yagisan> afternoon ajmitch
<ajmitch> nice & toasty warm there today?
<ajmitch> I heard it was hot in melbourne
<Yagisan> ajmitch: it's about 30 here in Sydney where I am
<ajmitch> hm
<psusi> LaserJock, you are pointing the client to 127.0.0.1 right?
<ajmitch> my friend in melbourne was expecting up to 43 there
* psusi doesn't like ssh tunnels
<psusi> ssl or ipsec are way better
<LaserJock> psusi: I have to connect through another computer to get to my FreeNX server computer. A ssh tunnel should work for that right?
<LaserJock> hi bmonty
<bmonty> hey Laserjock
<bmonty> evening everyone
<psusi> LaserJock, what do you mean "through" another computer?
<psusi> when you set up an ssh tunnel, the ssh client listens on localhost and forwards any connections it gets, so you need to tell freenx to connect to localhost
<LaserJock> psusi: I have to log into one computer (the uni server) and from there log into my machine
<psusi> both with ssh?  why two steps?
<LaserJock> psusi: both with ssh, because it is department policy
<psusi> that's.... about gay... heh
<LaserJock> we can't connect to outside computers directly
<psusi> but you should be able to tunnel from localhost to x, then tunnel from x to y
<psusi> what nazi decided you shouldn't be able to do that?
<\sh> moins
<LaserJock> psusi: all the Windows IT guys that get viruses on a daily basis, and the same guys that closed the .torrent and irc ports
<ajmitch> hey \sh
<psusi> bit torrent can use any port the client chooses... as can irc... but yea... that says enough about the type... morons in other words
<psusi> are you sure they have port forwarding enabled on the server then?
<LaserJock> psusi: well, soon I will have an iMac at work and I can bring the Ubuntu box home
<Amaranth> LaserJock: intel imac?
<LaserJock> psusi: I can use VNC by setting up a tunnel
<LaserJock> Amaranth: yes
<psusi> ok, then freenx should work the same way
<LaserJock> psusi: well, I thought so
<Amaranth> LaserJock: kick ass
<psusi> btw... do they let traffic out on port 80?
<LaserJock> Amaranth: I hope so, we got 2
<\sh> openmotif is so broken bah
<LaserJock> psusi: yes
<Amaranth> LaserJock: everything i've seen says they're fast as hell
<LaserJock> Amaranth: I'm a little worried about their support for older PPC software
<LaserJock> Amaranth: and of course I can't install Ubuntu on it yet
<psusi> get a machine outside their retarded network to run an openssl s_server on port 80 tied to a pppd then ppp over ssl to it on port 80 ;)
<Amaranth> as long as the software doesn't touch mach, the partition layout, etc it should be fine
<ajmitch> psusi: ppp over tcp/ip is evil
<Amaranth> iow as long as they stuck to carbon and cocoa
<LaserJock> psusi: well, all I have is Windows on the outside until I bring home my work box
<bmonty> In general I have found that network admins get upset when you take active measures to circumvent their rules
<psusi> ajmitch, it's better than most proprietary VPN solutions
<Yagisan> LaserJock: just tell us where to find these systems - we'll open those ports for you >:)
<Amaranth> in general i've found that network admins that do things like that don't know enough to catch you
<Yagisan> ajmitch: umm - don't you use pppoe to connect to the net ?
<ajmitch> Yagisan: pppoa
<psusi> bmonty, that's the point... if they upset you with their asanine draconian rules, upset them back..
<Yagisan> ajmitch: it's about the same overhead
<ajmitch> Yagisan: I'm meaning the slowdown of having tcp over tcp
<\sh> well...I leave it to the debian maintainer, to fix the breakage...when they deal with modular xorg
<psusi> and yea.. if they are stupid enough to believe they are doing some good with those measures, they are too stupid to catch you getting around them ;)
<LaserJock> well, luckily freenode has 8001 open so I can irc from work
<ajmitch> where a slight slowdown in the base level causes issues
<psusi> ppp over what?  what's the a?
<psusi> pppoe = gay
<Yagisan> ajmitch: ah - I've done things like tcp over udp to get through restrictive networks like that
<ajmitch> atm
<ajmitch> tcp over udp isn't nearly so bad
<bmonty> psusi: I disagree, I generally think the policy of disallow all and allow by exception is the way to go
<\sh> bah..watching a movie :)
<psusi> pppoe exists soley for the reason that ISPs are stupid and want to use an ethernet network but still have their customers "log in"
<Yagisan> psusi: yes - so they can charge you for every little bit of data that passes over their network
<bmonty> especially on a production network
<psusi> bmonty, for incoming connections sure... not for outgoing... users want to get where they want to go... trying to stop them is futile and annoying
<Yagisan> psusi: well - I block outgoing too actually
<psusi> Yagisan, which they could very well account for without pppoe
<bmonty> except when they are trying to use apps that have the potential to increase risk
<LaserJock> hmm, I can't even get nxsetup to work so maybe I have bigger issues
<Mez> why is packages.ubuntu.com lagging lately?
<ajmitch> Mez: because it's not run by canonical but it's a separate project?
<Mez> is it?
<Mez> oh
<LaserJock> Mez: at leasts it's better than packages.debian.org ;-)
<bmonty> anyone having issues using network configuration?
<psusi> time to test my custum dmraided flight 3 install cd... bbiab
<bmonty> yeah, p.d.o going down was upsetting to me this morning :(
<LaserJock> StevenK: so you have to wait for elmo to be able to upload?
* Yagisan wonders why people insult networking protocols with homophobic insults
<LaserJock> does it make sense to set up a tunnel for port 22 when ssh is running on port 22?
<bmonty> outbound traffic isn't on port 22
<LaserJock> bmonty: ? I'm not very good with networking
<bmonty> LaserJock: the purpose of the tunnel is to circumvent your network's firewall rules, right?
<LaserJock> no
<LaserJock> it's because I can't directly connect to my computer
<LaserJock> I have to connect to the departments server first
<bmonty> so you are creating tunnels for all the protocols you want to use?
<LaserJock> well, I'm trying to get FreeNX to work, which uses port 22
<bmonty> I don't know about FreeNX, but I'm assuming you can tell it to connect to a port other than 22?
<LaserJock> I was using VNC but now vnc can't be installed because of an unmet dep, so in the mean time I was trying to check out FreeNX but it is turning into a major project
<LaserJock> bmonty: well, in that case I might run into the firewall problem
<bmonty> so you want a tunnel from the department server to connect to your home machine on 22, and some other port on the department server to connect FreeNX to
<LaserJock> hmm, makes sense
<LaserJock> but I'm not sure why port 22 doesn't work
<LaserJock> but I think I also might have other problems with the setup
<bmonty> two guesses....one it is already being used by the ssh server and two you might not have enough privledge to open port 22
<LaserJock> I think I shoulda just built vnc4 from source ;-)
<psusi> blast....
* psusi needs to figure out how debian-installer's hardware detection works
<bmonty> LaserJock: you are using something like "ssh -R 32400:home-machine:22" ?
<LaserJock> not right now, no
<bmonty> if you used that command, you would tell FreeNX to connect to 32400 on the department server and it would be forwarded to port 22 on your home machine
<Yagisan> hmm - anyone tried installing ubuntu on a system with no floppy or cdrom, and no existing os ?
<bmonty> why not just install a cdrom?
<bmonty> they are <$40 for a DVD burner on newegg.com
<bmonty> with shipping
<psusi> Yagisan, so what IS availible? :)
<psusi> Yagisan, usb stick?
<minghua> Yagisan: netboot?  not sure ubuntu has that option though
<Yagisan> bmonty: because I can't find one - I need a box up and ruuning to help fix a problem, and it's getting built out of leftovers
<psusi> debian-installer appears to support netboot
<psusi> so ubuntu should too
* Yagisan will give it a shot
<psusi> Yagisan, plug the hard drive into a machine that already has ubuntu on it and install that way ;)
<minghua> you still need an FTP server to host your files and images though
<Yagisan> btw bmonty $40US is worth more then the whole pc at this point
<bmonty> Yagisan: well good luck
<Yagisan> thanks - this will be fun.
<Yagisan> now to grab a spare netcard out of the firewall - back later
<bmonty> anyone know of a python debugger that can provide command line arguments or connect to a running process?
<LaserJock> lol, I was able to kill my ssh server but I still can't get FreeNX to work. I can't even get it to setup correctly. I just doesn't like my ssh
<LaserJock> well, I'm going to try to get my install back to where it was and build vnc4 from scratch
<StevenK> Oh bugger. Now vnc4 doesn't build from source.
<minghua> why suddenly everybody is starting to play with vnc4?
<crimsun_> I'm gone til Tuesday, flying to Washington, D.C. for meetings
<pef> hello
<lifeless> opensync is now at the two week point
<lifeless> sigh
<Treenaks> two week point?
<lifeless> in NEW
<Treenaks> ah
<siretart> lifeless: upload 0.18-0ubuntu1 to ubuntu, and sync over later
<lifeless> siretart: I cannot upload to ubuntu.
<siretart> lifeless: I'll sponsor you happily :)
<lifeless> we're past UVF anyway
<siretart> but before FF
<lifeless> so I'm not panicing, just bitching...
<siretart> new packages are allowed before FF
<Mez> siretart: ping
<zakame> hi all
<siretart> Mez: pong
<siretart> hi zakame
<zakame> heya siretart :)
<Mez> siretart: er - your comment on the rar bug ?
<Mez> it was saying that the source was there?
<Mez> or asking for that to be fixed too ?
<siretart> Mez: just that the source is in debian/non-free
<Mez> not source ...
<Mez> they have binary packages in there
<Mez> rar doesnt distribute it's source
<Mez> it's just binary stuff built by rarlabs
<siretart> ah, sure
<Mez> anyways - it's fixed (and I seem to now be adopting the godamn thing!
<phanatic> hi people
<zakame> heya phanatic
<siretart> Mez: did you set yourself in the maintainer field? ;)
<Mez> siretart not in the ubuntu upload ;)
<Mez> though technically I should have
<Mez> 1) the package was changed specifically for ubuntu with the first update in nearly 2 years
<Mez> and 2 I'm adopting it
<phanatic> zakame: i updated the nanoweb package: http://revu.tauware.de/details.py?upid=1579
<Mez> though - well - I didnt know that till after I uploaded
<zakame> is it now recommended for MOTU-modified Debian packages to change the Maintainer field (sorry, not been into reading {d,u}-devel and -motu)
<zakame> ?
<zakame> phanatic: checking
<siretart> Mez: to avoid further discussion and confusion, just upload another one with you as maintainer
<siretart> zakame: we didn't agree on anything yet
<Mez> siretart: "further discussion and confusion"
<phanatic> zakame: thanks
<Mez> ??
<siretart> Mez: see the flamewars the last week
<Mez> siretart, I doubt that anyone will be watching what I'm doing lol
<siretart> Mez: if you care for it, just hijack it
<Mez> and there was nothing there
<zakame> ah
<Mez> siretart: I'm officially adopting it in debian ;)
<Mez> so no need to hijack
<siretart> Mez: oh. even better :)
<Mez> just wait for a sponsor ;)
<Mez> lol - because chris and I talked about it earlier :D lol - and well - shrugs*
<minghua> Mez: by all means hijack it
<siretart> zakame: there have been some packages, which we adopted in ubuntu. gajim comes to mind
<Mez> I'm taking it over case he hasnt got time
<minghua> Debian doesn't care about non-free packages anyway
<Mez> minghua: there no point in just uploading a hijack ;)
<siretart> zakame: in my opinion, we should use this possibility more often. but no, we didn't agree on that yet
<Mez> minghua: if i COULD hijacj t I would
<Mez> lol
<Mez> but - I need a sponsor
<Mez> once I'm a DD ... *shrugs* it'll be fine
<minghua> Mez: I mean hijack it on the ubuntu side
<minghua> don't leave the previous Debian maintainer's name in the Maintainer: field
<zakame> siretart: hmm, I haven't thought of it much really, but I'm inclined to agree with you
<Mez> minghua: lol ;)
* siretart lunch - cu
<zakame> pakain! :D
<zakame> er ECHAN
<sivang> Mez: going to be a DD?
<minghua> Mez: why not point the debian-mentors list to your ubuntu package?
<Mez> sivang, one day
<sivang> Mez: :)
<minghua> Mez: usually a RFS need to have packages ready anyway
<Mez> minghua: you mean point them to where I made the changes?
<Mez> minghua: ah well I'm jsut packaging it up atm lol - then gonna upload to mentors
<minghua> Mez: no, the source packages, diff.gz and stuff
<Mez> or my own server
<Mez> minghua: I'm packaging up the latest version of rar thats why
<minghua> Mez: but they are already uploaded to ubuntu, no?
<Mez> minghua: no thats really just a bugfix ;)
<minghua> oh I see.  then probably "Intent To Adopt" would be a more appropriate title ;-)
<Mez> not really ;)
<Gloubiboulga> hi
<raphink> hi Gloubiboulga
<Gloubiboulga> salut raphink :)
<raphink> a farte?
<raphink> lol
<Gloubiboulga> :D a farte
<Mez> minghua: I've like - hijacked it in ubuntu and hae a sponsor for debian ;)
<minghua> Mez: wow that's fast, good job
<phanatic> hi raphink
<phanatic> raphink: upstream released new version: http://revu.tauware.de/details.py?upid=1583
<Mez> minghua: lol - well I posted to the d-m list and someone offered
<raphink> yes I saw phanatic that's good
<phanatic> patch applied + license info included in source headers
<raphink> I'll throw an eye on it, but not right now
<raphink> there is about 600KB diff
<raphink> so I won't just advocate blindly
<raphink> :)
<phanatic> okay :)
<phanatic> upstream reworked the whole automake system
<phanatic> that's why the huge diff :)
<raphink> phanatic: then I'll test build again
<\sh> moins
* StevenK waves to \sh./
<StevenK> s/\\//
<StevenK> Er, s/\///
<Mez> moinmoin ;)
<Mez> lol
* StevenK wants a bug to fix so he try out his All-New Upload Privs.
<\sh> oh man i'm tired..
<\sh> this stupid gentoo update marathon is not finished yet
<StevenK> A bug to fix in universe, since I uploaded a package to main, and that didn't work so well.
<Yagisan> \sh: gentoo ?
<\sh> Yagisan: yo...
<\sh> 5 machines
<Yagisan> \sh: G'day. I've been so busy this week, I barely have time to get my work done, let alone any ubuntu stuff :(
* Yagisan build a pc out of spare parts and thrown away pc components today
<\sh> oh I will have a busy week from monday on...6 suse machines to administrate and taking care for :)
<StevenK> \sh: Well done! You're now job enabled?
<\sh> StevenK: well..not directly...the gentoo machines are for the guys, which are sponsoring my root server and some parts of my hardware
<Yagisan> It's a high speed pentium 2 233Mhz,  144MB RAM, 2GB HDD, Radeon 7500, and I *just* squeezed breezy it. funnily it runs rather well.
<\sh> StevenK: and the suse work is freelancing for 2 weeks...I have to see, if the boss of this company is giving me a long time employee contract, or a long time freelancer contract...
<\sh> s/which/who/
* StevenK needs to figure out how to speed up Breezy on his laptop.
<Yagisan> StevenK: speed up in what way ? and how old is the laptop ?
<StevenK> It just feels sluggish sometimes.
<StevenK> It's an X40, so not that old.
<Yagisan> StevenK: ok. On older boxes prelink helps with load times, otherwise not much other then making sure hdd dma is on, and adding ram really helps
<\sh> ok..need to go back to the gentoo machines
<siretart> hi folks
<foampeace> hi
<foampeace> who do i give a graphic to
<siretart> foampeace: try to ubuntu artwork team
<foampeace> ok thanks
<siretart> foampeace: or if it is for a specific package, create a malone bug and attach it there
<foampeace> malone bug?
<Mez> siretart: ping
<foampeace> whats the url?
<Kyral> Morning MOTU
<siretart> Mez: pong
<mxpxpod> what's up with mono in universe? mono-jit depends on mono-classlib-1.0-1.1.10, but mono-classlib-1.0-1.1.13.1 is installed
<torkel> mxpxpod: mine depends on 1.1.13.1
<mxpxpod> torkel: hmmm
<mxpxpod> torkel: what arch?
<torkel> i386
<mxpxpod> powerpc here
<phanatic> mono on ppc has some problems afaik. there was a discussion about this some days ago...
<mxpxpod> nice
<mxpxpod> ugh
<Mez> siretart: reping
<Mez> or even \sh_away ping
<siretart> Mez: Im not really here, but, what is it?
<Mez> siretart: would it be possible to use motu-tools to automate a check on stuff thats currently in backports but has a higher version in dapper?
<siretart> Mez: I think this shouldn't be hard with lucas' multidistro tools, but I didn't look further into it yet
<Mez> cool ;)
* Mez got the impression they were one and the same
<slomo> hmm, is the current gnome-panel in dapper crashing constantly for someone else too?
<siretart> hi slomo
<slomo> hi siretart
<siretart> slomo: do you know if siggi wants to upload the latest stable version or a recent cvs snapshot?
<slomo> siretart: no idea... he's not very verbose ;) but i didn't find any time to do anything this weekend with xine :(
<siretart> slomo: anyway, the changelog does look quite promosing, even now.
<siretart> I'm quite happy if all those bugs mentioned in the changelog get finally in debian
<slomo> yes... and i need to merge them all in our current two xine packages ;)
<siretart> slomo: perhaps we can script that?
<slomo> sure... but i don't know if it's worth the effort for two packages ;) currently i'm getting the diff between the debian versions and add the changes that apply to the packages
<siretart> ok
<Gloubiboulga> siretart, slomo, could have a look at http://revu.tauware.de/details.py?upid=1582 and tell me what you think about this package?
<siretart> sorry, not now, I'm not at home
<Gloubiboulga> siretart, np
<slomo> Gloubiboulga: i'll take a look in a few minutes :)
<Gloubiboulga> thanks slomo
<slomo> Gloubiboulga: any specific reason why you need debhelper >= 5.0.7 and not only 5?
<Gloubiboulga> slomo, not really
<Gloubiboulga> it's just because we have 5.0.7 in dapper
<slomo> Gloubiboulga: ok, just stay with 5 :)
<Gloubiboulga> ok :)
<slomo> why do you call the library libswitch0.3.1?
<Gloubiboulga> slomo, because of the soname... just have a look at the prvious comments
<slomo> ok, will do ;)
<Gloubiboulga> hub and sistpoty disagree about that...
<slomo> and i would copy the libswitch description (long and short) to the libswitch-dev package and add "(development files)" to the short one and add what you have now to the long one...
<Gloubiboulga> ok
<slomo> in rules there is much stuff from dh_make
<slomo> remove everything not needed please :)
<Gloubiboulga> I will :)
<slomo> and you have a arch all package... please add some stuff to the binary-indep rule
<slomo> err wait...
<slomo> is netswitch really arch all? imho it should be any as it's arch specific
<Gloubiboulga> it's a script which calls gswitch | kswitch
<ajmitch> morning
<Gloubiboulga> hi ajmitch
<slomo> Gloubiboulga: oh wait... yes... sorry :/ but then please add needed stuff to binary-indep :)
<slomo> hi ajmitch
<Gloubiboulga> slomo, ok
<slomo> Gloubiboulga: hmm, but shouldn't the netswitch package should depend on gswitch | kswitch then?
<slomo> damn panel...
<Gloubiboulga> slomo, upstream recommends to run gswitch, but netswitch doesn't depend on it
<Gloubiboulga> that's why i didn't add {g,k}switch to Depends line
<Amaranth> please don't do what apt-file did
<Amaranth> apt-file can use curl or wget but installs neither as it wants to let you choose
<slomo> Gloubiboulga: ok... /me compiles now :)
<Gloubiboulga> slomo, libswitch0.3.1 is ok, or should i change the package name?
<slomo> Gloubiboulga: ok, the soname is really broken imho... but could work when they really mean it like it is now... libswitch0 would be the correct thing then... but better teach them about soname :)
<Gloubiboulga> damn soname ;)
<slomo> but hub was right... it's only that they seem to use the package's version instead of something correct...
<Gloubiboulga> I'll talk with the author about this
<slomo> Gloubiboulga: the packaging is ok except the few points i noted above... but i won't vote for it until the soname issue is solved
<Gloubiboulga> slomo, ok, thanks for the review !
<slomo> Gloubiboulga: np :)
<Gloubiboulga> hello mrfreeze
<mrfreeze> salut gloubi
<Gloubiboulga> slomo, mrfreeze is the author of libswitch
<mrfreeze> Hello slomo
<slomo> hi mrfreeze
<mrfreeze> so gloubi told me there was a problem ?
<mrfreeze> with the soname
<slomo> yes... you shouldn't use the version number... as long as the number directly behind the .so stays the same programs expect your library ABI compatible... i.e. in your case programs expect to be runnable with 0.0.1 and 0.9.9 without recompilation
<mrfreeze> yes but that's false :)
<mrfreeze> in fact 0.3 and 0.4 are uncompatible
<ajmitch> do you really break backwards compatibility with each & every release?
<mrfreeze> not necessarily, but sometimes
<mrfreeze> do you want I change the version and add another number ?
<slomo> ajmitch: can you explain it to him? i only know the notation of libtool with current/revision/age but don't know how this computes to the number used in the filename...
<mrfreeze> in fact for the moment, I some times change some structures
<slomo> mrfreeze: at least you should use .so.1* for 0.4 then when it breaks binary compatibility
<ajmitch> slomo: sorry, I've got to run down to LCA & help out
<ajmitch> conference is starting today
* ajmitch will try & get on irc from there :)
<mrfreeze> slomo, but that's ugly
<slomo> mrfreeze: why?
<mrfreeze> well 0.4 is 1 ?
<mrfreeze> that doesn't mean anything then
<slomo> that number has nothing to do with the actual version of your library
<slomo> yes
<mrfreeze> what a strange thing
<slomo> it's only to keep track of binary compatibility
<mrfreeze> well ... i don't believe in binary compatibility :)
<mrfreeze> ok, I will change the soname to make this .... but tht's strange
<slomo> so you want us to rebuild every program using your library against the latest version of your library? ;)
<mrfreeze> that's what I do :)
<mrfreeze> So I just change the soname parameter, and your package will always work ?
<mrfreeze> but how must the application be configured to connect to the right lib ?
<slomo> no... but it would be much easier for us to garantuee stability of programs using your library as we know when we need to recompile... and we could keep different versions of your library at the same time so nothing will ever break...
<mrfreeze> well if you want :)
<slomo> that's not your job but ld's ;) it will simply use the version with the soname it is compiled against... i.e. *.so.0 in the current version
<mrfreeze> ok hope it will work ;)
<slomo> mrfreeze: why don't you use autotools and libtool btw?
<mrfreeze> I prefer to understand my makefile
<mrfreeze> and I don't know how to generate it in fact (the autotool for the application was generated by glade)
<slomo> for simple stuff (as in simple to build) like your application you will find millions of tutorials out there :)
<mrfreeze> yes but source compatibility was enough for me :)
<mrfreeze> and know ... I don't know if I will loose something
<mrfreeze> btw how autotool and libtool would know the library isn't compatible ?
<slomo> it wouldn't... but for libtool you have 3 easy values to fill in and it keeps care of everything else for the filename...
<mrfreeze> slomo, as I do the job of libtool for the moment, I create my so.0.3.1, a link so.0 -> so.0.3.1 and a link .so > .so.0 that's it ?
<mrfreeze> slomo, I will switch to autotool and libtool during the week
<slomo> mrfreeze: yes, but libtool will do more things... for example create this .la files you probably saw already... or create a static version of your library, etc...
<mrfreeze> yes but I don't need that
<mrfreeze> I just want dynamic lib
<slomo> you don't need that... right ;) but maybe other people want it for whatever reason
<slomo> well, and using autotools/libtool will make it easier for your application to be used on other architectures
<slomo> for example solaris doesn't use .so for shared libraries iirc
<mrfreeze> thank you slomo, I repack, and 0.4 will use libtool
<slomo> mrfreeze: no problem :) for a good example take a look at libnotify...
<slomo> mrfreeze: if you want i could take a look at it before you release 0.4
<mrfreeze> slomo, lol, yes but I can't find the tarball
<slomo> for libnotify?
<slomo> http://www.galago-project.org/files/releases/source/libnotify/libnotify-0.3.0.tar.gz
<mrfreeze> thanks
<cyberix> Fuddl: Online?
<Fuddl> cyberix: yepp, right here
<cyberix> Fuddl: Did my private messages reach you?
<Fuddl> cyberix: private message???
<cyberix> Ok. So blocked by spam protection
<cyberix> 21:54 <cyberix> I retrieved the Loki Quake III Arena cd-rom
<cyberix> 21:54 <cyberix> cyberix@bunnypump:/media/cdrom1$ find |grep pak
<cyberix> 21:54 <cyberix> ./baseq3/pak0.pk3
* ajmitch returns
<Fuddl> wb ajmitch
<Fuddl> cyberix: spam? uuuuh... i don't filter spam, and i set gmx to not filter it... but, thx for that path!
<cyberix> Fuddl: freenode filtters
* ajmitch waves to Lathiat 
<cyberix> 21:53 [freenode]  -!- Private messages from unregistered users are currently blocked due to spam problems, but you can always message a staffer. Please register! ( http://freenode.net/faq.shtml#privmsg )
<Fuddl> ah, i c
<cyberix> Fuddl: Is there something else you need to know?
<cyberix> icon ?
<Fuddl> cyberix: nope, it's just that one pk3 file that's copied from cd rom
<cyberix> ok
<cyberix> Fuddl: quake3 package will be in dapper universe?
<Fuddl> cyberix: is that icon a special one? quake3 source come with an icon, but for gnome's eye-candy something more fancy would be nice ;)
<Fuddl> cyberix: i don't know, yet. i'm waiting for it to apper on the launchpad
<Hieronymus> cyberix: not universe
<cyberix> Hieronymus: Why not?
<cyberix> Hieronymus: The contents of the package are free software, even if the stuff installed from cd-rom are not.
<Fuddl> cyberix: oh, one thing you could do for me. what's that md5sum of that file?
<Hieronymus> cyberix: so a free software program which fetches non-free programs from the net or cd-rom should be in universe?
<cyberix> Hieronymus: Is this not equal to e.g. a cd-player?
<cyberix> Hieronymus: quake3-data could be in multiverse
<cyberix> Fuddl: computing...
<Hieronymus> cyberix: but quake3 Depends: on quake3-data
<cyberix> Hieronymus: :-/
<cyberix> There is not a project making use of the engine without the original data-files?
<cyberix> (a free software one)
<Fuddl> i don't know of one...
<Fuddl> neither does upstream
<cyberix> quake III rally, but it is uncomplete and a dead project
<cyberix> And I'm not sure if mods run without the original game
<cyberix> http://www.quakerally.com/
<Hieronymus> there's OpenArena
<cyberix> Fuddl: .
<cyberix> cyberix@bunnypump:/media/cdrom1/baseq3$ md5sum pak0.pk3
<cyberix> 1197ca3df1e65f3c380f8abc10ca43bf  pak0.pk3
<Fuddl> Hieronymus: url? gimme! gimme! gimme! :)
<Fuddl> cyberix: thx
<Fuddl> phuuu, thank god, the files are the same
<cyberix> http://en.wikipedia.org/wiki/OpenArena
<Fuddl> mmmmh.... openarena indeed looks interesting
<Hieronymus> Fuddl: it's playable, but it needs work
<Fuddl> cyberix: good news. i created a "fake loki q3 iso" and used that iso as source medium
<Fuddl> and i even didn't break support for the original cd ;)
<spacey> if you want to play q3 you should check out the icculus.org sourcetree
<spacey> its nice
<Fuddl> spacey: they're my upstream guys - and i've never seen a mailinglist that's more fun than their q3 ml!!!
<Fuddl> cyberix: do you know how many different "flavours" of quake3 cds exist? "the" q3 cd, the loki cd, the xyz cd?
<mdke> anyone around who can give me a quick tip on how to build a package?
<mdke> i downloaded the yelp source and have made some small changes to one file, now I'd like to test the package
<mdke> actually, nm
<mdke> i'll just install the file directly, it doesn't need building
<mdke> if anyone wants to fix the easiest bug in the world ever, check out https://launchpad.net/distros/ubuntu/+source/xine-ui/+bug/6099
<Ubugtu> Malone bug 6099: "xine has a poor entry in the Menu" Fix req. for: xine-ui (Ubuntu), Severity: Normal, Assigned to: MOTU Media Team, Status: Unconfirmed
<mdke> I've posted the fix to the bug, someone please commit it!
<moyogo> hi
#ubuntu-motu 2006-01-28
<chx> hi. I am not sure this is the right channel, sorry if not. WHere can I find a 1.0-8xxx nvidia-glx for Breezy?
<raphink> shouldn't https://launchpad.net/distros/ubuntu/+source/xine-ui/+bug/6099 use a patch to correct this instead of modifying the source?
<Ubugtu> Malone bug 6099: "xine has a poor entry in the Menu" Fix req. for: xine-ui (Ubuntu), Severity: Normal, Assigned to: MOTU Reviewers Team, Status: Fix Committed
<azeem> raphink: the xine-ui package doesn't use a patch system, so I think it is fine to not move it over to one when adding another change
<raphink> oh ic
<raphink> good point
<raphink> first bug fix for me as a MOTU
<raphink> if I want to commit this change, I guess I should get the source package for xine-ui, then apply the patch, run debuild with my key and upload the source package again
<raphink> right?
<azeem> and document the changes in the changelog
<raphink> azeem: well the patch documents the changes already
<raphink> so applying the patch will document changelog
<azeem> ah, ok
<raphink> :)
<raphink> hub: k9copy failed to build some time ago, because of the xlib issue. Since you uploaded it, maybe you could request a rebuild.
<raphink> Kyral: did you get anything from Katie (if you're whitelisted)
<raphink> I uploaded gtkedit two days ago but it's not in dapper-changes yet
<raphink> well it's NEW so I guess it takes more time
<Kyral> "whitelisted"?
<Kyral> yah I got gtkedit_0.1-0ubuntu1_source.changes is NEW from Katie yesterday
<raphink> ok good
<raphink> :)
* Kyral still doesn't understand "whitelisted"
<raphink> whitelisted means Katie sends you message
<Kyral> ah lol
<raphink> you are in the list of people who receive messages from Katie
<Kyral> yah
<LaserJock_away> and then you ask, "who's katie?" ;-)
<Kyral> I know who Katie is ;P
<Kyral> or what as it may be
<raphink> hehe
<raphink> anyone could throw an eye on http://revu.tauware.de/details.py?upid=1591 and maybe upload it again?
<Kyral> yo Corey
<raphink> wb Burgundavia
<Kyral> by.. lol
<raphink> lol
<hub> raphink: how do I request a rebuild? and where do I check the build state?
<hub> raphink: I haven't found anything in the wiki :-/
<raphink> you check the build state on http://people.ubuntu.com/~lamont/buildLogs/
<raphink> and you request a rebuild by pinging elmo imo
<Kyral> Hmm, anyone know about the status of Xen in Dapper?
<raphink> no idea
<Burgundavia_> Kyral, someone integrated into the old kernel for breezy, but that was out of band
<Burgundavia_> Kyral, currently waiting on either developer resources or integration into the mainline kernel. Never going to happen for dapper
<Kyral> Yah the guy who did that graduated from Clarkson last year
<Kyral> we still have his devel machine in the COSI ;P
<Burgundavia_> he was a google CoC student that got dropped by google but then showed up on the last day and produced his results
<Burgundavia_> unknown if he got paid
<Kyral> Yah
<Kyral> Ed Despard
* Burgundavia_ considers google coc to have failed for Ubuntu
<Kyral> ouch
<Kyral> I
<Kyral> am playing with the idea of a Yast like thing for Ubuntu (NOT Yast4Debian)
<Burgundavia_> I think the Ubuntu devs are simply too busy to be able to effectively mentor people
<ajmitch> Burgundavia_: you mean SoC?
<Burgundavia_> Kyral, better work would be to work with the upstream gnome guys. See http://live.gnome.org/PreferencesRevisited
<Burgundavia_> ajmitch, yes
<Burgundavia_> s/coc/soc
<Kyral> Burgundavia_: I don't mean it limited to GNOME
<Kyral> I mean like a universal control panle
<hub> raphink: ok
<Burgundavia_> Kyral, system tools backends in desktop neutral
<Kyral> one that will work just as well in Flux as it would in GNOME ;P
<hub> raphink: mail or bug?
<Burgundavia_> Kyral, you might also want to look at guidance
<Kyral> Link?
<raphink> hub: mail I suppose
<Burgundavia_> http://www.simonzone.com/software/guidance/
<Burgundavia_> the thing with s-t-b is that they are written in perl, which is not a preferring language for gnome or ubuntu
<Kyral> Burgundavia_: its based on KDE it said
<Burgundavia_> Kyral, guidance is, but it written in python and I understand it has a fairly good seperation between backend and frontend
<Kyral> yah..maybe I should have clearified my intent
<Kyral> we have a good Sysadmin controls right now
<Kyral> but like extras
<Kyral> like setting up and monitoring HTTP servers, Xen, etc
<Burgundavia_> then I would look at system-config stuff
<Burgundavia_> the problem with all these preferences tools is that they are all written in different languages and for different projects without sufficent backend/frontend seperation
<Kyral> Like I was playing with SuSE in a VM yesterday
<Burgundavia_> so there is no single set of tools to do the job
<Kyral> and I was quite impressed with all the Server options there are there
<Kyral> like setting up a LAMP only took like 3 minutes
<hub> raphink: mailed elmo
<Kyral> I dunno
<raphink> hub: cool :)
<Kyral> its just a project idea right now
<Kyral> but it would be nice...
<Kyral> Written in PyGTK of course
<hub> why off course?
<Kyral> okay...
<Kyral> PyQt?
<hub> Py?
<Kyral> Python
<hub> yeah
<Kyral> yah?
<Burgundavia_> Kyral, The KDE project's policy of leaving operating system specific software such as administration and configuration tools up to distributors to handle has not worked. The distributions have failed to produce a good working set of tools. Instead we've seen proprietry tools, non-KDE tools and often just plain poorly designed and implemented tools. <-- substitute GNOME in there and you see what I feel
<Kyral> Burgundavia_: thats what I mean
<Kyral> I mean this tool would rely on Apt...
<Kyral> but If I do it right it wouldn't be hard to swap in Yum for Apt
<Burgundavia_> Kyral, make it as desktop agnostic as possible
<Kyral> "desktop adnostic"?
<Burgundavia_> seperate out the backend and frontend
* Kyral blinks
<Burgundavia_> and make the backend package management agnostic
<Burgundavia_> much like Ubuntu express
<Kyral> Which I still need to play with lol
<Burgundavia_> not ready yet
<Burgundavia_> post dev sprint at earliest
<Kyral> Yah I mean during install I could have it look at the system to determine which type its running on
<Kyral> I'd prolly write a module to handle it so the rest of the program doesn't care
<hub> Burgundavia_: proprietary tools? I know only one distro that do that in KDE
<hub> Burgundavia_: the rest is Free Software
<Kyral> Like if Yum is detected, load the Yum tools into the program, if Apt-Get etc etc
<Kyral> This would be a big project lol
<Kyral> If I pulled it off right...would it be big?
<Burgundavia_> hub, the fragmentation is as bad as it being non-free
<Kyral> GRCC
<hub> Burgundavia_: you are preaching the choir
<Kyral> Grand Unified Control Center :D
<Burgundavia_> hub, yes
* Kyral starts work on the project...
<Kyral> by learning Python lol
<hub> Burgundavia_: for the proprietary thing, my employer does it
<hub> Burgundavia_: and at one point that annoys me
<Burgundavia_> hub, indeed, so does mine
<raphink> hub: isn't your employer Xandros?
<Kyral> lol
<hub> raphink: yep. and they write network configuration tools for their desktop env which is KDE
<raphink> and that are proprietary
<Burgundavia_> a mine writes tools in GTK for setting up multiseat sytesms
<raphink> who do you work for Burgundavia_ ?
<Burgundavia_> Userful
<raphink> ...
<hub> raphink: yep
<raphink> anyway
<raphink> time to go to bed really
<raphink> I was just waiting for a build and it's done now :)
<raphink> so later guys ;)
<Burgundavia_> "hardware comes found and shaped in automatic rifle" <-- I love google translate
<raphink> lol
<raphink> ciao
<Burgundavia_> it is translated italian talking about automatic hardware detection in Ubuntu/Ufficio Zero
* Kyral wonders how hard it would be to get Xen in Dapper...
<hub> Kyral: need kernel support
<Kyral> hub: Not afraid to patch my own kernel ;P
<Kyral> Should be interesting if I can get it working :D
<Lathiat> tseng:ping
<Kyral> oh Lathiat you pinged me a couple days ago?
<Lathiat> ~>
<Lathiat> i did ?
<Lathiat> if i did i dont know what about :)
* psusi wishes he could ping someone and get an answer back so far in the future that it comes before the ping
<thierry_> any MOTU that could review my package?
<thierry_> slomo , slomo_ : JohnnyMast told me you could review my package
<thierry_> url is http://revu.tauware.de/details.py?upid=1589
<Kyral> Whee! Xen kernel compiling
<Kyral> wb LJ </late>
<bddebian> Heya gang
<ajmitch>  hi
<Kyral> hey bddebian
<bddebian> Whassup gents?
* ajmitch is listening to debian vs ubuntu panel talk/debate at LCA ;)
<bddebian> Heh
* Kyral is compiling the Xen Kernel
* crimsun is setting his alarm clock
* psusi is trying to figure out WTF hal-set-property is being a jackass when called from a hal callout script and saying "error: libhal_ctx_init: (null): (null)
<Kyral> mmm...Xen
* bddebian is still being a LOSER
<Kyral> lol
<Kyral> I will be quite pleased with myself if I can get Xen running on Dapper
<Kyral> even moreso if I can get Debian running on Domain 1
<psusi> what component pops up the force quit dialog box?
<LaserJock> bddebian: hi!
<bddebian> Heya LaserJock
<phlaegel> so does UVF mean no new packages can go in?
<crimsun> no, it means no new upstream versions of existing packages in the repo
<phlaegel> ok
<crimsun> new packages can go in up til FF
<phlaegel> so mod_dnssd could still go in...
<Yagisan> G'day all
<Yagisan> dumb question. As there is no Breaks: field in debian/control can I emulate it with a conflicts ?
<minghua> a question better for #ubuntu-devel or #debian-devel, I am afraid
<Kyral> Got it working...
<hub> Yagisan: Conflicts
<bddebian> Kyral: Contrats
<Kyral> too bad that Xen requires the 2.6.12 kernel
<Yagisan> ok - thanks guys.
<mr-russ> how does apt work out which package is more up to date from two different repositories?
<mr-russ> is it just the version number?
<crimsun> the version number is taken primarily, but pinning has an effect, too
<Yagisan> mr-russ: TTBOMK yes, the version number - unless you do apt-pinning
<mr-russ> hmm..  apt-cache show, shows the wrong version, but apt-get installs the updated one ?
* mr-russ will have to do a little more work.
<mr-russ> so much to learn so fast.
<crimsun> use apt-cache policy
<crimsun> then you'll see which ones are available to apt
* crimsun heads to bed, 'night all
<bddebian> Later crimsun
<crimsun> night bddebian :)
<dcode> can somebody check their grub menu.lst for me and tell me something?
<dcode> wrong channel
<dcode> sorry] 
<dcode> :-(
<psusi> so.... anyone know what happened to the perty new logout/shutdown dialog that was in dapper?  it went away..
<SEJeff> psusi, unfortunately, I think it was something upstream
<psusi> hrm... I want the other one back ;)
<SEJeff> psusi: ditto :)
<minghua> I like the current one better
<psusi> the one with the timeout and the silly switch, or the one with the nice icons?
<minghua> the icons on the previous one just make me wince
<psusi> really?  I thought they were perty
<minghua> I like the one with "silly switch"
<minghua> although I can't say I like the switch icon much
<psusi> it felt more intuitive... was quicker/easier to shutdown/suspend/hibernate/reboot
<minghua> I like the design, I just hate the icons
<LaserJock> ajmitch: did your zope syncs go through?
<SEJeff> minghua, well theming is fairly trivial to change normally
<minghua> SEJeff: I am not against the old dialog, I am jest expressing my personal preference
<minghua> SEJeff: although if dapper releases with those icons I probably will try to figure out how to change the theme
<SEJeff> minghua, to each his own
<Burgundavia_> minghua, I agree with you that the icons don't match the current style of the rest of the desktop
<minghua> SEJeff: yes indeed
<minghua> Burgundavia_: glad to see I am not alone here :-)
<psusi> I suppose I like the layout more than the icons themselves
<psusi> and yea, I can see how they don't mesh quite so well with the rest of the desktop... but they still look nice ;)
<LaserJock> I'll take anything that lets me log out. ;-)
* psusi wishes he could find decent info on reiser4... the mailing list is nothing but spam
<Yagisan> psusi: why reiser4 ?
<psusi> because I really like what I read on their web page
<psusi> both about the on disk filesystem design, and the semantics... everything is a file
<psusi> wondering logs.... all very interesting stuff
<\sh> if reiserfs 4 is at least so slow like reiserfs3 then forget about it...xfs is much faster and handling of the journals is much nicer...
<psusi> plus... I just might be able to get it to organize files needed for boot so they are sequentially stored at the start of the disk so readahead-list can suck them up fast ;)
<psusi> based on the reiser 4 page, reiser 3 is shit in comparison
<Yagisan> \me prefers jfs
* Yagisan prefeers jfs
* psusi has only ever used ext2/3 and reiser3
* Yagisan can't type to save his life today
<LaserJock> \sh: I think ReiserFS4 is quite a bit faster than ReiserFS3 but the fs choice is like gnome vs. kde, or emacs vs. vim
<Yagisan> I saw benchmarks that showed reserfs4 was a regression in speed - let me see if I can find it
<psusi> not really... speed is not subjective ;)
<\sh> LaserJock: I have reiserfs3 on partition and xfs on another (same disk connected via usb)
<\sh> LaserJock: mounting the reiser parition (80GB) let me wait at least 4-5 seconds, while mounting xfs partion let me wait less then 1 second
<\sh> on both partitions I have more then 10000 files
<\sh> partition even (I hate monday mornings)
<psusi> \sh, that's because the current kernel reiser3 code reads in the whole free block bitmap on mount... there's a patch pending on the lkml right now to fix that so it only loads it on demand
<LaserJock> psusi: speed is subjective to some degree because people want speed in different areas and it depends on the benchmark
* hub is conservative
* hub use ext3 only
<psusi> LaserJock, yea... but when it's faster on all the benchmarks, it's hard to argue ;)
<Yagisan> psusi: but it's not
<LaserJock> psusi: i've seen other benchmarks that say it's not
<psusi> imho, the design of ext2/3 isn't much better than fat
<Yagisan> psusi: for me resier4 is like attaching a boat anchor to a car
<\sh> psusi: right..but another (in my eyes) advantage is, that I don't need to handle fscks anymore with xfs :) it just works :)
<Burgundavia_> I figure there is a good that reiser4 is not in the mainline kernel and why it is a not the default fs
<psusi> \sh, you don't fsck with ext3 or reiser3 either
<LaserJock> my point is that I can (and have in the past) found benchmarks/data that convince me that Reiser4, ext3, or xfs are the best
<psusi> Burgundavia_, the reason is poletics.... Hanz Reiser seems to not get along very well with the other kernel people
<LaserJock> but I'm not really that into it so I just use ext3
<\sh> psusi: i have to manually fix sometimes the reiser3 partition when I just turn off the computer because of some foo with crashing kernels :)
<\sh> psusi: while it was reading or writing something on this partition...
<psusi> \sh, you shouldn't have to... my machine crashes all the time and I never fsck ;)
<\sh> psusi: well, if I don't do, I see many read errors and other funny messages from reiserfs
<psusi> strange....
<\sh> psusi: after fscking it everything is back to normal
<LaserJock> again, I've seen where people have had lots of data corruption with reiser but not ext3 and vice versa
<SEJeff> http://linuxgazette.net/102/piszcz.html reiser4 is pretty crap according to these benchmarks
<psusi> that shouldn't happen since it's journaled
<psusi> oh no
<SEJeff> psusi, thats bs. We used bonnie++ to stress test reiserfs (on SLES9) and ext3. We consistently saw problems with the reiser volumes and nothing much more than a hiccup with the ext3 one
<\sh> psusi: but the best thing happend to an old customer of mine...he had everything running on reiserfs (it was a suse distro) and suddenly his important db drive was crashing
<psusi> today's dapper updates broken xchat's url opening ability
<Yagisan> SEJeff: thanks - that's the link I was looking for
<LaserJock> SEJeff: Reiser 3 or 4?
<\sh> psusi: he tried to get the data from this drive (because he was a hard man and didn't have any backups) via ontrack rescue services
<SEJeff> Yagisan, I found that very interesting when it first came out. I even used it + the results of our internal benchmarking to see that reiser is pretty much crap for our environment
<\sh> psusi: ontrack told him, they don't know how to rescue reiserfs data, because it's not a standard :)
<SEJeff> SLES is reiser3
<psusi> SEJeff, it _shouldn't_ have problems because it is journaled... also, I've read that bonnie++ is a completely unrealistic benchmark
<\sh> psusi: that was 2002
<LaserJock> SEJeff: I think Reiser4 fares much better in most benchmarks than Reiser3
<Yagisan> SEJeff: yeah, the only system I use that has reiser(3) on it is my www server, as it was the only system I benchmarked that performed better with it
<psusi> \sh, supposedly that long ago it did have a few bugs that ended up getting fixed...
* psusi shrugs
<SEJeff> LaserJock, actually I think that might be the wrong link. I saw one earlier that had reiser4 and showed reiser4 was horrible
<psusi> btw, "it's not standard" is a cop out bullshit excuse of an answer
* SEJeff looks around more
<Yagisan> SEJeff: it was a tossup between XFS or JFS for everything else, and I chose JFS as it was just a bit quicker
<SEJeff> psusi, bonnie++ is made to stress the harddrive and nothing else. That is an EXCELLENT benchmark for a database server
<psusi> it's like ISPs who tell you they don't support Linux and refuse to do anything else when you call and tell them their DNS servers are fucked up
<psusi> heh
<SEJeff> Yagisan, yes
<Yagisan> http://linuxgazette.net/122/TWDT.html#piszcz
<Yagisan> ^^^ right link
<SEJeff> Yagisan, yes, that is the correct one. I just didn't look at the date
<LaserJock> I've seen benchmarks that showed the ext3 (or xfs) was best and some that say Resier4 is better but I don't think I've seen any that said Reiser3 was best
<psusi> SEJeff, I believe I read somewhere that the usage patterns it tests aren't even very close to how a normal db behaves
<SEJeff> psusi, Well I was in charge of running tests. And this included oracle stress testing. Reiser sucks, I am saying so from my personal experience
<psusi> SEJeff, 3 or 4?
<SEJeff> psusi, 3. reiser4 is not in SLES
<SEJeff> and reiser4 is not stable
<Yagisan> ++
<psusi> btw... I don't trust anything with the word "oracle" in it any further than I can throw it.... I got to mess with oracle for a while in a rdbms class in college and man it was a pile of shit
<Yagisan> psusi: the best filesystem for you, depends on what you do with it
<SEJeff> psusi, take a look at the link Yagisan gave and notice that the benchmarks show reiser4 getting beat by ext3 in the large majority of them
<psusi> had such utterly retarded bugs in it... like if you fed it a text file to import into a table that did not end with a newline, it crashed.... pffft
<psusi> SEJeff, aye... for some things reiser3 can be slower than ext3... reiser4 apparently is a lot different
<SEJeff> psusi, well weblogic and oracle are our standard at work. I dont have a say in that I'm just a lowly admin
<SEJeff> psusi, look at that link and you will eat your words :) reiser4 is hype from Hans Reiser
<LaserJock> SEJeff: I agree that Reiser3 is probably not going win any contests but I think that Reiser4 will be really good. I personally use ext3 since it is standard and I don't do anything where it would really matter
<psusi> SEJeff, the design sounds very promising
<Yagisan> psusi: yes, but the implementation isn't as good as the hype - can you say "longhorn" - because that's what it reminds me of
<SEJeff> psusi, I'm *really* not trying to flame you... the design of minix is very promising. A microkernel is far superior to a monolithic one in theory. In implementation, linux wins and it is not microkernel based
<psusi> certainly much better than ext2/3... which don't even use extents for allocations... still uses direct and indirect block pointers... that's nearly as bad as fat
* SEJeff agrees with Yagisan again
<psusi> microkernels never were superior in theory for performance ;)
<LaserJock> I've heard that a properly tuned ext3 is the best FS but I haven't bothered to try it
<SEJeff> psusi, There is 1 and ONLY 1 case that reiser is better than ext*
<Yagisan> psusi: if it is a win for you, go for it
<SEJeff> LaserJock, with dir_index enabled, it is very fast
<Yagisan> psusi: but make your own benchmarks first, based on your usuage
<SEJeff> reiser is very nice in that you can resize it online as in without unmounting it. If you use lvm, that will be great for you
<psusi> Yagisan, aye....
<SEJeff> Actually I am again wrong. reiser allocates free space much better than any other filesystem out there so you can squeeze more out of your storage if you have many small files
<Yagisan> SEJeff: which is why it is on my www server
<psusi> very good for Maildirs ;)
<LaserJock> anyway, that's why I say it is like gnome vs. kde or emacs vs. vim . You really have to find out which is best for you
<SEJeff> agreed
<psusi> in any case, ext3 is the worst ;)
<LaserJock> not necessarily
<Yagisan> in my experience ext3 and jfs both work well for the filesystem pbuilder does it's work (I actually have a seperate partition for that)
<psusi> wow
<Yagisan> I tried xfs but it was a but slower in unpacking the tarballs on a multiple pbuilder tun
<Yagisan> s/but/bit
<psusi> for that kind of thing I would use ext2 instead of ext3... don't really need a journal just for pbuilder and it slows things down
<psusi> btw Yagisan, you ever play with that defrag package? ;)
<SEJeff> psusi, well if you ever want to try out ext3, enable the dir_index option and it is much faster. tune2fs -O dir_index /dev/hdax
<Yagisan> psusi: yes - it doesn't work on jfs ;)
<psusi> SEJeff, much faster if you are creating 1000+ files in a directory... not otherwise, right?
<psusi> Yagisan, on your pbuilder partition silly ;)
<Yagisan> psusi: my pbuilder partition is on a raid5 array, a journal won't slow it down much
<Yagisan> psusi: I ended up with jfs for pbuilder
<psusi> ahh
<psusi> thought you said it was ext3
<psusi> and damnit this guy's graphs are retardedly unreadable
<SEJeff> psusi, Well it makes it faster to access dirs with lots of files. think /usr/* and /var/*
<Yagisan> psusi: I benched both ext3, jfs, and xfs for it. jfs won
<Yagisan> s/both/each
<psusi> SEJeff, I don't think anything in either of those has more than 100 or so?
<SEJeff> psusi, I actually enabled dir_index today on my parents computer. I did hdparm -T before and after. Before 107.9MB/s after 174.8MB/s
<SEJeff> psusi, I read it on ubuntuforums a few days ago
<psusi> SEJeff, Ummm... hdparm doesn't go through the filesystem
<psusi> it accesses the block device directly
<SEJeff> psusi, well why would there be that big of a difference before and after?
<psusi> caching is my guess... turn it back off and see if it goes down
<Yagisan> SEJeff: -T is cache
<psusi> thought so...
<Yagisan> SEJeff: -t is disk
<psusi> use -t
<Yagisan> SEJeff: my system -T -> Timing cached reads:   1676 MB in  2.00 seconds = 836.45 MB/sec
<SEJeff> that was on my parents old old system
<Yagisan> SEJeff: and -t -> Timing buffered disk reads:  174 MB in  3.02 seconds =  57.61 MB/sec
<SEJeff> ok thanks.
<ajmitch> Yagisan: far faster than mine
<psusi> I modified dd to use aio with the O_DIRECT option... gets like 20-30% better throughput with less than half the cpu of hdparm -t
<LaserJock> btw, has anybody got some good resources on using the emacs modes for debian stuff? I'm not very familiar with emacs so I'm not sure how to use the stuff in devscript-el and debian-el for instance :(
<Yagisan> ajmitch: I'm not satisfied I need more speed
<ajmitch> Yagisan: I could probably get more speed by using the ide controller card on the shelf
<ajmitch> ATA133
<Yagisan> ajmitch: that is 1x ATA 100 + 2x SATA 150
<Yagisan> ajmitch: I have 2 x ATA133 ports empty, but need dappers kernel to use them
<psusi> hdparm -t only gets 63 MB/s on my raid-0.... my modified dd gets 98
<\sh> hey ajmitch
<ajmitch> hey \sh, what's up?
<psusi> 2x 10,000 rpm sata
<\sh> ajmitch: how's life
<ajmitch> it's alright, LCA has started
<Yagisan> psusi: 3 x 7200rpm seagates here
<ajmitch> been at the debian miniconf today :)
<ajmitch> met up wiht lathiat
* Yagisan wished he could go
<psusi> I've heard bad things about seagate's ide drives... I've only ever used their scsi products
<ajmitch> I might not have much packaging time this week, and the network is a bit broken there still
<\sh> ajmitch: jdub should be attending as well, right?
<ajmitch> \sh: yes, he was on the panel of debian & ubuntu discussion :)
<ajmitch> and mjg59 is there, he took a look at my laptop :)
<psusi> had one blow up... first generation 10,000 rpm drive... was a refurb though... the original one is still running today
<\sh> ajmitch: oh...no fights?
<\sh> ajmitch: no boxing no bloody noses?
<ajmitch> almost
<ajmitch> some strong words, anyway
<LaserJock> really? that's sad
<\sh> .oO(hope nobody mentioned my name)
<ajmitch> \sh: they did :)
<psusi> I think I got that thing in 2000? damn...
<\sh> WOOT?
<psusi> no... must have been 2001
<\sh> wtf?
<ajmitch> LaserJock: the strong words were more about time-based releases vs 'when its ready'
<Yagisan> psusi: I've always had good experience with seagate drives myself, but always bought mine new
<LaserJock> ajmitch: oh, well that's not too bad then ;-)
<ajmitch> \sh: your name came up when we were talking about motus & pushing stuff back to debian - it's understood that MOTUs will have differences of opinions, and can just be overworked
<ajmitch> I had a bit of a chat with womble
<\sh> ajmitch: you are joking, right?
<ajmitch> \sh: no, not really
<\sh> ajmitch: oh damn
<psusi> Yagisan, yea.... I think I got ripped off when I got the second one... didn't say it was a refurb, but it turned out it was... that's the one that finally died... the original one is still going
<ajmitch> blogging makes you famous
<psusi> actually, it didn't even die... I stopped using it when my friends asked me where the jet engine was hiding
<\sh> I'm damned and doomed and should go away...now they are talking about me in a country far far away ;)
<ajmitch> haha
<psusi> then I realized it was just making so much damn noise because the bearings were shot...
<ajmitch> \sh: don't leave us!
<psusi> but it grew gradually and I slept with it next to me every night so I had been used to it
<psusi> those first gen 10,000 rpms ran HOT though... oh boy
<Yagisan> psusi: odd - I live seagates because they are quiet compared to other brands (longer warranty too, was 5 years when I checked last)
<\sh> ajmitch: please tell everyboody I'm just a fake
<psusi> I think they drew like 20 watts each idle.... and you could cook an egg on them
<Yagisan> s/live/like
<\sh> ajmitch: jdubs german alter ego or something like this...I'm not real.
<psusi> Yagisan, yea... they have really high MTBF
<psusi> their scsi ones anyhow
<psusi> heard their ide lines aren't so reliable
<LaserJock> \sh: lol
<Yagisan> psusi: well, i've been psuuing mine almost 24/7 since I bought them - 2+ years ago
<Yagisan> s/psuuing/pushing
<psusi> yea.... the one first gen 10k scsi drive is still going in a machine at my dad's I think... been on nearly 24/7 since 2001 or so when I got it
<psusi> also have a first gen 15,000 rpm cheetah still going at work... got that in 2003
<psusi> wait... is that right?
<psusi> no... got that one in 2002
<psusi> feb 2002
<psusi> first batch that hit the market, I was there... had been waiting for 4 months trying to order them but they took forever to come out with production quantities
<Yagisan> psusi: think they will actually get around to writing a repacker for resier4 ? I'm still waiting for a reiser3 repacker ?
<Yagisan> bah - I can't type
<psusi> beats me....
<psusi> all I know is I REALLY think the pseudo file stuff is cool
* netjoined: irc.freenode.net -> niven.freenode.net
<siretart> morning
<zakame> heya siretart
<lucas> hi all
<\sh> good morning
<zakame> hey lucas
<mr-russ> for a non pooled mirror, does a .dsc file belong in the binary folder, or the sources folder?
<lucas> sources
<mr-russ> how does the .deb know it's signed when you install it?
<mr-russ> from the Releases signing?
<lucas> good question
<mr-russ> okay, I'll look further into it. Quite a new experience setting up my own apt mirror.
<lucas> http://wiki.debian.org/SecureApt
<lucas> answer is: releases file
<minghua> generally the .debs are not signed as far as I know
<lucas> they are signed when you upload them, but that's all
<mr-russ> I was there, Setting up a secure apt repository: TODO scared me off. :(
<siretart> mr-russ: just use a sensible repo software
<siretart> mr-russ: like mini-dinstall, debarchiver or reprepro. they will handle this for you
<mr-russ> siretart: I've got it all working now.  all in one little script.
<mr-russ> siretart: thanks for the advice though.
<siretart> mr-russ: I don't see much point in inventing the wheel over and over again
<mr-russ> siretart: I know, but understanding the documentation for some of those is harder than it seems.
<ajmitch> hi
* Yagisan used debarchiver for my repo
<Yagisan> G'day ajmitch - having fun today ?
<ajmitch> yeah, was a good day today
<siretart> hey ajmitch
<Yagisan> anyone here use 3rd party repos on their ubuntu boxes ?
<mr-russ> Yagisan: yes, I use mine :)
<mr-russ> Yagisan: mainly so servers I maintain, I can move packages from universe into my own main tree and not allow those servers use of all those packages.
<mr-russ> Yagisan: plus some other software that isn't public.
<Yagisan> mr-russ: good - I'm not the only one :)
<mr-russ> Yagisan: I started using ubuntu 1 month ago, never used debian. and now I'm running my own repo.
<mr-russ> Yagisan: just need to get better at packaging software.
<Ubugtu> Ubuntu bug 1: "openssl: Expired certificates and recertification" Product: Ubuntu, Component: openssl, Severity: normal, Assigned to: fabbione@ubuntu.com, Status: RESOLVED, Resolution: NOTWARTY http://bugzilla.ubuntu.com/show_bug.cgi?id=1
<Yagisan> heh
<Yagisan> mr-russ: you are supposed to get better with practice, but sometimes looking at my work, I wonder about that
* Yagisan is off to test a game :-D
* mr-russ goes back to packaging software that was supposed to be done already.
<rob> hi, in the source repo there is a "pygtk" package, but not in the normal repos, has the name been changed?
<siretart> rob: sorry?
<rob> an apt-cache search doesn't bring up a package by that name (at least on my system), but I can download it via apt-get source
<lucas> rob: the source package name might not match the binary package names
<rob> yeah I thought so, how can I find out what the name was changed to for the binary package?
<lucas> see http://packages.qa.debian.org/p/pygtk.html
<lucas> you'll find the list of binary packages on the left
<lucas> basically python-glade2 python-gtk2 python-gtk2-dev
<rob> its broken up?
<lucas> a bit
<rob> I'm actually trying to tell if it was built with --enable-threads, but I'm having no such luck either way
<lucas> ah
<lucas> ubuntu's pygtk doesn't match debian's
<lucas> so my above comment might be wrong
<rob> yeah, I know debian's one was
<lucas>         cd build-2.4 && PYTHON=`which python2.4` \
<lucas>                 ../configure --host=$(DEB_HOST_GNU_TYPE)        \
<lucas>                         --build=$(DEB_BUILD_GNU_TYPE)           \
<lucas>                         --prefix=/usr --enable-thread
<lucas> in debian/rules
<rob> ah
<rob> I wonder if the 's' matters?
<lucas> I dunno
<lucas> you have some reasons to think it matters ?
<rob> I'm just learning threading with python, and got a bit stuck. just want to rule it out
<lucas> I'm not into python, so I can't help you, sorry
<rob> I'll try building it with the 's' and see what happens
<rob> gives me something to chew on, thanks lucas
<dholbach> good morning
<lucas> hi dholbach
<dholbach> hey lucas
<ajmitch> hi dholbach, lucas
<lucas> hi ajmitch
<lucas> dholbach: about the syncs, I thought you wanted to batch them too ?
<lucas> regarding the NEW packages, are there automatically imported until UVF ?
<lucas> err
<lucas> FF ?
<lucas> I'll ask on the ML
<lucas> so everybody benefit from it
<dholbach> they won't be autosynced I guess, I won't handle syncs.
<dholbach> But I'll answer on the mailinglist.
<\sh> dholbach: syncs for new upstream versions are as well UVF exceptions :) after they are approved, they can go to elmo :)
<dholbach> \sh: Yes, but not normal syncs.
<dholbach> I'm just the guy handing stuff to Colin and Matt.
<dholbach> I'm not the guy handing any stuff to anybody. :-)
<siretart> dholbach: there are a couple of UVF requests pending in the mailing list
<\sh> dholbach: you mean "NEW in debian, and not in ubuntu" to sync to ubuntu, which is more likely a NEW package for ubuntu as well...new revisions of debian packages can still be synced without any approval, as I understand the rationale behind the dapper UBZ spec regarding UVF for universe
<siretart> dholbach: at what frequency do you intend to forward them to matt/colin?
<siretart> dholbach: and if you do, could you please CC: ubuntu-motu@?
<dholbach> siretart: I answered that on the mailing list as well.
<dholbach> siretart: I thought about *trying* weekly,
<lucas> > The proper process for this is sending the Upstream ChangeLog diff and
<lucas> > the complete diffstat between our current and the new version.
<dholbach> \sh: yesd
<lucas> can you clarify "upstream changelog" ?
<lucas> is it the real upstream's, or debian's ?
<dholbach> the former
<\sh> lucas: not debian/changelog but <sourcetree>/ChangeLog
<siretart> ok
<siretart> diffstat/changelog and co sent
<lucas> dholbach: you forgot to answer regarding the UVF exc req later in the mail. was it on purpose ,
<lucas> ?
<dholbach> No, I'm just busy and didn't look over them yet.
<dholbach> I wanted to respond to the rest of the mail earlier.
<dholbach> I want UVF to be a team effort, so no need to get stuff blocked on me.
<dholbach> I'll send a first mail with a list of the stuff we agree on to Matt and Colin later today.
<lucas> ok
<dholbach> Thanks.
<tseng> Lathiat: pong
<jdong|livecd> mez: ping
<Mez> lol
<Mez> evening jdong|livecd, pong
<jdong|livecd> Mez: morning... :)
<jdong|livecd> Mez: can you get me more LP permissions?
<jdong|livecd> Mez: most of the edit buttons lock me out
<Mez> jdong: what do you mean ?
<jdong|livecd> Mez: for example, https://launchpad.net/products/breezy-backports/+edit gives me permission denied
<Mez> yeah
<Mez> thats meant to be like that
<Mez> why you editing it
<Mez> jdong|livecd, leae it alone for now - I'm talking to LP devs to see if they can sort something out
<Mez> and one of them has come up witha  great idea
<jdong|livecd> Mez: alright
<jdong|livecd> off topic, but how stable/usable is Dapper right now?
<Mez> jdong|livecd, It's quite good
<Mez> lil problem with xorg7
<Mez> but i believe thats fixed now
<jdong|livecd> and from day to day, no big nuclear meltdowns from dist-upgrading?
<Mez> jdong|livecd, not so far
<jdong|livecd> ok, then I guess I'll set myself up as a dual-boot...
<jdong|livecd> have an extra 15GB partition
<jdong|livecd> would sharing home partitions between a breezy and dapper dual boot be a bad idea atm?
<jdong|livecd> FF is one incompatibility that comes to mind....
<jdong|livecd> but I think I can work around that
<Mez> jdong: shouldt be too much of a problem
<zakame> heya dholbach
<dholbach> re
<dholbach> :-)
<zakame> dholbach: is it really that cold over there? :-)
<dholbach> Yes. :-)
<dholbach> The small channels and the river are frozen too.
<zakame> wow, my dad would like that :) but my mom would freeze too :))
<zakame> heya raphink , master REVU-er :)
<raphink> talking about REVU, anyone could review http://revu.tauware.de/details.py?upid=1591 please ?
<bddebian> Heya gang
<zakame> heya bddebian !!! long time no see :-)
<bddebian> Aye.  How you doing zakame
<zakame> bddebian: quite fine, just keeping some eyes out on REVU (although I've yet to comment :(
<bddebian> Ah :-)
<`Djon> hi
<`Djon> There is who alive?
* bddebian grasps his chest and falls on the floor
<raphink> siretart: are you there?
<siretart> raphink: rather not, I'm currently fighting with cfengine
<raphink> ok
<raphink> i've got a pb with an upload that I made wrongt
<raphink> I didn't run debuild properly (:e
<siretart> does anyone happen to know how to set a group/class in cfengine which name is the output of a shellcommand?
<raphink> :(
<raphink> so I got a .tar.gz and a .dsc instead of orig and diff
<raphink> and it was accepted in multiverse :(
<raphink> it should be in universe though
<raphink> ajmitch_: what's the server name to log in to REVU?
<raphink> ah got it :)
<siretart> raphink: you need to upload another version of the package, this time non-native
<raphink> yes
<raphink> good news is that beta2 is out since two days ago
<raphink> so Tonio will release a new version of the package with beta2
<raphink> and I'll upload it properly
<raphink> so I'll upgrade beta1
<raphink> siretart: how do I run revu-build on tiber?
<raphink> etc.
<raphink>  /usr/local/bin/revu-build: line 30: libswitch0.3.1_0.3.1-0ubuntu1_i386.info: Permission denied
<raphink> etc.
<raphink> I've tried with sudo, in case there was a special rule for this, but it doesn't work either
<raphink> it runs but I don't have the right to write on the server it seems
<raphink> ajmitch_: I'm sure you know the answer ;)
<raphink> dholbach: are you there?
<dholbach> raphink: yes
<raphink> :)
<raphink> dholbach: do you know about my question?
<raphink> when I try to use revu-build on tiber, I get series of errors :
<raphink>  /usr/local/bin/revu-build: line 30: libswitch0.3.1_0.3.1-0ubuntu1_i386.info: Permission denied
<raphink> oh and I have another question about tiber actually ;)
<raphink> well do you know about whether there is a way to get revu-build to work first of all?
<dholbach> raphink: no, no idea, no access to tiber
<raphink> oh ok
<raphink> dholbach: maybe you have an idea on the second issue although you have no access
<raphink> I have an account on tiber, and dput is installed and configured on the system
<raphink> do you think it is safe to import by .gnupg settings from my machine so I can upload directly from within tiber?
<tseng> erm that is a pretty bad idea
<tseng> you dont put your private key on shared hosts
<dholbach> raphink: what tseng said, don't do it.
<raphink> yep ok :)
<tseng> or really any host that has a direct opening to the internet
<raphink> so uploading from tiber is a bad idea
<tseng> no, having your private key on tiber is a bad idea
<raphink> hmm
<tseng> upload all you like
<raphink> my key is on a few machines directly opened to the internet
<tseng> :)
<tseng> raphink: well stop that
<raphink> but only on machines on which I have admin rights
<raphink> tseng: I can't
<bddebian> tseng baby!
<tseng> bddebian!
<raphink> see my machine is opened to the internet
<raphink> my main one
<tseng> raphink: as in, you are running open services?
<raphink> and I don't own a whole bunch of machines
<raphink> tseng : http, ftp, ssh
<tseng> ergh
<raphink> at least
<tseng> see, if there is a zero day exploit in httpd
<raphink> well ssh at least, otherwise I can't access my machine remotly
<raphink> and I only have one
<tseng> plus a privelage escalation
<tseng> someone can steal your key
<raphink> plus someone intersted in my key
<raphink> plus someone who is able to decrypt my password once he has the key
<raphink> that's a lot of ifs ;)
<tseng> its not enough, imo
<raphink> my machine is not the US Army main server
<tseng> but tiber is a definate no
<raphink> ok
<Mithrandir> raphink: you know you can sign remotely by using debsign -r host /path/to/file?
<tseng> tiber has alot less ifs :)
<raphink> and I guess I shouldn't have it on this machine either
<raphink> Mithrandir: oh interesting
<tseng> hi Mithrandir
<Mithrandir> hiya tseng-dude.
<Mithrandir> how's life?
<tseng> its good
<tseng> first day at "new" job
<Mithrandir> oh, doing what?
<raphink> :)*
<tseng> which means i get a better paycheck at the same desk
<raphink> what's your new job?
<tseng> Mithrandir: i write network management tools for a big financial company
<bddebian> Nice
<tseng> Mithrandir: snmp, rrdtool, expect.. fun stuff
<raphink> nice
<Mithrandir> sounds nice
<tseng> ya
<tseng> all built on Breezy, of course
<hub> raphink: elmo told me to contact LaMont Jones or Adam Conrad for the rebuild
<raphink> hub: ok
<raphink> :)
<raphink> Mithrandir: that means I could build the source package on tiber
<raphink> then sign it from my comp
<raphink> then upload from tiber
<raphink> ?
<raphink> keeping my gpg key on my comp only
<tseng> raphink: yes.
<Mithrandir> yup
<raphink> seems good
<phanatic> hi people
<phanatic> hey raphink, thanks for the upload
<phanatic> hi people
<LaserJock> hi phanatic
<bddebian> Hello phanatic
<LaserJock> bddebian: hi, how's it going?
<bddebian> LaserJock: Busy as usual. :(  You?
<bddebian> Heya \sh
<phanatic> gnome-power-manager is driving me crazy
<LaserJock> bddebian: yeah, I've got to get a poster ready for a conference, but I just got docteam repo access today so I might try to push out some Packaging Guide
<phanatic> it hibernates my laptop everytime it is launched, and it is started automatically... suxx :)
<\sh> hey bddebian
<bddebian> LaserJock: You da man! :-)
<LaserJock> who should I ask about getting packages removed?
<bddebian> Elmo
<bddebian> Good luck :-)
<LaserJock> bddebian: should I get a MOTU to ask for me?
<LaserJock> dholbach: ping?
<dholbach> LaserJock: pong
<tseng> bddebian: what is going on
<LaserJock> dholbach: I would like to get one of the apt-get.org imports (mathpazo) removed, could you ask elmo for me?
<bddebian> tseng: Work, work, work. :'-(  You?
<tseng> nothing
<tseng> fighting with motorola routers and expect
<bddebian> Joy
<dholbach> LaserJock: can't you ask himself?
<tseng> it wasnt killing telnet at the end of my loop
<tseng> so i ended up with 1000s of proceesses
<LaserJock> dholbach: I could but I don't know if he listens to nonMOTUs too much. I guess I could try :-)
<dholbach> yeah :)
<bddebian> LaserJock: Don't worry, he doesn't listen to MOTUs either ;-P
<LaserJock> lol
<\sh> siretart: ping
<Tonio__> hi all
<LaserJock> hi
<LaserJock> jeeze, rasmol has some upstream versioning - 2.7.2.1.1
<Amaranth> wow
<LaserJock> so is that a major version, minor version, miny version, micro version, and nano version ;-)
<bddebian> Heh
<thierry__> anyone who could review my package? http://revu.tauware.de/details.py?upid=1589
<ajmitch> morning all
<LaserJock> hi andrew
<\sh> ok...fixed bluefish
<\sh> malone #1426 resolved
<Ubugtu> Malone bug 1426: "opening files with bluefish -n confuses window title" Fix req. for: bluefish (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: Fix Released http://launchpad.net/bugs/1426
<LaserJock> hmm, so there are still 84 packages on the "Accepted" merge list
<ajmitch> yeah, I've probably got a few to clear
<\sh> what is a non-unicode version of wxWidgets?
<LaserJock> with the rest we should be able to at least see if UVF applies and merge/sync those that it doesn't, right?
<\sh> malone #3194
<Ubugtu> Malone bug 3194: "No non-unicode wxWidgets 2.6" Fix req. for: wxwidgets2.6 (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: Unconfirmed http://launchpad.net/bugs/3194
<LaserJock> \sh: I've been wondering that myself
<LaserJock> \sh: I think there might be at least 2 Malone bugs about that
<zul> hmm...blam is broken
<\sh> well...unicode should be a standard for ubuntu, right, so the applications should support unicode :)
<LaserJock> oh, I'm wrong. 2 comments on the same bug
<LaserJock> so it's not wxwidgets2.6's fault but the apps that are using it?
<\sh> xtranslate.c:28: warning: return type of 'main' is not 'int'
<\sh> wtf...
<\sh> LaserJock: I would say yes
<LaserJock> \sh: so what do you with the bug report?
<LaserJock> \sh: could we even provide a non-unicode version?
<\sh> LaserJock: well to be honesy I don't know...I would say set another non-utf8 locale and it should work
<\sh> but I don't use the applications he is talking about
<LaserJock> \sh: ok, I'll make a comment suggesting they try a non-utf8 locale and see if that works but stating that unicode is the standard for Ubuntu
<\sh> LaserJock: cool thx :)#
<LaserJock> \sh: np, I had the bug report open in my browser anyway ;-)
<\sh> I'm writing very serious changelog entries
<\sh>   * xtranslate.c:
<\sh>     + changed void main(...) to int main(...) to be C compatible
<\sh>     + added return (0); at the end of main to return, yes, returncode 0
<tseng> \sh++
<\sh> tseng: well, I wonder why this bug never got fixed in the past
<\sh> eventually "void main()" is such a common mistake
<tseng> yeah
<sivang> \sh: what bug is that, what packages?
<\sh> malone #3807
<Ubugtu> Malone bug 3807: "Crash opening xtranslate" Fix req. for: xtranslate (Ubuntu), Severity: Normal, Assigned to: MOTU Reviewers Team, Status: Fix Committed http://launchpad.net/bugs/3807
<\sh> but I found another one related to this package
<\sh> debian 349446
<Ubugtu> Error: Could not parse data returned by Debian bugtracker: need more than 1 value to unpack
<\sh> debian #349446
<Ubugtu> Error: Could not parse data returned by Debian bugtracker: need more than 1 value to unpack
<\sh> shit
<\sh> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=349446
<Ubugtu> Error: Could not parse data returned by Debian bugtracker: need more than 1 value to unpack
<sivang> \sh: ah, I see. thanks
<sivang> can anyone do a quick test for me? (of some python code that uses dbus and hal)
<Tonio_> dholbach: ping ?
<dholbach> Tonio_: pong
<Tonio_> dholbach: hi !
<dholbach> Hello
<\sh> oh man, the easiest things are not done....<metacode> if display == NULL then complain about it endif
<Tonio_> dholbach: I know the reason pwmanager doesn't upload correctly....
<dholbach> Aha? Tell me!
<Tonio_> dholbach: ready ? quite fun ;)
<Tonio_> Same rejection reason as the last 6 times. Too generic a name for something
<Tonio_> tied to a specific desktop environment.
<dholbach> Oh wow!
<Tonio_> katie's log
<Tonio_> it doesn't like the name ^_^
<dholbach> They can't say, we didn't try :-p
<Tonio_> dholbach: I must say I'm a bit lost on what to do hihi ;)
<dholbach> kde-pwmanager *shrug*
<dholbach> dunno
<\sh> hmmm?
<dholbach> monsieur riddell might have a clever idea
<Tonio_> I'll ask him yes
<\sh> pwmanager a wrong name?
<\sh> why?
<\sh> only if a package with the same name is in the archive
<dholbach> I suppose it was not an automatism.
<Tonio_> \sh: absolutly no idea, but that's katie's output... and there is no package with that name in the archive... I already checked
<Riddell> it'll be manual
<\sh> Tonio_: somewhere in the provides?
<Riddell> I've forgotten what pwmanager kdoes anyway
<\sh> or elmo :)
<Riddell> but kde-pwmanager would be the sensible way to go
<Tonio_> Riddell: do you want me to rebuild the package and upload it to revu ?
<Tonio_> \sh: the output is signed "James", does it means it has been rejected by elmo directly, or can that be an automated process anyway ?
<\sh> Tonio_: it means elmo rejected it :)
<Tonio_> \sh: okay ;) I quite don't understand, but he should have his reasons....
<\sh> james != our beloved katie...I think elmo was petting katie at this time...and katie enjoyed it very much .
<Riddell> Tonio_: please
<Tonio_> Riddell: I'll do now
<\sh> bah
<\sh> it's unbelievable
<\sh> Display *display=XOpenDisplay("")
<ubuntu_> I'm testing flight 3 live-cd and I wonder on wich package to fill a bug
<\sh> will return NULL if no DISPLAY is set...what happens when you try to use a NULL pointer?
<ubuntu_> when I enter the french language, I get the wrong keyboard layout, I think it should ask wich kind of layout I want (there's mainly 2 in french)
<ubuntu_> wich package could that be?
<\sh> ubuntu: #ubuntu :)
<ubuntu_> k sorry for spamming
<jamessan> \sh: of course, everything will work as expected.  NULL pointers automatically do what you want them to  ;)
<phanatic> \sh: segmentation fault i suppose :)
<\sh> jamessan: yes, right, correct, segfaulting :)
<\sh> and it's only a matter of 4 lines...if (!display) { fprintf(stderr,"You fck bastard, set your DISPLAY properly!"); exit(EXIT_FAILURE);}
<phanatic> lol
<jamessan> but that's work that you have to do instead of letting the program do it for you
<\sh> but what Yann fixed was much better...
<\sh> wort = malloc((char) "TRANSLATEWORD=");
<\sh> that's really the best one I ever saw
<\sh> make a string packed into a char.
<jamessan> hah
<\sh> that's better then gzip99 compression
<\sh> and such software is really in our archives and in debians
<thierryn_> slomo : JohnnyMast told me you could review my package...
<Tonio_> Riddell: kde-pwmanager uploaded to revu
<thierryn_> Tonio_ : are you a MOTU?
<Tonio_> thierryn_: nope
<LaserJock> thierryn_: you are probably better off just asking for a review from any available person in general and giving the package name or REVU URL
<LaserJock> any available reviewer I mean
<Riddell> Tonio_ should be a MOTU
<azeem> thierryn_: why do you install the headers from libfxruby1.4/*.h and not debian/tmp?  Are they not getting installed there?
<Riddell> Tonio_: are you a member?
<Tonio_> Riddell: maybe tomorow :) I'll finally get to oportunity to introduce at the CC
<Riddell> Tonio_: got a wiki page?
<Tonio_> Riddell: yep but not fully up to date
<Tonio_> I'm working ont it
<Riddell> need to do that before the meeting
<Tonio_> Riddell: I know, I put
<Riddell> Tonio_: give me a ping before the meeting to make sure I'm around
<Tonio_> Riddell: okay ;)
<thierryn_> azeem : it's my second package so I'm a but confused with all that stuff of installing what where... if it works and installs all I want where it should I'm happy
<thierryn_> azeem : but if you have a better way to do to offer me, it would be great :)
<azeem> you shouldn't blindly put any header files into the -dev package
<azeem> there is a destinction between public and private headers
<thierryn_> k, I didn't know
<thierryn_> azeem : so how should I fix this?
<thierryn_> checking if the headers is public or not??
<azeem> I asked you whether those headers are getting installed into debian/tmp
<azeem> if they are, that is a good indication they are public
<thierryn_> ok going to check that when I'll have finished testing flight 3
<azeem> I also wonder why you have C headers in a ruby package, but maybe they have something similar?
<thierryn_> azeem : to what I have seen, the package use C and ruby... the whole config, make and install stuff is in ruby but some stuff seems to be in C also
<thierryn_> azeem : anything else that could stop my package from being advocated?
<azeem> I don't know, I only took a short glance on it
<azeem> thierryn_: did you have a look at how other ruby packages are built?  I thought they are rather called ruby-something, but maybe I am confused
<phanatic> could someone have a look at this: http://revu.tauware.de/details.py?upid=1579 ?
<thierryn_> azeem : well it's also because of libfox1.4 ...
<dholbach> Have a nice evening.
<bddebian> Later dholbach
<ajmitch> bddebian: you'd like this talk - about the structure of debian packages & how to build them using various tools :)
* ajmitch is at linux.conf.au
<bddebian> ajmitch: WHen/where?
<bddebian> Ooohhh
<ajmitch> bddebian: now, dunedin, NZ
<Riddell> Tonio_: does that soundkonverter break UVF?
<sivang> ajmitch: successor to the "pkging like real men used to do" talk?
<sivang> anyway folks, I'm off to bed. I'm pretty beat
<ajmitch> sivang: sort of
<sivang> ajmitch: cool, just make sure it has a nice wiki page like the current one has, and you're a hero for ever :)
<sivang> ajmitch: the current one is very good
<bddebian> Later sivang
<sivang> ajmitch: helped me see some of the stuff very clearly for some first time :)
<sivang> later bddebian
<ajmitch> sivang: um
<ajmitch> sivang: I didn't give the talk :P
<sivang> leave your highlights for me, I will check them tomorrow
<Tonio_> Riddell: possibly yes, I think it breaks UVF
<Riddell> Tonio_: did you ask for an exception?
<Tonio_> but while uploading the previous version, a little mistake was done, resulting a package orig.tgz
<Tonio_> Riddell: nope
<Tonio_> Riddell: what's the process for this ?
<Riddell> Tonio_: ask dholbach I think and he'll forward to mdz once a week
<Riddell> I could be wrong
<Tonio_> Riddell: k
<bddebian> Later folks
<\sh> Tonio_: read ubuntu-motu...a small description what the new version does, a diff of real upstream changelog from old version to new version, and a diff -ruN <old sourcetree> <new sourcetree>|diffstat attached to a mail to ubuntu-motu :)
<Tonio_> \sh: the old file has been uploaded without a diff.....
<\sh> Tonio_: I don't mean diff.gz
<Tonio_> \sh:  ah ok ;)
<\sh> Tonio_: diff -ruN <old sourcetree>/ChangeLog <new sourcetree>/ChangeLog
<\sh> Tonio_: diff -ruN <old sourcetree> <new sourcetree>|diffstat
<\sh> both outputs piped into files and those files attached to your exception report
<Tonio_> \sh: thanks for the info, I'll do that and email daniel
<\sh> explanations, why it should be an exception and the rists of upgrading the package should be included in the text
<Tonio_> okay
<\sh> Tonio_: no. mailing ubuntu-motu ML :) so we can discuss it
<Tonio_> \sh: ok
<\sh> Tonio_: dholbach wrote a mail how this process is working...if you missed this mail, I can forward it to you
<Tonio_> \sh: yep, that would be with pleasure....
<\sh> Tonio_: email address?
<Tonio_> \sh: I lost lots of datas while migrating to dapper on my maptop.... I had to format and come back to breezy ;)
<Tonio_> \sh: anthony.mercatante(at)laposte.net
<Tonio_> I forgot to backup emails before upgrading..... shame on me
<\sh> Tonio_: on the way
<\sh> Tonio_: that's why I'm using imap :)
<\sh> and not pop3
<Tonio_> \sh: I'm using imap on all my accounts except this one ;)
<\sh> Tonio_: shame :)
<\sh> on you :)
<Tonio_> and the worst thing is that this accounts provides imap for free.......
<\sh> anyways...time to sleep :)
<Tonio_> \sh: so you can say and say it again :)
<Tonio_> nite \sh
<\sh> good night everybody :)
#ubuntu-motu 2006-01-29
<Tonio_> siretart: there was a problem while uploading kmhtconverter on revu, and upload fails for me actually....
<Tonio_> siretart: can you remove it from queue ?
<siretart> Tonio_: done
<siretart> gn8
<Tonio_> siretart: thanks :)
<raphink> siretart: ajmitch made me an account on tiber
<raphink> it's a really nice, but I don't have writing rights on /var/revu/revu1-incoming
<ajmitch> yes, I told him about that :)
<raphink> so that I can't run revu-build
<ajmitch> umm
<ajmitch> you should be in the pbuilder group
* raphink forgot about the command to check the groups of a user
<ajmitch> ok, looks like you need to be in another group
<ajmitch> one moment
<raphink> otherwise it's very nice. I was able to find out why some upload didn't go up, by looking at /home/ftp and other stuff
<raphink> very useful
<raphink> ok
<ajmitch> it should work now, might need to logout & login
<raphink> ok
<raphink> I'll try
<raphink> siretart, ajmitch
<raphink>  $ revu-build kmhtconvert_0.7.3-0ubuntu1.dsc
<raphink> W: /home/raphink/.pbuilderrc does not exist
<raphink>   -> Logging to kmhtconvert_0.7.3-0ubuntu1.buildlog
<raphink> ls: *.deb: No such file or directory
<raphink> is that normal ?
<raphink> :s
<ajmitch> it's normal if the build breaks
<ajmitch> which happens often enough, when the uploaded package just doesn't build in pbuilder
<raphink> hmm
<raphink> it builds in my pbuilder though
<raphink> so maybe it's the revu pbuilder that isn't up-to-date
<raphink> .
<raphink> ?
<ajmitch> raphink: then update it
<raphink> how ?
<raphink> do I have the right to run pbuilder update ?
<raphink> mkdir: cannot create directory `/var/cache/pbuilder/build//6798': Permission denied
<raphink> ;)
<raphink> oh I hvae sudo rights for pbuilder
<raphink> good to know
<raphink> :)
<ajmitch> use pbuilder-dapper update
<raphink> hmm
<raphink> I'm running sudo pbuilder update currently
<raphink> is that fine ?
<ajmitch> please don't
<ajmitch> no
<raphink> oh no it's a breezy one :(
<raphink> argh
<raphink> ok I'm updating the dapper one
<raphink> ajmitch: is it possible to have revu-build a bit more verbose?
<ajmitch> it's a script, so yes
<raphink> hehe
<raphink> I guess I just have to cp /usr/local/bin/revu-build to my ~ and modify it ;)
<raphink> so its more verbose ;)
<raphink> that's how you mean?
<raphink> ;)
<LaserJock> so is revu-build what is used to generate what you see when you click on the details for a package on revu?
<raphink> its used to generate this LaserJock http://revu.tauware.de/details.py?upid=1606
<raphink> just ran it on this package to test :)
<LaserJock> but it can also be used from ~/ to right?
<raphink> how do you mean?
<raphink> you mean if you want to use it on your comp?
<raphink> anyway
<raphink> time to go to bed
<raphink> almost 3 AM
<raphink> and I have to go out and see seveas tomorrow :)
<raphink> 'night
<raphink> <>< LaserJock :)
<ajmitch> Riddell: ping?
* psusi is getting worried now... running smart long self test on my hard drives and they sound like they are going to explode... heh
<psusi> the head is massively thrashing and the pitch is getting higher and higher
* dcode is away: sleeping...
<hub> wow
<hub> kernel seriously broke
<ajmitch> how badly?
<hub> the console is messy
<hub> X does not even start
<hub> trying the old kernel
<hub> thumbnailing in nautilus is also broken
<hub> files a bug
<hub> and it stall on "detecting and activating hardware"
<hub> for a long time
<hub> now I understand the "freeze"
<ajmitch_> hm, I missed the comments
<hub> ajmitch_: udev is fscked
<hub> completely
<hub> I reboot signle
<ajmitch_> hm
<ajmitch_> I might put off dist-upgrading tonight then
<hub> yeah
<hub> possibly
<hub> but the old kernel does not boot either
<hub> 'cause of udev
<minghua> does that mean I should update kernel but hold udev?
<hub> minghua: hold eveything
<ajmitch_> well there's been no udev upload for two weeks
<ajmitch_> so you can't blame changes there
<hub> kernel got updated
<minghua> hub: all right, fortunately I don't need any new stuff, thanks
<hub> I did a mass upgrade
<ajmitch_> last kernel upload I see was 5 days ago
<hub> and I still miss bits like dbus 0.60
<ajmitch_>  2.6.15-13.18 ?
<hub> I don;t know why
<hub> ajmitch: that one
<hub> ajmitch: but maybe the machine is fscked
<hub> it is an old PIII
<ajmitch_> so it's nothing new that's been introduced in the last day or so
<ajmitch_> where does it stop booting for you?
<minghua> Hmm, I am using 2.6.15-13.18
<ajmitch_> so am I
<minghua> so it looks the bug is specific to hub's machine
<ajmitch_> I had it stop once at detecting & activating hardware today
<ajmitch_> like it did last week
<ajmitch_> but a reboot fixed it
<hub> I did reboot thrice
<hub> now I'm in signle user
<hub> and try manual fiddling
<hub> maybe should I install Xandors ;-/
<minghua> heh
<hub> where do I find udev logs?
<hub> udevplug fail
<LaserJock> muahahaha, I got vmware-player to use linux in Windows.
<LaserJock> now VMware is useful ;-)
<Kyral> lol
<Kyral> I got a LAMP setup
<Kyral> azuredream.homelinux.org
<LaserJock> Kyral: nothing there :(
<Kyral> LaserJock: eh?
<hub> fsck
<Kyral> http://azuredream.homelinux.org/blog/
<LaserJock> Kyral: all I see is "The Career Fair Cometh"
<Kyral> yah
<Kyral> right now thats all it is lol
<Kyral> a blog lol
<Kyral> I just set it up today shessh
<LaserJock> Kyral: np, I think I have a blog somewhere but I don't remember where at the moment (blogger.com perhaps)
<LaserJock> Kyral: I don't even have enough time to get the things done I would blog about let alone write the blog ;-)
<minghua> LaserJock: same here. :-)  my last blog entry is in June
<hub> plugdevd does not even have a debug mode of any soirt
<hub> udevplug I mean
<LaserJock> hmm, I haven't seen elmo on -devel all day
<hub> isn't he at LCA?
<LaserJock> oh, that could be
<LaserJock> well, he's excused then ;-)
<hub> krap
<hub> my console is really messed up
<hub> it display garbage
<Kyral> okay bedtime
<LaserJock> cya Kyral
<zakame> hi all
<dholbach> good morning
<lucas> hi dholbach
<lucas> you are up early :)
<dholbach> Yeah, just waking up :)
<Revan> heya dholbach :)
<dholbach> hey zakame
<dholbach> gar... it's cold over here
<lucas> hehe, you got into that cold wave from the east of europe ?
<dholbach> -17C; felt temperature -24C
<dholbach> I'll wait a bit with taking the dog out. :)
<Treenaks> dholbach: ouch
<dholbach> Once you're walking, it's ok - but long mobile conversation hurt. :-)
<Treenaks> dholbach: -4 here
<dholbach> Nice
<Treenaks> thanks to the north sea
<lucas> dholbach: have you heard of some plans about getting ekiga (gnomemeeting 2) in dapper ?
<Treenaks> that would ROCK
<Treenaks> btw, wpd2sxw needs a recompile (it's uninstallable atm)
<dholbach> lucas: yes, i talked to the pkg-voip team
<dholbach> lucas: after they have it, i'll test it and talk to matt and colin - which reminds me, need to mail them
<lucas> ok, that's great
<dholbach> What's the ipython situation?
<dholbach> Are we about to request UVF exception and sync or what?
* lucas doesn't know
<dholbach> Ok just saw - requires ubuntu update)
<lucas> https://wiki.ubuntu.com/DCT
* lucas wants to get things moving
<dholbach> I'd like to hear more opinions on the UVF requests
<dholbach> I don't want to be the only one deciding.
<lucas> dholbach: the problem is that, in the end, you'll be the one deciding
<dholbach> No, we can have a look and say "wow that's lot of fixes" - or "no, that's just features"
<lucas> my POV would be :
<dholbach> I don't want to be the only one with an opinion.
<lucas> - if it's a lib, let's take things carefully
<lucas> - if it's not a lib (no packages depending on it), and it was suffficiently tested to make sure it doesn't explode, let's sync it
<dholbach> Hm...
<lucas> but I know it's not the opinion I'm supposed to have :-)
<dholbach> You can have every opinion you can think of  :-)
<dholbach> libgettext-ruby looks good to me
<lucas> shouldn't we track UVF exc req using bugs in malone, assigned to MOTU or motureviewers ?
<lucas> I find it hard to follow the mails
<dholbach> It is, but I want people to read this.
<dholbach> I'm not sure, if many people track motureviewers.
<dholbach> I want this to be discussed
<dholbach> What about sisu?
<dholbach> Is there no Upstream changelog or anything?
<lucas> yup, no upstream changelog
<lucas> the changes are mainly to the build system
<minghua> dholbach: I think the problem is, many people don't have the knowledge / don't care enough to give opinions
<dholbach> gar!
<minghua> dholbach: take myself as example, I use none of the packages that request for UVF exception now
<dholbach> minghua: It's merely reading and thinking... :-)
<minghua> I don't know if I should speack out my opinion
<dholbach> it's a gut feeling
<minghua> dholbach: just reading the diffstat would be good enough?
<dholbach> the changelog mostly - the numbers in the diffstat can make sense too
<dholbach> If you see 90% changes in doc/ you can be pretty sure, that we have enough time to fix the 10% if they explode :-)
<dholbach> stuff like that
<dholbach> lucas: sisu looks unintrusive, I just can't see sense in all the changes :-)
<lucas> me neither, but I'd prefer to stay in sync
<lucas> since the packaging looks complex, it might be hard to fix later
* ajmitch_ just hasn't had time for ubuntu or debian work this week :)
<dholbach> I'm going to request uvf exception approval for lyx, iypton, libgettext-ruby and sisu
<dholbach> If I missed something you all have time to find out, as long as I'm under the shower.
<lucas> can we discuss psi ?
<lucas> it's the most popular jabber-only client
<lucas> it would be a shame to release dapper with an old version
<dholbach> Can you send the relevant info to the mailing list?
<lucas> ok
<dholbach> Thanks.
<lucas> psi is badly maintained in debian :/
<lucas> i'm not sure what to do with what \sh changed to the package
<minghua> Hmm, I wonder what is the difference between lesstif and openmotif
<lucas> dholbach:  btw, what's the process for UVF and packages requesting a merge ?
<lucas> you first seek approval by Kamion and then upload the merged package ?
<dholbach> Not sure - the Schedule mentions that this week is the "finish rest of the merges" week
<lucas> no I mean: psi has local changes in ubuntu.
<lucas> let's say you ask for an UVF exception for psi
<lucas> how do we proceed with uploading 0.10-2ubuntu1 ?
<dholbach> I don't understand the question.
* lucas thinks about it
<lucas> psi:
<dholbach> We ask to get new Upstream code in, we upload it if they say ok.
<lucas> Version in Ubuntu: 0.9.3-2ubuntu1
<lucas> Version is Sid: 0.10-2
<lucas> oh ok
<dholbach> It's quite easy. :-)
<dholbach> ok, brb
<ejofee> why isn't mc (midnight commander) included in a standard (k)ubuntu install? or why not at least on the cd?
<lucas> hi
<ajmitch_> because very few people use it, compared to something like nautilus or konqueror?
<ajmitch_> there are many packages that could be on the cd, but aren't due to lack of space
<ejofee> ajmitch_: mc is not very large
<ajmitch_> neither are a number of others
<lucas> many packages are not very large :)
<ajmitch_> but they add up
<ajmitch_> mc is not in main, either
<minghua> Is vim/emacs in standard install?
<Mithrandir> vim, not emacs
<Mithrandir> emacs was thrown out after 4.10
<ajmitch_> Mithrandir: didn't they want another desktop environment?
<Mithrandir> ajmitch_: haha. :-P
<ejofee> ajmitch_: oh, it is not in main? it's ok, then. it compensates. :P
* ajmitch_ uses emacs :)
<Mithrandir> ajmitch_: you do know vim has more embedded languages than emacs?
<ajmitch_> Mithrandir: no, since I rarely use vim
<Mithrandir> ajmitch_: perl, python, ruby, tcl at least.  Or can be compiled with.
<ejofee> Mithrandir: is vim better than nano?
<Mithrandir> ejofee: is a SUV better than a bicycle?
<minghua> the answer is pretty subjective, I am afraid
<ejofee> Mithrandir: if vim is so good, then why do fewer and fewer people use it?
<Mithrandir> ejofee: they do?
* minghua wonders what emacs would be if vim is a SUV :-)
<Mithrandir> minghua: a JSF or AH-66, of course. :-)
<Mithrandir> uh, AH-64
<ajmitch_> hm
<ejofee> minghua: emacs is a text editor
<ajmitch_> ejofee: that's one of its minor functions
<ejofee> ajmitch_: what is vim's equivalent for windows, btw?
<Mithrandir> ejofee: you have vim for windows too
<Mithrandir> or you could use vim-gtk or something
<ejofee> Mithrandir, ajmitch_: if emacs is better than vim, then why do many distros include only vim by default?
<ejofee> is it because vim is smaller?
<ajmitch_> better? now that's a good topic for a heated discussion
<Mithrandir> ejofee: I'm not going to have that discussion.  Editor preference is mainly that -- a matter of preference.
<Mithrandir> I happen to prefer emacs, but I wouldn't say that vim is a worse editor.  It's just not my favourite.
<ejofee> Mithrandir: ok, then, statistically speaking, which one has a larger user base?
<Mithrandir> I don't know
<Mithrandir> (and I don't really care, I use the one I prefer and I would expect others to do the same)
<minghua> and a lot of people use both vim and emacs
<Mithrandir> I would also recommend people to learn both, at least on a superficial level so they won't be lost if their favourite isn't on the system.
<ejofee> Mithrandir: sometimes statistics can show how evolved (or adapted) a subject can be.
<zakame> emacs!?! vim!?! all in one sentence!?!
<Mithrandir> I'm not sure what you mean with you mean by "evolved".
<ejofee> Mithrandir: doesn't vim tend to be found everywhere?
<Mithrandir> no
<torkel> ejofee: no, vi maybe but not vim...
<ejofee> Mithrandir: adapted to most users' needs
<Mithrandir> elvis or nvi can be found on most systems, though.
<Mithrandir> ejofee: my needs are surely different that yours.
<ejofee> Mithrandir: some needs are statistically more obscure or less representative than others.
<ejofee> Mithrandir: statistically. not ethically.
<ejofee> Mithrandir: but yes.
<Mithrandir> sure, but if that's a critical piece of functionality for me, I don't care if 99% of the users don't need it.
<ejofee> Mithrandir: agreed.
<Mithrandir> (like, I do moderate newsgroups once in a while and having a good integration between my news reader and editor is crucial.  I don't expect other people to really care about that.
<ejofee> btw, is there any distro (that you know of) which includes emacs on a default install? what about on a minimal environment?
<Mithrandir> if you want something resembling a stripped-down emacs, use jed.
<Mithrandir> and no, but why is the default install so important?  emacs is on the cd, it's in main and supported.
<ejofee> Mithrandir: when i boot an distro's official cd in the rescue mode and i see that i can't modify files because it uses vim (which i don't know how to use), i do care. i then miss mc, or maybe nano or emacs.
<Mithrandir> ejofee: use our live cd and install emacs, then. :-P
<ejofee> Mithrandir  :)
<zakame> hm, there's nothing wrong in being ambidextrous
<minghua> debian's rescure CD (actually just the installer) should use nano instead of vi, don't know about ubuntu's though
<ejofee> minghua: why do you think it *should* use nano instead of vi?
<Mithrandir> the ubuntu installer cd has nano on it.
<Mithrandir> ejofee: because nano is way more newbie friendly.
<Mithrandir> a rescue/install cd needs an editor everybody can use to rescue their system.  It doesn't matter if it's suboptimal for writing lots of code or books or such.
<ejofee> Mithrandir: right.
<minghua> ejofee: sorry, I was not clear.  I meant "should be using nano now"
<minghua> or "I remember they are using nano now"
<ejofee> Mithrandir, minghua: then mc (which has its internal editor) would be the very best! plus it resembles nc.
<ejofee> ... or bios.
<ejofee> i think mc is best for a minimal, rescue cd.
<Mithrandir> I never ever liked norton commander.
<zakame> netcat?
<zakame> err norton commander, sorry
<dholbach> going to request uvf exceptions for lyx, ipython, libgettext-ruby, sisu, psi
<dholbach> the rest requires discussion
<ejofee> mc is THE BEST minimal tool when it comes to user friendliness. plus it provides a nice way to browse the file system (sh is not that friendly to the noob).
<Mithrandir> ejofee: we're going to switch to a live cd based installer for dapper anyway, so you shouldn't need to use a shell to browse the fs anyway.
<lucas> ejofee: feed2imap is the best feed aggregator from my POV. Am I bitching about getting it on the CDs ? ;)
<ejofee> Mithrandir: what about the rescue cases?
<Mithrandir> ejofee: a live cd should be much better suited for that, don't you think?
<dholbach> ejofee: discuss tihs on a mailing list, justify it and suggest what should be removed from the CDs instead of it.
<ejofee> Mithrandir: ok, but some live cds fail back... into vim
<dholbach> ejofee: this discussion doesn't get nowhere without a concrete proposal
<ejofee> Mithrandir: let mc be the live cd's failsafe case. why not?
<ejofee> dholbach: right
<lucas> ejofee: subscribe to ubuntu-devel@lists.ubuntu.com and discuss it there
<Mithrandir> ejofee: I am of the opinion that mc's UI is horrible, so convincing me will be quite hard. :-)
<ejofee> Mithrandir: as people were doing back in the 90s, when they were "failsafing" to dos / nc
<lucas> we are not the one able to take the decision anyway, so it's worthless discussing it there
<Mithrandir> I've never ever, ever met somebody who had a boot floppy which fell back to norton commander.
<ejofee> Mithrandir: well, you're right :)... but we are talking cds here
<ejofee> lucas: thanks. i will.
<Mithrandir> ejofee: Installed-Size: 5952
<Mithrandir> I don't think that qualifies as "minimal" in any sense of the word.
<ejofee> Mithrandir: i think it has a minimal version
<ejofee> Mithrandir: for the post-cd era, it IS minimal *by all means*.
<lucas> we aren't yet in the post-cd era
<ejofee> lucas: ok... for the cd era :D
<Mithrandir> no, it's not.  You need to stuff this into a ramdisk and a 6MB hit to the installer's memory requirements is _huge_
<Mithrandir> if it was 250k would could possible be having a meaningful conversation.
<Mithrandir> possibly, even
<ejofee> Mithrandir: then is there any console file browser (with no internal editor) which is slimmer?
<ejofee> Mithrandir: user friendly, that is
<ejofee> Mithrandir: rather, "noob-friendly"
<ptlo> one thought about live cd in rescue mode - can it be unmounted? i've never used ubuntu live cd's (never needed a rescue :), but i once tried using knoppix' cd and i remember the frustration i got when i tried to access something on another cd (the system had only one cd drive)
<Mithrandir> ejofee: that's not relevant.  6MB is too much.
<Mithrandir> ptlo: no, it can't.
<ejofee> Mithrandir: that was not an argument. i was really wondering whether there was some alternative.
<Mithrandir> ejofee: none I know of.
<Mithrandir> ejofee: I think we just have to live with the fact that the console is, more or less, dead.
<ptlo> Mithrandir: that's a pity, i believe it'd be more usable in that case (i'm not starting a rant here, i do trust that there are very good reasons for not being so)
<ejofee> Mithrandir: anyway, vim alone is 1300 kb...
<zakame_away> hm, then again, what's the diff between {noob,user}-friendly?
<Mithrandir> ejofee: vim's on the live cd, but not in the installer.  There's nano there.
<ejofee> zakame_away: vim is user-friendly
<ejofee> zakame_away: vim helps the user do lots of things
<ejofee> zakame_away: ... and very easily... as soon as the user is a user, not a noob.
<Mithrandir> zakame_away: newbie-friendly means it's easy to get started with.  User-friendly means it's easy to do the stuff you want to do, but it might require learning effort to get there.
<ejofee> zakame_away: that is, as soon as the user *learns* how to use it
<zakame_away> ptlo: I had a similar experience, but it was quite easy in my case
<zakame_away> ejofee, Mithrandir : ah
<zakame_away> well, in that case, iptables is ``user-friendly'' for me ;)
<Mithrandir> ptlo: yes, it's a hard problem to solve.  What you'd need to do is to load all the data into memory and mount that tmpfs somewhere.  > 2GB memory isn't too common just yet.
<ejofee> zakame_away: iptables isn't user-friendly for anybody. it has a way too techie design.
<zakame_away> IMU, user-friendly approximates (or daresay equals) being intuitive, right?
<Burgundavia> ejofee, vim is far from userfriendly. nano is
<Mithrandir> intuitive interfaces aren't.
<Mithrandir> Burgundavia: nano is not user friendly.  It gets in my way.  vim and emacs generally doesn't.
<Mithrandir> Burgundavia: however, nano is newbie friendly.
<Burgundavia> Mithrandir, yes
<zakame_away> ejofee: I was testing yours, and Mithrandir's definition.  :)
<ejofee> Burgundavia: from what i've heard, nano is user-unfriendly, but noob-friendly
<Mithrandir> zakame_away: I think iptables is user-friendly, but it takes a fair amount of time to learn
<Mithrandir> (a lot of which is not iptables' fault, but more that it exposes a lot of functionality which is not easily explained and which require you to understand how the internet works)
<zakame> Mithrandir: exactly. hence the definitions hold, but I must add that to gauge the learning effort is mostly subjective
<ejofee> Mithrandir, zakame, Burgundavia:  "user friendly" vs. "(perpetual) noob friendly" --- i don't think i can find any explanation better than this: http://linux.oneandoneis2.org/LNW.htm (search for "blissfully" on the page, to get to the right paragraph)
<StevenK> At least iptables is a little more user-friendly than ipchains.
<StevenK> ipchains bites back.
<ejofee> to me, this is a very insightful distinction. what is your opinion?
<Mithrandir> ejofee: I don't agree with the car analogy in there, but the rest holds (fairly well)
<ejofee> Mithrandir: yeah, the car analogy is slightly... off-topic :)
<Tonio__> hi everyone
<zakame> haha
<zakame> heya Tonio_
<Tonio_> yop zakame
<ejofee> Mithrandir: i intend to send the author this "correction", which makes the analogy much shorter and on-topic: "It's like the difference between an axe and a chainsaw. It's easier (more intuitive, easier to figure out how) to cut a tree with an axe, right? However, for somebody who knows how to manage it, it's much easier and efficient to do it with a chainsaw." :)
<Riddell> ajmitch_: pong
<ajmitch_> Riddell: was just questioning the xlibs-static-pic dep for libqt4-dev
<ajmitch_> I'm guessing the dep is meant to be removed?
<Riddell> ajmitch_: it's not meant to be since the debian packagers would have put it there for a reason but it may well should be
<Riddell> ajmitch_: but qt4 built successfully, does it not do so any more?
<ajmitch_> it's not a build dependency
<ajmitch_> and it makes libqt4-dev uninstallable, sadly
* ajmitch_ is just wanting it for an LCA tutorial session by a trolltech guy tomorrow :)
<tortho> Hi, The gtk-gnutella package in Dapper is not working, is this supposed to be entered as a bug in launcpad? Or is it to early?
<Mez> argh
<Mez> someone give me something to kill
* siretart hides the dagger from mez
<TheMuso> c
<siretart> tortho: launchpad is the right place for this
<Mez> sorry
<Mez> very frustrated... at the moment
<Mez> and not in a good way
<siretart> tortho: use this link https://launchpad.net/distros/ubuntu/+source/gtk-gnutella/+filebug
<tortho> siretart: Thanks, Reported.
<siretart> tortho: your report confuses me because of https://launchpad.net/distros/ubuntu/+source/gtk-gnutella/+bug/6472
<Ubugtu> Malone bug 6472: "[breezy]  gtk-gnutella reports "*** RUNNING AN OLD VERSION ***"" Fix req. for: gtk-gnutella (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: Unconfirmed
<siretart> you report it was working in breezy, the other user that it was not. This indicates me that it might be not only depending on the version
<tortho> I have been running breezy since it was released, without any problems.. If you have a look on their web page, the only version wich should be "blocked" is the 0.95 version and that was from the 22. of november i I remember right..
<tortho> siretart:  From the page:: Version 0.96b is a beta version of forthcoming 0.96. It is now mandatory to use this beta version as the 0.95.x series is about to expire on November 26th.
<siretart> tortho: I'm not familar to gnutella nor to gtk-gnutella at all. That was just a guess
<ajmitch_> how very annoying, that they break compatibility so quickly
<ajmitch_> hey koke :)
<tortho> siretart: I duplicated those bugs... the bad thing is that i downloaded the original package from their website and it doesn't work either.
<raphink> still about 110 packages to review and there we are :)
<raphink> lol
<ajmitch_> morning \sh
<\sh> moins ajmitch_ sitting in an office and try to destroy cacti :) or better improve it
<ajmitch_> hehe
* ajmitch_ is just doing a dist-upgrade
<ajmitch_> and then I might see if I can get qt4 to be installable before tomorrow morning
<ajmitch_> \sh: try & install libqt4-dev :)
<\sh> ajmitch_: kick someone who is not \sh :) looking for a fix just now :)
<ajmitch_> hehe
<ajmitch_> probably just drop the dep from control
<ajmitch_> I talked to riddell briefly
<Riddell> ajmitch_: I'll look at qt4
<ajmitch_> we don't have the package needed here, and I don't know enough about the -pic crack :)
<ajmitch_> Riddell: thanks
<Tonio_> anyone's got a few minutes to revu jRe's "keep" ? http://revu.tauware.de/details.py?upid=1601
<ajmitch_> sigh
<ajmitch_> mail to utnubu-discuss from me just doesn't seem to get through
<ajmitch_> lucas: did you receive the email I sent? it was addressed to you & Cc: utnubu-discuss
<lucas> I got it, yes
<lucas> are you subscribed ?
<ajmitch_> yes
<ajmitch_> with my debian.org address
<lucas> strange
<ajmitch_> quite strange
<to2> hi!
<ajmitch_> hello
<to2> Where is the home from 'ubuntu-motu'? america?
<dholbach> 'home'?
<dholbach> We're located around the globe, luckily.
<raphink> this is our home here :)
<raphink> welcome home
<raphink> come sit by the fire :)
<raphink> and have yourself a drink
<Yagisan> to2: earth
<raphink> so far I think we're all on earth, yeah
<raphink> except sabdfl, from time to time ;)
<to2> 'ubuntu-motu' was set in which country - sorry my english is not the best!
<Yagisan> to2: no single country. so earth
<raphink> you mean the chan? the ML?
<to2> no land - no time!
<dholbach> a couple of countries, all the time :)
<to2> raphink, how late in your country?
<raphink> :)
<raphink> 13:02
<Yagisan> 23:02
<to2> in germany it is 'the same'
<to2> 13:02
<to2> Yagisan, 'where is your homeland'?
<Yagisan> to2: Australia
<to2> ... so far
<to2> from my living room
<to2> ciao - bye, bye - aufwiedersehen ...
<KuriKai> hello
<KuriKai> anyoen see this?
<raphink> hi KuriKai
<raphink> ajmitch_: grep-dctrl that you gave me searches in control files of the binaries it seems, so it can't find Build-Depends
<raphink> ajmitch_: or am I missing something?
<KuriKai> cool people can see what i type
<KuriKai> cause yagisan cant
<raphink> ah?
<KuriKai> he was in the channel a bit ago
<azeem> raphink: you can tell it to search Sources.gz as well, I believe
<KuriKai> im going to be hosting doomsday ubuntu packages
<raphink> hmm let's see
<raphink> I don't seem to find this in the manual but I'll serach again
<Yagisan> ???
<Yagisan> raphink: I must be getting popular now - people look for me even in the wrong channel
<raphink> hehe
<raphink> :)
<Yagisan> raphink: he's a mirror operator for a can't-be-in-ubuntu-because-upstream-stuffed-up package
<raphink> stuffed up?
<raphink> how do you mean?
<Yagisan> raphink: although, finally upstream is fixing the mess
<raphink> ok
<Yagisan> raphink: mixed licenses
<raphink> ok
<Yagisan> raphink: they are rewriting, and properly copyrighting the source code now, so in a few versions it will be an in-ubuntu-package. probably at dapper + 3 at upstreams pace
<raphink> ok
<Yagisan> raphink: it seems repeated cluebats helped :)
* raphink doesn't understand how to use grep-dctrl :s
<raphink> grr
<StevenK> raphink: grep-dctrl -F<Search Fields> -s<Fields to show> data < /var/lib/apt/lists/...
<raphink> yeah just found out
<raphink> thanks :)
<StevenK> steven@broken:~% grep-dctrl -FMaintainer -sPackage stevenk /var/lib/apt/lists/au.archive.ubuntu.com_ubuntu_dists_breezy_main_binary-i386_Packages
<StevenK> Package: linda
<Yagisan> raphink: could you check something for me. can you /msg me ? just type anything
<raphink> StevenK: :)
<Yagisan> raphink: thanks. not my client that is broken.
<raphink> :)
<raphink> this guy might not be registered
<raphink> ;)
<raphink> on freenode
<StevenK> raphink: Just remember, F is for Find, and s is for Show.
<raphink> yes
<StevenK> -sPackage,Installed-Size or so works too.
<raphink> I just missed the < file
<Yagisan> raphink: ah - thanks
<raphink> I had to find where the source files where
<raphink> since I wanted to grep for Build-Depends
<raphink> thanks much StevenK :)
<StevenK> No problem.
<raphink> dholbach: should I file bugs for these ? https://wiki.ubuntu.com/MOTU/Transitions/Automake
<raphink> or juts fix them and upload them
<raphink> ?
<dholbach> As you like it.
<raphink> ok
<raphink> :)
<tseng> dholbach: when/have UVF requests gone to matt/collin?
<raphink> I thought there would be more FTFS because of this. Won't be as long as I excpected it
<dholbach> 4h ago or something
<tseng> thanks
<\sh> raphink: are they needed those dependencies, or can we regenerate automake stuff locally and provide them as patch to the source files?
<raphink> I think they are needed, otherwise they wouldn't be there
<raphink> I'm rather for bumping automake1.6 to automake1.9 in these packages
<jc-denton> i'm looking for a way to try out beagle 0.2 w/o building mono from source
<\sh> raphink: cool :)
<raphink> :)
<raphink> \sh: that's a minimal harmful change
<dholbach> \sh: does ooqstart work with oo2?
<\sh> dholbach: I adjusted the install deps for openoffice.org2 first...I can't test right now, if it's really working.
<\sh> dholbach: has to wait until this late evening
<\sh> or night better
<dholbach> I worked on this quite a while and didn't get it working.
<dholbach> So I'm interested if you really fixed it.
<dholbach> What I found out in the end was that on Linux OO.o2 didn't support the preloading at that time.
<dholbach> Hopefully it got better.
<\sh> well, if it's not working that it's quite useless ...
<\sh> dholbach: what does real upstream say about this lack of cooperation between ooqstart and OO.o2?
<dholbach> I didn't mail the lists, it was very shortly before Breezy release.
<dholbach> So I tried to fix the code and read as much info on the web as I could find.
<Tonio_> dholbach: heya ;)
<dholbach> hi tonio_
<Tonio_> dholbach: will you be there at the CC ? I fill finally introduce toonight :)
<dholbach> When is it?
<Tonio_> dholbach: this time is the good one !
<Tonio_> today, 21 UTC
<dholbach> No, sorry I won't make it. :-/
<Tonio_> no pb :)
<siretart> dholbach: did you already get an answer for the pending uvf requests?
<dholbach> siretart: nope.
<siretart> ok
<ejofee_> will gaim-2.0.0.beta2 (launched several minutes ago) be built for dapper?
<\sh> dholbach: ooqstart is not working...but I can't debug it...how can I start the applet from the console and see what (not) happens
<\sh> ejofee_: we are in upstream version freeze period.
<\sh> ejofee_: and gaim is IMHO in main, and must be supported for 3 years for dapper, so it's unlikely that a beta will go into dapper...but actually we can think about the final release :)
<ogra> \sh, it really depends how quick they are to release their final
<ejofee_> \sh: what about including both, in parallel? the standard gaim, and a supplementary gaim2 (just like we did with openoffice2)
<ogra> we wont duplicate apps in main
<ejofee_> ogra: no, not in main
<ogra> but in case gaim2 will enter, gaim will move to universe
<ejofee_> ogra: oh, ubuntu-motu only deals with main?
<ogra> nope
<\sh> ejofee_: no...only with universe...but ogra is main :)
<ejofee_> :)
<ejofee_> ogra, \sh: building the gaim beta and making it available could be nice to do, as they don't offer any debian / ubuntu version on their site
<\sh> ogra: well...right now gaim is quite stable...and gaim2 is not tested properly for dapper so I think for dapper it can be a nogo for main..but this depends on the exception of gnome uploads I think
<\sh> ejofee_: they actually know why :)
<ejofee_> \sh: they know why? what do you mean?
<ejofee_> \sh: debianers don't like to be... beta testers?
<ogra> \sh, its in consideration and will depend on how fast the release their final
<\sh> ejofee_: debianers can always compile it from source :)
<ogra> +putting it in universe *now* not packaged by the future main maintainer would be very silly
<ogra> since it duplicates work
<\sh> ok...I have to go now...
<ogra> so just be patient and poke the gaim2 devs to get the final ready :)
<\sh> cu laters when I'm back at home...around 19 or 20 UTC
<\sh> bye
<bddebian> Heya gang
<siretart> huhu bddebian !
<bddebian> Heya siretart
<raphink> argh
<raphink> auto update in debian/rules
<raphink> eviiiiiiiiil
<Lathiat> haha
<raphink> grr
<bddebian> Heh
<raphink> pff
<raphink> how can Debian packages still use this crap
<raphink> jpatrick: ready for tonight?
<jpatrick> raphink: yes, sir
<raphink> good :)
<raphink> WikiPage ready?
<jpatrick> Not a lot I can do to it...
<raphink> ok :)
<raphink> lol
<stratus> raphink,, auto update thing is really evil and ftpmasters aren't accepting NEW packages with that crap.
<raphink> yes I know stratus thats why I'm surpsied to find it in a package that comes from Debian
<stratus> raphink, btw you're free to bug old packages
<dholbach> raphink: You'd be surprised with a lot of packages. :-)
<raphink> yes I guess dholbach
<raphink> for now I'm bumping this one to automake1.9
<stratus> raphink, there's a lot of people in Debian trying to put more than 15000 packages in shape but unfortunately some others don't do the same.
<raphink> because it build-depends on automake1.6
<LaserJock> lucas: around?
<raphink> and the auto update option prevented me from doing so
<stratus> raphink, bug reports are the best thing to do. With these the DDs that cares about QA can act faster.
<raphink> stratus: I'm fixing it in Ubuntu frist
<raphink> then reporting to Debian
<raphink> with the patch
<stratus> btw, i already back merged a package from ubuntu with the auto update cdbs thing
<stratus> of course i get rid of that before uploading it to Debian
<raphink> sure
<raphink> stratus: you're a DD?
<stratus> raphink, yes like some others around.
<raphink> ok
<raphink> maybe you could merge this into Debian :)
<stratus> raphink, sure if you can open a bug report to Debian inform me the bug number or mail me with the details and i'll open the bug and do the rest with the package maintainer, thanks.
<raphink> stratus: shall I open a bug on the BTS and post my debdiff on malone so you can get it and adapt it?
<stratus> raphink, yes, but you can attach a patch in your BTS report. You even can tag it as containing a patch with what we call a 'pseudo-header' using   Tag: patch
<raphink> hmm
<raphink> but I might not put my ubuntu patch directly
<raphink> that wouldn't be appreciated, would it?
<stratus> raphink, i think everything will be appreciated with the exception of debian/changelog
<raphink> stratus: so I should remove the debian/changelog part from the patch before submitting?
<stratus> raphink, yes. You just should list the changes in your bug report (the message body).
<raphink> ok
<stratus> raphink, thanks
<stratus> raphink, any problem ask me. I hope it will be easier to you merge changes with the next package in Debian.
<LaserJock> hhmm, I think it might be useful to do a motu-school session on bug reporting and interaction with Debian for MOTU(Hopefuls)
<bddebian> Hmm, I think I might be worthless :'-(
<raphink> hmm
<raphink> just commited the change but ....
<lucas> LaserJock: pong
<raphink> stratus: it seems this package was bumped from Debian in the meanwhile
<stratus> raphink, which package?
<raphink> kboincspy-cvs
<raphink> kboincspy is still in both ubuntu and debian
<raphink> but kboincspy-cvs is a cvs snapshot
<LaserJock> lucas: I was reading your DCT and utnubu-discuss stuff. Do you think that you can get many DDs to accept the DCT?
<raphink> last version merged from Debian is from march 2005
<raphink> and it doesn't exist in sid anymore
<lucas> LaserJock: my problem now is to get many ubuntu devs to participate
<lucas> regarding DDs, probabl
<lucas> y
<stratus> raphink, looking..
<raphink> stratus: sure :)
<LaserJock> hmm, I'm really stuggling to understand this issue
<tseng> LaserJock: you can struggle forever
<tseng> LaserJock: if you make one set of DD's stop complaining, you will piss off another
<tseng> see multiple opinions on Maintainer: field or what have you
<teprrr> hmm.
<LaserJock> tseng: true, I just am trying to find my place in all of this. I have never done much with Debian. Ubuntu has been my first real .deb experience.
<minghua> LaserJock: Do you keep track of our feedback on science-related packages?
<LaserJock> minghua: what do you mean by feedback?
<minghua> LaserJock: I was thinking of using the usertag in Debian BTS to track this
<azeem> minghua: how?
<minghua> LaserJock: I mean ITP/RFP and bug reports for Debian
<raphink> hmm kvpnc was nuked from sid, too stratus. But we still maintain it in Ubuntu, even recently
<azeem> ah
<minghua> LaserJock: we keep doing good feedback for, say, three months, then after that we can point people to some pages and say:
<raphink> or maybe it never was in Debian
<LaserJock> I would like to keep track of things but I really don't know how to work with Debian very well and it seems like all of these discussions assume it is a lack of interest that is the problem and not a lack of know-how, which is my problem
<stratus> raphink, yes that -cvs package was removed the kboincspy maintainer was maintaining kboincspy-cvs too but opted to keep just the releases and not follow the cvs anymore.
<raphink> stratus: so shall we nuke it too?
<minghua> these are what we have done for the past months, we reported X bugs, and Y of them got fixed, Z of them got response from Debian maintainer and the rest are simply ignored
<minghua> LaserJock: I would volunteer to do that
<stratus> raphink, i think it's with dholbach or ogra but if you don't have a fork of the package in my opinion yes.
<minghua> LaserJock: and write a small howto to motu-science list
<azeem> minghua: that is not different w.g. with bugs reported against GNOME's bugzilla
<LaserJock> minghua: right, I would really love to seem some actual numbers
<azeem> eh, s/w.g./e.g./
<lucas> LaserJock: that's one of the goals of DCT
<minghua> LaserJock: I just need to know what we did from you :-)
<lucas> work only with maintainers who care
<minghua> azeem: I just want to provide some data to DDs, at least the debian-science list
<minghua> azeem: and show them we tried to contribute back
<minghua> if the number of bugs getting ignored is too large, then at least on next flamewar they can't blame everything on ubuntu
<LaserJock> I'm working on writing up a MOTU Science Update to send to debian-science with stuff that we've done and where we currently are
<minghua> LaserJock: do you like that idea?
<LaserJock> minghua: I do, I just need to get some ideas put together.
<minghua> LaserJock: I'll starting doing that tomorrow then.  Today is for the CC meeting :-)
<LaserJock> minghua: going for membership?
<minghua> yes.  and speaking of that, any MOTU would show up and be my advocate? :-)
<LaserJock> minghua: when is the meeting?
<minghua> 21:00 UTC
<azeem> minghua: are you reporting bugs, or sending patches?
<minghua> azeem: about the usertag thing?
<lucas> minghua: what's your wiki homepage ?
<LaserJock> minghua: I can probably be there. I'm no MOTU but I can at least say something.
<minghua> lucas: /MingHua
<azeem> minghua: no, I mean about those numbers of bugs being ignored by DDs
<minghua> I finished most of my wiki page, the "future plan" part still need work though
<minghua> azeem: my plan is basically tracking all ITPs/bugs/patches with usertag, so we can easily see them in one page
<lucas> "and is generally " => and am generally"
<azeem> minghua: well, ok.  That is a good thing in general of course
<minghua> azeem: then it should be easy to categorized finer
<raphink> ouch
<raphink> is that really allowed ? http://pastebin.com/520860 ...
<lucas> minghua: I'm not sure where that's the way to go (usertags)
<lucas> they are cool, but they lack some info
<azeem> raphink: which part?
* lucas has to think about it
<raphink> azeem: the download part
<minghua> lucas: thanks.  what info do you think is lacking?
<azeem> get-orig-source is not called by dpkg-buildpackage
<raphink> get-orig-source
<azeem> it is just a convenience I guess
<raphink> then what is it?
<raphink> a convenience?
<lucas> minghua: the global view
<azeem> raphink: an easy way to get the source for the maintainer
<LaserJock> minghua: well, I think that MOTUScience could be a good example of Ubuntu contribution to Debian and having a good working relationship but I think we need more info and tools
<raphink> hmmpf
<lucas> but I have to write the spec for https://wiki.ubuntu.com/DCT/SpecDatabase
<raphink> ok
<lucas> i'll have to think about it
<azeem> raphink: the upstream source is provided as .bz2, so they need to repack it to .orig.gz anyway
<raphink> yes
<minghua> lucas: I am writing the "plans" part, and I will give a more general view there.  I hope you can review that again when I finsh.  Thanks.
<minghua> LaserJock: I am doing what I can think of / capable of doing
<lucas> ok
<minghua> LaserJock: I'll worry about the big picture later :-)
<LaserJock> minghua: well, *we* need to do that, perhaps we should have a MOTUScience meeting some time
<LaserJock> but I do think in general a good motu-school session on working with Bugs would be nice
<minghua> LaserJock: my problem is I don't have much time for planning/organizing
<minghua> LaserJock: I want to do this because (1) I want to make MOTUScience a good example of Ubuntu-Debian collaboration, and this help that goal; and (2) I want to learn using usertags of Debian BTS
<LaserJock> minghua: well, I think I can do a fair amount of that, but I need to get feedback and info from those smarter than myself ( especially on the Debian side)
<pef> hello
<minghua> LaserJock: I'll write what I did and what others can benefit to motu-science list
<minghua> LaserJock: then let's see if other people like my idea / what I've done
<LaserJock> minghua: ok, I gotta push out some attempt at least of Packaging Guide today for the docteam but I will also try to put together some thoughts about MOTUScience
<LaserJock> minghua: sounds good
<minghua> LaserJock: no hurries :-)  If you feel the work with docteam is more important, by all means concentrate on that
<LaserJock> but already the package lists I made have been useful
<LaserJock> since I got them going we have been able to fix a few packages, get ITPs, found out we need to remove a couple.
<LaserJock> and now I can see what packages we can sync/merge without breaking UVF
<LaserJock> we had 9 packages (out of ~450 I think) that were in Ubuntu but not in Debian, shortly we will have only 2-4 and we have added 4 new packages to Debian
<bddebian> Nice
<LaserJock> But it wasn't terribly hard, I just needed to be able to see what was going on. (Thanks lucas for mdt)
<LaserJock> I really think the big thing is working with our differences in release and maintaintership
<LaserJock> there are times when we need to do things fast (UVF for example) and Debian doesn't have that pressure. In debian, for the most part, as long as all the DDs do there job everything is in good shape.
<LaserJock> but in Ubuntu, a package can get neglected pretty easily if a DD is not taking care of it because of our team maintainership
<LaserJock> or if it is not in Debian
<LaserJock> but then I'm not very knowledgable about these things and I'm just trying to figure these things out in my own mind
<minghua> lucas: Just finished my wiki page.  Can you look at it again?  Thanks.
<lucas> minghua: good
<lucas> I usually like to see some keywords in bold
<lucas> (for example, the Plans part is quite long, putting some keywords in perspective might help)
<minghua> lucas: you mean in the "plans" part, to show the focus of my interests?
<lucas> yes
<minghua> lucas: will do that, thanks for the review and comments
<minghua> some keywords / key phrases made bold
<lucas> perfect :)
* minghua goes for lunch
<dholbach> See you tomorrow - bye!
<LaserJock> hmm, if xchat-gnome had better handling of the user list I'd be inclined to use it :(
<LaserJock> dholbach: cya
<bddebian> Later dholbach
<Kyral> minghua isn't a memeber?
<Seveas> raphink, poke
<LaserJock> Kyral: guess not
<Kyral> daamn
<Kyral> now I have 3 people I'm vouching for lol
<LaserJock> Kyral: CC is in 2 hours right?
<crimsun> 1 hr
<crimsun> hmph, 2 hrs, but fridge reports 1 hr
<Kyral> LaserJock: I think its variabl
<LaserJock> crimsun: cause it is 1hr and 55 min which it takes as 1hr
<crimsun> silly rounding
<LaserJock> yep
<LaserJock> Kyral: what do you mean variable?
<Kyral> like whenever they are done they are done :P
<LaserJock> Kyral: I was just trying to figure out when it started
<LaserJock> thank goodness for "date -u"
<minghua> Kyral: no, not yet
<crimsun> I'm happy to vouch for you
<crimsun> though I think your current scim (both in Debian and in Ubuntu) work speaks for itself
<minghua> crimsun: great, thanks!
<minghua> Kyral: and thank you for vouching for me too
<minghua> I would hope so, but I think CC usually take MOTU's opinion seriously if I am going to touch universe packages
<minghua> and it's never bad to have advocates :-)
<Kyral> lol
<LaserJock> minghua: becoming a member isn't too tough, I think the TB is much tougher on MOTU candidates
<LaserJock> minghua: basically, if youv'e been working on Ubuntu for >= 2 months membership isn't too bad
<Kyral> Look at the cute puppy NOW! ;P
<Kyral> http://azuredream.homelinux.org/blog/
<LaserJock> Kyral: lol, my wife would love that dog
<Kyral> He never stops lol
<minghua> cute puppy
<minghua> LaserJock: yeah, I can imagine, but I plan to apply for MOTU soon, too
<minghua> it won't hurt to try, I suppose
<minghua> and at least they would tell me which area I should do more
<LaserJock> I'm thinking about it as well
<\sh> raphink: why didn't you update debian/control.in to use automake1.9 in kboincspy-cvs?
<Kyral> I'm not ready to be MOTU
* bddebian isn't either ;-)
<Kyral> pfft
<\sh> bddebian: wasn't, barry, wasn't..you are already one :) and I hope you will rock during dapper+1 again :)
<LaserJock> Kyral: I'm not sure if I am but it would be at least good to see where I am at.
<Kyral> lol
<Kyral> LaserJock: I plan to try during Dapper + 1
<Kyral> Right now I'm glad GTKEdit is in Dapper now
<bddebian> \sh: I was but now I suck :'-(
<LaserJock> I have always looked at it this way, when not being a MOTU is getting in the way of me getting work done then maybe it is time to become a MOTU
<LaserJock> I think I am starting to get to that point in some areas (mostly in MOTUScience)
<\sh> bddebian: hey, easy, call a lawyer, tell him you want to be getting divorced, and you are not the father of those children, and actually, you don't want your job either...the lawyer can help *lol*
<ajmitch_> morning all
<LaserJock> hi ajmitch_
<tseng> hi ajmitch_
<\sh> bddebian: after this call, you will have a lot of time for MOTU, i mean, no fun anymore, but time for MOTU :)
<bddebian> \sh: Heh, I wish :-)
<bddebian> The job part anyway
<bddebian> Heya ajmitch_
<ajmitch_> \sh: well that's about where I am at the moment ;)
<ajmitch_> \sh: thanks for the qt4 upload ;)
<\sh> well...I was sitting today, the first time since >1 month, in an office again...and it was good to have people around me...and I was more productive somehow for motu since the last couple of weeks
<ajmitch_> \sh: now I should be able to grab it before the tutorial in ~90min
<\sh> ajmitch_: which tutorial?
<ajmitch_> http://lca2006.linux.org.au/abstract.php?id=379
<\sh> ajmitch_: that's more then cool...is anybody recording it on tape or digital as mpg?
<ajmitch_> yes
<\sh> ajmitch_: much cooler...
<ajmitch_> all going to a nice 5TB RAID box :)
<\sh> ajmitch_: I would be in need of this session somehow...and my wish is to attend it...it could be very interesting :)
<ajmitch_> it should be online in a few days, I guess
<\sh> but sadly I'm nut in dunedin :(
<\sh> i'm not even
<\sh> not nut :)
<ajmitch_> well... ;)
* ajmitch_ thinks anyone must be crazy in a way to be a MOTU
<LaserJock> +1 :-)
* \sh is not crazy, but totally insane
<tseng> you know pappy
<tseng> of course you are
<\sh> tseng: bah...thx
<ajmitch_> hehe
<ajmitch_> ok, time for me to get back down to the conference
<\sh> tseng: this comparison .... *beserk&
<\sh> killall -9 tseng
<tseng> hm
<\sh> mv /been/tseng /dev/null *harhar* :)
<bddebian> heh
* tseng SIGTERM
<\sh> tseng: you can't compare me with pappy :) please :) Now I'm crying
<tseng> it was a joke
<\sh> tseng: come on....don't you see my invisible ;)
<tseng> ja
<bddebian> Who is pappy?
<tseng> he is a nut
<bddebian> So am I, so what are you saying? :)
<tseng> you arent in the same weight class
<bddebian> I have just been a fucking worthless nut for dapper :'-(
<\sh> bddebian: believe me you are not :) because of this guy I had a muzzle on #ubuntu-devel
<\sh> bddebian: directly from mdz...that was I think before my time being a member or motu...I don't remember anymore
<bddebian> :-)
<bddebian> They just ignore me on -devel ;-)
<minghua> bddebian: you are not, I still saw your changelog entries when I did merging for dapper :-)
<bddebian> So what can/should I be working on if I get time? :-)
<ogra> bugs and reviews
* bddebian can't do reviews :-)
<bddebian> Are merges all done?
<crimsun> 99%
<crimsun> all the ones I've touched that don't need a newer upstream are done, at least
<bddebian> crimsun: Because you ROCK honey :-)
<crimsun> we all do :-)
* bddebian doesn't this go-round :-(
<crimsun> bah, you had excess from breezy ;-)
<Kyral> I'll be back in time for the Meeting
<sivang> Kyral: MOTU meeting I suppose?
<LaserJock> sivang: CC
* sivang pokes the fridge
<\sh> hmmm...anyone here with breezy?
<\sh> and have to time to check https://launchpad.net/malone/bugs/29453 ?
<Ubugtu> Malone bug 29453: "Installing programs" Fix req. for: Ubuntu, Severity: Normal, Assigned to: Nobody, Status: Unconfirmed
<bddebian> Sorry, Dapper only :-(
<minghua> hehe, that's the problem of a dev team :-)
<minghua> I have a few bugs I would like to test on breezy too
<minghua> maybe I'll install one after feature freeze
<LaserJock> I have a breezy chroot
<LaserJock> although now AMD64
<LaserJock> s/now/no/
<\sh> LaserJock: doesn't matter can you try it? I would have to regenerate my breezy i386 chroot frst
<LaserJock> \sh: I'll see what I can do
<LaserJock> \sh: I just need to install lilypond?
<\sh> lilypond-data and look postinst message
<LaserJock> \sh: ok I did "sudo apt-get install lilypond" and I don't get any error for lilypond-data (2.2.6-2)
<LaserJock> \sh: I just get : Running /usr/bin/mktexlsr /usr/share/texmf...
<LaserJock> mktexlsr: Updating /var/lib/texmf/ls-R-TEXMFMAIN...
<LaserJock> mktexlsr: Done.
<LaserJock>  GNU LilyPond configuration completed.
<LaserJock>  Please read /usr/share/doc/lilypond/README.Debian to get started.
<\sh> LaserJock: grmp...then I have to regenerate my breezy chroots...give me a couple of mins
<\sh> slomo: ping
<\sh> or anyone else: did anyone tried to play matroska files with vlc?
<Kyral> I have
<\sh> and?
<Kyral> you need libmatroska
<Kyral> or somesuch
<\sh> we have libmatroska-dev with static libs..and vlc is compiled to support it...but it breaks with a nice glibc message
<Kyral> oh
<Kyral> haven't tried recently ;P
<\sh> trying to recompile :)
<Kyral> It worked a couple months ago though
<\sh> slomo: I'm trying to get vlc buildable again (removing xlibs-static-pic)
<\sh> .oO(but some rationale why vlc needs a gcc-snapshot and not the normal toolchain gcc?)
<minghua> nothing written in the changelog?
* minghua wonders what it needs from gcc 4.1
<\sh> Build-depend on gcc-snapshot on i386 and amd64, because currently only
<\sh>       that version of gcc properly builds some of the MMX modules.
<\sh> minghua: changelog says:
<minghua> hmm, interesting
<minghua> it better be a recent changelog
<minghua> as the version of gcc-snapshots keeps changing
<\sh> minghua: 20 sep 2005
<minghua> fair enough then, sounds the debian maintainer has a good reason
<\sh> minghua: when I build it now, and tested it, I will try tomorrow to build it with just our toolchain compiler suite...until slomo will say something else...because he is my expert in things like video / sound packages ;)
<minghua> \sh: sure, I would like to see it use gcc instead of gcc-snapshot, too
<\sh> minghua: sure..right now I'm fixing some other bugs like missing mozilla-dev or something like this
<\sh> build run no. 2
<Kyral> Drinks on Tonio_
<Kyral> ;P
* Kyral hugs Tonio_ too
<Tonio_> hehe, thanks Kyral ;)
<Kyral> So when MOTU :P
<LaserJock> minghua: one last upload before CC? ;-)
<minghua> LaserJock: from me?
<minghua> LaserJock: ah, somebody else asked for the sync :-)
<ogra_> finally
<ogra_> i was waiting for it already, i asked on UVF day and elmo didnt have your mail address :)
<Kyral> minghua you should get in easy as well
<minghua> Oh ogra it's you, thanks a lot
<minghua> now I should go write the scim-tables UVF exception report :-)
<ogra_> yeah
#ubuntu-motu 2007-01-22
<crimsun> I was just about ask why kdm on feisty was kicking me out, and then I read ``df -h''
<crimsun> +to
<owh> I have a sideways question to ponder. Feel free to tell me to shut up. As a member of Launchpad, I signed the code of conduct and supplied a PGP key, like I'm expecting most here. I set my key to expire in two years. This is the second key I have "in the wild". I have not yet set a key to "never expire" and wondered what others do, specifically why they do it.
<somerville32> Mine is set to never expire
<crimsun> owh: out of paranoia, I set mine to expire annually
<owh> somerville32: But what if protocols are upgraded or change, then you have a key that floats around "forever".
<somerville32> owh, No. You can recall the key.
<somerville32> There is a revocation certificate or something
<owh> crimsun: That is my quandary. Am I being paranoid? I mean, my D/L expires, my Passport expires, so why not my key?
<crimsun> owh: my rationale is that many protocols have a timeout to mitigate certain attacks.
<persia> somerville32: One might lose the secret (fire, earthquake, lightning strike, tornado, typhoon, tsunami, etc.).  In that case, the revocation certificate is hard to distribute.
<owh> somerville32: I didn't know that. So, that would mean that you can revoke a key from the whole server tree, automatically, or does it mean that if some nefarious person has your key and refuses to revoke it, it can still be used?
<owh> persia: That's not as silly as it sounds.
<persia> owh: It wasn't meant as a joke.  My keys expire each year.
<owh> persia: I know. I didn't take it as such.
* somerville32 shrugs.
<somerville32> lol
<geser> you should ideally have already a revocation certificate
<somerville32> I guess it has never meant much to me
<somerville32> I mean, no one has ever signed my key
<geser> so you can upload it if you lose control over you key
<somerville32> I just use it when required
* owh was just signing an Insurance form and it needed to be on paper, but I was emailed a PDF. So I opened it in Gimp and sent them back a JPG :)
<owh> geser: That is an excellent suggestion. I suppose you could store that certificate on a disk at a bank.
<geser> or print it out
<owh> geser: Even better :-)
<owh> I suppose I've always been aware of keys, but I never had the opportunity to discuss the implications.
* owh resolves to read up about revoking a key.
<owh> Thanks all for indulging me on an OT question.
<crimsun> good thing you didn't sign them back a signed pdf
<crimsun> s/sign them/send them/
* enyc tries to remember what enyc discussed with crimsun previously ;-)
<owh> crimsun: Hmm, well, Acrobat allows you to digitally sign a PDF, but most offices wouldn't know what to do with it if it hit them :-)
<owh> Just found a useful article on the topic: http://www.spywarewarrior.com/uiuc/ss/revoke/pgp-revoke.htm
<owh> In addition to persia's comment, your hard disk may also crash and you'll be SOL.
<bddebian> OMG these packages are fsck'd up
<LaserJock> Adri2000: pong
<bddebian> Heya LaserJock
<Adri2000> LaserJock: what do you want to do for this bug https://launchpad.net/ubuntu/+source/genesis/+bug/80814, the man page already says to copy /usr/share/genesis/startup/simrc to ~/.simrc
<Ubugtu> Malone bug 80814 in genesis "genesis doesn't start from menu without ~/.simrc" [Undecided,Unconfirmed]  
<LaserJock> Adri2000: well it's no good if it's run from the menu
<LaserJock> Adri2000: people expect a menu entry to work
* persia thinks the .desktop file should be removed from genesis
<Adri2000> that's the other bug, Terminal=true is needed in the .desktop file
<LaserJock> yeah, but we already filed the bug in Debian and got it through
<LaserJock> I hate to go send an email saying "Ooops, please take it out again"
<LaserJock> but perhaps that's the way to go
<LaserJock> regardless I think that genesis doesn't handle it well
<LaserJock> they don't say where to get the .simrc file
<Adri2000> the man page does
<persia> The ,desktop file has two purposes: it allows execution from the menu, and includes the program in app-install-data.  Perhaps the menu entry can be hidden?
<LaserJock> I don't think that's sufficent
<LaserJock> persia: I don't mind a menu entry, it just should work
<LaserJock> that's why I filed two bugs there
<LaserJock> 1) the menu entry should work
<LaserJock> 2) genesis should copy the simrc file to ~/.simrc if it doesn't exist
* persia needs to look at Initial Reporter more carefully
<LaserJock> well, I filed them for a user that came to #ubuntu-science
<LaserJock> they wanted to try out genesis but when they clicked on the menu entry it didn't do anything
<LaserJock> when I asked to run it from a terminal they got that message
<Adri2000> that would be easy to patch the program to say "use cp /usr/share/... ~/.simrc" in the error message
<LaserJock> well, that would be a start
<LaserJock> but it's still not sufficent for me
<persia> Adri2000: Alternately, a wrapper script could be installed [ -f ~/simrc ]  || cp /usr/share/genesis/startup/simrc ~/.simrc
<LaserJock> that's more along the lines of what I was thinking
<LaserJock> if you used something like genesis-start and then had the .desktop call that
<LaserJock> it should be sufficient without fiddiling around with the source
<bddebian> Gah, why isn't debian/changelog getting installed? :-(
<bddebian> Err copyright I mean
<facenew> OT: a short movie mocking Kim Jong Il and his secret agent buying something from China: http://www.youtube.com/view_play_list?p=EE52D9ED01495685
<Adri2000> facenew: can you stop spamming channels please?
<_MMA_> Hello guys. thenetduck here wants to learn to package. I sent him here.
<thenetduck> oh thanks _MMA_ :)
<_MMA_> thenetduck: Start by looking at the links in the topic.
<LaserJock> welcome thenetduck 
<thenetduck> hi LaserJock , I just added myself to the launchpad is it too soon for me to do that? 
<LaserJock> thenetduck: what did you add yourself to in Launchpad?
<thenetduck> to the contributors of packages. I
<thenetduck> I haven't done anything yet but would to get involved 
<thenetduck> (I am out of school for a while and it has been a goal of mine to learn and contribute since I started using Ubuntu) 
<LaserJock> yes, that's fine. Do you have a gpg key on your launchpad account?
<thenetduck> I.. don't think so. 
<thenetduck> can you explain to me what a gpg key is? 
<LaserJock> !gpg
<ubotu> gpg is the GNU Privacy Guard.  See https://help.ubuntu.com/community/GnuPrivacyGuardHowto
<LaserJock> thenetduck: I'll let the wiki explain ^^ ;-)
<thenetduck> :) ok 
<thenetduck> ok so it makes it so that not just anyone is downloading or uploading to that server? Kind of like a real key to the door of a server? 
<thenetduck> LaserJock, ok so I looked up the keys and have this one gpg: /home/duck/.gnupg/trustdb.gpg: trustdb created
<thenetduck> 
<thenetduck> LaserJock, is that the correct key? or should I make a new one ?
<LaserJock> make a new one
<thenetduck> LaserJock, what is my key ID? 
<LaserJock> that is the unique ID of your new key
<LaserJock>  gpg --list-keys should list your key
<thenetduck> ok
<ToHellWithGA> is this the correct place to ask about tetex and texlive?  i heard that tetex may be dropped for texlive in the near future.
<Hobbsee> ToHellWithGA: FYI, i'ts a sunday in most countries
<ToHellWithGA> it's a monday in your country!
<Hobbsee> true that, but i'm an aussie
<LaserJock> ToHellWithGA: I don't think Ubuntu would really make that decision. Debian is where that decision would most likely take place
<ToHellWithGA> oh right on then.  i'm afraid of those guys so i guess i'll jsut watch it play out :/
<LaserJock> ToHellWithGA: I can't imagine tetex going away very soon. texlive has still got a fair amount of bugs to work out it seems to me
<ToHellWithGA> i was not a fan of the texlive cd
<ToHellWithGA> so i can't see how it could be much better under *buntu
<LaserJock> well, I think gradually texlive will become the preferred tex distribution
<ToHellWithGA> i don't think of debian folks as hasty, so i reckon the transition will be smooth when it happens
<LaserJock> I would hope so
<ToHellWithGA> thanks for the explanation LaserJock 
<LaserJock> the Debian TeX maintainers are pretty good
<LaserJock> they seem on top of it
<ToHellWithGA> i'll leave you cats to your dev club channel :)
<ToHellWithGA> peace out
<thenetduck> hey, I get this when I type in gpg --list-keys 
<thenetduck> pub   1024D/00F267E8 2007-01-22
<thenetduck> uid                  Sterling Cobb (This is me! First time I used my name and email address at the same to so thats a lot of trust.) <thenetduck@gmail.com>
<thenetduck> sub   2048g/87C36AD8 2007-01-22
<thenetduck> doesn't make since 
<Hobbsee> 00F267E8 is the key ID.
<thenetduck> Hobbsee, thank you
<thenetduck> does it really take about an hour for these keys to sync up with the key server/ 
<bddebian> crimsun: You aboot?
<crimsun> eh?
<bddebian> crimsun: Do you happen to have a minute for another quick review for me?
<crimsun> sure. Will be a bit lagged.
<bddebian> NP
<bddebian>  libticables2-1
<bddebian> I'm trying to get back into LaserJock's good graces ;-)
<ajmitch> good luck with that
<crimsun> yeah, talk about a slavedriver ;)
<bddebian> Heya ajmitch
<bddebian> Ah, so I am in the dog-house with him eh?
<LaserJock> hmm
<LaserJock> bddebian: is that an SRU?
<thenetduck> LaserJock, I have gotten a gpg all set up anything else I should do? :)
<bddebian> LaserJock: No, I'm going through your bug list again :-)
<bddebian> Is it bad policy to delete a file on postinst?
<persia> bddebian: Plenty of packages do that, but apparently only when transitioning from one method of doing things to another.  I can't speak to policy though.
<bddebian> persia: Well eagle creates a .eaglerc because it runs on postinst, therefore it gets created with root perms.  It has to in order to create the license file. So I was thinking just deleting .eaglerc after the fact..
<persia> bddebian: I can't find anything in policy that indicates you shoudn't do that, but can you be sure which .eaglerc is being created?  I'm thinking about the case of a package upgrade by a user running `sudo aptitude` from their home directory.  How does this interact with the license process?
<bddebian> persia: The license gets in ~/eagle afaict.  And apt-get runs as sudo right?  So what would be different.  (Probably dumb question, sorry)
<persia> bddebian: Let me look at the specific package.  In general, I thought the user might have put customisation in ~/.eaglerc, in which case deleting this would fall under loss of user data.
<bddebian> Lethargy: ?? :)
<bddebian> Anyone know if we have a Yahtzee time game in the archives at all? :)
<persia> bddebian: Tali
<Lethargy> bddebian, :D
<persia> bddebian: Ah, are you trying to address the "run once as root" problem with eagle?
<bddebian> persia: Aye
<bddebian> persia: And I don't see a "Tali" in the archive?
<persia> bddebian: That's why I'm not finding anything about .eaglerc :)  One solution would be to run su -l root -c eagle && rm ~root/,eaglerc in postinst.  This avoids collision with the user configuration, although I haven't tested it.
<persia> bddebian: gnome-games provides /usr/games/gtali.
<bddebian> persia: It doesn't get in ~root, it gets in ~<user>
<bddebian> Oh and thanks for gnome-games :)
<persia> bddebian: with su -l?
<bddebian> Oh.. Hmm
<persia> bddebian: No worries.  Ask me about games anytime :)
<bddebian> Well I keep meaning to focus on games but I keep getting "distracted" :)
<persia> bddebian: https://bugs.launchpad.net/~motugames/+assignedbugs doesn't include as much as it should (and it should probably be subscribed), but is one of the places I like to check for games, or do you mean actually playing them?
<bddebian> persia: No, I meant fixing them/packaging them.  When I play games I stick to RPGs in Windows :-(
<persia> bddebian: From what I can tell, it's the plot.  There are plenty of great engines available, but few plots are free.  Something about a return on creative energies.
<bddebian> Yeah :-(
<nixternal> DA BEARS!!!
<bddebian> Heh
<LaserJock> heh
<persia> Is anyone familiar with xmllint?  Is echoing the entire XML file an indication that there are no problems?
<LaserJock> Colts are going to kick the Bear's butt
<bddebian> LaserJock: Colts lost :-(
<bddebian> persia: Not me, ,sorry
<LaserJock> persia: that doesn't sound quite right
<LaserJock> how are you calling it?
<LaserJock> bddebian: no way
<persia> LaserJock: That's what I thought.  I'm working on #4736, and xmllint echoes my local preferences.xml while reporting problems with the submitters preferences.xml.  I'm trying to determine if torcs' xml parsing is completely broken or just not good at entity handling.
<persia> LaserJock: xmllint preferences.xml
<LaserJock> persia: try xmllint --noout --postvalid preferences.xml
<persia> LaserJock: Thanks, that works as expected.  I wonder why xmllint is so verbose by default.
<bddebian> Man, I can't fix shit :-(
<persia> Are -dbgsym packages only created for main, or just when packages are rebuilt?
<bddebian> LaserJock: Holy crap, I lied, the Colts did pull it out
<LaserJock> yeah
<LaserJock> bddebian: I wasn't lying to ya dude ;-)
<bddebian> LaserJock: I stopped watching and a buddy told me that NE won so I didn't pay attention :-(
<TheMuso> c
<LaserJock> d
<LaserJock> nixternal: you put money on the Saints?!?!
<bddebian> Well obviously the genesis bug doesn't seem that difficult but how do you keep .simrc from being root owned?
<persia> bddebian: The solution dicussed earlier was to have the .desktop call genesis-startup, which was `[ -f ~/.simrc ]   cp /usr/share/genesis/startup/simrc ~/.simrc; genesis`.  Also, add Terminal=true to the .desktop file.
<persia> bddebian: I think Adrian is working on it.
<bddebian> persia: OK but what if they run it from the CL? :)
<persia> bddebian: If they run it from the CLI, the error message is posted.  Perhaps the source needs to have the error message made nicer?
<persia> bddebian: Alternately, install genesis as the wrapper, and have /usr/bin/genesis.real be the actual binary :)
<bddebian> Or install .simrc with 777? ;-P
<persia> bddebian: I don't think it is a good idea to install it in the postinst, as the system may be a multiuser system, and a new user may be created, for whom there is no .simrc.
<bddebian> What is the "working" dir for genesis, ,do you know?
<bddebian> Like why isn't there an /etc/genesis/.simrc or some such?
<persia> bddebian: I don't know (I've never used genesis: just was thinking about these bugs yesterday).
<LaserJock> well
<LaserJock> I think providing a wrapper around genesis wouldn't be that hard
<LaserJock> although it aggravates me when upstreams don't take the time to think about this sort of thing
<bddebian> I suppose the easiest thing would be to add the wrapper genesis_startup or something from the menu or .desktop file and have it check if ~/.simrc exists and if not copy it.  If they run it from the CL, they'll get the error and know what to do I suppose.
<LaserJock> well, I think running it from CL should do the same thing though
<LaserJock> but it should at least work from the menu
<persia> bddebian: IF you're worried about the command line interface, reference the wrapper in bristol.  /usr/bin/bristol is a shell script that does all the fancy stuff, and /usr/bin/bristol.real is the actual executable.
<bddebian> Well we could hack the executable itself I suppose :-)
<LaserJock> I'm just not sure if it's a good idea to move the genesis binary to binary.real
<persia> LaserJock: Why not, if it is to be wrapped?
<LaserJock> persia: if something else relies on /usr/bin/genesis being the binary
<LaserJock> it's probably perfectly safe in this instance
<bddebian> persia: I have to agree with LaserJock.  What if something else expects it there?  Say genesis-convert or whatever that is
<LaserJock> but just moving around binaries seems a little invasive
<LaserJock> bddebian: in that instance though still, the wrapper just calls genesis.real
<LaserJock> so it's just adding a couple lines before executing it
<persia> I see.  I'm not sure most of that can't be worked around using $*, but it's probably safer not to modify it (especially for non-regular users).
<LaserJock> I can't see how it would do any harm
<bddebian> LaserJock: I mean /usr/bin/genesis-convert exists already.  Does it expect genesis?
<LaserJock> bddebian: doesn't matter though
<bddebian> Why not?
<LaserJock> because it will get genesis if it runs genesis
<LaserJock> it just has a couple lines of code inbetween
<bddebian> Ahh I see what you mean
<LaserJock> but I can see if there was hardcoding somewhere there could be a possibility of something going wrong
<bddebian> Oh well, I digress and have to get my old butt to bed.  Gnight gang
<persia> Good night bddebian
<LaserJock> oh my gosh, gnuplot just ploted my data as ASCII art!
<ciscosurfer> Does anyone know if the Feisty devs or package maintainers plan on backporting Xfce 4.4 to Edgy?
<Mez> ciscosurfer, http://launchpad.net/edgy-backports/
<Mez> and - ciscosurfer I'm one of the backports team - I'm not going to look at it - seems a nightmare - jdong might
<ciscosurfer> Mez: okay.  Thanks for the repsonse though.  Maybe I can get JDong to agree :-)
<ciscosurfer> Mez: will it be in Feisty (or is it already?)
<ciscosurfer> Mez: I realize you are on the backports team, but thought I'd ask anyhow :-)
<Mez> ciscosurfer, -> #xubuntu
<Mez> I dont use XFCE - ask in there
<ciscosurfer> okay, i'll give it a shot
<ciscosurfer> thanks
<StevenK> TheMuso: Ping, re: espeak 1.18
<persia> Could anyone familiar with C++ help me find the typo in this patch: http://paste.ubuntu-nl.org/2521/
<persia> nevermind.  Sorry for the spam.
<LaserJock> persia: spam? I usually don't think of 1 line as being spam
<persia> LaserJock: At least for my client, I receive notice whenever there is traffic, so useless traffic generates useless activity on my part.  On the other hand, please take a look at bug 4736!
<Ubugtu> Malone bug 4736 in torcs "torcs b0rks preferences.xml and then crashes on it" [Medium,Confirmed]  https://launchpad.net/bugs/4736
<StevenK> persia: Surely there has to be other variables to replace than just <, >, and &?
<StevenK> s/variables/entities/
<persia> StevenK: Torcs doesn't crash when I use ";" as a control character.  What other characters do you suggest changing?
<StevenK> I'm not sure, since my XML escaping is a little rusty.
<persia> StevenK: I'm not familiar with all keyboards in use, but I think only ;, <, and > are common XML characters that are also unshifted characters on some keyboards.
<StevenK> Personally, I'd assign curParam->value to a temporary value, and then switch() on it, changing the temporary variable to the entity, and then printing the whole lot.
<persia> StevenK: I didn't think switch() worked for strings in C++, but I'm mostly famliar with C.
<StevenK> It's a char, not a string, surely?
<persia> StevenK: It's a string.  The interface limits it to a single character for controls, but the same output interface is also used for things like the Player name, and I'm not writing a patch that separates that: upstream can change it if they really want.
<StevenK> persia: *nod* And use strncmp
<persia> StevenK: strncmp, not strcmp?
<StevenK> Hold on, is it a STL string, or a char *?
<StevenK> persia: A caveat is that my C++ is rusty as hell. :-)
<persia> StevenK: char* (my C++ is based on the assumption that mostly it's like C).
* StevenK nods
<StevenK> Right, for char *, use strncmp(). STL strings come with their own comparsion routines and headaches.
* persia goes to update the patch
<StevenK> Note strncmp() of course takes 3 arguments. :-)
<persia> StevenK: man page indicates strncmp(str1, str2, n).  Does that match your memory?
<StevenK> Indeed
<StevenK> persia: Perhaps you should say strncmp() == 0, given that strncmp() can return less than 0, which means curParam->value was less than "&".
<persia> StevenK: Thanks for your refinements.  I've been eyeing this bug for the past year, and this is the first time my solution worked without regressions.
<StevenK> persia: Any time. :-)
* StevenK is looking forward to a drivable racing game under Linux.
<cypher1> persia: just for my interest..can i look at your patch ?
<persia> StevenK: Regarding strncmp==0, I've always thought !strcmp() was cleaner, but I suppose it is a personal preference.  if (! (-1) ) should still not execute.
<persia> cypher1: see bug 4736
<Ubugtu> Malone bug 4736 in torcs "torcs b0rks preferences.xml and then crashes on it" [Medium,Confirmed]  https://launchpad.net/bugs/4736
<cypher1> persia: thanks..
<StevenK> persia: !strncmp() should match two cases, though?
<persia> StevenK: Is your keyboard one of those affected?  I thought the common keyboard there used shift for &, <, and > (and ; is kept in an awkward location).
<StevenK> persia: I have to shift for &, < and >
<persia> StevenK: That's what I thought.  My understanding is that < is a base key only for some of Europe and Brasil, but I'm not certain of that.
<StevenK> I was going to use Dvorak as an example, but that requires shift as well.
<persia> StevenK: My understanding is that those characters are only base in places where the typography calls for common use as containers (e.g. <hello world>).
<cypher1> persia: is "&lt" is what we have use to represent "<" in an xml file ?
<persia> cypher1: http://www.xml.com/pub/a/98/08/xmlqna0.html
<cypher1> persia: thank you.. how about the other two predefined entities ' and "
<persia> cypher1: I'm testing now...
<cypher1> persia: ok :)
<persia> cypher1: Thanks for prompting me.  I'd been remembering my XML, rather than looking it up :)
<cypher1> persia: no problem :)
<cypher1> persia: i am looking for a bug to fix in C++.. any idea anything is open ?
<cypher1> persia: since i am learning C++ .. and would love to code something
<cypher1> persia: is ur name inspired from prince of persia ??
<persia> cypher1: No.  I used to say "Yeah, and I'm the king of Persia" when someone said something obviously false (Persia chose to change it's name in the early 20th century, and never had a king).  When I received my first UNIX account, I was assigned that handle.
<cypher1> persia: cool
<persia> cypher1: Take a look at bug 69433.  Half the fun is finding the crash, at which point you get to fix it with C++.
<Ubugtu> Malone bug 69433 in glob2 "crash upon canceling of further campaigns" [Undecided,Unconfirmed]  https://launchpad.net/bugs/69433
<dholbach> good morning
<ajmitch> morning dholbach 
<cypher1> persia: thanks.. let me have a look
<cypher1> dholbach: good morning !
<dholbach> hiya ajmitch, hey cypher1
<raphink> hi ajmitch, dholbach
<dholbach> hey raphink
<ajmitch> hey raphink 
<raphink> what's up?
* ajmitch is wishing that he got to code in python at work, not php
<raphink> :s
* raphink is having fun trying to see how far bash replacement strings can be used
<raphink> instead of sed
<raphink> I think the limit is not very high though :(
<ajmitch> hehe
<raphink> i.e. ${FOO##bar1%bar2} doesn't work
<raphink> nor does ${FOO/.*_\([1-9a-z] *\)\.changes/\1}
<raphink> :(
* ajmitch tends not to touch those parts of bash
<raphink> hehe
* raphink adds dinstall-like basic functionality to his mirror scripts to send back "INSTALLED" mails to buildds :)
<raphink> that's fun :)
<ajmitch> nice :)
* ajmitch was just playing with some list comprehensions with python
<ajmitch> useful features
<raphink> mhm
<raphink> buildd/wanna-build is still quite complicate
<\sh> moins
<persia> I'm looking over unmetdeps, and there are many binaries in universe that are no longer built.  Could someone show be a template bug that matches those I should file.  I have heard that OUTDATED doesn't include universe.
<ajmitch> hey \sh 
<ajmitch> persia: search for one with UNMET in the title?
<ajmitch> or is that not what you need?
<persia> ajmitch: The few I've just looked at aren't really what I need.  They seem to either be rebuild requests, or require small patches to debian/control to build properly.  I'm looking for a bug to complain about packages that are no longer built from current source.  My memory is that Tollef reported that OUTDATED didn't include universe, and there seem to be a fair number in the unmet list.
<asimon> Hello, I lost connection during uploading something to REVU (gtk2-engines-qtcurve). Now I cant reupload the package because of already existing files. Is there something I can do to fix this (dcut doesn't seem to help) or should I mail the revu admins? Thanks.
<gpocentek> asimon: did you try 'dput -f *source.changes' ?
<asimon> gpocentek: Yes, I still get an '553 Could not create file.'-error with -f
<gpocentek> asimon: then mail the admins, they'll have to remove the existing files I think
<asimon> Okay, thanks.
<raphink> hi
<gpocentek> hello raphink 
<raphink> yop gpocentek
<raphink> anyone knows why sbuild only tries to install the first build-dep when build-deps are listed with | ?
<raphink> and if this is a normal behaviour for sbuild
<dholbach> did anybody ever upload 'murrine'?
<dholbach> http://revu.tauware.de/details.py?upid=4150
<dholbach> it has two ACKs
<dholbach> but is not in NEW or in the archive nor anywhere else
* ajmitch thought the 2nd ACKer should upload it usually
<ajmitch> ah, subsequent uploads since the acks
<geser> https://launchpad.net/ubuntu/feisty/+queue?queue_state=4&queue_text=murrine
<persia> dholbach: https://lists.ubuntu.com/archives/ubuntu-motu/2007-January/001179.html
<geser> looks like murrine was rejected again
<fernando> moin all
<ajmitch> geser: you free to check over & ACK the needinfo bugs that ubuntu-archive is subscribed to?
<ajmitch> there's 6 of them, all done by the debian maintainer
<StevenK> ajmitch: Hey, you're not supposed to delegate it. :-P
* ajmitch needs to get to bed asap so that I can get to work in the morning
<ajmitch> StevenK: it's what I do
<StevenK> :-P
<ajmitch> StevenK: now that you've spoken up, you get the job
<StevenK> ajmitch: Can't, sorry.
<ajmitch> rubbish
<StevenK> ajmitch: I would, but I'm in the middle of an after-hours callout for work
<ajmitch> pfft
<StevenK> Hence the can't, sorry
<ajmitch> and you're on irc :)
<StevenK> Yeah, well.
<StevenK> Maybe I might do them while I wait for a callback
* ajmitch is doing some, it just takes some time to run pbuilder even for simple stuff
<ajmitch> hm, I see doko ACKing some
<ajmitch> doko: thanks, now I can go & sleep
<persia> If it's ACK time, perhaps someone would be interested in 80540 or 80404?
* ajmitch wanders off for sleep
<StevenK> bug 80540
<Ubugtu> Malone bug 80540 in openoffice.org-en-au "Please sync openoffice.org-en-au 2.1-3 (universe) from Debian unstable (main)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80540
<StevenK> persia: It builds and installs fine on Feisty?
<persia> StevenK: It did for me.
<persia> StevenK: It's failing for me now.  I'll take another look.  Sorry.
* StevenK is downloading the source
<StevenK> 40,840         1.59K/s    ETA 55:06
<StevenK> Go ftp.debian.org!
<StevenK> And http.us.d.o is not synced up, woo
<persia> StevenK: Don't bother.  There's something odd (unless it's my build environment).  Wait for the sync (or let someone closer hit it).
<StevenK> I have the source, it's fine
<StevenK> persia: It's because /bin/sh != bash
<persia> StevenK: My apologies then.  My build environment was not ideal then.  I'll reject and go make a patch.
<StevenK> persia: bashisms in debian/rules, like install -m644 en_AU.{aff,dic} th_en_AU_v2.{dat,idx} /tmp/buildd/openoffice.org-en-au-2.1/debian/usr/share/myspell/dicts aren't going to work
<StevenK> persia: It's fine. :-) Bug me when you want a sponsor
<StevenK> If you're quickish, anyway
<xerxas> Hi all 
<xerxas> can someone review http://revu.tauware.de/details.py?upid=4162 ? 
<persia> StevenK: Thanks.  Patch up (on the bug).
<StevenK> Neat
* StevenK looks forward to ignoring it
<StevenK> :-P
<StevenK> Perhaps you should include the previous Ubuntu changelog entries, as well as saying "Merge from Debian unstable. Dropping all Ubuntu changes. Remove bashisms from debian/rules." ?
<StevenK> Like MoM does, etc etc
<persia> StevenK: All previous Ubuntu changelog entries are included in the Debian source.  There are no preserved changes.
<persia> or rather, Debian merged all the changes (and documented it).
<StevenK> persia: Not the point, I still need the changelog entry for 2.1-1ubuntu1, so that all of the changes since then can be in the .changes file
<muzzol> im compiling cinelerra feisty packages with pbuilder from an edgy machine, is there any diference if i compile it from a feisty box? i mean if kernel and gcc versions can affect final package...
<persia> StevenK: Debian ships that changelog entry.  I consider this to be a very special case.
<StevenK> They do?!
<StevenK> They do too, right, I take it back
<persia> StevenK: Yep.  2.1-2 is 2.1-1ubuntu1 + new changes.
<StevenK> Okay then, that's one point of two addressed.
<persia> StevenK: OK.  I'll change it to MoM style.  I thought it might be avoided in this case, as it wasn't really a merge.
<StevenK> Hrrrrrrm
<StevenK> I think it is
<muzzol> anyone?
<Hobbsee> muzzol: it'll be the same as with your feisty pbuilder
<Hobbsee> (the feisty machine, that is)
<Hobbsee> assuming it's updated
<did448> muzzol:it's the point of pbuilder
<muzzol> yes, i've just created the pbuilder feisty package
<persia> StevenK: How's this for phrasing (before I upload): Merge from debian unstable, all Ubuntu changes merged in Debian.
<muzzol> so the gcc package is the one iside pbuilder virtual chroot, not the one on my machine, right?
<Hobbsee> muzzol: correct
<muzzol> thanks Hobbsee
<muzzol> is what i thought but i just wanted to be sure
<muzzol> :)
<StevenK> persia: That works. Show me the debdiff. :-P
<muzzol> bye
<persia> StevenK: Posted.
<StevenK> Looks fine, applies fine.
<StevenK> Builds fine too
<StevenK> Installs fine three
<persia> Yay!  I'm down to less then 7% of the u-u-s queue!  Thanks.
<StevenK> persia: Uploading. Sorry for being such a nitpicky so-and-so. :-)
<persia> StevenK: No, it's a good thing.  As Ubuntu grows it needs the stronger procedures to maintain order.  Coming back after my last engagement, I am now motivated to follow processes, whereas before there was more work than the few around could do, and I still have bad habits.
<StevenK> Procedures shouldn't be a stick to beat people with, though.
<StevenK> Even if it is very fun.
<persia> StevenK: I can agree with that (especially the pause).
<Hobbsee> StevenK: excluding SRU's, though
<Hobbsee> they're just a bloody pain.
<StevenK> Hey now, I like the SRU procedure
<StevenK> Mind you, I'm a nice part of it, so I'm biased
<persia> Hobbsee: From what I've seen here compared to trying to get updates into Debian Woody, it's really easy.
<StevenK> That's only because Joey says "Security? What non-security updates
<StevenK> ?"
<Hobbsee> StevenK: heh :)
<Hobbsee> persia: ugh, havent looked at that
<StevenK> You can't anyway, Woody is long dead.
<persia> Hobbsee: When Woody was released, drupal was completely broken.  Fixes were available, and waited for Sarge (see StevenK's comment above).
<Hobbsee> persia: ugh
<StevenK> Personally, I love the idea of -updates.
<persia> Me too.
<StevenK> persia: Oh, s/ing/ed/
<persia> StevenK: ?
<StevenK> Successfully uploaded packages.
* StevenK ponders core-dev some more
<persia> StevenK: Ah.  Thanks.  Speaking of procedures, where is the assignment, the .changes comment, and the Fix Committed?
<StevenK> Assign to whom?
<StevenK> Like I sponsor packages. :-P
<Hobbsee> StevenK: sureyou do :P
<StevenK> Shush! I have a reputation!
<persia> StevenK: cf bug 80472.  My understanding is that the uploader self-assigns, includes the .changes in the comment, and sets to Fix Committed.
<Ubugtu> Malone bug 80472 in mhwaveedit "merge mhwaveedit 1.4.11-1 from Debian unstable" [Wishlist,Fix released]  https://launchpad.net/bugs/80472
* Hobbsee just uploads, doesnt assign, and marks it fix released
<Hobbsee> if it doesnt build, i find otu in other ways 
<Hobbsee> (like, it sends me the build log saying it failed)
* persia has at least one upload that needed to be reverted because Hobbsee set it to Fix Released and it FTBFS.
<Hobbsee> which was that?
* Hobbsee loosk
<persia> Hobbsee: drscheme.  It was agreed to leave it, as it built on more architectures than the previous version, but still.
<StevenK> Heh
<StevenK> drscheme evidently subscribes to the piecemeal building approach.
<Hobbsee> oh right, it's not under my list of packages, as it was signed by your key
<Hobbsee> StevenK: the which?
<persia> drscheme needs a lot of work.  Every time I look it fails in completely different ways.
<StevenK> Hah
<StevenK> Hobbsee: "I built on i386 last time, let's build on i386 and ia64, just to confuse people."
<Hobbsee> hehe
<persia> Hobbsee: Your key, my name in the changelog.  Launchpad only uses keys for trust, but changelog entries for notification.  That's the reason for the Committed step.  For your own uploads, Fix Released is probably fine.
<Hobbsee> oh...interesting...
<StevenK> Oh, sigh, it doesn't really use it for trust.
<Hobbsee> persia: true.   i thought it sent failed messages to both.
<StevenK> Since it allows unsigned keys to be used.
* Hobbsee snorts
<Hobbsee> uh, yeah
<persia> StevenK: I thought LP verified the signatures on acceptance?  Does it not?
<Hobbsee> it does, yes.  that the key is the same as LP
<StevenK> Yes, but a verified signature means close to nothing without a trust path.
<Hobbsee> it doesnt check that it's signed or anything
<StevenK> The *key* being signed is very very different from the *package* being signed by the key
<persia> I see.  Still, it verifies that the key belongs to the LP account which received the acceptance of the CC/TB.  It could be a committee, so long as they worked well together.
<StevenK> It doesn't, actuallyt
<StevenK> s/lyt/
<persia> StevenK: Huh?  It doesn't check the key against the LP account?  Oh my.  There is a feature request, surely?
<StevenK> persia: You aren't understanding me, but I don't think I'm explaining very well.
<persia> StevenK: I understand you to be saying that LP only validates that the package is signed by a valid key, but doesn't require that the authenticity of the key is verified.
<Hobbsee> the end effect is that someone can change the key on LP, LP doesnt require the new one to be signed, or to be of that user, presumably, so the only safeguard is the launchpad p/w
<StevenK> persia: It *does* check the signature, and *does* check it against a Launchpad account. That isn't the issue at all. What the issue is, is that some -dev member gets their Launchpad password comprimised, and some nasty person removes the current GPG key, adds their own, and uploads nasty crap into the archive.
<Hobbsee> ah...that's right
* persia enjoys the discrepancy with the documentation on w.u.c/GPGKey
* StevenK reads it
<persia> StevenK: I see.  In that case, the solution is more annoying and complicated.  Thanks for the details.  (LP could authenticate with certificates, or something)
<StevenK> Or could refuse to accept a key unless it can verify at least signature in the keyring.
<Hobbsee> persia: effectively, you'd have to ensure that the real name on LP was in fact the real name on the key - and that the primary email on LP was on the key too
<StevenK> at least one
<Hobbsee> that too
<StevenK> Hobbsee: Somewhat less important, since the person signing it would have checked that
<Hobbsee> mmm....true
<StevenK> Right, can I stop giving a GnuPG lesson now? :-P
<persia> StevenK: Yes.  No more lesson (it's been GPG day all day - at least four threads).
<StevenK> Heh
<Hobbsee> mmmm....crack...
<StevenK> Hum?
<Hobbsee> http://ubuntuforums.org/showthread.php?t=338279 <-- various news sites have pointed to that in the past few days...
<StevenK> Oh yeah, that's a whole lot of crack
<StevenK> Installing into an ext3 image. Yummy.
<Hobbsee> and "supposedly not modifying the bootloader, but chainloading grub to the end of hte windows bootloader"
<StevenK> Yup. Because that's the recommended way to boot Linux.
<StevenK> :-P
<tepsipakki> what's the procedure to get an update for a package I maintain in multiverse (gtkpod-aac)? I have a new version ready, the old one segfaults in feisty
<Hobbsee> tepsipakki: debdiff, find an uploader
<Hobbsee> s/uploader/sponsor/
<tepsipakki> debdiff against the old version?
<Hobbsee> tepsipakki: StevenK looks willing
* Hobbsee ducks
<Hobbsee> yes
<tepsipakki> ok
<tepsipakki> it's a new upstream also
<persia> tepsipakki: More formally, upload a debdiff including your fixes to the bug that you are fixing (open a new bug for >=3 fixes), and subscribe ubuntu-universe-sponsors.  A sponsor will upload your bug when they have time.
<tepsipakki> well, I need to put the tarball somewhere
<tepsipakki> but I'll just attach the URL
<persia> tepsipakki: For a new upstream, upload your package to REVU, and open a bug pointing to the REVU location including your new changelog.  For ease of reviewing, include diff -Nur of debian/
<tepsipakki> nooo..
<tepsipakki> it can wait, then ;)
<persia> tepsipakki: Those were the procedures I was given.  Linking to an alternate location from REVU probably works as well.
<Hobbsee> persia: people dont look at REVU unless poked to.
<persia> Hobbsee: You told me to upload for bug 79498.  Consider yourself poked.
<Ubugtu> Malone bug 79498 in libjsw "new upstream version 1.5.6" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79498
<tepsipakki> filed bug 80981, includes a link to a webfolder
<Ubugtu> Malone bug 80981 in gtkpod-aac "a new upstream version" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80981
<Hobbsee> persia: way cool :)
<persia> tepsipakki: Does the new version include any fixes for outstanding bugs in Debian or Ubuntu?  If so, it's a good idea to include these in your changelog.  Also, if there are no bug fixes, it's a good idea to include some rationale explaining why someone should upload it.
<persia> Hobbsee: So it can go in?  torcs depends on libjsw, and I just fixed a torcs bug, and I'd rather the builds happened in the appropriate order to use the new fixes.
<tepsipakki> well, the current version in feisty crashes immediately, so yes, it does fix _something_ :)
<Hobbsee> persia: looking now.
<tepsipakki> also, there are some older bugs that this hopefully should fix
* Hobbsee decides that she's way too tired to look into big diffs
* Hobbsee eyes StevenK 
<persia> tepsipakki: That's a really good reason, but the bug doesn't make it clear.  Take a look at 79498 (above) for an example changelog for a new upstream version that fixes some things.
<tepsipakki> hobbsee: it's midnight down under?-)
<Hobbsee> tepsipakki: 12.30am, yeah.
* Hobbsee is eating dinner
<tepsipakki> persia: http://www.gtkpod.org/news.html
<tepsipakki> that's too much to put in debian/changelog :)
<tepsipakki> ..but a link might do
<tepsipakki> or just the bugfixes
<persia> tepsipakki: You don't need that much.  Just New Upstream Version and below - doesn't crash (fixes Ubuntu: #99999), - New Firmware Updater (fixes Ubuntu: #99998).
<tepsipakki> yeah, I'll take another look at those crashdumps
<persia> tepsipakki: I'd include just the bugfixes that match Ubuntu bugs, and perhaps "support for several iPods" or "tomboy support".  The rest look like normal new upstream features.
<tepsipakki> the "normal" gtkpod-0.99.8 is already in feisty
<tepsipakki> since mid-December IIRC
<tepsipakki> but yes
<tepsipakki> this should be a no-brainer, so I'll make the bug look like it
<persia> tepsipakki: That's the goal.  Sponsors are busy, and don't like messy changes (see the response to poking above) :)
* Hobbsee is just half asleep
* persia is just joking
<lritter> hey there
<lritter> where can i apply for inclusion requests?
<persia> lritter: Inclusion requests?  Inclusion in what?
<sladen_> for Nain, or universe?
<lritter> what is "nain"?
<sladen_> main
<lritter> oh ;)
<lritter> universe, i suppose
<persia> lritter: Are you willing to package it, or do you want someone else to package it?
<lritter> it depends
<lritter> i would be happy if someone could write the package metafiles for me, and i would pick the work up from there
<lritter> but if someone does maintenance, that would be even better
<lritter> i tried to do this myself, but i'm an idiot
<lritter> and i had trouble with this, and also the feeling that i was not doing it right
<lritter> although i was following instructions
<lritter> and i feel that this needs someone with experience
<lritter> the software i'd like to package is aldrin, libzzub, python-zzub, and llvm 1.9
<lritter> regarding llvm, i know that 1.8 is in the repository, but needs to be upgraded
<persia> lritter: The easiest way (and least effective) is to register it on https://wiki.ubuntu.com/MOTU/Packages/Candidates.  If you are willing to package it, https://wiki.ubuntu.com/MOTU/Packages/New provides guidance (and links to some guides).
<lritter> all other packages are new
<lritter> i need people, too ;)
<lritter> oh, but, yes i could try it.
<lritter> thank you 
<lritter> persia: is there also documentation on how to create my own repository?
<persia> lritter: http://www.debian.org/doc/manuals/repository-howto/repository-howto
<xerxas> dholbach,  ? 
<xerxas> you there ?
<dholbach> xerxas: yes, I'm here
<xerxas> dholbach,  what's up ? 
<xerxas> can you review http://revu.tauware.de/details.py?upid=4162 
<xerxas> it's tapioca-cil 
<dholbach> can you drop me a mail with that?
<dholbach> i'd very much appreciate if a mono person would review iw
<dholbach> it
<dholbach> I have no clue about mono packages :-/
<xerxas> k
<xerxas> I've asked slomo to do it also 
<dholbach> giskard, ajmitch_, bhale and slomo are good that kind of stuff
<xerxas> giskard is probably the best person for it then 
<xerxas> giskard,  ? you there ? 
<xerxas> dholbach,  do you still want a mail ? 
<xerxas> or you won't review it ? 
<dholbach> i'm currently at a conference, but I can review the basics of the package, if you still like
<xerxas> I has already been reviewed, but I had some errors 
<xerxas> lintian and linda are 0 bytes 
<incorrect> does ubuntu patch the kernels or are they straight from kernel.org?
<xerxas> I think I'm really close to have a correct package 
<zul> incorrect: they are patched
<xerxas> dholbach,  maybe I can update the code in the cvs 
<xerxas> svn I mean 
<xerxas> to the latest one 
<xerxas> and change the version 
<dholbach> xerxas: which code? which svn?
<incorrect> people in #ubuntu don't know the answer, please excuse me questions here
<xerxas> the tapioca-sharp code from their upstream svn 
<xerxas> dholbach,  I also have a bzr branche for the packaging 
<xerxas> incorrect,  apt-get source thekernel 
<xerxas> and see if there are some patches
<incorrect> but, would i be better off with getting the source from edgy and compiling the 2.6.17 kernel or getting 2.6.19 from kernel.org
<incorrect> xerxas, sadly i have sas drives and 2.6.15 doesn't love them
<xerxas> sas ? 
<crimsun> incorrect: the trees for dapper, edgy, and feisty are on www2.kernel.org/git/
<incorrect> oh thanks crimsun 
<incorrect> Serial Attached SCSI
<white> raphink: hi, are you interested in maintaining biblememorizer for debian (including ubuntu as well) ?
<bddebian> Heya gang
<white> then i do not need to write a mail :)
<raphink> sure white
<white> great :)
<raphink> white: if you're willing to sponsor me
<raphink> I can give you a package today
<white> i somehow feard this question :)
<xerxas> hey bddebian  
<bddebian> Hello xerxas
<xerxas> bddebian, would you review http://revu.tauware.de/details.py?upid=4162 , please 
<xerxas> ? 
<raphink> white: heh, I'm not a Debian dev (yet at least)
<raphink> white: let's bring that to PM
<white> raphink: this is a question of time i reckon ;)
<white> raphink: can you write an ITP? :)
<white> raphink: if you can write an ITP and send me the path to the .dsc file in a query, i will try to look into it around tonight and give you feedback, if that is ok with you
<raphink> white: did you look at the package I've put in Ubuntu already?
<white> raphink: yes it came on my radar as it was recently added :)
<raphink> it will be the same - except with -1 instead of -0ubuntu1
<raphink> so just check this one
<giskard> xerxas, pong
<giskard> :)
<xerxas> giskard,  tapioca-cil uploaded to review 
<xerxas> giskard,  for telepathy-cil , I created a bug because dll files are executable 
<xerxas> I know how to fix that 
<xerxas> :)
<giskard> ok, where i can find the packages?
<giskard> package*
<xerxas> http://revu.tauware.de/details.py?upid=4162
<giskard> xerxas, ubuntu1 is the fixed package?
<bddebian> crimsun: Did you get too busy for me? :-(
<xerxas> giskard,  ? 
<xerxas> it should be 0 ? 
<crimsun> bddebian: s/busy/ill/, but yeah. Sorry.
<giskard> nono :) 
<bddebian> crimsun: Ugh, sorry to hear that
<giskard> xerxas, i'm talking about the dll bug
<xerxas> giskard,  ahh , maybe I recall wrong 
<xerxas> It was an error from mine 
<xerxas> # dpkg -S NDesk.DBus.dll
<xerxas> banshee: /usr/lib/banshee/NDesk.DBus.dll
<xerxas> f-spot: /usr/lib/f-spot/NDesk.DBus.dll
<xerxas> libtelepathy-cil: /usr/lib/telepathy-sharp/NDesk.DBus.dll
<xerxas> is that normal ? 
<xerxas> can't we package NDesk.DBus.dll ? 
<giskard> no
<giskard> as alp (upstream) asked us to not package Ndbus-sharp
<xerxas> ok 
<xerxas> giskard: Version: 0.0.svn.20061115-0ubuntu1 
<xerxas> # ls -l /usr/lib/telepathy-sharp
<xerxas> total 76
<xerxas> -rwxr-xr-x 1 root root 25088 2006-11-16 03:18 INdT.Telepathy.dll
<xerxas> -rwxr-xr-x 1 root root 48128 2006-11-16 03:18 NDesk.DBus.dll
<giskard> ?
<xerxas> those dlls aren't suppose to be executable 
<xerxas> you need to put a install/libtelepathy-cil::
<crimsun> siretart: any opinions on adding libpulse-dev to xine-lib's build-dependencies?
<xerxas>  find debian/ -type f -name "*.dll" -or -name "*.mdb" -or -name "*.cs" -or -name "*.config" | xargs chmod -x
<xerxas> in debian/rules
<giskard> xerxas, yes.
<giskard> crimsun, what did Debian for it?
<xerxas> giskard,  are you reviewing my package? 
<giskard> xerxas, rebuildint it right now
<xerxas> ok 
<xerxas> great 
<giskard> i have some questions for you: ) why you didn't run autogen.sh before tar czf the package?
<giskard> i guess we need to depend on autoconf/automake, i'm wrong?
<crimsun> giskard: meaning for libpulse-dev and xine-lib? It's not listed as a build-dependency in unstable's dsc, at least.
<crimsun> giskard: which makes sense, since only 1.1.3 added pulse support, and pulseaudio was only recently promoted to Ubuntu main
<bddebian> Can GNU/Linux actually run .dlls?
<Lathiat> .NET dlls, yes
<Lathiat> through mono
<xerxas> giskard,  ahh , yeah , right
<giskard> crimsun, right! and I guess you can enable it as ubuntu ships 1.1.3 :)
<xerxas> giskard,  I didn't wanted to run autogen.sh before so that I'm the closer I can from the source tree 
<xerxas> is it a bad idea ? 
<giskard> xerxas, i don't know, and i don't know if there is a policy about this issue, i prefer to run autogen.sh before.
<xerxas> ok 
<bddebian> Lathiat: Ah, thx
<asimon> A question regarding naming. I am packaging  YAZ++ (1.0.0), a C++ binding for libyaz2. The actual library which gets build is called libyazpp.so.1.0.0. So, should the package name be libyaz++1 or libyazpp1 ? Thanks.
<giskard> libyazpp1 :) ihmo
<xerxas> giskard, anyway, if it build in a pbuilder without the autogen dependency and it works, I don't need to add autogen as dependency 
<xerxas> right ?
<xerxas> sudo pbuilder build my.dsc installs autogen 
<giskard> autogen != autogen.sh
<bddebian> asimon: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi
<xerxas> giskard,  right :) 
<asimon> bddebian: Thank you :)
<bddebian> NP
<xerxas> giskard,  do you want me to correct sth ? 
<xerxas> it work like this 
<xerxas> autgen.sh calls gnome-autogen.sh 
<xerxas> $ apt-file  search gnome-autogen.sh
<xerxas> gnome-common: usr/bin/gnome-autogen.sh
<xerxas> and I depend on gnome-common anyway 
<bddebian> Heya dholbach
<giskard> xerxas, take a look on gnome-common Deps
<xerxas> ok 
<xerxas> giskard,  so it's ok then , right ? 
<giskard> yes.
<xerxas> I just prefer not to run autogen.sh in the source tree so it's easier to update to the latest svn version 
<xerxas> but I learnt I can still run autogen.sh in the source tree, that's right 
<giskard> hi ogra 
<ogra> hey
<Kano> hi, could someone update xine-ui to the one from sid?
<Kano> dr keybindings are missing in feisty one and there are 2 menu entries for it
<Kano> vdr keybindings are missing in feisty one and there are 2 menu entries for it
<xerxas> bddebian,  thanks for the review 
<xerxas> how do I fix : E: libtapioca-cil: description-synopsis-is-duplicated 
<xerxas> is it this : 
<xerxas> Depends: ${shlibs:Depends}, ${misc:Depends}, ${cli:Depends}
<xerxas> Description: tapioca bindings for c#
<xerxas>  tapioca bindings for c#
<xerxas> in the control file ? 
<zul> when is the meeting again?
<ScottK> Is there a MOTU other than bddebia available for REVU?  I have two packages looking for a 2nd advocate: http://revu.tauware.de/details.py?upid=4115 and http://revu.tauware.de/details.py?upid=4127
<Kano> used pbuilder on feisty with sid package, no problem at all, please add
<bddebian> xerxas: No, the Long description in debian/control shouldn't be the same as the Description feild
<xerxas> ok 
<ScottK> BTW, good morning bddebian!
<jdong> Kano: you say it builds fine in feisty pbuilder?
<bddebian> Heya ScottK :)
<Kano> jdong: yes
<jdong> Kano: filing a "sync request" https://launchpad.net/ubuntu/+source/xine-ui/+filebug indicating you want the Sid version and that it built fine in pbuilder would get the ball rolling
<Kano> building vdr for it
<Kano> just fixed xinelibout
<jdong> then just need some +1's from MOTU Media team and others
<bddebian> jdong: Did crimsun already take care of the rest of your changes?
<Kano> without xinelibout vdr is pretty useless
<Kano> for budget cards
<jdong> bddebian: yes
<jdong> bddebian: there's still one FTBFS I'm scratching my head at :)
<bddebian> OK, thx
<jdong> bddebian: are you suited to deal with the request from Kano?
<bddebian> Probably not :)
<jdong> hehe
<jdong> bddebian: why do I feel queasy about touching media stuff now?
<bddebian> Heh, I know that feeling :)
<afflux> is there any special reason why we have a libenet-dev package and no library itself?
<jdong> !libenet-dev
<ubotu> Sorry, I don't know anything about libenet-dev - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<jdong> that's what my apt-cache said too....
<afflux> it's in feisty. http://packages.ubuntu.com/feisty/libdevel/libenet-dev
<afflux> if a library package produces only a .a file, it's not a library package, right?
<jdong> afflux: oh yeah, it's designed only to be statically linked to, right?
<jdong> afflux: sorta like how x264 is done.
<afflux> might be correct. I just created a .so file by modifying the source slightly. upload it?
<afflux> if yes, should I take the source from the debian guys or should I get a clean one from the web?
<afflux> eh... forget what I just said please. there is no point in it.
<jdong> afflux: if you created a .so file it's a better idea to make a real libenet package then...
<xerxas> bddebian,  giskard, I have uploaded a new version with a more detailed long description in debian/control 
<xerxas> I will soon appear on revu 
<xerxas> bddebian,  it's in there ! 
<xerxas> can you advocate ? 
<xerxas> giskard,  the same ! :)
<giskard> i will upload it today
<xerxas> giskard,  ok , thanks ! 
<xerxas> :)
<xerxas> gone !
<Kano> btw. mc does not work right with ubuntu
<Kano> did someone change it
<givre> Hello guys
<givre> If any motu in good mood could have a look at http://revu.tauware.de/details.py?upid=4166 that's could be great. Thanks.
<keescook> mornin'
<givre> morning keescook
<keescook> hiya givre
<bddebian> Heya keescook
<keescook> hi bddebian
<thenetduck> does anyone know what programs are going to be included in ubuntu stuido ? 
<rexbron> thenetduck: see wiki.ubuntu.com/UbuntuStudio
<rexbron> and look at the metapackage page
<thenetduck> ok
<rexbron> bddebian: Would you have time to review soma and murrine? upid 4150 and 4149
<thenetduck> rexbron, do you know a little bit about Ubuntu Studios? 
<rexbron> yes, I am on the packaging team
<thenetduck> great!
<rexbron> hop on #ubuntustudio
<thenetduck> rexbron, would it be bad to talk on this page? 
<rexbron> nope, just OT
<rexbron> and there is another channel
<bddebian> Heya LaserJock
<rexbron> LaserJock: Would you have time to review soma and murrine? upid 4150 and 4149
* rexbron is trying his hardest to get theses packages looked at
<bddebian> rexbron: Last time I did murrine I got in trouble :)
<rexbron> really?
<rexbron> Crimsun oked it, but it got rejected due to a licence mismatch
<LaserJock> rexbron: I don't have time right now. sorry
<rexbron> LaserJock: np
<rexbron> bddebian: crimsun is really busy as far as I can tell
<rexbron> the licening issues were fixed from upstream
<bddebian> OK
<christopherl> Im on Ubuntu 6.10 with Gnome 2.16.1. How can I remove all tooltips in Gnome? I've tried almost everything and asked alot of people, but I don't find any solution.
<Toadstool> heya everybody
<somerville32> christopherl, Have you consider the possibility that you can't? lol
<LaserJock> christopherl: also, have you asked Gnome?
<christopherl> it's a computer all things can be done
<bddebian> Heya Toadstool
* somerville32 needs a core-dev.
<christopherl> I asked in gnome Irc channel, nobody knows
<Toadstool> hey bddebian 
<LaserJock> somerville32: generally -devel is the place to find core-devs
<Mez> sorry sru team
<christopherl> what are the tooltips used for, it doesn't provide anything??
<cypher1> LaserJock, hi
<LaserJock> christopherl: I don't even know what you're talking about really and this isn't a gnome channel :/
<LaserJock> christopherl: you really should talk to the Gnome devs if you have a problem specific to Gnome
<Toadstool> christopherl: perhaps you can disable notification-daemon, never tried though
<christopherl> Toadstool: where do I disable that?
<Toadstool> no idea
<somerville32> sudo apt-get remove notification-daemon? lol
<Toadstool> christopherl: you should ask on #ubuntu or on a gnome channel
<christopherl> I have
<siretart> crimsun: if it is in main, sure!
<bddebian> siretart: !
<siretart> bddebian: !! :)
<bddebian> :-)
<bddebian> siretart: Wanna review a package for me? :)
<cypher1> is not qtella available in any repositories ?
<somerville32> !find qtella
<siretart> bddebian: sorry, I'm not at home right now
<ubotu> Package/file qtella does not exist in edgy
<bddebian> Gah, I get no love :-)
<cypher1> somerville32, seems like ubuntu does not have qtella
* ScottK hugs bddebian
<bddebian> :-)
<bddebian> ScottK: So stop whining, I can't even get MY packages reviewed ;-P
<luks> if I'd like to get a new version of some package uploaded, what's the best way to do it?
<luks> is uploading such packages to REVU a "standard" way?
<luks> or should I rather just file a bug against the package?
<geser> bddebian: isn't hotplug dead? so why installing files for hotplug?
<bddebian> geser: Yeah, I should rip those out
<geser> bddebian: wouldn't it be better to name the dev package libticables2-dev?
<bddebian> Why?
<geser> you wouldn't need to modify libticables3-dev to conflict with it
<geser> in most cases you don't need the soname in the -dev package name
<bddebian> So they don't have to be consistent?
<somerville32> rexbron, ok
<rexbron> cool
<somerville32> rexbron, Tell me about this makefile
<somerville32> It is auto-generated, right?
<geser> bddebian: no, see http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id271662
<rexbron> somerville32: I have not touched the make file
<rexbron> so I would guess so
<geser> the most -dev packages have no soname in the name, as you usually what to build against the last version of the library
<bddebian> OK
<rexbron> bddebian: Would the ffmpeg copyright be nessicary even tough we are not using the source provided (the package uses the ffmpeg libraries provided by ubuntu)
<bddebian> rexbron: Unfortunately I don't know.  Licensing/copyright crap is my weakest link :-(
<rexbron> bddebian: also, are you using the latest upload, as revu does not list anything wrong with lintain or linda
<bddebian> rexbron: Yeah afaict it's the latest. But I'm building on Edgy so maybe it's a linda/lintian thing
<rexbron> maybe
<rexbron> bddebian: who would be a good contact on the copyright thing
<bddebian> rexbron: Anyone better than me :-)
<bddebian> geser: See anything else wrong?
<rexbron> bddebian: I will run the licence by crimsun (if he ever gets time)
<bddebian> rexbron: OK, sorry :-(
<rexbron> bddebian: Thank you for taking the time of actually looking at my work
<rexbron> I appreciate it
<geser> bddebian: I'd name the source package only libticables2 so you don't have to rename the source package once the soname changes
<geser> bddebian: it looks like the udev-files are now directly installed into /etc/udev/rules.d/ (no symlink anymore)
<geser> bddebian: and the number for the udev rules file is wrong, see /etc/udev/rules.d/README for the numbering scheme
<bddebian> geser: OK, thx
<geser> bddebian: once you remove the hotplug part from the udev file it can be installed as 45-libticables.rules
<geser> bddebian: why are you creating a debian/dirs file which is removed in the clean target?
<bddebian> That's a damn fine question.  I "borrowed" this debian crap from libticables3 ;-P
<geser> bddebian:  dh_installdocs automatically installs debian/copyright if it exists. 
<bddebian> geser: It wasn't doing it
<bddebian> But I think I know why
<nukeDev> Hello all
<bddebian> Hello nukeDev
<geser> bddebian: and you could set yourself as maintainer :)
<bddebian> I really don't want to :)
<nukeDev> what do MOU actually do?
<bddebian> geser: Don't we have a generic MOTU maintainer yet? :)
<bddebian> nukeDev: We maintain the packages in the Universe and Multiverse repositories
<bddebian> Or at least try to
<geser> even the MOTU maintainer would be better as Debian's QA group
<nukeDev> so when i type apt-get in the terminal and get a file from the universe or the multiverse it is you lot that have put it there and 'maintained' it?
<tsmithe> is anyone free for revu?
<bddebian> nukeDev: More or less, yes
<nukeDev> Cool
<bddebian> tsmithe: Which package?
<tsmithe> bddebian, asoundconf-gtk please if you could
<bddebian> geser: What is the MOTU maintainer info?
<bddebian> geser: And apparently he's doing the .dirs file for linux for the hotplug/udev stuff.  What's the better way to do that?
* tsmithe wonders when the next cc meeting is
<geser> bddebian: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
<bddebian> geser: Great, thanks
<geser> bddebian: you could add "etc/udev/rules.d" to debian/dirs and remove it on ! linux
<geser> or call dh_installdirs only on linux
<geser> bddebian: once again the udev file: BUS is now SUBSYSTEMS and I don't know if you need "usb" or "usb_device"
<geser> bddebian: for libticonv2: E: libticonv2 source: version-substvar-for-external-package libticonv2-dev -> libticonv
<geser> bddebian: do you know if the .la files should still be installed? IIRC Debian will get rid of them
<geser> and you are provided .pc files
<givre> bddebian: manpage done -> http://revu.tauware.de/details.py?upid=4171 Thanks for the review :)
<AnAnt> bddebian: hello
<AnAnt> ping bddebian 
<bddebian> geser: Yeah, I don't think the .la files should be installed anymore
<bddebian> AnAnt: Yo
<AnAnt> bddebian: about tss
<AnAnt> bddebian: setuid is needed for the lock feature to work
<bddebian> AnAnt: I know, you have told me that.  No worries
<AnAnt> bddebian: ok, thanks
<AnAnt> bddebian: oh btw, Hide !
<bddebian> heh
<AnAnt> as for archmage I didn't know that someone finally succeeded to get it into Debian
<AnAnt> so I sent my diff to him, that would be better I think
<bddebian> Aye
<bddebian> geser: I'm talking to upstream about libticonv2, it has some issues, but thanks!
<bddebian> Lutin: Hi.  Was aptoncd rejected last time??
<Lutin> bddebian: you mean kayali ?
<bddebian> Fruck, yeah, sorry
<Lutin> yeah, waq rejected because there was a missing license in two files in the orig tarball
<bddebian> Ahh, OK
<Lutin> pexpect.py and antlr.py
<Lutin> sorry, gotta go
<Lutin> thanks for your review :)
<bddebian> NP
* enyc wonders when Hobbsee may be here ;-)
<zul> probably sleeping
<bddebian> geser: If you get a free minute can you check out my updated libticables2?
<Toadstool> grah! I won't be able to make it to the MOTU meeting :/ I have a work meeting in 5 minutes and it'll probably last more than 1 hour...
<somerville32> OH crap
<somerville32> Thats today isn't it
<geser> somerville32: yes, in 30 minutes
* somerville32 nods.
<somerville32> I'll be there
<somerville32> :)
<tsmithe> what happens at motu meetings? what's on the agenda?
* tsmithe needs membership
<keescook> crimsun: are you around?  Any chance you could prepare acroread 7.0.9 for edgy?
<ajmitch> tsmithe: that won't happen at this meeting
<ajmitch> hey keescook 
<keescook> hiya ajmitch!
<tsmithe> ajmitch, i know :P
<keescook> I'm still catching up from being at LCA; is the MOTU meeting today (in 25 min) or was it yesterday?
<tsmithe> keescook, he's away (work) it seems
<tsmithe> keescook, today
<keescook> tsmithe: *nod* I suspected.  :)
<tsmithe> oolcay
<ajmitch> keescook: you were at LCA?
<ajmitch> how was it this year?
* ajmitch really regrets not being able to get there this year
<keescook> ajmitch: I was, yes.  It was great fun, though I spent more time exploring Sydney than hanging out at LCA.  :)
<StevenK> That could take a while. :-P
<zul> damn should have remembered to make a initrd
<LaserJock> are we having the meeting in here or #ubuntu-meeting?
<zul> well the tradional place is in -meeting
<ajmitch> sigh, meetings
<bddebian> Heya ajmitch
<LaserJock> zul: but MOTU meetings tend to be last minute and not on the #ubuntu-meeting schedule ;-)
<LaserJock> ajmitch: yep, I just got out of a 2 hrs one
<zul> LaserJock: its in the topic for #ubuntu-meeting
<LaserJock> zul: ok, cool
<Adri2000> I'm upgrading a package to a newer upstream version, debhelper compat and version is at 4, should I bump it to 5 or it's not necessary?
<geser> bddebian: ./etc/udev/45-libticables.rules <- you are missing the rules.d directory
<geser> and check the postinst for libticables2-1
<LaserJock> Adri2000: is it in Debian?
<geser> dito for the postrm
<Adri2000> LaserJock: yes, but not up to date and there is a bug in malone for a new upstream version
<LaserJock> Adri2000: is the bug also filed in Debian?
<Adri2000> LaserJock: no but I'm not sure if there is still a maintainer for this package... 10 outstanding bugs for 1, 2 and even 3 years
<LaserJock> Adri2000: what package?
<Adri2000> http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=hardware-monitor;dist=unstable
<LaserJock> oh, Sven Luther
<ajmitch> sometimes the maintainer can just have more important things to fix :)
<ajmitch> oh dear
<ajmitch> run away
<ajmitch> run away now
<LaserJock> ajmitch: did he get kicked out yet?
<zul> oh he isnt that bad
<ajmitch> LaserJock: no, he's still too busy arguing
<zul> ajmitch: i find him to be quite "friendly"
<ajmitch> hah
<LaserJock> who got kicked out not long ago?
<ajmitch> krooger
* ajmitch tries to recall his real name
<ajmitch> ted walther
<StevenK> He didn't get booted, if I recall
<LaserJock> was he the one that was sent home from Debconf?
<StevenK> LaserJock: Yup
<LaserJock> does Debian have a list of "ex" DDs?
<ajmitch> StevenK: oh?
<StevenK> There is a list of Emeritus DDs
<zul> http://www.debian.org/vote/2006/platforms/krooger
<ajmitch> StevenK: it's hard to recall if people were booted or resigned
<StevenK> Indeed
* StevenK goes back to get another hour of sleep, after being woken for a callout
<ajmitch> heh
<Adri2000> ok, so what should I do?
<Adri2000> also, I find debian/dirs a bit strange, I think it's useless, if so can I remove it?
<Adri2000> and for Standards-Version: 3.5.9, bump to 3.7.2?
<bddebian> geser: Sorry, was away.  You mean it should be in /etc/udev/rules.d/foo ?
<geser> yes
<bddebian> Gah, OK thx
<persia> bddebian: dh_installudev might help (or I could have no context).
<LaserJock> Adri2000: generally we do as little to Debian packages as possible
<sistpoty> hi folks
<LaserJock> Adri2000: go ahead and fix stuff (make sure you are right) and then send it upsteam when you're done
<Adri2000> LaserJock: upstream being debian I guess, but is the maintainer still active?
<LaserJock> Adri2000: well, that kinda depends on the definition of "active"
<LaserJock> he's still a DD and is "active" in discussions
<LaserJock> but the fact remains that he needs to be aware of what we are doing
<LaserJock> maintianing divergence is a pain
<ajmitch> hi sistpoty 
<bddebian> persia: You are probably right :)
<sistpoty> hi ajmitch
<bddebian> Heya again sistpoty
<sistpoty> hi bddebian
<Adri2000> LaserJock: ok, I will send a bug report for the new upstream release with the list of changes I have done in ubuntu
<ajmitch> MOTU meeting now on in #ubuntu-meeting
<ScottK> Is it OK for non-MOTUs to speak in MOTU meetings?
<sistpoty> ScottK: sure
<ScottK> Thanks.
<bddebian> ScottK: No way man, it's top secret shit ;-P
<geser> bddebian: I've left a comment on revu for you
<bddebian> geser: Uh oh :-)
<bddebian> geser: Thanks for your time.. I suck at library packages :-(
<ScottK> tsmithe: You're working on maintaining also stuff, right?
<tsmithe> yeah
<ScottK> If you want a guinea pig, I've got two identical laptops that had sound working fine in Dapper and nothing in Edgy.  I'd be glad to test/troubleshoot.
<tsmithe> ok
<tsmithe> filed a bug report? ;)
<ScottK> Of course not.
<ScottK> I'll do that first...
<tsmithe> and link me :)
<ScottK> Sure.
<tsmithe> and make sure to attach what's listed at https://launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/42718/comments/11
<Ubugtu> Malone bug 42718 in linux-source-2.6.17 "Sound capture on Thinkpad T20, T21, T22 not working" [Low,Needs info]  
<tsmithe> stupid Ubugtu
<jdong> Mez / crimsun: If I prepare a few source-changed backports would you guys be willing to sponsor them to edgy/dapper-backports? (only changes being undoing the renaming of some build-deps)
<jdong> and oh yeah, Mez, when/what do you want done before bug 72725 can go thru?
<Ubugtu> Malone bug 72725 in edgy-backports "Backport prevu" [Undecided,Confirmed]  https://launchpad.net/bugs/72725
<tsmithe> ScottK, how's this bug?
<ScottK> Just finished uploading all the stuff you asked for.
<tsmithe> ah cool :)
<ScottK> Bug#81030
<ScottK> Was about to add you to it.
<tsmithe> bug 81030
<Ubugtu> Malone bug 81030 in Ubuntu "Dell Latitude L400 has no sound after upgrade from Dapper to Edgy" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81030
<tsmithe> ScottK, no need :) i get bug mails anyway :P
* tsmithe just needs a way to sort them all
<ScottK> OK.
<ScottK> Well, there you go then.
<tsmithe> ScottK, what kernel are you running? `uname -r` s'il te plait
<ScottK> Just a sec.  I'm not on that machine, but it's whatever is current for Edgy.
<tsmithe> ok
<tsmithe> i'll get it myself :)
<ScottK> 2.6.17-10-generic
<tsmithe> ah thanks
<tsmithe> saves me some work :P
<ScottK> You should add that to the list of stuff you ask for...
<ScottK> BTW, I think that bug comment you pointed me at should be in the wiki somewhere if it's not...
<tsmithe> yeah
<LaserJock> persia: you around?
<tsmithe> DebuggingALSA (a variation on the theme of DebuggingACPI)
<persia> LaserJock: Yep.
<tsmithe> ScottK, let's take this to #ubuntu-bugs
<persia> LaserJock: I presume it's about my draft procedures document?
<LaserJock> persia: I appreciate the work on the MOTU/Launchpad/Guide wiki page but I think we should be working on individual processes
<persia> LaserJock: Is there any start on that?  I'd like to help.
<LaserJock> well, yes, there is a start
<LaserJock> https://wiki.ubuntu.com/MOTU/Processes is the names space where I think we should be doing this
<persia> LaserJock: OK.  And there should be a separate document for each process, explaining all the roles, and who does what when, and the decision tree?  Much of the information seems available for gleaning from other parts of MOTU/.
<LaserJock> yes
<LaserJock> I want to make the MOTU wiki pages more compact/organized/updated
<persia> LaserJock: Was my draft roughly on target?  If so, I'll proceed to collect information from the Wiki, editorialise, and add pages in that namespace.
<LaserJock> persia: it looks good, I think SRU is the only process that has a specific policy/worflow nailed down so I wouldn't mess with that right away
<LaserJock> but other processes should be documented and if needed have policy statements as SRU does
<persia> LaserJock: SRU seemed to be both contentious and contradicted from my Wiki browsings (which is why I skipped it).
<ScottK> Now that the MOTU meeting is over, if any MOTU has time for reviewing... I have two packages looking for a 2nd advocate: http://revu.tauware.de/details.py?upid=4115 and http://revu.tauware.de/details.py?upid=4127
<LaserJock> persia: yep, and we just reworked it :-)
<LaserJock> persia: we have over 100 wiki pages in MOTU
<LaserJock> we need to clean it up
<LaserJock> if you want to help out there it would be greatly appreciated
<persia> LaserJock: OK.  So page structure consists of the following outline, initially to be added below the current text: 1. Policy Statemets,   2.  Procedures (2a, 2b, 2c...),  3. Draft policies (need approval by MOTU meeting or MC) 3a patching, 3b, SRU, 3c, SYNC, 3d, DROP, 3e, etc., 4. Draft Procedures...
<LaserJock> persia: gimme a sec
<LaserJock> persia: ok, I created a new cateogry on the wiki CategoryMotuCleanup
<LaserJock> persia: what I think we should do is go through the MOTU wiki and add that category to any wiki page that needs updating, fixing, etc.
<LaserJock> initially pretty much everything will be in there
<persia> LaserJock: So rather than write the procedures, you're asking that I first mark all the old/outdated pages in Category MOTU as Category MOTUCleanup?
<LaserJock> well, we'll need a bit of both
<persia> persia: I'd rather start writing procedures, and only after the drafts are considered acceptable by at least a couple of MOTUs begin replacing the current material (although I agree it needs much work).  What do you think of setting MOTUCleanup on those pages that are believed to be replaced as a start, and then marking the rest once the body has migrated?
<LaserJock> persia: for your immediate goal of getting procedures or "best practices" on the wiki I don't think you need to ad them to a cleanup category
<LaserJock> persia: I did create the MOTU/Sandbox/ namespace for drafts
<LaserJock> you might want to use that
<LaserJock> I hate having old wiki pages that we have to delete or redirect
<persia> LaserJock: OK.  I'll start with adding to MOTU/Sandbox, and then start looking at cleanup.  All the equipment in my MDF is being replaced today, so there will likely be a gap between when I start and when I get more done.
<LaserJock> persia: no problem. any help is appreciated. I made a push to get rid of a bunch of our old stuff
<LaserJock> but I haven't had time to fix the current stuff
<LaserJock> or move the structure around better
<persia> LaserJock: Can the pages be renamed?  I'm not sure that creation of MOTU/Sandbox/foo is desireable, if it later needs to be MOTU/Processes/foo.
<persia> LaserJock: time is what I currently have.  Soon enough I will have none, so I'm happy to help now.
<LaserJock> well, they can be renamed, but you can also just move the contents
<LaserJock> I want to be able to delete MOTU/Sandbox/foo once we are done drafting
<LaserJock> what seems to happen is people draft in MOTU/foo and then when it's done we realize it should go in MOTU/bar/foo
<persia> LaserJock: Ah, so I should add all the draft pages as sections in MOTU/Sandbox, for placement as new pages once they have passed first review?
<LaserJock> and so we have to put in a redirect or delete
<LaserJock> yeah
<persia> LaserJock: Got it.  I can work with that.
<LaserJock> sometimes there is discussion as to where to put it too
<LaserJock> and putting it in the sandbox provides a neutral territory to draft
<persia> LaserJock: Sounds like each section deserves a discussion subsection.
<bddebian> geser: Still aboot?
<geser> yes
<bddebian> geser: I can probably delete .postrm entirely eh?
<geser> yes
<bddebian> geser: You're my new hero btw :)
<geser> bddebian: I've looked into the postrm, it also contains a call to ldconfig (added by dh_makeshlibs)
<geser> and I don't know if a postrm will be created if you remove it from /debian
<bddebian> Gah, I just deleted it :-(
<persia> geser: bddebian: If no .postrm exists, and dh_foo wants to add stuff, a .postrm will be created automatically.
<ScottK> persia: Would you mind looking at the patch in bug 79683 to see if looks correctly formed?
<Ubugtu> Malone bug 79683 in libspf2 "spfquery: conflict with libmail-spf-query-perl Debian bug#306875" [Unknown,Unknown]  https://launchpad.net/bugs/79683
<bddebian> persia: Ah, thx
<persia> bddebian: NP.
<persia> ScottK: When you change many files for the same thing, you might want just one changelog line (e.g. update-alternatives support (rules, postinst, prerm).  Also, when a bug is fixed, often (closes: 306875) is appended to the line in the changelog that fixes it.
<ScottK> That's right, you told me that before - about the closes... going on the end (slaps forehead).
<ajmitch> bddebian: 1 month to do reviewing
<bddebian> geser: New version up if you get bored :-)
<bddebian> ajmitch: ??
<ajmitch> & then the whip comes down for qa & bugfixing
<ajmitch> bddebian: you were at the meeting
<persia> ScottK: Other than that, it looks OK to me from brief visual inspection.  You probably want to make sure it applies cleanly (apt-get source foo; patch -p0 < patch).  I also think there should be a dh_alternatives :)
<ScottK> I did apply the patch and it applied cleanly with -p0 <.  I'll look at alternatives.  Thanks
<persia> ScottK: Sorry for the confusion, as far as I know, dh_alternatives doesn't exist.  I just think it should.
<ScottK> Ah OK.
<ScottK> Thanks.
* ScottK is trying to learn enough to help fix things...
<bddebian> ajmitch: Oh aye
<_MMA_> Hi guys. muzzol and I are trying to work out the sticky licensing issues with Cinelerra-CV. Is there anyone here atm who would like to give us a hand?
<LaserJock> _MMA_: lots of volunteers
<_MMA_> I know. :)
<muzzol> so...
<Toadstool> uhuh... QA?! What's that? :)
* Toadstool hides
<ajmitch> Toadstool: something scary
<Toadstool> and you're the one with the whip?
<ajmitch> seems like it got handed to me
<ajmitch> I'll delegate :)
<Toadstool> sounds even scarier :)
<ajmitch> of course
<sistpoty> any native speaker, who'd like to proofread the minutes?
<sistpoty> (I've added them to the wiki, so please correct errors you'll find)
<Adri2000> sistpoty: wrong date: MOTU/Meetings/2007-01-21, should be 22
<sistpoty> Adri2000: thx, I'll fix it
* muzzol goes to bed
<sistpoty> Adri2000: fixed
<LaserJock> ajmitch: do you have a lp team for MOTU QA?
<sistpoty> ok, universe release schedule is set in stone on the wiki :)
<LaserJock> excellent!
#ubuntu-motu 2007-01-23
* ScottK is having a hard time getting his head around the concept of "set in stone on the wiki", but he knows what you mean...
<LaserJock> :-)
<LaserJock> that's why I'm considering if we should move some things off the wiki
<ScottK> LaserJock: Was that funny enough to get a package REVU out of you?
<LaserJock> oh what the heck, what's the URL?
<ScottK> http://revu.tauware.de/details.py?upid=4127
<rmjb> Hey guys
<rmjb> Happy New Year to all
<LaserJock> hi rmjb 
<rmjb> so... the MOTU meeting has already passed? I have it on my calendar as starting in 30 mins
<ScottK> Yes, already passed.
<Adri2000> rmjb: it was 20:00 UTC
<rmjb> hmm... shoot... google calendar didn't handle the timezone properly and I didn't notice... d'oh
<LaserJock> ScottK: you really don't want to be put in the Maintainer: field?
* ScottK doesn't particularly care.
* ScottK will support the package either way.
<LaserJock> well, I'll leave it up to you. But sometimes it's nice to be able to look at Maintainer: for people who know about the package
<ScottK> If I have to fix anything else, I'll change it, but if you'd be willing to advocate the package, I'd much rather get it on it's way to NEW.
<sharms> so I am on revu, and I am looking at the apt-proxy package, and it looks good and the report said it builds ok.  Does this mean I request a sync, or is there something wrong I am not seeing?  Could someone hold my hand here for a few mins
<sharms> or rather merges.ubuntu.com
<LaserJock> sharms: have you looked for an existing sync request?
<sharms> have not
<LaserJock> apt-proxy is done I think
<LaserJock> I don't see it on http://tiber.tauware.de/~laserjock/motutodo/universe.html
<sharms> Ok so if I see a package on merges.ubuntu.com then it doesn't mean I should actually look it over for changes
<LaserJock> hmm, hang on a sec
<geser> sharms: apt-proxy is a special case due to bad versioning
<sharms> ah I am just trying to follow https://wiki.ubuntu.com/MOTU/School/Merging-and-Syncing and pretend I know what is going on
<LaserJock> geser: yeah, I was just looking at that
<geser> if you look into the changelog of 1.9.35ubuntu2 you will see that it's a merge of 1.9.35-0.1
<LaserJock> it doesn't show up on my list I'm guessing because of the versioning
<sharms> this package looks like we can just use the debian version though, or am I missing something
<geser> sharms: the changelog mentions some remaining ubuntu changes
<LaserJock> sharms: https://launchpad.net/ubuntu/feisty/+source/apt-proxy/+changelog
<sharms> I am looking at: apt-proxy_1.9.35-0.1ubuntu1.patch
<geser> and 1.9.35ubuntu2 > 1.9.35-0.1
<sharms> from the update-merge script
<sharms> ah ok
<sharms> I see
<LaserJock> but ubuntu2 is based on 0.1, right?
<sharms> so in this case the best thing I could do to help would be file a report with debian qa and try to get those changes pushed into their package right
<LaserJock> well, but the person that did the merge is the one that did the NMU
<LaserJock> and at least that install bit is Ubuntu specific
<sharms> I was looking at the init echo to  log_daemon_msg type things
<LaserJock> I would think there would already be bugs about it but if not I guess you could file them :-)
<sharms> ha I guess I am just striking out here
<sharms> maybe I just need to stick to making controversial blog posts
<LaserJock> ;-)
<LaserJock> nah, if you want to file bugs fine, but I don't think there's anything that needs to be done on the Ubuntu
<LaserJock> move on to another package :-)
<geser> before ajmitch comes with his whip
<TheMuso> c
<TheMuso> bah
<LaserJock> hmmm
<LaserJock> ScottK: actually I'm not sure what to think about your creating a non-native package from a native package
<ScottK> That's a legacy of the upstream including a /debian dir.
<LaserJock> right
<ScottK> I probably should have removed it, but I was trying to be minimally invasive.
<LaserJock> which makes it a native package
<LaserJock> but you packaged it as a non-native package
<ScottK> I think the upstream changelog that makes it look native is in error.
<ScottK> It's not meant to be a Debian only package.
<ScottK> Sounds like I ought to just remove the upstream Debian dir and provide my own???
<LaserJock> well, let me see if I can dig something up in Debian docs real quick
<ScottK> Thanks.
<sistpoty> LaserJock, ScottK: if there are any changes to the package, it shouldn't be a native package... however there is not a clear opinion about no changes==native (e.g. wxwidgets does this, but this is controversial)
<LaserJock> sistpoty: I don't think there are any patches or anything
<LaserJock> sistpoty: it's just that upstream ships debian/
<ScottK> No.  There aren't any changes.
<ScottK> BTW, I've asked him to remove it and he declined.
<LaserJock> of course ;-)
<sistpoty> ScottK: hm... is it debian/ubuntu specific? then it should be native. otherwise you can do as you please ;)
<ScottK> It's not Debian/Ubuntu specific.
<sistpoty> (though I'd personally prefer to have a non-native package, since it's easier to introduce changes then *g*)
<ajmitch> geser: you mentioned a whip?
* sistpoty ducks from the mighty ajmitch and his whip
<ajmitch> LaserJock: why would I need yet another team for motu qa?
<sistpoty> ajmitch: because of the icon ;)
<ajmitch> it's something everyone should be doing anyway
* geser ducks before ajmitch 
<ajmitch> hm
<LaserJock> sistpoty: should he just remove debian/ from the tarball? is mentioning that in README.Debian?
<LaserJock> ajmitch: well I asked so I could join it of course :-)
<ajmitch> why do people think I'm going to go crazy with a whip?
<ajmitch> LaserJock: oh, of course
<LaserJock> that's what QA means
<LaserJock> QA == ajmitch with a whip getting people to do all his bidding
<ajmitch> oh right
* ajmitch notes that there are actual canonical people who do QA who'd be more than willing to help us out
* ScottK thinks maybe ciscosurfer  was scared...
<sistpoty> LaserJock: not quite sure... removing debian-dir looks cleaner, but it'll mean to change the tarball
<ajmitch> LaserJock: what'd be nice for launchpad would be some way to tell if a source package is univer, main, or otherwise
<ajmitch> for ubuntu
<LaserJock> how does it not?
<ajmitch> how can you tell by looking at a page, whether this package is main or universe?
<LaserJock> if I go to https://launchpad.net/ubuntu/+source/<packagename> it has a Component column
<ajmitch> not very visible
<LaserJock> ?
<LaserJock> https://launchpad.net/ubuntu/+source/apt-proxy
<ajmitch> one problem is that there's *lots* of information on some of these pages
<LaserJock> you want it in the bug reports?
<sistpoty> LaserJock: it'd also be nice, if I could know about the archive-queue of -proposed (my reports are merely based on comments of bug reports)
<ajmitch> I'd like it if it was a little more visible if a package was officially supported or community-supported
<LaserJock> sistpoty: yes, I was trying to think about that
<sistpoty> hi raphink
<LaserJock> ajmitch: where though? on the +source page or bugs or ?
<LaserJock> sistpoty: yeah, I was thinking that the package names and perhaps versions should be available
<ajmitch> any & all :)
<LaserJock> sistpoty: the reason they don't have anything right now is that they aren't "accepted" yet
<ajmitch> LaserJock: same problem as at freeze time - we can't see the unapproved queue
<sistpoty> LaserJock: exactly... because the version is just not there yet... but there is a queue for e.g. edgy/dapper, but not for -proposed though
<ajmitch> infinity had to dump out the queue contents for dholbach & I to approve them
<LaserJock> ajmitch: why do you want that? So users know the difference?
<ajmitch> LaserJock: users & bug triagers
<ajmitch> LaserJock: it may be a minor thing, and I'm just odd for thinking it'd be nice
<LaserJock> well, no, it sorta makes sense. I think that it's pretty clean on +source pages
<LaserJock> but not at all on bug reports
<sistpoty> It'd greatly reduce the time I spend on motu-sru reports ;)
<ScottK> LaserJock: Thanks for the comments.  I have to go deal with a hungry 3 year old. if there's a resolution on what, if anything, I should do about the provided /debian dir (my preference at this point would be to edit it more heavily than to remove it and have to repack the tarball) or any other comments, I'll read it in the scrollback.  Thanks again.
<ajmitch> having to jump to another page is annoying
<LaserJock> ajmitch: but there isn't another page to jump to
<ajmitch> +source, as you said
<LaserJock> but that's where you go anyway
<ajmitch> not really
<LaserJock> or do you not do that?
<ajmitch> I always go to the bug pages
<ajmitch> very rarely to the +source page 
<LaserJock> +source/<packagename>/+bugs?
<LaserJock> or to a specific bug?
<geser> every bug report has a "source package" box in the left pane
<ajmitch> lp is too slow for me to click through 10 pages to do what I need
<sharms> so when I run the grab-merges script, and files end in .DEBIAN but there is no corresponding .UBUNTU, is that normal?  How do I merge changes between two packages with that diff?
<ajmitch> LaserJock: depends which smart bookmark I use in firefox :)
<LaserJock> ajmitch: right, which is why I use +source
<LaserJock> ok, but it still seems that the only problem is bug reports, not +source pages
<ajmitch> right, but it's still buried even if it's there
<LaserJock> ?
<LaserJock> it's right in your face
<ajmitch> unlike the duplicate notice, for example
<ajmitch> hardly
<LaserJock> go to https://launchpad.net/ubuntu/+source/apt-proxy
<ajmitch> maybe in your face if you're looking for it over there
<LaserJock> is it hard to find universe all over that page?
<ajmitch> if you're not looking for it
<LaserJock> hmm
<ajmitch> and if you know the difference between main & universe
<LaserJock> I just don't know how you can make it clearer than 11 "universe"s under Component
<ajmitch> which are terms not necessarily used in the UI (gnome-app-install), etc
<ajmitch> never mind then
<sistpoty> maybe with colors?
* ajmitch goes back to hacking stuff for work
* sistpoty goes back to hacking stuff for thesis
<LaserJock> ajmitch: no, no, I'm just trying to hash it out with you so I can have something clear and concrete
<LaserJock> I was thinking of emblems
<ajmitch> https://launchpad.net/ubuntu/+source/f-spot/+filebug
<ajmitch> no indication as to the package status there
<ajmitch> no 'supported' emblem or notice
<LaserJock> should it matter?
<ajmitch> lp is just not consistent
<LaserJock> I'm just not sure that we differentiate between Main and Universe as far as filing bugs
<LaserJock> who get's to deal with them yes
<ajmitch> response times, yes
<ajmitch> if you don't think it matters, then fine
<ajmitch> it was just an idea I had
<ajmitch> rather than a major complaint
<LaserJock> so something like "You are filing a bug for a community supported program. Please be patient while our volunteers work on your problem." or something
<sistpoty> please attach a debdiff to the bugreport :P
<LaserJock> I'm think it'd have to be clear what "supported" vs. "community supported" means though
<ajmitch> yep
<ajmitch> since plenty of main is just 'community-supported' :)
<LaserJock> so the general idea is "don't yell at us we're just volunteers"
<Burgwork> LaserJock: basically, there is no easy way to do that
<LaserJock> Burgwork: I know
<Burgwork> to most people, if we provide, we need to support it, a view I support (in theory)
<ajmitch> Burgwork: I'm not saying we abandon the users
<LaserJock> sure, but there *are* levels of support going on here
<ajmitch> I want to make universe *less* buggy
<ajmitch> not more, as it seems we do
<LaserJock> we are currently getting a fair amount of "Why is this taking so long. You suck!"
<LaserJock> some of that for sure is that we aren't doing so great
<ajmitch> or "OMG how could ubuntu release this when it has critical bugs we fixed!"
<LaserJock> but also it's unreal expectations of users
<LaserJock> mhm
<ajmitch> the emblem thing could be useful, if put in the right place
<LaserJock> and was consistent
<ajmitch> yep
<LaserJock> any place where you saw a package name, more-or-less
<LaserJock> well, I do notice that the little emblem in Synaptic is noticable to me
<LaserJock> I'm not sure if it is for the average user or not
<Burgwork> the emblem in gai is less than noticable and less than clear what it is
<LaserJock> hmm, well I'm not quite sure how to do this in a way that the LP guys will like
<LaserJock> but I can certainly put it on my list
<LaserJock> it seems like we differentiate a lot between Main and Universe (different teams, gai, synaptic, repos obviously)
<LaserJock> but there is nothing in bug reports that says anything about it
<LaserJock> the thing for me though, is in practice I don't see a huge difference between Main and Universe when it comes to "supported"
<LaserJock> I don't even know what "supported" is supposed to mean
<ajmitch> canonical will support it commercially, there's meant to be X months of security fixes, etc
<farruinn> I haven't been involved for a while, but I though main was supported by canonical, universe by volunteers
* farruinn nods
<LaserJock> right, but traditionally we "support" releases for just as long
<LaserJock> we just aren't paid to do it all day long
<LaserJock> and commercial support seems sort of irrelavent to what we're talking about
<_MMA_> (but do anyway)
<LaserJock> ;-)
<LaserJock> in practice, Main seems to fix bugs faster (although there are a lot of old Main bugs) but has more to fix
<farruinn> could that be because main includes a majority of the most common/popular packages?
<LaserJock> yes
<LaserJock> kernel+Xorg+gnome is huge
<LaserJock> I guess I'm just a little uncertain of what we are trying to tell users and the bug reporting/triaging/fixing consequences
<farruinn> *reads scrollback* so it's users doing the yelling/complaining?
<LaserJock> yes, basically
<LaserJock> people get mad at us for not being quick enough or releasing packages that have bugs
<LaserJock> and granted, we haven't been doing stellar there. But we *are* volunteers
<LaserJock> and people seem to sometimes have too high of expectations
* ajmitch shouldn't have brought this up :)
<LaserJock> ajmitch: no, I wish you would discuss it more
<Adri2000> LaserJock, sistpoty: you were talking about the proposed queue, it's just here: https://launchpad.net/ubuntu/edgy/+queue?queue_state=1 but it's 403 for non archive admins (I guess)
<LaserJock> Adri2000: exactly, we need access to it (at least parts)
<ajmitch> LaserJock: heh, right
<LaserJock> ajmitch: stress managment, you gotta vent sometimes ;-)
<sistpoty> Adri2000: ah, nice
<ajmitch> LaserJock: oh I will
<LaserJock> sistpoty: my thought was to ask for them to give us a "sanatized" version of that url
<sistpoty> LaserJock: /me wouldn't mind to have access to the queue as well :P
<LaserJock> ajmitch: that amule bug on motu-reviewers almost landed me a CoC violation ;-)
<LaserJock> sistpoty: we've asked about that before and ubuntu-archive doesn't want us mere mortals to see it ;-)
<ajmitch> haha
<sistpoty> hm... I guess time will tell... imo the more ubuntu-archive get's "spammed" with universe requests, the more likely is it that they'll hand in some of the powers to us
<LaserJock> well, we've been there too
<LaserJock> and so far archive admining requires too much access to Canonical machines for them to be ok with non-Canonical employees doing it
<Adri2000> LaserJock: you are saying that ubuntu-archive don't want us to be able to see the content of the proposed queue?
<LaserJock> Adri2000: that is correct
<LaserJock> well, the content of that page
<LaserJock> that's why it is forbidden :-)
<Adri2000> from #ubuntu-devel two days ago:
<Adri2000> Mithrandir	hmm, I thought the queue was supposed to be visible to everybody. :-/
<LaserJock> right, but it's not
<sistpoty> LaserJock: but the access to canonical machines seems more like a medium term solution to me... have you read the ubuntu-archive howto? seems kinda crude to get a package synced to me
<LaserJock> sistpoty: I haven't read the howto, but I can imagine
<Adri2000> LaserJock: but it seems Mithrandir is ok with that
<sistpoty> LaserJock: it didn't sound *that* easy ;)
<LaserJock> but that's why I'm said "so far" because I'm sure the plan is to get soyuz Canonical-independent at some point
<sistpoty> s.th. like run that script and then wget that source and put it into that place and then... ;)
<ajmitch> LaserJock: it has to be for them to have other distros using it
<LaserJock> exactly
<sistpoty> and we motu's make great guinea pigs :)
<LaserJock> well, all  I can say is last time we asked they said it wasn't possible
<LaserJock> and I haven't seen anything to suggest that anything has changed yet
<LaserJock> so for now we are stuck with the ubuntu-archive bottleneck
<LaserJock> hopefully mdz will relieve that some at the sprint
* Hobbsee waves
<sistpoty> hi Hobbsee
<LaserJock> Adri2000: well, I did say we can work on it. I belive last time it was mdz or cjwatson that said no
<Hobbsee> hey sistpoty!
<ajmitch> Hobbsee!!
<LaserJock> hi Hobbsee 
<Hobbsee> hey ajmitch!  hey LaserJock!
<LaserJock> ScottK: have a look at http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz
<Adri2000> LaserJock: is it possible to add this topic to the next TB agenda? or it's not a good idea? :)
<LaserJock> Adri2000: I don't think it warrants a TB decision
<LaserJock> we can ask mdz/LP if we can get access and if not ask for a "sanatized" version
<LaserJock> although ...
<LaserJock> with our new SRU policy will we need access to that?
<sistpoty> LaserJock: no
<LaserJock> SRU was the only real need that I saw
<sistpoty> hm... it's still nice to *have* access to it ;)
<LaserJock> pretty much everything else goes at least to a visible queue pretty fast
* Toadstool curses rodarvus and his qemu 0.8.2-0ubuntu1 upload
<LaserJock> well, sometimes "nice" is a bit hard to justify when work is involved
<ajmitch> Toadstool: why?
<sistpoty> LaserJock: being able to look at the queue for -proposed significantly reduces my time for sru-reports. Otherwise I can't tell the difference if a package was already uploaded or not
<sistpoty> LaserJock: unless someone left a comment on the bug
<Toadstool> ajmitch: 'cause he left the binary blobs that are removed in the debian orig tarball and I have to juggle with origs and that sucks :] 
<LaserJock> sistpoty: but if a member of SRU does the upload they probably will probably say, and it *should* be fast enought that it wouldn't matter (optimistically)
<ajmitch> Toadstool: oh nasty
<Toadstool> yup
<Toadstool> Rejected: md5 mismatch... yay!
<sistpoty> LaserJock: in theory: yes
<LaserJock> hehe
<ajmitch> Toadstool: I presume it was the bios code?
<Toadstool> indeed
<LaserJock> sistpoty: well, I put it on my list of things to talk to LP (and probably this case mdz) about
<Toadstool> ajmitch: is there any way to ask an archive admin for an orig tarball removal or an override?
<sistpoty> LaserJock: btw.: the way I read mdz's reply to my mail regarding sru, I have a little bit the impression that he wants us to get in direct contact with LP devs rather than going the redirection mdz -> lp-devs
<ajmitch> Toadstool: I doubt it a lot
<sistpoty> but I may have read that wrong though ;)
<imbrandon> ahhh finaly
<ajmitch> Toadstool: 0.8.2+dfsg-0ubuntu1
<sistpoty> hi imbrandon
<ajmitch> imbrandon!
<imbrandon> heya fella's
<Toadstool> ajmitch: yep
<LaserJock> sistpoty: actually, that is a good point
<LaserJock> sistpoty: I'll bring that up, k?
<sistpoty> LaserJock: yes, thanks
<LaserJock> ok, so here's a quick list of LP bugs I've found so far that are interesting to us, I think:
<LaserJock> * Bug watches can't be removed
<LaserJock> * Bug mails should explain why the person is getting emailed.
<LaserJock> * Attach files via email
<LaserJock> * Should be able to link to a wiki page with bug filing guidelines per source package.
<LaserJock> * Bugs have no fields to specify package or product versions
<LaserJock> * Allow recording and use of canned searches
<LaserJock> and * Malone/Launchpad should be CVE compatible
<LaserJock> some of those are from 2005
<imbrandon> ajmitch, where are those scripts on tiber ?
<sistpoty> LaserJock: what's the 2nd one?
<imbrandon> in usr/local/bin ?
<ajmitch> imbrandon: /srv/revu1-production/scripts
<imbrandon> kk
<LaserJock> sistpoty: if a person is on multiple teams and they are getting emails, right now you can't tell which team you're getting the email from
<LaserJock> this is happening to me a fair amount right now
<LaserJock> I get all this bug email from LP
<LaserJock> and I'm not really sure why I'm getting it exactly
<ajmitch> it'd be good if it was in the headers at least
<LaserJock> sometimes the context isn't enough
<LaserJock> ajmitch: I think that's the plan
<ajmitch> since it's easier to filter on mail headers
<sistpoty> LaserJock: cool... I'd like to sort my bugmails by team somehow automatically :)
<LaserJock> either that our a footer in the message, but that's not as easy
<LaserJock> sistpoty: yeah, exactly
* ajmitch would like for his bugs to be fixed automatically too
<Hobbsee> dream on, ajmitch 
<LaserJock> it's better than setting up a seperate list for each team
<sistpoty> LaserJock: s.th. that would come in really handy is if someone from -sru or -swat could accept nominations for a release
<LaserJock> hehe, sistpoty is full of all kinds of good ideas today :-)
<sistpoty> LaserJock: no, I'm just trying to not work on my thesis *g*
<Hobbsee> sistpoty: which of course means stacks of good ideas :P
<sistpoty> hehe
<Adri2000> LaserJock, sistpoty: I'd say even ubuntu-dev should be able to target for release, I don't understand why it should be more restricted...
<LaserJock> well
<LaserJock> I can kinda
<sistpoty> Adri2000: I don't have a problem with that as well
<sistpoty> LaserJock: you can?
<LaserJock> I'm not exactly what it's used for
<sistpoty> LaserJock: if you take a look at motu-swat's subscribed bugs, you'll get a clue ;)
<LaserJock> well, if I was mdz and I was using the release targets to manage things, having ~80 other people (with varying understanding of what it's used for) being able to do that I can see where he might get a little nervous
<ajmitch> especially if they rely on those lists of targetted bugs
* LaserJock looks
<sistpoty> LaserJock: well... LP could differentiate between main and universe
<Adri2000> as I understand that, it's just a way to track a bug that is being fixed in a stable release
<sistpoty> Adri2000: imo it's also used to track bugs that definitely need fixing after some schedules (e.g. BetaFreeze)
<LaserJock> hmm, so is this for adding (Dapper) or (Edgy) tasks?
<Adri2000> sistpoty: isn't that "milestone"?
<Adri2000> LaserJock: yes
<sistpoty> Adri2000: oh, nice... LP has too many features *g*
<sistpoty> Adri2000: I guess it is. 
<LaserJock> hmm, I thought that was freely available. I must have been using it before they stopped allowing everybody to do it
<LaserJock> well, I should think that ubuntu-dev should be able to set release and milestone for Universe packages
* LaserJock adds to his list
<sharms> so when I run the grab-merges script, and files end in .DEBIAN but there is no corresponding .UBUNTU, is that normal?  How do I merge changes between two packages with that diff?
* sistpoty is off to bed now
<sistpoty> gn8 everyone
<ajmitch> night sistpoty 
<LaserJock> darn, too slow
<bddebian> Heya gang
<ajmitch> salut
<bddebian> Hi ajmitch
<LaserJock> hi bddebian 
<bddebian> Heya LaserJock
<ScottK> Laserjock: Thanks.  Since the reference you gave says "You should upload packages with a pristine source tarball if possible" that leans me in the direction of not repackaging it.  I can solve the native/non-native question with a little more pruning of the upstream debian/changelog.  Working on it now (and there's a bugfix update from upstream, so I'll capture that at the same time).
<bddebian> Man, its quiet tonight
<ajmitch> bddebian: people are busy hacking
<bddebian> ajmitch: Ah cool, wanna review my package for me? :-)
<ajmitch> no
<imbrandon> pristine source tarball != tar streight from the upstream at times, pristine == good/great/godlike imho 
<imbrandon> :)
<bddebian> Heya imbrandon
* bddebian hugs ajmitch
<imbrandon> heya bddebian 
<ajmitch> bddebian: when i said people are hacking, that included me
<imbrandon> hehe
<imbrandon> bash/python to parse html == my hacking for the day
<ajmitch> python script to convert a set of user details into a corresponding set of organisation details
<ajmitch> what I'm doing for work right now
* ScottK is fixing packaging thanks to Laserjock's comments...
<imbrandon> gah
<imbrandon> i hate life at times
<imbrandon> cut: the delimiter must be a single character
* imbrandon grumbles
<ajmitch> hehe
<ajmitch> that's why python was invented
<imbrandon> heh my python skills are very small though, i would be better off doing it in php-cli
<ajmitch> ugh
<ajmitch> php was meant for one thing, and that's being burnt at the stake
<imbrandon> hahaha
<imbrandon> i even do qt in php at times ;)
<imbrandon> depends on how fast i need a prototype
* ajmitch codes in php all day long, and does python at night to relax
<ajmitch> or python at work when I can use it
<chillywilly> python++
<chillywilly> ruby+++
<chillywilly> ;P
<ajmitch> thank you for that useful contribution
* zul_ thinks ajmitch is pmsing
<bddebian> Heya chillywilly
#ubuntu-motu 2007-01-25
* Starting logfile irclogs/ubuntu-motu.log
<geser> bddebian: I've left a comment on libticables2 for you :)
<bddebian> geser: You're deliberately trying to push me over the edge now arent you? :-)
<azeem> bddebian: beware, Drepper is lurking beyond the edge
<bddebian> heh
<bddebian> Again, does anyone know what has happened to gnome-vfs-mime.h??
<slomo> jdong: ping?
<AnAnt_> I got a problem with pbuilder, I have set COMPONENTS="main restricted universe multiverse" in /etc/pbuilderrc
<AnAnt_> yet, when I run pbuilder it cannot find packages that are in universe !
<AnAnt_> I am using edgy
<asantoni> only 2 more chunks to go!
<asantoni> man, we brought this on ourselves
<asantoni> Mixxx's build system uses qmake, and we basically manage to have a single tarball that compiles across all three OSes (Win, Linux, OS X)
<asantoni> but boy this is really making it tricky to package properly, lol
<palski> what is wrong with nedit package? lp says that edgy has 5.5-2 but when I install nedit I get 5.5-1
<palski> and same goes with feisty
<imbrandon> palski, then -2 probably hasnet built successfully for the arch your on ( if any )
<palski> imbrandon: yes, that's it
<imbrandon> infact loooking thats it
<imbrandon> imbrandon@aurora:~$ sudo apt-cache madison nedit nedit | 1:5.5-1ubuntu1 | http://mirror.imbrandon.com edgy/universe Packages nedit | 1:5.5-2ubuntu1 | http://mirror.imbrandon.com edgy/universe Sources
<Toadstool> heya everybody
<jdong> slomo: pong
<slomo> jdong: you pinged me hours ago :)
<jdong> sladen: was gonna ask if you knew how to fix ffmpeg --enable-x264 FTBFS on AMD64....
<jdong> err, slomo
<jdong> it needs to link against PIC x264
<jdong> but instead goes for libx264.a
<jdong> (not libx264_pic.a)
<slomo> then fix the build system :)
<jdong> slomo: what do you mean?
<slomo> but i wonder how it can build against x264 anyway? isn't x264 in multiverse and ffmpeg in universe?
<jdong> slomo: this is for medibuntu
<jdong> (the "new" PLF)
<slomo> tell ffmpeg's build system to link to libx264_pic.a instead of the one without _pic
<jdong> slomo: excuse my noobishness with this linking stuff...  roughly how would I do that?
<slomo> look where the -lx264 is set and make it -lx264_pic
<jdong> ah, ok
<jdong> slomo: and I presume linking against the PIC version on non-amd64 is a no-no?
<slomo> no that's fine iirc
<jdong> oh
<jdong> so if I make that for all arches, there's no side effects?
<slomo> iirc not but it's long ago since i read about this stuff :)
<slomo> ask google or something if you're unsure ;)
<jdong> "The extra indirection may cause PIC code to be less efficient, although modern processors are designed to ameliorate this."
<jdong> lovely
<simon__> hi
<simon__> package mednafen is outdated compared to the version in debian
<simon__> by around 5 months
<johang> you can request a sync
<johang> i just did it with a different package
<johang> https://wiki.ubuntu.com/DeveloperResources
<johang> check under sync.
<asantoni> Ok, I've got Mixxx ready for packaging I think
<asantoni> I've got a mixxx-1.5.0 directory with a "debian" subdirectory and everything set up/patched properly
<asantoni> Do I need to install pbuilder now to test this?
<bddebian> geser: New libticables2 up ;-)
<jdong> mr_pouit: ping
<mr_pouit> jdong, pong
<jdong> mr_pouit: I attached a debdiff against feisty for ffmpeg in bug 81518
<Ubugtu> Malone bug 81518 in ffmpeg "When x264 is enabled, link against libx264_pic.a" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81518
<jdong> mr_pouit: it contains a patch that should resolve FTBFS on amd64 with x264
<jdong> mr_pouit: would appreciate it if you guys can test it, then get it into universe would be a bonus too :)
<mr_pouit> jdong, great! thanks ;)
<mr_pouit> jdong, ok, we'll test it ^^
<jdong> thanks, you guys are awesome
<simon__> johang, if you don't mind could you add it for me?
<geser> bddebian: looks ok for me. advocated.
<bddebian> Thx geser
<tmarble> quick question: how can I get dkpg-buildpackage to use gpg-agent?
<jdong> you don't.
<jdong> you debsign afterwards
<jdong> dpkg-buildpackage runs under fakeroot
<jdong> which gpg-agent will not accept as an authorized user
<tmarble> ah, that's why it didn't work (of course)
<jdong> totally silly in my mind :)
<tmarble> jdong, thanks
<jdong> np
<ademan> heh, how do i reply to something in the mailing list?  Or do i just need to make sure the subject line is RE: the last post in the thread ?
<\sh> press "reply" in your mailclient
* \sh 's gone
<ademan> heh, really? cause then it has the last author as the recipient rather than ubuntu.motu.mailinglist or whatever, but that's how it should be?
<jdong> then reply to all
<jdong> or reply to list, if your client has such a feature
<ademan> evolution, dunno if it does...
<\sh> ademan: well, you have to configure your email client the correct way...or press reply all, and remove the last author...because it's annoying to read mails two times
<\sh> use a real client, thunderbird or kmail 
* \sh runs
<ademan> lol
<ademan> so really the requirement is to: ubuntu.motu.mailinglists.com    and   the subject should be Re: Last Post's Subject Line ?
<geser> ademan: the threading happens from the In-Reply-To: header (usually set automatically by your mua)
<ademan> ah, ok, maybe i've got that kind of functionality
<ademan> thanks
<asantoni> jdong: Thanks again for the help, I think I've got a .deb built properly now :)
<jdong> cool
* enyc throws an aoeuidhtns around
<Amaranth> check this out: http://img212.imageshack.us/my.php?image=screenshot8de.png
* Amaranth cries
<LaserJock> mwuahahaha
<LaserJock> anybody alive in here?
<lifeless> no
<LaserJock> fine
<LaserJock> be that way then
<LaserJock> ;-)
<somerville32> no
<LaserJock> I just talked with the director of instuments for my department
<LaserJock> he's interested in putting Ubuntu on the computers that run our research instruments
<somerville32> Use Xubuntu and poke Canonical for Official Support. ;] 
<LaserJock> that's up to Canonical, and we probably wouldn't use Xubuntu
<LaserJock> it might be Edubuntu actually
<LaserJock> right now they have a couple RHEL machines
<LaserJock> and some Windows/OS X I think
<somerville32> But Xubuntu is awesome. Have you tried it on Feisty?
<LaserJock> I'm sure it is awesome, as is Ubuntu, Kubuntu, and Edubuntu
<LaserJock> I'm not a big XFCE fan
<LaserJock> but the screenshots are looking nice
<somerville32> Xfce4, not XFCE : P
<LaserJock> whatever ;-)
<somerville32> What does Xubuntu have that gnome doesn't? : P
<somerville32> Or... the other way around : P
<LaserJock> lots
<LaserJock> both ways
<LaserJock> they are just different
<LaserJock> I generally use Gnome ( "It sucks less" ) but if I need to go minimal I use openbox
<LaserJock> Xfce4 is sort of like middle-of-the-road for me
<LaserJock> and I haven't found a need for it personally
<ScottK> LaserJock: That sounds really great.
<LaserJock> I've been trying to think of how to get Ubuntu into the department
<LaserJock> I know one group uses it a fair amount for computation chemistry stuff
* ScottK was suprised to walk in to the local public library recently and find all the computers running Ubuntu.
<LaserJock> I think I'm the only one that ever uses it for a desktop (although I'm not presently :/)
<LaserJock> really? sweet!
<ScottK> It was actually my first time using Ubuntu on the desktop as I've always used KDE.
<ScottK> If you are trying to get people interested in transitioninf off of Windows, Kubuntu will look less foreign...
<LaserJock> I suppose
<LaserJock> I generally don't see the "KDE is more Windows looking" but whatever :-)
<ScottK> Of course, if you push it, you'll end up supporting it, so best something you are familiar with.
<LaserJock> well, I install Kubuntu, Edubuntu, and Ubuntu fairly regularly
<LaserJock> and sometimes I'll even have Xfce for a few minutes ;-)
<ScottK> I'm not religious about desktop choices myself, just happen to like one better for my own use.
<LaserJock> same with me
<LaserJock> I used KDE for a long time (and FVWM)
<LaserJock> but Ubuntu has gotten me more into Gnome
<LaserJock> I generally try to stay familiar with both
* ScottK had fun the other day in a meeting with his Kubuntu laptop poking at a presenter who had trouble with Windows/Office being sluggish for using "Inferior prioprietary tools".  
<LaserJock> hehe
<ScottK> I think it even started to penetrate after a while that I wasn't kidding.
<ScottK> If you can find a way to just use Ubuntu and have it work better/more reliably/cheaper, whatever is important there, people will notice and want some too.
<LaserJock> yeah, I love it when they laugh, and then they're like "Your serious"
<LaserJock> either that or use your power and force it on them ;-)
<ScottK> If you have that, that works too.
<ScottK> IME though in large organizations (where large is probably more than about 10) orders to do things people don't want to do have a way of not being gotten around to.
<LaserJock> worked for my wife :-)
<LaserJock> I just edited grub to default to Ubuntu instead of XP
<LaserJock> once Flash9 came out for Linux it was bye-bye Windows
<ScottK> It's a slower start to attract people with honey than beat them with baseball bats (or whatever kind of bats you have) - less fun too, but more sustainable.
<ScottK> Yeah.  Worked on my kids too.
<LaserJock> yah know, I've always thought the "Firefox by default because it's something Windows people know" was kinda weird
* ScottK needs to find time to convert some effing huge Outlook archives to Mbox before my wife will convert (she dual boot some now).
<LaserJock> until one day I saw my wife surfing the net and she had no clue if she was running Windows or Ubuntu
<LaserJock> simply because it was FF
<LaserJock> she couldn't have cared less
<LaserJock> what OS it was
<ScottK> With the kids I first got them using FF, T-bird, and OO on Windows and then swapped them to Linux and they hardly noticed.
<LaserJock> yeah
<ScottK> Of course then when I was in a meeting that happened to have a senior MS guy in it a few months ago and the conversation turned to spam, virii, bots, etc. I could say, "Yes, that's why I don't allow my kids to use Windows".  The look on his face was priceless.
<ScottK> He asked me a lot of questions after that too.  It was fun.
* ScottK goes to look for more coffee.
<LaserJock> ScottK: hilarious
<ajmitch> morning
<bddebian> Heya ajmitch
<ajmitch> sigh
<ajmitch> people that deliberately cc offtopic stuff to devel lists
<jdong> like bad computer jokes?
<bddebian> ajmitch: Just to piss you off :)
<ajmitch> just like #u-motu
* ajmitch knows it's a conspiracy
<Adri2000> Seveas: feisty-changes rss feed seems broken
<Seveas> Adri2000, it's not
<Seveas> it's just on manual
<ajmitch> hey Seveas 
<Seveas> ola ajmitch 
<bddebian> ajmitch: Wanna help my dumb arse with some packaging?
<Seveas> Adri2000, I'm improving the USN parser so the whole email parsing shebang was on manual
<ajmitch> bddebian: depends if it'll take some time or not
<ajmitch> I just got to work & all
<Adri2000> Seveas: USN? UWN?
<ajmitch> checking the fallout
<bddebian> Oh, yeah it might take a while, mn
<bddebian> Err nm even
<Seveas> Adri2000, Ubuntu Security Notices
<Seveas> I have an email2rss parser for that as well
<Adri2000> ah, I thought weekly newsletter
<Adri2000> ok
* keescook hugs Seveas
<Seveas> heh
<Seveas> keescook, yes, I'm working on including details :)
<keescook> \o/
<Seveas> but also improving the thing in general
<bddebian> Ugh, do I wanna touch fai-kernels?
<Seveas> bddebian, with a 10-foot pole?
<bddebian> Maybe 20 foot
<Seveas> yeah, that's safer
<Seveas> ask hobbsee for her big pointy stick of doom
<ajmitch> keescook! how's the hacking week going?
<keescook> ajmitch: hiya, I'm actually not there.  :)
<bddebian> ajmitch: Do you happen to know why gnome-vfs-mime.h is gone?
<DogWater> does anyone know who maintains the redhat kickstart style installation stuff?
<ajmitch> keescook: oh, that's unfortunate
<ajmitch> bddebian: ENOCLUE
<ajmitch> bddebian: I'm guessing it had to run away
<DogWater> also anyone know who maintains the netboot portion of the installer?
<bddebian> Gah, I hate crap that we've brought in that is now in Debian.. :-(
<bddebian> DogWater: My guess would be that the installer stuff is done by the main folks.
<DogWater> the netboot installer is broken in 6.10
<ajmitch> didn't you ask this in about 2 or 3 other channels & get an answer?
<DogWater> no, there was no answer
<ajmitch> 09:00 < dsas> DogWater: I'm not sure who's responsible for updating that, perhaps cjwatson
<DogWater> so i pester cjwatson about it?
<bddebian> Gah fruck, -GLw..
* bddebian begins crying and whining
<ajmitch> he's a tad busy this week, I think
<DogWater> well, i was just trying to figure out if there is anything we can do to help to get the kickstart process a little more polished
<DogWater> as we do all of our builds exclusively with kickstart and we'd like to start offering ubuntu
<ajmitch> there's a distro team sprint on at the moment, which I think he's attending
* ajmitch reassigns bug to d-i
<ajmitch> hopefully that's the right one, and he'd hopefully see it then
<keescook> does anyone know if the buildds have /usr/bin/lsb_release ?
<ajmitch> I doubt it
<keescook> I can't tell, but it seems to be a dep of base-files ?
<ajmitch> nope
<ajmitch> Replaces: base, miscutils, lsb-release (<< 3.0-8)
<ajmitch> Provides: base
<ajmitch> Depends: libc6 (>= 2.4-1ubuntu3), awk, base-passwd (>= 2.0.3.4), libpam-modules (>= 0.79-3ubuntu3)
<keescook> hmmm
<ajmitch> ubuntu-standard depends on it, I think
<ajmitch> but I don't think that's on the buildds
<ajmitch> I think it's just build-essential on there, but I can't be certain
* keescook nods
<keescook> I wonder how it snuck into my chroots...
<LaserJock> morning ajmitch 
<bddebian> So since we don't have libGLw, I need to disable mesa entirely?
<ajmitch> bddebian: try libgl1-mesa-swx11-dev
<LaserJock> ajmitch: you got OT in -motu?!? :-)
<ajmitch> LaserJock: hm?
<LaserJock> ajmitch> people that deliberately cc offtopic stuff to devel lists
<ajmitch> people are never offtopic in here
* LaserJock looks around
<LaserJock> I don't know what channel you've been lurking in
<LaserJock> but it hasn't been here ;-)
<poningru> I wanna bother someone re: getting alpine into universe
<LaserJock> poningru: why do you need to bug someone about it?
<poningru> LaserJock: its in debian unstable
<poningru> should I just file a bug in lp for inclusion?
<poningru> http://packages.debian.org/unstable/mail/alpine
<bddebian> ajmitch: I thought we dropped libGLw in Edgy?
<LaserJock> poningru: you can file a sync request if you verify that it builds, installs, and works in Feisty
<poningru> yes sir
<ajmitch> bddebian: I don't know, take a look & find out :)
<bddebian> ajmitch: Uhm, that wants to remove ubuntu-desktop :-)
<LaserJock> poningru: ohhhhh, alpine. I just realized what you were asking about
<LaserJock> poningru: that would be cool to see in Feisty
<poningru> LaserJock: yeah I know right my friend packaged it up
<poningru> but got no lovin from ubuntu :(
<ajmitch> bddebian: I have every confidence that you can fix it & make everything happy
<LaserJock> well, it *should* go in Debian first
<ajmitch> and ponies will be out dancing in the fields, etc
<bddebian> ajmitch: Well that's your first mistake :-)
<poningru> its in debian unstable...
<LaserJock> poningru: if it had gotten into Debian early enough it would have been automatically picked up
<poningru> oh hehe yeah
* ajmitch wonders what alpine is
<poningru> I will build it in feisty tonight and file a sync request
<poningru> http://en.wikipedia.org/wiki/Alpine_%28e-mail_client%29
<LaserJock> ajmitch: pine replacement
<LaserJock> well, not replacement
<ajmitch> oh, you mean mutt
<LaserJock> it's pine 2.0
<ajmitch> :)
<LaserJock> bah
<LaserJock> I used pine for a long time at school
<ajmitch> poor fellow
<LaserJock> I don't think they even had mutt installed
<LaserJock> it worked just fine mostly
* ajmitch just had a .forward sending stuff onto home
<LaserJock> my boss still uses it
<hub> I used mutt until I used to many imap accounts
<ajmitch> and I read my mail via ssh to home
<LaserJock> ajmitch: well, until recently the uni server was the most stable machine I had access to
<LaserJock> then it went up in flames
<LaserJock> almost literally
* poningru sets LaserJock's server on fire
<enyc> LaserJock: hrrm what univ. was that?
<enyc> LaserJock: I remember security.debian.org. on fire
<ajmitch> different fires
<ajmitch> that was in .nl, I think
<fernando> mutt is the best :P
<LaserJock> enyc: mine is the University of Nevada, Reno USA
<LaserJock> I haven't quite fallen in love with mutt
<LaserJock> I guess my biggest problem is that I always run it on the email server
<LaserJock> and then attachments are a pain
<LaserJock> apparently our server started smoking
<LaserJock> and the raid control died
<ajmitch> a bit annoying
<LaserJock> so the department decided to off-load everything to the campus servers
<LaserJock> and just the other day the shut down our server
<LaserJock> so.. now I have a nice webmail account and get my Ubuntu mail sent elswhere
<fernando> somebody know any article about the better pratics to command line options? =) example, more intuitive, more clean, more easy to users
<fernando> better format
<fernando> =)
<LaserJock> *cough*
<LaserJock> *more*  intuitive and user friendly CLI options?
<LaserJock> *stuffy british voice* it's simply not done
<fernando> hehehe
<ajmitch> all apps must become like tla!
* Seveas thwacks ajmitch 
<ajmitch> hey now
<ajmitch> tla was a masterpiece
* fernando not kidding =(
<bddebian> Heh, disabling MESA doesn't work either :-(  ../include/xwin.h:122:22: error: GL/xmesa.h: No such file or directory
<giskard> LaserJock, did you tried mutt -f pops:// ?
<tsmithe> !tla
<ubotu> tla: arch revision control system. In component universe, is optional. Version 1.3.3-3.3 (edgy), package size 277 kB, installed size 744 kB
<tsmithe> meh
<giskard> the first arch implementation
<giskard> written by tom lord (iirc)
<enyc> LaserJock: hrrm i see
<enyc> LaserJock: I remember security.debian.org went up in smoke at the university of twente......
<plugwash> went up in smoke recently?
<geser> plugwash: recently as in nov 2002 :)
<asantoni> hey guys
<asantoni> the Ubuntu wiki told me to "ask the REVU admins in #ubuntu-motu .... to re-sync the REVU uploaders keyring"
<asantoni> :D
<ajmitch> running it now
<asantoni> thanks a ton :D
<ajmitch> should be done in ~10min
<asantoni> awesome
<_MMA_> Anyone know when this stuff will show in the repos? https://launchpad.net/ubuntu/feisty/+queue Im still trying to learn the process.
<_MMA_> Is their someone who pushes it from the queue or does it happen automatically at some point?
<ScottK> There is someone who pushes it.
<geser> _MMA_: when an archive admin accepts them (which is only needed for the first time)
<_MMA_> geser: Ok. I thought that was the step to get them _to_ the queue not after? Im still learning. :)
<geser> there are several queues
<geser> this is the NEW queue where every new package lands
<ajmitch> REVU queue, NEW queue, source publishing, build queue, binary publishing
<ajmitch> what else?
<_MMA_> :)
<ajmitch> apart from -proposed, etc
<ajmitch> which are special
<geser> isn't between build queue and binary publishing once again the NEW queue (this time for the debs)?
<ajmitch> if they're binary NEW
<ajmitch> so that's the same queue used twice
<ajmitch> unapproved queue for freeze times
<LaserJock> _MMA_: it went REVU -> source NEW -> binary NEW
<ajmitch> heh
<ajmitch> "no blobs by default petition"
<LaserJock> of course
<_MMA_> Ahh... Ok. Just eager to test some of the packages like a bunch of people I guess. Thanx for the info.
<geser> _MMA_: we have (had?) archive days (tuesdays and fridays) where an archive admin went through the accumulated stuff (syncs, NEW, etc)
<LaserJock> who wants scary blob monsters in their computer?
<LaserJock> _MMA_: well, the .debs are in Launchpad if you want to try them out :-)
<LaserJock> at least I think they are
<ajmitch> LaserJock: blobs are great
<_MMA_> LaserJock: I want have them show all perdy in Synaptic. :)
<LaserJock> _MMA_: hehe, I know the feeling. apt-get update apt-get install <sweetness>
<LaserJock> ajmitch: but they are scary
<LaserJock> I don't want some "Swamp Thing" running around my hard drive
<ajmitch> LaserJock: they eat ponies!
<LaserJock> poor little ponies :(
* ajmitch has his laptop running here, it has eeevil ipw2200 firmware blobs
<ajmitch> which are shipped in the ubuntu kernel
<LaserJock> I don't know and frankly don't care what blobs I have
<_MMA_> Best pony ever: http://sg.geocities.com/mental_89/blogskins/MY_little_pony.jpg
<TheMuso> ajmitch: Are we ever likely to see alternate firmware for those cards?
<TheMuso> That is free?
<ajmitch> joy, My Little Pony complete with teenage angst
<LaserJock> but ... it's not cute and huggy
<ajmitch> TheMuso: possible but unlikely in the near term
<LaserJock> yeah, are we going to get Emo Pony?
<_MMA_> lol
<ajmitch> TheMuso: openbsd has drivers that work without their firmware I *think*
<TheMuso> ajmitch: I rmeember hearing something about that, but not sure about the firmware either.
* LaserJock wonders if My Little Metallica Pony would sell well
<ajmitch> TheMuso: ah no, their page says you need the firmware
<LaserJock> probably too old :/
<bddebian> LaserJock: I'd buy one :-)
<TheMuso> ajmitch: ah well./
* ajmitch can handle using the intel firmware
<LaserJock> just as long as we don't get My Little Maryiln Manson Pony
<LaserJock> that'd be tooo creepy
<TheMuso> ajmitch: Me too, because I don't really have any other choice.
<ajmitch> unlike nvidia drivers, they don't taint the kernel & run on the cpu
<TheMuso> I'll use free wheever possible, but am happy to use slightly non-free to make use of hardware I own.
<somerville32> In recovery mode, it won't ask for the root passwd no matter what, right?
* TheMuso wonders whether Intel will make Linux drivers for their new wireless chips.
* ajmitch uses nvidia drivers, but wants to help out with nouveau where/if possible
<ajmitch> anyway, back later
#ubuntu-motu 2007-01-26
<ademan> hey i'm doing a sort of test build of the binary package for code::blocks, and pbuilder is downloading g++ 3.4  wtf?  Should i change it to 4.1 in the control file (i assume that's what's making pbuilder download it)
<jdong> is it building with g++ 3.4 or 4.1?
<jdong> it might FTBFS with newer GCC  and that's why it asks deliberately for an older one.
<ademan> FTBFS?
<ademan> well pbuilder is downloading 3.4, so i assume it's going to build with 3.4
<ademan> haven't quite gotten there yet :-)
<jdong> let it do it first
<jdong> and see if you can contact the previous maintainer
<jdong> see if ther ewas a reason why it builds against 3.4
<ademan> well the upstream packager wrote the debian dir
<ademan> he kinda looked at me funny when i suggested letting the individual distros take care of packaging for themselves
<LaserJock> no don't I feel smart, I just changed the password on my computer and promptly forgot it :/
<TheMuso> LaserJock: lol
<ademan> hrm, " *** No rule to make target `configure', needed by `config.status'.  Stop.
<ademan> pbuilder: Failed autobuilding of package"  That would be a problem with debian/rules most likely right?
<StevenK> LaserJock: Live CD, chroot, passwd ?
<LaserJock> well, it's on OS X, not sure if that'd work very well
<StevenK> Oh right, you're a Mac fanboy
<LaserJock> well, it's what I "get" to use
<ademan> anyone on my pbuilder error?
<LaserJock> ademan: look at the configure.status: rule and see if it calls configure:
<ademan> LaserJock: ./configure?
<LaserJock> no
<LaserJock> debian/rules has to have a configure: rule
<LaserJock> I think
<LaserJock> anyway
<pochu> hey, does anybody know if network-admin belongs to gnome-system-tools?
<LaserJock> look at debian/rules and see if config.status: is calling configure: 
<ademan> heh, config.status depends on configure
<ademan> which doesn't exist
<ademan> and of course, the debian dir is part of the upstream source, but i suppose i should just edit it anyways?
<coNP> pochu: yes it does
<pochu> coNP: thanks!
<pochu> it's for bug 81564
<Ubugtu> Malone bug 81564 in Ubuntu "network-admin fails to switch properly between profiles" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81564
<ademan> LaserJock: so should i just edit the debian/rules to have a configure target?  (which does nothing, but could in the future) ?
<LaserJock> yeah
<ademan> LaserJock: i avoid autotools like the plague (actualyl that's the main reason why i'm trying so hard to package all these IDEs), how do I get a ./configure script?  as of now i've got a configure.in,  i have to run like aclocal or something, then autoconf?
<ademan> ugh, it doesn't work at all anymore
<ademan> i broke it :-)
<ademan> anyways i gtg, i'll work on it later tonight
<ademan> actually, before i do, dpkg-buildpackage complains about  a "missing separator"
<ademan> what's it talking about?  the line before says debian/rules clean    but i didn't modify the clean target at all
<bddebian> Probably a missing/extra tab or \
<ademan> yeah, i just figured it out
<ademan> gedit was set to use 4 spaces rather than a tab character :-)
<ademan> er, :-/
<bddebian> Damn, I swear half of the merges left are just plain borked
<ademan> merges from debian?
<bddebian> Yeah
<ademan> heh, sorry :-(
<ajmitch> that's why they're still on the page
<ademan> i'm not much of a motu, this'll be my first package, last time i tried to package something i ended up failing and vil stepped in and fixed it
<bddebian> somerville32: You here?
<somerville32> bddebian, Yup
<ademan> pbuilder told me aclocal doesn't exist, wtf?
<ajmitch> not in build deps?
<ademan> in debian/control?
<ademan> the autotools package right?
<bddebian> somerville32: Did you ever try fnfx merge?
<ajmitch> ademan: an appropriate automake package
<somerville32> I'm doing it as we speak
<ajmitch> eg automake1.9 or 1.10
<ademan> ajmitch: aclocal is a part of that?
<ajmitch> hm, we don't have 1.10
<ajmitch> well yes
<bddebian> And doko and slomo are plastered all over merges.u.c :)
<somerville32> bddebian, Are you expecting me to have difficulties or just interested in me doing it? :)
<bddebian> somerville32: Both ;-P
<ademan> ajmitch: under Build-Depends: right?
<somerville32> bddebian, What difficulties do you expect?
<ajmitch> yes
<ademan> thanks, i gtg now, i'll be back later tonight to pester you guys
<bddebian> somerville32: If you are using the scripts it might not be too bad.  I was doing it by hand :-(
<bddebian> Heya LaserJock
<LaserJock> brb
<somerville32> bddebian, It says in the changelog that it "resynced" with debian, so this would mean changes before hand no longer apply, right?
<bddebian> somerville32: Probably not.  Some of us say re-synced even if/when we mean re-merged
<ajmitch> LaserJock!!
<LaserJock> well, that was annoying
<ajmitch> server gone up in smoke again? :)
<LaserJock> no, reset my password and immediatly forgot it
<LaserJock> it's one of those days
<LaserJock> anyway, one OS X install disc and Keychain recovery and I'm back in business ;-)
<somerville32> bddebian, Guh. Maybe I don't want to do this merge ;] 
<bddebian> somerville32: How come? :-)
<somerville32> Welp, here goes nothing
* somerville32 tries to build
<somerville32> bddebian, Ok
<somerville32> I think I've merged it, lol
<bddebian> somerville32: Does it build? :)
<somerville32> Yup
<somerville32> There are some deltas that I'm not sure are right
<bddebian> I actually asked for a sync but Mithrandr questioned me
<bddebian> I think most of the crap is old and unnecessary but hey, what do I know? :)
<somerville32> There are some Ubuntu specific changes
<somerville32> But I dunno if it is applicable any longer
<bddebian> Exactly
<bddebian> Some (many?) of them go back to Hoary
* somerville32 nods.
<somerville32> Can I DCC send you the debdiff for review?
<bddebian> I don't think I can receive dcc
<somerville32> Look at the debdiff
<somerville32> There are acpi-related mods by Ubuntu
<somerville32> But they aren't really mentioned in the changelog
<bddebian> I know
<somerville32> I can just delete the autogenerated Makefile.in and stuff from the diff, right?
<somerville32> bddebian, ^^
<bddebian> somerville32: Should be fine, yes
<somerville32> is configure autogenerated?
<bddebian> Can be
<somerville32> It looks like Canonical has invested money in this package, ;] 
<bddebian> somerville32: How so?
<LaserJock> what package are you working on?
<somerville32> fnfx
<somerville32> bddebian, It appears they rewrote the entire acpi stuff for it
<somerville32> The author has a canonical e-mail
<bddebian> somerville32: Ahh
<somerville32> Ok, I think I have a sane patch that I'm going to try
<crimsun> keescook: do we need a security update for breezy's and dapper's acroread, too?
<keescook> crimsun: yeah, if you're interested.  :)
<crimsun> ok, working on it now.
<keescook> awesome.  :)
<bddebian> crimsun: Then you want to look at libticables2 for me? :)
* bddebian takes that as a no
<somerville32> bddebian, If this compiles, I'm going to file the merge.
<somerville32> It fails, lol
<somerville32> Must have removed something needed
<somerville32> How can I use filterdiff to remove files?
<crimsun> the man page is pretty nice.
<crimsun> essentially: use -x with '*foo' to exclude; use -i with '*foo' to include
<azeem> W18
<azeem> hrm
<somerville32> thanks
<crimsun> bddebian: security errata first.
<bddebian> azeem: :-)
<bddebian> crimsun: I'm just busting your chops
<crimsun> bddebian: sorry, but you've got all the chops :-)
<zakame> morning all
<crimsun> 'morning
<bddebian> Heya zakame
<zakame> yo bddebian crimsun
<bddebian> wtf is linux-tree-2.6.18?
<crimsun> should be a meta for source and patches.
<somerville32> bddebian, you there?
<somerville32> If I wanted to test my patch, I would create the debdiff as usual (latest debian and merged ubuntu) and then extra latest debian and apply patch to it?
<somerville32> s/extra/extract
<zakame> somerville32: sure you could
<somerville32> And then rename directory?
<crimsun> keescook: http://adhd.irule.net/~crimsun/breezy-security/ , http://adhd.irule.net/~crimsun/dapper-security/
<keescook> crimsun: cool, can you put a note on the bug for it?  I'm about to head to dinner and I don't want to lose it.  :)
<crimsun> keescook: will do.
<bddebian> Any idea what would cause this:?  /bin/sh: Can't open libtool
<bddebian> somerville32: Yeah sorry was putting the kids to bed
<somerville32> No idea but I'm getting:
<somerville32> fnfxd_newacpi.c: In function 'do_fnkey':
<somerville32> fnfxd_newacpi.c:90: error: 's_acpi_cfg' has no member named 'fnkey_descr'
* somerville32 ponders what he is doing wrong.
<crimsun> bddebian: missing libtool?
<somerville32> Maybe all those files I removed aren't so autogenerated as I thought
<bddebian> somerville32: Have you messed with the s_acpi_cfg struct at all?
<somerville32> No
<bddebian> crimsun: It's a build-dep
<crimsun> bddebian: what immediately precedes it?
<zakame> any pointers on what's the right upgrade path from edgy to feisty? :D
<bddebian> apt-get dist-upgrade? :-)
<Hobbsee> zakame: try a dist-upgrdae.
<bddebian> crimsun: Dunno but /bin/sh libtool does the same on my machine but /bin/bash libtool works
<crimsun> bddebian: interesting bashism?
<bddebian> Yeah but why/what? :-)
<zakame> bddebian, Hobbsee: I'm just checking, don't wanna experience another dapper/edgy blowout ;)
<bddebian> I went dapper->edgy->feisty the other day on a laptop and didn't have a problem.  Of course it was a minimal install
<bddebian> crimsun: Any idea how I fix it?  Just add bin/bash?
<crimsun> that would hack around whatever's breaking it
<bddebian> Here's the call in debian/rules:
<bddebian>         dh_testdir
<bddebian>         sh compile-gtk2im.sh
<bddebian> then compile-gtk2im.sh does /bin/sh libtool ...
<crimsun> try /bin/bash compile-gtk2im.sh
<crimsun> but god is that ugly
<bddebian> Yeah it is
<Hobbsee> zakame: kubuntu worked OK last time i checked.
<zakame> Hobbsee: cool, thanks
<somerville32> me try dvorak
<somerville32> bddebian, The merged package doesn't build at all
<bddebian> crimsun: Didn't work, I'd have to change all the sh libtool commands in compile-gtk2im.sh also :-(
<bddebian> somerville32: Does the vanilla Debian package build?
<crimsun> bddebian: that's AWESOME.
<crimsun> nearly as awesome as say, high definition audio not working because it's HIGH DEFINITION
<bddebian> heh
<somerville32> bddebian, attempting now
<somerville32> bddebian, yes, it does.
<bddebian> Hmm
<somerville32> Who is William Grant?
<ajmitch> a motu
<Hobbsee> somerville32: fujitsu
<somerville32> What are "Updated Merges"?
<bddebian> I believe after a merge has already been done and another Debian version gets uploaded but I'm not sure
<Hobbsee> bddebian: you're right
<bddebian> Hobbsee: Ah cool.  That happens so rarely :-)
<somerville32> :)
* somerville32 hugs bddebian.
* somerville32 moves onto something else.
<somerville32> Any news on imbrandon's build boxes?
<ajmitch> nope
<ajmitch> back later
<somerville32> https://bugs.launchpad.net/ubuntu/+source/xfce4-genmon-plugin/+bug/81582
<Ubugtu> Malone bug 81582 in xfce4-genmon-plugin "xfce4-genmon-plugin: merge new debian version" [Undecided,Unconfirmed]  
<jdong> can someone sponsor bug 79356
<Ubugtu> Malone bug 79356 in gpac "request version bump to 0.4.2~rc2" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79356
<jdong> and if any MOTU-media's around, I merged xvidcore 1.1.2 @ bug 81405, awaiting feedback....
<Ubugtu> Malone bug 81405 in xvidcore "Sync xvidcore 1.1.2 from debian-multimedia" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81405
<superm1> hey crimsun, i've updated the mythtv/mythplugins packaging to the new upstream version a few days ago.  any chance in a lookover/upload?
<somerville32> How do you pronounce your nick, superm1?
<superm1> "super M 1" is how i go about it
<superm1> it dates way back to when i was little
<superm1> and my mom had gotten AOL for our house
<superm1> and they had limitations on your screen name length
<somerville32> Ah
<superm1> and i wanted "super mario"
<superm1> but couldnt have it, so i went for superm, but that was taken
<superm1> so i ended up with superm1
<somerville32> Cute : )
<superm1> honestly, i dont know why it's stuck with me - now that i've grown up more, i can see how its very easy to read that as something else
<somerville32> When I was in grade 2 I went to this computer camp in the summer and we created hotmail accounts
<somerville32> I wanted my last name, somerville
<somerville32> But it wasn't available
<crimsun> superm1: tomorrow during my office hours.
<superm1> but you liked intel's 32 bit architecture a lot at this age ?? :)
<superm1> crimsun, okay cool
<superm1> crimsun, so i can be around when your looking if you have questions or concerns, what times are your office hours?
<somerville32> aha, ;]  It offered different alternatives such as somerville32 and I couldn't pick so my instructor picked somerville32 for me
<somerville32> superm1, I've used somerville32 as my handle ever since
<superm1> funny how these things stick with you
<crimsun> superm1: anytime after 1900 UTC.
<superm1> k, i'll try to be on IRC after that then
* Hobbsee attempts to create a hackergotchi
<Hobbsee> !planet
<ubotu> Planet Ubuntu (blogs of Ubuntu developers and members) can be found at http://planet.ubuntu.com
<Hobbsee> that *doesnt* help
<somerville32> Isn't there an e-mail address you can send a picture off to an it'll do it for you?
<Hobbsee> somerville32: imbrandon did one of me once.  it was crap
<somerville32> lol
<somerville32> Are you looking for the drop shadow?
<ScottK> Good evening every one.
<Hobbsee> somerville32: no, i look crap with it
<Hobbsee> http://img253.imageshack.us/img253/6017/snapshot2bt1.png
<ScottK> I'd appreciate it if someone from u-u-s would take a look at my patch for bug #79683 - the version described as 'Patch w/cleaner changelog' it's a much simpler patch than the number of tries I've had at it might indicate...
<Ubugtu> Malone bug 79683 in libspf2 "spfquery: conflict with libmail-spf-query-perl Debian bug#306875" [Unknown,Unconfirmed]  https://launchpad.net/bugs/79683
* ScottK will go look and see if I can find a merge simple enough that I can pull it off in the meantime...
<somerville32> Hobbsee, Why not just take the image and round it up?
<Hobbsee> somerville32: i could, yeah
<somerville32> But?
<Hobbsee> *shrugs* 
<Hobbsee> i tend to look very odd with no hair, no surroundings, etc
<LaserJock> Hobbsee: you should just use that picture of you with your car ;-)
<Hobbsee> LaserJock: hehe, could do.  i thought that one was pretty, too
<LaserJock> interesting tar message: implausibly old time stamp 1969-12-31 16:00:00
* Hobbsee commits
<ScottK> Hobbsee: You were the last one to upload syslog-summary.  Do you mind if I make a try at that merge?  It looks easy enough even form me.
<Hobbsee> ScottK: yes.  dodgy ubuntu version.
<Hobbsee> iirc, it's a sync, the next time
<ScottK> Thaks.
<ScottK> THanks
<Hobbsee> it's actually been merged already
<ScottK> Oh.
<Hobbsee> but you dont really see it, due to difference in version
<ScottK> Then I won't do it over...
<Hobbsee> (native package with a debian NMU always screws up)
<Hobbsee> :)
<ScottK> Does the list at http://merges.ubuntu.com/universe.html get automatically updated?  Is there something that should be done to get syslog-summary off the list that I can do (e.g. file a bug...)?
* ScottK will go look for another one...
<Hobbsee> ScottK: nope.  the debian version is higher than ubuntu's
<crimsun> ScottK: 79683 uploaded.
<Hobbsee> i'm not sure it still does get updated, actually
<ScottK> crimsun: Thanks.
<somerville32> Hobbsee, I'm pretty sure it does.
<somerville32> I did some last night and they aren't there anymore
<jdong> crimsun: care to reexamin the xvidcore merge?
<jdong> (bug 81405)
<Ubugtu> Malone bug 81405 in xvidcore "Sync xvidcore 1.1.2 from debian-multimedia" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81405
<Hobbsee> somerville32: cool
* ScottK is trying to understand.... bug #55298 was rejected because I merge is needed....
<Ubugtu> Malone bug 55298 in syslog-summary "Please sync syslog-summary 1.12-0.1 from debian sid" [Undecided,Rejected]  https://launchpad.net/bugs/55298
<Hobbsee> yes
<Hobbsee> ScottK: met dpkg --checkversions or whatever it is?
* somerville32 hasn't.
<Hobbsee> dpkg --compare-versions
<ScottK> So maybe I misunderstood... Is a merge not needed or was it already done (don't see a bug for a merge)?
* Hobbsee is a MOTU.  
* Hobbsee doesnt need to file bugs to merge things
<jdong> Hobbsee: well aren't you special :)
<jdong> _you_ want to look over my xvidcore merge, and/or sponsor a ffmpeg or gpac upload?
<somerville32> jdong, Are you going to apply for -dev?
<jdong> somerville32: maybe... I think I probably still need more experience before I stand a chance though
<bddebian> ScottK: Did someone already upload your patch?
<ScottK> bddebian: Yes.
<ScottK> Thanks.
* jdong wimpers in a corner
<ScottK> Hobbsee: Ah I understand now.  Thanks.
<bddebian> ScottK: Who?
<somerville32> jdong, whats your launchpad page?
<crimsun> bddebian: .changes is attached to the bug report for sponsored uploads.
<crimsun> bddebian: and that would be me.
<jdong> somerville32: ~jdong
<bddebian> Damn man
<ScottK> crimsun types faster than I do...
<crimsun> I'm just going to pretend this 56kbps loves downloading the xvidcore tar.gz from ftp.sunet.se.
<jdong> lol
<jdong> poor crimsun  :)
<ScottK> Next merging question then...  Other than asking here, how could I tell that package didn't need a merge done?
<crimsun> jdong: please follow merge policy (list existing Ubuntu delta)
* jdong is ashamed.... there's a merge policy?
<somerville32> Will someone look at my merge?
<somerville32> https://bugs.launchpad.net/ubuntu/+source/xfce4-genmon-plugin/+bug/81582
<Ubugtu> Malone bug 81582 in xfce4-genmon-plugin "xfce4-genmon-plugin: merge new debian version" [Undecided,Unconfirmed]  
<Hobbsee> ScottK: you eventually pick it up
<ScottK> OK.
<ScottK> While I go wonder off and try and merge something again, if a MOTU would look at http://revu.tauware.de/details.py?upid=4179, I'd appreciate it.  It's looking for a second sponsore...
* jdong goes wiki searching
<ScottK> sponsore/sponsor...
<crimsun> jdong: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-August/000182.html
<jdong> crimsun: ok, now I see the policy page. I apologize :(
<somerville32> jdong: What does the backporters team do?
<jdong> somerville32: tests and approves backports requests
<somerville32> Cool
<jdong> crimsun: btw is the recent flashplugin upload worthy to backport or no?
<crimsun> yes.
<crimsun> 81405 fixed & uploaded.
<jdong> ok
<jdong> bug 81405
<Ubugtu> Malone bug 81405 in xvidcore "Merge xvidcore 1.1.2 from debian-multimedia" [Wishlist,Fix committed]  https://launchpad.net/bugs/81405
<jdong> cool thanks :)
* jdong has diseased goldfish memory span with bugno's :D
<jdong> crimsun: so would you like to deal with my problems more? :)
* jdong has gpac waiting in line :D
<somerville32> PFft.
<somerville32> Bug #81582
<Ubugtu> Malone bug 81582 in xfce4-genmon-plugin "xfce4-genmon-plugin: merge new debian version" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81582
<crimsun> no, I'd like to sleep so I can get up for my 4 AM run. Thanks, though!
* somerville32 socs.
* somerville32 tries again.
* somerville32 sobs.
<LaserJock> crimsun: geeze, you run?
<LaserJock> :-)
<ScottK> Hobbsee: How about me taking a shot at merging kdissert?  It looks like a one bugfix update from Debian and your packaging differences were minor....
<jdong> crimsun: sleep tight :) and thanks for everything
<bddebian> LaserJock: Machines have to do something or they'd rust ;-P
<LaserJock> I guess you have to do *something* to keep your sanity
<bddebian> somerville32: I'm looking at it now
<somerville32> bddebian, Thanks :)
* Hobbsee looks
<Hobbsee> ScottK: go for it
<ScottK> OK.  Will give it a shot...
<jdong> whatever happened to bisexual apt?
<jdong> oh crap
<jdong> I meant biarch
* jdong should sleep too
<ScottK> debian bug #392940
<Ubugtu> Debian bug 392940 in kdissert "kdissert: FTBFS: could not make  /home/buildd/.waf-0.9.0" [Serious,Closed]  http://bugs.debian.org/392940
* ScottK is learning to like the bots...
<Hobbsee> :)
<jdong> bots rule :)
<jdong> kinda
<jdong> at least for bug reports
<jdong> they kinda are annoying when you say Mandriva 2007 and get a bug report :D
<Ubugtu> Mandriva bug 2007 in Installation "Switching to alternate screens during install crashes X" [Normal,Resolved: fixed]  http://qa.mandriva.com/show_bug.cgi?id=2007
<bddebian> Well who the hell would ever say Mandriva? :)
<somerville32> Just say Mandravia ;] 
<jdong> Seveas: that should really be fixed btw.... mandate mandriva _bug_ and not just mandriva. their version numbers trigger bug reports
<somerville32> Mandravia 2007
<jdong> lol
<jdong> mandrake 2007
<jdong> that works too
<somerville32> Indeed
* jdong files bugreport for new flash package
<jdong> backports request report, that is :)
<bddebian> And here I was hoping it was a package removal request ;-P
<jdong> lol
<somerville32> bddebian2, Everything ok?
<bddebian2> Yep, uploaded
<somerville32> Can I do merges in main?
<bddebian2> You can but we can't upload them for you
<zakame> lfittl: hi, are you packaging secondlife-client for debian?  How's it going?
<jdong> bddebian2: would you be willing to upload bug 79356? :)
<Ubugtu> Malone bug 79356 in gpac "request version bump to 0.4.2~rc2" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79356
* jdong is just about finished with media frenzy :D
<LaserJock> darn, this fitting program is taking forever :(
<zakame> what fitting?
<LaserJock> I'm fitting data to a kinetic model
<somerville32> If there is a package in Ubuntu that isn't in debian but now there is, do we just merge it like normal?
<LaserJock> I have to present a poster tomorrow morning
<LaserJock> so I need the data like yesterday
<LaserJock> somerville32: you have to watch the .orig.tar.gz
<zakame> somerville32: of course, be extra careful
<LaserJock> you can't merge them if they aren't same md5sum
<somerville32> ok
<somerville32> Also, what do the different colours mean? When is the merge dead line again?
<LaserJock> I'm not really sure what the colors are
<LaserJock> deadline is basicaly UVF
<LaserJock> Feb. 8th I think
<somerville32> Can promotions to main occur after UVF?
<LaserJock> I think that might be FF
<LaserJock> I wish it was later :/
<LaserJock> I've got quite a few to do
<bddebian2> LaserJock: Quite a few what?
<ScottK> Hobbsee: Kdissert is done (I think).  Bug #81590.
<Ubugtu> Malone bug 81590 in kdissert "Outstanding merge of debian 1.0.6.c-1.1" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81590
<LaserJock> ugg, people need to put the package name in the bug title
<ScottK> Good point.
<ScottK> I'll fix it...
<somerville32> I thought it was suppose to be: <packagename>: merge new debian version
<ScottK> Now you say something .... Bug #81590
<Ubugtu> Malone bug 81590 in kdissert "Kdissert - outstanding merge of debian 1.0.6.c-1.1" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81590
<somerville32> In doodled, I have: doodle (= ${binary:Version}) in the debian version
<somerville32> and doodle (= ${Source-Version}) in the Ubuntu version
* ScottK is off to bed.  
<somerville32> umm... nvm :)
<bddebian2> jdong: Uploaded
<bddebian2> Bedtime for me too.  GNight gang
<LaserJock> cya ScottK 
<LaserJock> and as always I miss bddebian
<ScottK> cya
* Hobbsee wishes this was the debian changelog bit.
<Hobbsee> done
<somerville32> :] 
<somerville32> Hobbsee, Will you be able to upload my doodle merge here in a second? :)
<somerville32> Yeah, upgrade complete. Now my computer isn't crawling :)
<ademan> hey how do i get a gpg key?
<LaserJock> ademan: you make one
<LaserJock> !gpg
<ubotu> gpg is the GNU Privacy Guard.  See https://help.ubuntu.com/community/GnuPrivacyGuardHowto
<mneptok> moof.
<ademan> woof
<mneptok> anyone want to admit to maintaining QuodLibet? :)
<ademan> lol, wtf IS Quodlibet?
<mneptok> aptitude show quodlibet
* somerville32 blinks.
<ademan> lol sorry, but how do you paste in vim?
<somerville32> Can someone sponsor #81593 for me please?
<somerville32> * Can someone sponsor Bug 81593 for me please?
<Ubugtu> Malone bug 81593 in doodle "doodle: merge new debian version" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81593
<ademan> how do you start up the gpg-agent again?  it told me gpg-agent wasn't a valid command
<LaserJock> I'm not sure I don't use one
<ademan> Laser_away: how do you not? don't you need gpg to sign packages?
<ademan> meh brb i'm just gonna restart my comp
<dholbach> good morning
<lifeless> ajmitch: ping
* Mez -> bed
<\sh> moins
<Q-FUNK> gaelic?
<\sh> no short form of "moin moin", which means "good morning" or "good day" in a north german slang
<Q-FUNK> (11:37:39) mnepton poistui huoneesta (quit: "Hwt! We Gardena in geardagum, eodcyninga, rym gefrunon, hu a elingas ellen fremedon!").
<Q-FUNK> not enough words ending in -ir to be icelandic, but they use  and  at a few places.  I'd have to assume some form of gaelic.
<cbx33> I've forgotten how do I go about making a feisty pbuilder?
<cbx33> I seem to remember editing a pbuilder distro script
<cbx33> but where are they located?
<Q-FUNK> confugure .pbuilderrc for feisty
<Q-FUNK> or /etc/pbuilderrc
<Q-FUNK> then:  sudo pbuilder create
<ademan> hrm, when i asked the Code::Blocks maintainer about my problems, he said he just built it with this command: "fakeroot debian/rules build"  is that really acceptable?  Shouldnt it use pbuilder?
<StevenK> ademan: The buildds won't.
<coNP> ademan: does pbuilder not build with "debian/rules binary"?
<ademan> coNP: i don't believe there's a binary target in rules, lemme check though
<coNP> ademan: there is :) I use it regularly :)
<StevenK> Well, there really should be.
<ademan> yeah, there is
<ademan> but i dunno, all i know is it fails with pbuilder
<ademan> i just do
<StevenK> How does it fail?
<ademan> pbuilder build ../*.dsc
<ademan> it was a problem in the rules file
<StevenK> Can you paste it into a pastebin?
<ademan> configure.in:3: file `revision.m4' does not exist
<ademan> make: *** [configure]  Error 1
<StevenK> That's a missing Build-Depends
<ademan> i've got automake and autoconf in the build depends
<ademan> (i had to add them)
<StevenK> Did he have something silly like make in the Build-Depends?
<ademan> i dunno honestly, this is my first package, he probably knows a hell of a lot more than me
<ademan> here's the build-depends line though
<ademan> Build-Depends: debhelper, autotools-dev, automake1.9, autoconf, libc6-dev, libstdc++6-dev, libwxgtk2.6-dev, wx-common, libgtk2.0-dev, zip, pkg-config
<StevenK> libc6-dev can go
<StevenK> Everything else looks fine
<StevenK> Actually, so can libstdc++6-dev
<ademan> why do you say libc6-dev can go? something else in there depend on it?
<ademan> g++ depend on those?
<ademan> huh, here's another thing, when i ran pbuilder, it fetched g++ 3.4, why didn't it fetch the newest version?
<StevenK> Okay, so it is assumed when you build a package that 'build-essential' is installed.
<StevenK> build-essential depends on libc6-dev, gcc and a few other things.
<StevenK> So libc6-dev and libstdc++6-dev can both go.
<ademan> ah, alright, thanks, is it proper to add build-essential to Build-Depends?
<StevenK> No.
<ademan> alright
<StevenK> It's implied
<ademan> btw, i'm gonna paste debian/rules cause it's kinda funky
<StevenK> Into a pastebin, if you please.
<ademan> http://rafb.net/p/TTXeZT69.html but of course :-)
<ademan> note the configure target I added because pbuilder was complaining about configure not existing
<ademan> i may have been wrong to do that i dunno
<ademan> it wasn't building before either though
<StevenK> It's because config.status depends on a configure target
<ademan> right, which is why i added a configure target
<StevenK> Apart from that, the only bad thing I can see is copying /usr/share/misc/config.{sub,guess} in the clean target.
<ademan> if there's a configure file in the current directory does that satisfy the dependancy?  I didn't think it did but the upstream maintainer seemed to say it did
<StevenK> It ought to, yes
<ademan> oh, hrm, should i remove the configure target then?
<StevenK> Except that he's not providing anyway to generate said file.
<ademan> well ./configure exists, you're saying that having the configure target (which calls autoconf) is good because it generates a new ./configure?
<StevenK> No, I'm saying that if configure doesn't exist in a pristine upstream tarball, debian/rules has no commands to generate it.
<ademan> ah, well actually i got this from svn, and it already had the debian dir, along with spec files (for rpm?) and a ./configure script
<ademan> wait no i totally lied
<ademan> there's no configure script even now
<ademan> it must be dying DURING the configure target
<ademan> yep, ok i think i've got this, is it bad for me to move lines 31-35 into the configure target?
<ademan> "configure.in:25: error: possibly undefined macro: AC_PROG_LIBTOOL" so what does that mean i have to do?  Is that where i need to copy a certain file into the current dir?  where should that happen?
<StevenK> ademan: You also need to Build-Depend on libtool
<ademan> ah, that's not a build-essential?
<StevenK> Nope
<StevenK> None of the auto* tools are.
<ademan> there was another m4 error "configure.in:24: error: possibly undefined macro: AC_DISABLE_STATIC
<ademan> "
<ademan> crap sorry about the newline
<StevenK> Not sure about that one.
<ademan> i think i'll work on this more tomorow, it's about 3:00 am and i've got school tomorow... lol
<imbrandon> moins all
<ademan> "configure: error: cannot find install-sh or install.sh in "." "./.." "./../..""     WHEE!!! at least it's a different error this time
<StevenK> ademan: install-sh is shipped by automake
<ademan> copy from /usr/share/automake then?
<StevenK> automake1.9: usr/share/automake-1.9/install-sh
<ademan> :-)
<StevenK> You could ln -s /usr/share/automake-1.9/install-sh . in the configure target, and rm install-sh in the clean target
<StevenK> $(RM) install-sh, rather
<ademan> any way to do the copy in a automake version agnostic way?
<StevenK>  /usr/share/automake-*/install-sh ?
<StevenK> :-)
<ademan> i'm hardly a bash expert, woudl that work?
<ademan> by the way, i'm seeing a trend here, would it be $(LN) ?
<StevenK> Nope
<StevenK> $(RM) is defined by make
<StevenK> Also, keep in mind you're hardly being automake version agnostic with your Build-Depends.
<ademan> true, but if i were to change it in Build-Depends, and forget about it in rules, you know
<StevenK> Then your build fails, you slap your forehead and fix it, no?
<ademan> lol, i suppose i would
<ademan> geeze, this is so fun, i CAN'T WAIT till i have to chop this thing up into multiple packages lol
<ademan> either way, yet another question (i know, i'm sorry, i'm just, well a n00b) do i have to dpkg-buildpackage everytime i change debian/rules?
<StevenK> If you want to test your changes...
<ademan> ok that's what i was wondering, i don't know where pbuilder reads the debian/rules from, if it's from like the orig.tar.gz or something, or the debian dir, the dsc, i dunno
<StevenK> pbuilder doesn't
<StevenK> pbuilder unpacks a tarball, chroots into it and runs dpkg-buildpackage
<ademan> oh, heh
<ademan> anyways, now it says it can't find Makefile.in,      Makefile.am -> (some command) -> Makefile.in ?  (for some nuts reason i thought it was the other way)
<ademan> i can tell my absolute loathing for autotools is comming back to bite me in the ass here
<ademan> oh duh, i'm retarded
<ademan> Makefile.am -> automake -> Makefile.in
<ademan> should automake go in the configure: target?
<StevenK> Probably.
<ademan> i feel i'm really close to getting it
<ademan> i think i'm going to go to sleep for now though, i can at least get 4 hours of sleep in
<ademan> i really appreciate your help and patience
<ademan> thanks
<ademan> gnight
<did448> Hi, question: if a bug is in a debian/patches/xxx, what is better: modify the patch or create a new one?
<ademan> i'd think you should create a new patch, i remember hearing something about being able to apply only the patches needed etc
<ademan> God, i've said gnight like twice and i'm still not gone
<ademan> SO CLOSE! i'm getting an error about some configure.h.in in the source not existing
<StevenK> Modify the patch
<ademan> here's the culprit i would think: AC_CONFIG_HEADER([src/sdk/config.h] )     and src/sdk/config.h.in doesn't exist, shoudl i remove the line? (i'll know i need it if g++ bitches about needing config.h)
<StevenK> Why should src/sdk/config.h.in exist?
<StevenK> config.h should just be a normal header file
<ademan> well doesn't autoconf generate config.h FROM config.h.in?
<StevenK> I have no idea, to be honest. I've managed to avoid auto* :-)
<ademan> hehe, avoiding autotools is the exact reason why i'm packaging a c++ IDE :-)
<ademan> although it doesn't seem to bad now, but man, the redundancy in the code, so much of it just seems superfluous, or like it could just be housed in a config file, and just read by a single build program
<ademan> anyways, gnight, i'm going to sleep for real now...maybe....
<ScottK> Good morning everyone.
<palski> could someone sponsor the fix (for feisty) attached to Bug #55782
<Ubugtu> Malone bug 55782 in kxdocker "doesnt open in edgy" [Medium,In progress]  https://launchpad.net/bugs/55782
<siretart> mmmmh. pushing a branch to launchpad takes aaages :/
<siretart> hi folks, btw
<ScottK> Hi.
<jrib> Kamping_Kaiser: hi
<jrib> I mean, "hi"
<jrib> I'd like to see http://packages.debian.org/unstable/python/python-dialog included in feisty.  I want to make sure that the proper process is to file a sync request as described in the wiki.  Is there anything I can do to help out with the process once that bug is filed?
<palski> hmm, that package is not in ubuntu at all?
<ScottK> jrib: I'm new here, but one thing is that python-dialog is the binary package.  You'd want to request the source pacakge pythondialog I believe.
<ScottK> pacakge/package
<jrib> ScottK: I see, so I should grab the info from http://packages.qa.debian.org/p/pythondialog.html then.  Thanks
<ScottK> That's my understanding, but as I said, I'n not an expert by any means.
<sunshine> hi
<siretart> crimsun: FYI: I imported the xine-lib packaging branch to ~ubuntu-core-dev team branch. I also imported your latest upload there. Feel free to point anyone interested to branch from there for submitting patches
<AnAnt> how can I specify a certain file as a changelog file ?
<AnAnt> using dh_installchangelogs I mean
<JKnife> "http://rafb.net/p/LenFVs68.html =\ ld core dumps when I try to build AWOS" 
<JKnife> here gnomefreak? =P
<gnomefreak> see my comments in +1 but again i dont know what it is and im no expert :)
<JKnife> :) i was just reading em
<imbrandon> siretart, the newest bzr is alot faster about it ( but its still slow )
<JKnife> "*** glibc detected *** ld: free(): invalid pointer: 0x0817d724 ***
<JKnife> that is what i am guessing
<gnomefreak> me too
<gnomefreak> JKnife: maybe the new libc6 is causing it?
<JKnife> which is why i asked in +1 :)
<gnomefreak> what your building expects lower version maybe?
<gnomefreak> but im not good at pointer
<gnomefreak> s
<JKnife> well AWOSDev is building it on Dapper.. but ld shouldn't core dump
<JKnife> it should print a nice error instead of letting everything out^__^
<siretart> imbrandon: I'm using bzr 0.13
<jdong> to whomever kindly sponsored my gpac package but is not showing up in feisty-changes for me.... thank you greatly :)
<gnomefreak> thats why i asked you in here. this is where are the SMART people play
<siretart> imbrandon: it would really help a lot if launchpad would offer repositories, though
<gnomefreak> and me
<JKnife> haha
<jdong> siretart / imbrandon : bzr network performance will be slow without smart servers
<gnomefreak> but someone in here might know what is going on with it
<jdong> there is an additional latency of `find .bzr | wc -l`*ping_latency
<jdong> supposedly launchpad will get smartserver support "sooner than I'd think" is what I'm told :D
<JKnife> well anyways.. ask the smart people.. i need to get a shower and head to class
<gnomefreak> lol
<gnomefreak> im gonna have to go on my assumtion to begin with
<gnomefreak> can anyone read backtraces good? im not real good at them but i would like confirmation that libc6 is causing the coredump if you have a few minutes
<JKnife> i look at it this way.. if it was libc6 then i would 99% of the time gotten a gcc error and might have known where it was, this is a core dump in ld.. so i have no clue.. 
<geser> gnomefreak: I might look at it. got an url?
<imbrandon> siretart, yea i hear ya, i talked with elmo a bit about that at UDS , it seems to be comming but not here fast enough
<gnomefreak> geser: yeah
<gnomefreak> geser: http://rafb.net/p/LenFVs68.html
<gnomefreak> imbrandon: you still working on kooldock?
<imbrandon> gnomefreak, not atm
<imbrandon> but i can if you need a hand with something
<gnomefreak> imbrandon: the kmenu when you add it to the dock in the docks prefferences it doesnt work it adds it but never opens
* gnomefreak just using until kxdocker gets fixed 
<geser> gnomefreak: can you reproduce the core dump when you run ld with the same parameters (in the same directory)?
<gnomefreak> geser: its JKnife's baby
* gnomefreak was looking at it for him not sure exactly what he is doing
<geser> JKnife: can you reproduce the core dump when you run ld with the same parameters (in the same directory)?
<ScottK> If any MOTU is available to do a revu, I'd appreciate you taking a look at http://revu.tauware.de/details.py?upid=4179 - It's looking for a 2nd advocate...
<JKnife> geser: "ld: cannot find bootup.o"
<JKnife> ohh n/m
* JKnife did a clean
<JKnife> yes it reproduceable
<JKnife> "svn co https://awos.svn.sourceforge.net/svnroot/awos/trunk awos" <- its svn repo if you wanna look at it
<geser> hmm, there is no dbgsym package  for binutils which makes it harder to get a good backtrace
<JKnife> want me to try libc6-dbg?
<bddebian> Heya gang
<geser> JKnife: the debug symbols for libc6 won't show you the details for ld
<JKnife> ohh well..
<geser> it would help if one know which function from ld are called
<JKnife> =\ 
<JKnife> well this has been fun but time for class
<h4writer> hoi, I've got a question about https://launchpad.net/ubuntu/+bug/81273
<Ubugtu> Malone bug 81273 in Ubuntu "list isn't rendered good" [Undecided,Needs info]  
<h4writer> I need to give a screen shot
<Tonio_> may I ping a motu concerning http://revu.tauware.de/details.py?upid=3689 please ?
<h4writer> but when I push PrtScr, the list is back rendered good !
<Tonio_> :)
<h4writer> so I can't show the problem :-(
<bddebian> Tonio_: Aren't you an MOTU? :-)
<jrib> Hi, I'm looking for an ubuntu developer to approve https://launchpad.net/ubuntu/+bug/81637 .  Can anyone help? :)
<Ubugtu> Malone bug 81637 in Ubuntu "[Sync Request]  pythondialog (2.7-1) from debian unstable/main to universe" [Undecided,Needs info]  
<Tonio_> bddebian: yes but I won't revu myself :)
<Tonio_> bddebian: you did the previous comment, I just fixed all of the required things
<bddebian> Tonio_: I'll check it out in a sec.
<jdong> h4writer: find a digital camera?
<Tonio_> bddebian:  thanks
<jdong> (wow, that's probably the worst advice I've given all week)
<crimsun> siretart: ok, thanks. I was going to submit a patch to Debian BTS against xine-lib in experimental. Is that still necessary?
<h4writer> jdong: I have no camera at hand, but do you know a screen capteringer (to make a video of the problem?
<jdong> h4writer: istanbul
<h4writer> jdong: thanks will try it immidiatly
<bddebian> Tonio_: My edgy machine just puked building jabbin so just give me a sec
<jrib> bddebian: thanks for the approval of pythondialog.  In the future, is that the correct way to go about requesting a package from debian or should I have emailed the MOTU list looking for a sponsor first?
<Tonio_> bddebian: sure :)
<bddebian> jrib: For a package straight from Debian, that is fine.  Though if you are not an MOTU yet, you should not subscribe Ubuntu Archive but Ubuntu Universe Sponsors
<jrib> bddebian: ah ok
<jrib> rrittenhouse: ok, that one does not have dapper multiverse, it only has dapper-backports multiverse
<jrib> erm ignore that, sorry
<siretart> crimsun: not really. it seems I'm the only one who actually cares about xine-lib in debian
<bddebian> Heh, hi siretart
<siretart> crimsun: currently, xine-lib 1.1.3 is in debian/NEW. 
<siretart> bddebian: !! :)
<bddebian> Shit I don't think my machine is going to come back?? :-(
<Adri2000> bddebian: shouldn't bug #81673 be for https://wiki.ubuntu.com/MOTU/Packages/Candidates ?
<Ubugtu> Malone bug 81673 in Ubuntu "No KPlayer package in Ubuntu" [Wishlist,Unconfirmed]  https://launchpad.net/bugs/81673
<bddebian> Adri2000: Probably but what's your point? :)
<Adri2000> because you marked it as wishlist, why not reject and forward the report to the wiki page?
<siretart> crimsun: thanks for the pulseaudio patch. I already pushed it to the debian branch here: http://bazaar.launchpad.net/~siretart/xine-lib/xine-lib.debian.1.1.3/
<Adri2000> s/forward the report/point the reporter/
<siretart> crimsun: I already have xine-lib 1.1.4 prepared. there are lots of bug fixes there, but the branch is still somewhat in flux, and our ffmpeg copy is too old
<siretart> crimsun: if you have the impression feisty should ship with it, just leave me a note
<siretart> any kubuntu folks having an opinion on this?
<giskard> who is working on soma?
<bddebian> It's on REVU
<jdong> so what are the chances of us being able to get a newer ffmpeg?
<bddebian> giskard: rexbron I think
<jdong> it's certainly not the easiest thing to update :D
<rexbron> giskard: U am
<rexbron> Iam
<rexbron> giskard: I am
<rexbron> giskard: is there a problem?
* jdong has a mini chroot running a SVN ffmpeg from last week... but has no idea how that change would impact ffmpeg's dependents
<\sh> jdong: certainly some packages will FTBFS if there are API changes ,-)
<giskard> rexbron, no, i will be happy  to sponsor it if you are not a motu :).
<rexbron> yay
<rexbron> it is still in development
<bddebian> giskard: REVU it man :-)
<jdong> \sh: yeah, certainly, but in my experience ffmpeg's API changes aren't too bad to work with
<rexbron> giskard: but any comments would be very much apprciated
<jdong> \sh: it's just annoying when they keep changing names here and there... :D
<bddebian> bbiab
<\sh> jdong: ;) 
<jdong> \sh: I've been trying to bring whatever media stuff I could up to date... but ffmpeg is a monster I'm scared to touch :)
<giskard> rexbron, i will do it
<giskard> rexbron, do you think to package also somaplayer?
<Toadstool> good morning everybody
<giskard> hi :)
<rexbron> giskard: somaplayer is already packaged and in the repos
<giskard> uh yes, right (my package, stupid me).
<rexbron> giskard: check out www.wiki.ubuntu.com/UbuntuStudio/ToPackage to see all the stuff we are working on
<giskard> i meant do you want to be the real maintainer?
<rexbron> giskard: of somaplayer?
<giskard> yes
<rexbron> I can certainly deal with new upstream releases, and since you have all ready done most of the work, I think so. But I do not want to make any commitments until after uS is released
<jdong> does anyone have any emotional attachment to gpac on ia64?
* jdong ready to mark bug 79356 Released but ia64 FTBFS'ed, installing a package failed in buildd
<Ubugtu> Malone bug 79356 in gpac "request version bump to 0.4.2~rc2" [Undecided,Fix committed]  https://launchpad.net/bugs/79356
<jdong>   libsmjs-dev: Depends: libmozjs-dev but it is not going to be installed
<Adri2000> jdong: eheh, xulrunner
<jdong> lovely :)
<Adri2000> it's the same for mplayerplug-in
<Adri2000> xulrunner FTBFSed on ia64
<jdong> ah, ok
<\sh> Adri2000: behappy...xiulrunner ftbfsed on amd64 before ;)
<Laser_away> ademan: I don't use a gpg-agent, that doesn't mean I don't use gpg ;-)
<\sh> because of fcking pointer casting from int to pointer...and that failes in x86_64
<LaserJock> and what the heck happened to our wiki?!?
<Adri2000> ahh \sh :p yeah thanks for this fix, but do you know how to fix it on ia64?
<\sh> Adri2000: well, no...I don't own an ia64 :(
<Adri2000> hmm, who owns one?
<\sh> lemme check what failes
<\sh> or no...I'm trying to get wine 0.9.30 into feisty...so monday I'll check...
<Adri2000> ok
<\sh> wine 0.9.30 is uploaded :)
<\sh> oops..this time I'm fast then scott *gg*
<jdong> argh \sh stop filling my todo list :D
<\sh> jdong: sorry ;)
<\sh> jdong: I'll prepare a backport on edgy
<jdong> :)
<\sh> but .. hmm...I need to upgrade my laptop
<\sh> ok..time to go home :)
<\sh> cu later 
<ademan> lol LaserJockthat comment was about 8 hours late haha
<ademan> anywho, school time, i'm bringing my comp with though, i'll see what i can do there
<somerville32> Can someone sponsor bug 81593 for me? thanks
<Ubugtu> Malone bug 81593 in doodle "doodle: merge new debian version" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81593
<geser> somerville32: sponsored
<somerville32> geser: Thanks a bunch! :)
<ScottK> geser: Do you have time to review a new package?
<geser> later perhaps
<ScottK> OK.  It's http://revu.tauware.de/details.py?upid=4179 If you can.  Thanks.
<bddebian> Jesus Christ, an hour and a half to install Service Pack 1 for Visual Studio 2005 :'-(
<nixternal_> hahahahahaha
<nixternal_> why may I ask?
<jdong> bddebian: that sounds about right
<jdong> bddebian: I once had to run VS.NET for school on a 133MHz P1
<nixternal_> I know we use it at school, but I have informed the instructors of my classes that it goes against my philosophy to use MS products and that I will be doing the class with Linux. so far none of them have gone against me, or given me a lower grade because of it
<jdong> bddebian: took overnight to install
<jdong> for me, it was a class project where the teacher implemented a good protion of the API in VS.NET managed and nonstandard C++
<nixternal_> as soon as one of my instructors doesn't agree, then I will let them know I belong to an OpenReligion and can't use proprietary software otherwise I will goto Microsoft when I die
<bddebian> nixternal_: Work
<nixternal_> ahhh
<somerville32> lol
<nixternal_> you know, please don't say that you work for AOL. you can ask imbrandon, we had a LinuxMonkey who worked for AOL. Granted he has since left us, but still, that was like saying I drive a Ford and work for Chevy
* nixternal_ stops from the next line he was going to say...
<nixternal> silly nicknames
<somerville32> You're colour changed
<somerville32> *Your
<ScottK> somerville32: It sort of works either way...
<somerville32> You are coloured changed vs. Your colour changed? :P
<nixternal> haha
<\sh> re
<\sh> umts with 1.8MBit/s ;) very nice :)
<Tonio_> bddebian: how about jabbin? is it ready for upload ?
<bddebian> Sorry just got my machine back up.  Test building now :-(
<Tonio_> hehe okay :)
<Tonio_> bddebian: I'll have to in 30 minutes for the all we, take your time then :)
<Tonio_> or upload it yourself ;)
<lritter> hi there
<lritter> i'm trying to do my first package, and i'm as far as having my debs created, but there are no files in it
<lritter> it seems to only include directories
<lritter> libzzub.dirs: http://rafb.net/p/2SGsD672.html
<lritter> libzzub.files: http://rafb.net/p/FwSxkk23.html
<\sh> re
<afflux> am I allowed to quote the wikipedia in the description of a package?
<somerville32> afflux, Sure.
<afflux> good. I'm too lazy to write myself, and the original developer seems to be lazy too.
<jdong> is there anything inherently unwise about using ext2?
<jdong> I know no ACL support...
<coNP> jdong: no journaling
<jdong> and I can deal with lengthy fscks on bad shutdowns (a rarity for me)
<jdong> coNP: yeah, but sometimes IMO the trade-off for journaling is too dear
* jdong goes to try booting his system as ext2 :D
<coNP> jdong: sure, but that is a bad point, not an inherently badness
<ademan> when i do "pbuilder build ../*.dsc" i get this error "configure.in:10: required file `src/sdk/config.h.in' not found"   in configure.in there's a line "AC_CONFIG_HEADER([src/sdk/config.h] )" , should i rcomment out that line to see if i can get things to build?
<ademan> anyone?
<Adri2000> for?
<coNP> ademan: which package?
<ademan> code::blocks
<Adri2000> ah sorry ademan, didn't read above :
<ademan> :-)
<ademan> i feel like i'm soooo close to getting this to work
<coNP> ademan: sorry, is this a new package?
<bddebian> ademan: Is that file in the package itself?
<ademan> coNP: yep, and the majority of the debian dir is from the upstream maintainer
<ademan> AND he only builds with fakeroot, not pbuilder
<coNP> ademan: that should not mean any problems, can you build via fakeroot?
<ademan> dunno, but it kinda does, cause there are lots of dependancy problems
<ademan> (via pbuilder)
<ademan> the Build-Depends was insufficient
<ademan> but i've fixed it to some degreee
<ademan> btw how in the heck do i comment stuff out in a M4 file? #?
<bddebian> Why would you want to do that?
<ademan> cause of my error described at 11:36
<ScottK> If I were to hazard a guess, you are missing a -dev library dependency somewhere.  Finding that's more likely to be fruitful than commenting out lines.
<ademan> but its a missing file in the src directory, rather than a dependancy problem, isn't it?
<Adri2000> LaserJock: really, it would be great to have a link to the debian changelog in http://tiber.tauware.de/~laserjock/motutodo/universe.html, please :)
<bddebian> ademan: Aye if you find ./ -name config.h.in it isn't there?
<bddebian> Or you could look in src/sdk directly I suppose :)
<gouki> Hi, I'm creating a package but I'm not able to find the required library on official repositories. Can anyone help me out?
<bddebian> gouki: What library?
<jdong> are universe syncs automagic or need to be requested?
<jdong> (looking at deluge-torrent atm)
<gouki> libssh - I just want to make sure it's not there
<bddebian> jdong: Early on they are automagic but have been manual for a while now
<jdong> oh
<jdong> do I need to be all formal requesting syncs
<jdong> or will a message here suffice? :D
<gouki> bddebian: I just found it on Feisty...
<bddebian> jdong: All formal.  We can't do syncs, only archive admins can
<jdong> got it
<jdong> bddebian: what is the format of a sync request?
<bddebian> jdong: Just a bug on LP.  State the package name, version, which archive (i.e. unstable, etc) and component (ie main, contrib,etc)
<jdong> bddebian: who should be subscribed? -archive?
<Adri2000> changelog between current version in ubuntu and last version in unstable (or whatever)
<Adri2000> jdong: u-u-s if you are not a MOTU
<bddebian> jdong: If you aren't an MOTU, you should probably subscribe UUS first and we will subscribe UA
<ademan_> did i miss anything?
<jdong> bddebian: ok
<ademan_> bbdebian: yeah there's no src/sdk/configure.in
<jdong> already there.... bug 79627
<Ubugtu> Malone bug 79627 in deluge-torrent "Update to 0.4.1" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79627
<jdong> uus is not subscribed though
<bddebian> ademan_: Are there any configure files in src/sdk/ ?
<ademan_> hrm lemme check
<jdong> bddebian:  ^^ should I subscribe uus or will you guys be able to handle it from this point?
<ademan_> bddebian: nothing *.in, there's a couple headers with configure in the name, but they don't have any of the text replacement looking stuff that *.in files generally have
<ademan_> should  i just try commenting out the offending line in configure.in?
<ademan_> (is "dnl" a comment? it seemed to be)
<ademan_> well it just about built
<ademan_> it was REALLY close
<ademan_> it seems g++ blew up, i'll make a pastebin
<ademan_> and it wasn't blowing up for a lack of configure.h.in
<LaserJock> anybody get Ubuntu ISO testing bug email today?
<ademan_> http://rafb.net/p/ejN6pR53.html  anyone who takes a look at this, it would be appreciated, this was while running pbuilder, it seems to have made it to the build target
<ademan_> might it have to do with the lack of svn? should libsvn be in Build-Depends?  (looking at line 7)
<Adri2000> LaserJock: me
<coNP> ademan_: if svn is not found, svn should be installed, I guess
<coNP> ademan_: might be some clib bug?
<ademan_> LaserJock: the kiso one?
<LaserJock> I mean bug #81630 email
<Ubugtu> Malone bug 81630 in ubuntu-iso-tests "20070126: ubuntu i386 desktop" [Undecided,Rejected]  https://launchpad.net/bugs/81630
<hub> ademan_: yeah looks like it can NOT find svn
<hub> ademan_: build-depend on subversion
<ademan_> not libsvn0-dev?
<ademan_> i guess probably not
<hub> ademan_: it is looking for the command line
<ademan_> thanks
<ademan_> alright, thanks
<coNP> ademan_: I guess the package is called subversion
<bddebian> Sorry guys, gotta run
<ademan_> later
<ademan_> God, i'm in my data-structures class learning about arrays....
<ademan_> the makefiles i have to write are longer and more complicated than the programs themselves...
<bddebian> ademan_: If I'm on later and you still have problems, poke me
<ademan_> alright i will, thanks for the help
<ademan_> thank you all really, bein pretty patient with me asking all these questions that would be better put in #ubuntu-motu-school
<ademan_> ...which is all but dead...
<ademan_> dear lord it's actually building!'
<jdong> ack
* jdong turns off highlighting on 'dear lord'
<ademan_> lol sorry, didn't mean to startle you :-)(
<ademan_> man i don't think i've ever compiled something that took > 5 minutes
<ademan_> course, i might have back on windows, but in my experience the msvc compiler was way faster than mingw
<LaserJock> ademan_: what?
<LaserJock> you need to try Gentoo
<LaserJock> I think pbuilder for gcl took over 1hr for me
<ademan_> i dunno, when i was on windows the msvc compiler beat the pants off of mingw every time on compiling speed (dunno about the speed of the resulting executable)
<ademan_> man, nothing system76 offers has a built in tv tuner
<ademan_> hey what does debian/dirs do?
<LaserJock> creates directories that weren't created by the source itself
<LaserJock> so if you need to add a file from the packaging (man page or .desktop say) you need to make sure that the directories exist
<ademan_> so usr/bin -> debian/usr/bin ?
<coNP> ademan_: I guess debian/dirs/usr/bin
<LaserJock> no
<ademan_> dirs is a file though not a dir
<LaserJock> it's debian/tmp/usr/bin/ or debian/<packagname>/usr/bin/
<coNP> I see
<LaserJock> that's why it's just usr/bin
<ademan_> ah, it's tmp then, i saw a bunch of tmp crap during the build
<ademan_> which is still happening by the way...
<LaserJock> ademan_: the whole .deb is built there :-)
<ademan_> man, i swear i'm just seeing the same lines over and over again
<ademan_> and the CFLAGS are rediculously long
<JKnife> back
<ademan_> longest.build.ever.
<LaserJock> and wait, as it's done building there will be some silly dh_install error and you'll get to do it all over again ;-)
<ademan_> i'm in class right now, i don't wanna scream lol
<ademan_> so far so good though, g++ is done for now, it's doing something else now
<ademan__> no errors
<ademan__> but where's my deb?
* ademan__ commits sepukku
<LaserJock> ademan: dude, you gotta calm down
<LaserJock> :-)
<LaserJock> ademan: you built it with pbuilder, right?
<ademan> yep
<LaserJock> then it's probably in /var/cache/pbuilder/result/
<LaserJock> unless you're using my script and then it's in ~/pbuilder/
<ademan> its there!
* ademan un-sepukkus
<LaserJock> good, no sepukku
<LaserJock> ;-)
<ademan> so, now the moment of truth, trying to install, and watching the package break something important :-)
<LaserJock> can't have our contributors doing that
<LaserJock> at least not too much
<LaserJock> ademan: run dpkg -c on the .deb
<ademan> alright thanks
<LaserJock> ademan: also install lintian and linda and run lintian -i and linda -i on the .deb
<ademan> is there any way to do that from the rules file? seems like a good idea
<LaserJock> you can also run lintian and linda on the source package too (by running it on the .dsc)
<LaserJock> no, that's *after* you build
<ademan> too bad
<LaserJock> well, it's not hard to do :-)
<ademan> dpkg -c   just spat out a bunch of path names
<LaserJock> ademan: dpkg -c gives you the contents of the .deb as they are going to be installed on the user's computer
<ademan> ah, so should i be worried all of the paths are ./usr  ./etc    and so on?
<LaserJock> ademan: you should check to make sure everything you *think* should be there *is* there and in the right place
<LaserJock> nope
<ademan> alright, well i guess heregoes, should i lintian them first?
<LaserJock> yeah, go for it
<LaserJock> dpkg -c and lintian/linda could save sooo much time on REVU
<ademan> yeah i'm not going to upload like this though, the package REALLY needs to be split up into multiple packages, for instance it includes a SDK among other things
<ademan> also, it's installing a bunch of shared objects into /usr/share, when it should be usr/lib shouldnt it?
<ademan> since share is for stuff like images, GUI xml files, etc, non-binary stuff right?
<ademan> crap, i gotta go, i'll be on again in about 4 hours
<ademan> thanks for all the help
<Adri2000> LaserJock: so, what do you think about the debian changelog link? it would be better for when there are many changelog entries since the last ubuntu version
<LaserJock> sure
<Adri2000> :)
<Q-FUNK> dammit.
<Q-FUNK> yet another $curse user that assinged his generic upgrade problems to 'upgrade'system'.  i thought i had reassigned it, but it only ended up adding another package to the bug.
<Q-FUNK> how do I fix this?
<Adri2000> LaserJock: actually, I didn't see the link "changelog" on packages.qa.d.o and I was clicking on each link in "latest news" :p so it still would be better to have the link directly but it's up to you :)
<Adri2000> LaserJock: where can I download the source of multidistrotools?
<geser> Adri2000: https://wiki.ubuntu.com/MultiDistroTools
<geser> but I don't know if this is still uptodate
<Adri2000> geser: it says "bzr branch http://ox.blop.info/bazaar/multidistrotools/" but 404
<geser> then it's outdated
<Adri2000> ping lucas, where can I download the source of multidistrotools?
<LaserJock> Adri2000: I have a bzr repo of it (with my patches)
<Adri2000> LaserJock: please url :)
* Adri2000 will have to learn bzr
<LaserJock> http://tiber.tauware.de/~laserjock/multidistrotools/
<Adri2000> thanks
<Simon80> so, about my upload
<Simon80> is there something else I have to do after getting it reviewed?
<Simon80> ...doing my homework now
<Simon80> (researching it)
<Simon80> ok, I couldn't find anything - in summary, I packaged something simple and it's been advocated by one person - what has to happen before it gets into Feisty?
<geser> Simon80: you need a second advocate
<Simon80> ok, change of subject :)
<Simon80> so, anyone want to review my shiny little package? it even has a manpage!
<coNP> Simon80: what did you do? (I am not a MOTU, just interested)
<Simon80> ah, it's logitech_applet, lets the user tweak the DPI and cruise control on certain Logitech mice
<Simon80> I think I should add Gentoo's patches though, for MX300/518
<Simon80> or I'll just package lomoco
<Simon80> hrm
<coNP> Simon80: thanks for the info
<Simon80> it's pretty high time for at least one of these packages to get in
<Simon80> and no problem :)
<TheMuso> Which Ubuntu supported architectures are big endian? I know PPC is.
<Simon80> I think that's it, unless niagara is big endian
<Simon80> and if your app's not a server app, you don't have to worry about that arch
<TheMuso> Well the fact of the matter, is that all packages are built for sparc, so I want to make sure things are done right.
<TheMuso> Regardless of whether its only a server platform or not.
<TheMuso> The package I am working on could indeed be used on a server.
#ubuntu-motu 2007-01-27
<bddebian> crimsun: You aboot?
<LaserJock> more content, more content *whip*
<bddebian> ??
<LaserJock> contentless ping
<bddebian> Yeah, so? :-)
<geser> bddebian: about bug #76544: are you sure the Ubuntu changes aren't needed anymore?
<Ubugtu> Malone bug 76544 in fnfx "[Sync Request]  fnfx 0.3-12" [Undecided,Needs info]  https://launchpad.net/bugs/76544
<bddebian> crimsun: <content> What's up with beep-media-player? </content>
<bddebian> geser: No, that should probably be rejected but I think a lot of the changes could/should go away
<bddebian> Gah, I hate these where we have strayed from Debian and now it's like what makes sense and what doesn't...
<crimsun> bddebian: yes?
<bddebian> Heya ScottK
<ScottK> heya
<bddebian> crimsun: I was just curious what was up with beep-media-player
<crimsun> bddebian: if you'd like to merge it, feel free (I'm short on time). Note the changes to the image files (default skin).
<bddebian> yeah, I saw that :)
<bddebian> Hmm, should we sync/merge a package with 3 RC bugs in Debian? :)
<geser> persia already did a merge. it only needs review and sponsoring
<bddebian> geser: Well what are you waiting for? :-)
<crimsun> well, persia has noted it blocking on maintainer mangling, though I think that's a superfluous blocker.
<Toadstool> bddebian: fix the bugs :)
<crimsun> (bug 79065)
<Ubugtu> Malone bug 79065 in beep-media-player "merge beep-media-player 0.9.7.1+cvs20050803-2 from debian unstable" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79065
<Toadstool> heya everybody
<bddebian> Heya Toadstool
<TheMuso> Whats the best way of putting a homepage URL in a package description?
<TheMuso> As in, at the end, with the homepage keyword?
<Toadstool> " .\n  Homepage: <URL>"?
<geser> "  Homepage: <URL>" (note the two spaces at the begin)
<TheMuso> ok thanks guys.
<TheMuso> I thought the long description only needed one space at the end.
<TheMuso> beginning sorry
<geser> TheMuso: the second space has a special meaning: no word-wrap
<TheMuso> ah ok.
<geser> crimsun: are you going to upload the bmp merge?
<crimsun> geser: no, I'm not near my keys.
<geser> ok, I will do it if you don't mind
<crimsun> that's fine.
* bddebian goes back to being useless
<geser> bddebian: you could merge fnfx :)
<bddebian> No thanks
<bddebian> I've looked at it twice and somerville32 has tried a couple I think
<StevenK> Heh, I can try, if you want.
<bddebian> Go for it
<coNP> Can someone help me how to fix packaging bugs?
<bddebian> We can try
<coNP> Upload an usual debdiff?
* Toadstool doesn't fix bugs, he creates them
<bddebian> heh
* coNP was sent here from #ubuntu-bugs
<coNP> okay, not sent
<Toadstool> coNP: prepare a debdiff fixing the bug, attach it to the bug report and subscribe ubuntu-universe-sponsor (or whatever the name is) or poke a MOTU here :)
<coNP> Toadstool: as is the usual process, isn't it?
<Tonio_> bddebian ping ?
<Toadstool> coNP: yep
<Tonio_> bddebian should I really add any copyright of any file of a project in debian/copyright ?
<Tonio_> bddebian that's really ridiculous, unreadable, and unmaintainable
<azeem> Tonio_: how many of them are different?
<bddebian> Tonio_: Well I've had to but I'm now where near an expert on the licensing stuff.  I tend to agree with you. :-)
<Tonio_> azeem dozens........
<azeem> yummy
<Tonio_> bddebian and the typo IS FIXED for at least two uploads :)
<Tonio_> bddebian s/from/of not the oposite :)
<bddebian> Yeah, I noticed
<Tonio_> bddebian I which that guy to revu the kdebase package and have fun in that case
<Tonio_> about 3000 different copyrights there
<Tonio_> I agree for the lgpl to be mentionned
<Tonio_> but that's all
<Tonio_> I'm not going to mention all copyrights, that's a pure bullshit !
<bddebian> Works for me :)
<Tonio_> or !!! or I'm doing this :
<Tonio_> grep -d recurse '(C)' ./ >> debian/copyright
<Tonio_> and have fun to revu
<Tonio_> I was about to post a flamming reply on revu, but I prefer to flame here, it'll have disapear on tomorrow :)
<Tonio_> revu stays online, that's dangerous :)
<bddebian> heh
<Toadstool> Tonio_: this channel is logged too :)
<bddebian> Hmm, what about all those libcommons-* merges...
<Tonio_> Toadstool: true, but well I had to empty my brain on that point :)
<Toadstool> heh
<Tonio_> some expectations on revu are sometimes ridiculous...
<Tonio_> how to maintain a package if every copyright on any file has to be mentionned, including headers ? that impossible
<Toadstool> you're talking about jabbin?
<Tonio_> yup
<Tonio_> I agree concerning the lplg, I missed it and will mention it, but for the copyrights......
<Tonio_> imagin the same requirement for kdelibs.....
<Toadstool> well, technically you're supposed to list them all although I agree it can be a real pita
<Tonio_> Toadstool that's theory, imagin the same for linux sources for example...
<Toadstool> I know :)
<geser> Tonio_: are you talking about my comment on jabbin?
<Tonio_> geser, probably :)
<Tonio_> I agree for everything but the copirights, that drives me nuts, really !
<Tonio_> ;)
<Tonio_> that's not against you, just that's simply impossible to maintain
<Toadstool> Tonio_: imho, list the main ones, upload and wait for any comments from an archive admin ;)
<Tonio_> Toadstoolthat's what I did
<Toadstool> oh
<Toadstool> and it got rejected?
<Tonio_> when 99% of the files of a tree are the ame and just one little file has a different copyright, I don't mention it
<geser> I don't meant you have to list each appearance of Copyright
<Toadstool> well, I guess so, otherwise you wouldn't be pissed off ...
<Tonio_> Toadstool yes, hehe :)
* Toadstool tired
<Tonio_> geser well you even added isolated header files on a full tree
<Tonio_> for the licence, I'm okay I'll add the lgpl
<Tonio_> geser the redistribution of iLBC is to be checked too, you are right on that point
<Tonio_> geser just the copyright thing pissed me off especially since I've been asked in the past to stop proviing them all :)
<Tonio_> on revu too :)
<geser> the other I mentioned have a license that looks like it's free enough (I haven't checked thoroughly) but it's not the GPL
<Tonio_> hum, if that's licence, I'm with you
<Tonio_> I must say the all tarball is released under the gpl so I didn't checked all files in it, I should have done it though
<Tonio_> geser okay I'll revu the all sources concerning the licence, since I perfectly agree with you on that point
<Tonio_> geser maybe I just missunderstood you on that point, sorry for this
<Tonio_> but the copyrights expectations has already been a long debate so once again drive me nuts :)
<Tonio_> geser I'll ping you for revu once I made ot clear concerning the licence
<geser> see for example http://revu.tauware.de/revu1-incoming/jabbin-0701261035/jabbin-2.0~beta/src/tools/crash/crash_sigsegv.h
<bddebian> ademan: Any luck yet?
<ademan> actually i haven't tried anything
<Tonio_> yeah that's not explicitly gpl, but looks like compatible
<ademan> but the build was successful
<ademan> only problem is the deb wants to install all of the shared objects into /usr/share/codeblocks/blah blah blah
<Tonio_> geser I think I missunderstood your point, you were talking about the licence more than the coyrights
<ademan> and iirc shared objects shouldn't be in /usr/share
<Tonio_> geser, and you were right, I admit
<geser> Tonio_: http://revu.tauware.de/revu1-incoming/jabbin-0701261035/jabbin-2.0~beta/voip/stun.h has a license at the end of the file
<ademan> is that right?  (i picked up a little pdf on the unix file structure, and iirc only platform independant stuff should go in /usr/share)
<bddebian> ademan: Is there a lib package?
<ademan> naw, it's all one package, it DEFINITELY needs to get broken up into multiple packages though
<ademan> like, there's an sdk included
<ademan> just a bunch of stuff that should be in separate packages
<bddebian> SO break it up :-)
<ademan> but most of the libs are essential to the base program, still put them in a codeblocks-lib package?
<ademan> i will, but as you could tell by me floundering around, i'm not so great at packaging just yet :-)
<Tonio_> geser, that's clear now, and I must say you are right, I'll have to check those files for their licence
<bddebian> ademan: Welcome to the club :-)
<ademan> hehe
<bddebian> I suppose ideally you would have codeblocks, libcodeblocks, libcodeblocks-dev, and codeblocks-sdk or something but since I haven't seen the package I'm just talking out of my arse
<ademan> bddebian: even if the libcodeblocks is essential to the codeblocks package?
<Tonio_> geser, thanks for beeing patient :) I'm tired, I wouldn't have reacted like this 3 or 4 hours ago
<Tonio_> bddebian, he was right hehe :)
<bddebian> Sure.  You can have the codeblocks binary depend on the libcodeblocks binary
<ademan> yeah, i just didn't know if that was preffered or what
<Tonio_> okay I'll check the full licence.... why  ALL those voip software like this ? same licence issue in wengophone.....
<ademan> now i just gotta figure out HOW to divide it up into multiple packages :-)
<ademan> the maintainer wrote the debian dir to generate these packages: codeblocks codeblocks-contrib libcodeblocks libcodeblocks-devel libcodeblocks-dbg but of course he hasn't committed the new debian dir... so i don't get them :-(   plus isn't libcodeblocks-dev preffered to devel?
<coNP> Toadstool: can you have a look at bug 81757 if it is okay?
<Ubugtu> Malone bug 81757 in xchat-systray "Duplicate entry in tasklist" [Undecided,Confirmed]  https://launchpad.net/bugs/81757
<ademan> course, i may just ask him for the new debian dir, i dunno
<ademan> i'd have to fix things up AGAIN, since what he claims builds, doesnt...
<ademan> i think the problem is he builds with ./configure && make FIRST, so things that AREN't taken care of in debian/rules are actually present on his system
<Toadstool> coNP: sure
<geser> coNP: you should probably use conflict instead of replaces
<coNP> geser: why? It does not actually conflict.
<geser> coNP: http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
<coNP> geser: ty
<geser> Replaces allows dpkg to move files owned by one package to another
<geser> you are more interested in xchat-systray getting deinstalled
<geser> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts
<Toadstool> coNP: what geser said (sorry, I am at work, kinda busy :)
<coNP> sorry, my DSL is broken :(
<coNP> geser: did you get my last message? 
<geser> last I've seen from you: <coNP> geser: ty
<coNP> geser: so I think replaced is better
<coNP> because the documentation says "Packages can declare in their control file that they should overwrite files in certain other packages, or completely replace other packages."
<coNP> Now xchat completly replaces xchat-systray.
<coNP> But I might be bad
<geser> that would be 7.5.2 Replacing whole packages, forcing their removal
<coNP> Actually then both replaces and conflicts should be added
<geser> so you would probably need replaces and conflicts
<coNP> And I think only to xchat, but not to xchat-common
<geser> yes
<coNP> but that was okay, I checked
<coNP> now I should add this new debdiff to the bug?
<geser> yes
<Toadstool> ok sick of working, I call it a day, let's go get drunk in LA \o/
<Toadstool> have a good weekend everybody
<coNP> by Toadstool 
<coNP> +e
<bddebian> Later Toadstool
<coNP> geser: can you have a look at it again? I think it is quite easy to check, if you want to. However, it is not (very) important at all.
<geser> looks ok. have you verified that it works as intended?
<ScottK> geser: No problem if you don't, but I was curious if you thought you might have time yet for the new package review I mentioned this afternoon?
<geser> ScottK: ah, forgot. I will look at it in the morning (it's past 2 am here)
<ScottK> No problem.  Thanks.
<coNP> geser: I think so, now it does not allow me to install xchat-systray again, and try again.
<coNP> I wanted to test it again
<coNP> maybe someone running feisty should do that
<geser> I could test it in the morning and upload it afterwards (if nobody is faster)
<bddebian> geser: No one is faster than you :-)
<coNP> geser: thanks
<coNP> good night everyone (in timezones, where it is night :))
<bddebian> Gnight coNP
* welshbyte wonders what to do next
<bddebian> welshbyte: Fix all the bugs :-)
<welshbyte> ok, i'll start from bug #1 and work my way up ;)
<Ubugtu> Malone bug 1 in ichthux "Microsoft has a majority market share" [Critical,Confirmed]  https://launchpad.net/bugs/1
<jdong> aah ichthux has taken over bug 1!!!!!!
<Liberax> hi any developer here?
<bddebian> Nope, no developers here. 
<Liberax> anybody with amd 64 and pptp could try this fix: https://bugs.launchpad.net/ubuntu/+source/network-manager-pptp/+bug/67881 ?
<Ubugtu> Malone bug 67881 in network-manager-pptp "Crash while trying to connect to PPTP server" [Undecided,In progress]  
<LaserJock> jdong: it's always somebody. I wish we could kill that bug
<jdong> lol
<Liberax> LaserJock: what bug?
<LaserJock> I should ask raphink about that
<LaserJock> Liberax: bug #1 of course ;-)
<Ubugtu> Malone bug 1 in ichthux "Microsoft has a majority market share" [Critical,Confirmed]  https://launchpad.net/bugs/1
<Liberax> :)
<LaserJock> I'm just annoyed at getting bugmail from it
<ScottK> Speaking of fixing bug and that other operating system...  I recently fix a python-dns bug, Bug #80360, here and then decided to report it upstream.  There I found a few open bugs that have been there for more than two years.  At least one of them is Windows only.  I am considering doing a patch here to resolve the upstream bugs too.  Would it be considered poor form to fix the Windows unique stuff in the same package?
<Ubugtu> Malone bug 80360 in python-dns "Crash - Fails to trap socket.error when network is not available" [Undecided,Fix released]  https://launchpad.net/bugs/80360
<crimsun> ScottK: no.
<LaserJock> ScottK: uneccesarly maybe, but not bad form surely ;-)
<bddebian> Shirley?  I thought his name was Scott? :-)
<LaserJock> darn, I'd sound so much more intelligent if I could spell better
<crimsun> we should be concerned about code quality, not what OS is affected.
<LaserJock> bddebian: bah
<ScottK> OK.  Thanks.  I thought I'd check before I went to the trouble.  Back when I was exclusively using Windows, the fact that Python was cross platform was one of the things that attracted me to it in the first place.
<LaserJock> I liked it because you didn't have to buy a compiler for it
<ScottK> I will also confess that the ESR piece on how all the cool geeks used Python influenced me too.
<bddebian> pfft :-)
<bddebian> I thought XbuildX revisions were synced automagically?
<LaserJock> should be
<bddebian> LaserJock: Care to review libticables2 for me? :-)
<bddebian> Ho hum
<crimsun> keescook: regarding #78339, a debdiff cannot represent the upstream changes in binary form.
<crimsun> keescook: my practice has always been to provide a debdiff otherwise.
<ScottK> Good (I'm guessing it's afternoon for you) afternoon Hobbsee
<Hobbsee> hey ScottK :)
<Hobbsee> yeah, it's afternoon
* ScottK has one customer in NZ, so is gradually learning to do timezone conversions in his head for that part of the world.
<Hobbsee> :)
* Hobbsee wonders why u-u-s is subscribed to a wiki page...
<Hobbsee> https://wiki.ubuntu.com/UpToDateAtiNvidiaDrivers
* Hobbsee wonders how to list subscriptions on a wiki page
<jdong> Hobbsee: if you defer it to backports... *shakes fist* :D
<Hobbsee> jdong: which?
<jdong> that spec you listed ;-)
<somerville32> Mez: Are there plans to backport Exaile?
<Hobbsee> jdong: i dont know where it's come from - it's just gone to ubuntu-universe-sponsors list
<crimsun> eek, pitti's an ftp admin now (or at least doing syncs)?
<bddebian> Yeah apparently :-)
<crimsun> looks like a script, actually.
<StevenK> Hobbsee: It requires u-u-s to have a wiki page and more importantly, a profile.
<Hobbsee> StevenK: true...
<LaserJock> bddebian: hmm, what did I have a problem with last time
<bddebian> For what libticables2?
<LaserJock> yeah
<LaserJock> sorry
<LaserJock> was afk and read away message
<bddebian> The missing pkgconfig file :)
<LaserJock> oh yeah
<ScottK> Any else (bddebian excluded) up for reviewing a simple Python package?  http://revu.tauware.de/details.py?upid=4194
<ScottK> OK.  Well if anyone turns up, I'll be here for a bit seeing if I can find a package I'm up to merging.
<bddebian> Thought you were gonna try fnfx? :-)
<StevenK> That was me
<somerville32> lol
<ScottK> bddebian: Do you mind if I do endeavour?  You did it last time.
<bddebian> Go for it
* ScottK is going...
<StevenK> How 'cott' can be confused with 'teven', I have *no* idea.
<bddebian> Damnit, did I do it again??
<ScottK> me neither, but 90% pluss of the time when is name is gotten wrong it's Steve or some variation of it...
* nixternal points out bddebian to LaserJock - HIM TOO!
<nixternal> BOO
<nixternal> wth
* Hobbsee points LaserJock at ScottK 
* nixternal points Hobbsee at Hobbsee 
<TheMuso> There is something called tab completion. :)
<bddebian> Heh, heya nixternal
<LaserJock> what?
<Hobbsee> LaserJock: [15:42]  <ScottK> Any else (bddebian excluded) up for reviewing a simple Python package?  http://revu.tauware.de/details.py?upid=4194
<nixternal> no, the boo was BOO
<Hobbsee> tabcompletion on irssi kinda sucks
<StevenK> It does not, you tell lies
<LaserJock> oh, yeah, I'm firing up my pbuilders now
<nixternal> not if you get the silly script to fix the case issue
<LaserJock> I *love* irssi tabcompletion
<LaserJock> it's the only one that works well for me
* Hobbsee isnt a fan of the "if htere are multiple matching nicks, pick the first one"
<nixternal> LaserJock: I find myself trying to tab complete everything I type now
* Hobbsee only likes konvi tab completion
<StevenK> Hobbsee: What do you prefer?
<nixternal> Hobbsee: spoiled by the dropdown?
<Hobbsee> nixternal: yse
<Hobbsee> nixternal: yes
* ScottK likes konvi tab completion too.
<nixternal> hehe, that was nice
<TheMuso> You just make sure you type the first four or so characters.
<StevenK> Hah, I don't think irssi can do that.
<LaserJock> I hate dropdowns
<LaserJock> so annoying
<LaserJock> I don't want to have to arrow or click
<LaserJock> I just want to hit tab darnit
<nixternal> irssi can't do the drop down, but after a couple of tabs you will eventually make it, unless of course you get bitten by someone with funky case
<TheMuso> I dislike the mouse.
<TheMuso> Stupidest computer invention ever.
<ScottK> Well to get ScottK and StevenK correct one only needs to type two characters...  That appears to be difficult for some.
<TheMuso> Irssi usually fixes up the case.
* ScottK goes and merges...
* StevenK stops reading irssi stuff on changing completion behaviour.
<Hobbsee> StevenK: the other sane option would just be to complete to wherever the next character is, and wait for you to type hte next one
<Hobbsee> TheMuso: uploaded espeak
<StevenK> Hobbsee: Why? The shell does what irssi does.
<Hobbsee> StevenK: does it?
<LaserJock> yeah
<TheMuso> Hobbsee: Thanks.
<LaserJock> well, kinda
<TheMuso> Gotta love that list of changes I had to do to the damn thing.
<StevenK> pb <tab> -> pbuilder <tab again> lists pbuilder pbuilder-upgrade
<TheMuso> Hobbsee: You did review the package I hope.
<ScottK> If it turns out that no Ubuntu specific changes are required any more, do I just go file a bug that requests a synch vice a merge?
<Hobbsee> TheMuso: yeah.  appears to build, cant see anything crazy.
<TheMuso> Hobbsee: Righto.
<Hobbsee> TheMuso: and you'll into trouble yourself if you broke it :P
<StevenK> Heh, "appears to build"
<StevenK> The debian/rules just cats a build log, but doesn't do anything
<Hobbsee> heh
<StevenK> That'd be cool. :-P
<Hobbsee> StevenK: no, it runs a build log, but rm -rf's /
<Hobbsee> StevenK: package name is beryl :P
<StevenK> And if you build packages as real root, you deserve what you get.
<Hobbsee> indeed
<TheMuso> The only thing I was slightly worried about, is that upstream moved the location of a header file in libespeak-dev. I just want to make sure I covered all my bases. I am pretty sure I did.
<TheMuso> Gotta love upstream moving things around, and you have to find out for yourself.
<StevenK> TheMuso: Try ALSA some time. 
* StevenK twitches
<TheMuso> StevenK: lol
<StevenK> TheMuso: They moved entire drivers around, and release at least once without updating the Makefiles
<TheMuso> eeeew
<StevenK> released, even
<StevenK> "No wonder it doesn't build, the whole directory doesn't exist. .... Oh wait a moment..."
<LaserJock> darn bddebian already acked it
<LaserJock> I hate being number 2 ;-)
<TheMuso> StevenK: Well as I may have told you, I am trying to get the espeak author to separate voice data compilation routines out of a graphical app, and include them in the espeak source package, so the voice data can actually be built on the fly when the package gets built.
<TheMuso> Trouble is, they are tied to damn wx data types.
<StevenK> Ewwww
<bddebian> LaserJock: Bah, you're #1 baby :-)
<ScottK> Anyone?  If Ubuntu specific changes are no longer required for a package on the merge list do I file a bug requesting a synch instead?
<bddebian> ScottK: yes
<StevenK> Sync, and yes
<ScottK> Thanks.
<LaserJock> ScottK: just be sure that it builds
<TheMuso> StevenK: Yep.
<TheMuso> I literally had to ship two copies of the voice data files in the orig tarball, for little and big endian architectures.
<TheMuso> I'd rather not have to do that.
<StevenK> At least it doesn't hook to perl datatypes
<TheMuso> Well, for ppc anyway
<ScottK> LaserJock: Thanks.
<StevenK> TheMuso: In Perl, any variable translates to one of two structs, where one of the members is "magic" that is a function pointer
<StevenK> And people wonder why I'm insane. It's all Perl's fault.
<TheMuso> StevenK: riiight
<StevenK> TheMuso: Is that in reference to all what I just said? :-)
<TheMuso> StevenK: yeah
<TheMuso> You know,not having a maintainer for any particular universe package is a good idea, but someone who is dedicated to maintaining a package is a good thing, as they get to know the package source, and can work with upstream to fix bugs.
<TheMuso> case in point, me and espeak.
<Hobbsee> TheMuso: definetly true
* ScottK is discovering it takes a while to build the binary for endeavour...
<Hobbsee> uh, yeah
<ScottK> Endeavour builds then.  Here's the bug #81795:
<Ubugtu> Malone bug 81795 in endeavour "endeavour: sync new Debian version (2.7.5-1)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81795
<TheMuso> Is the motu council happening yet/
<LaserJock> just waiting on TB
<TheMuso> Right.
<StevenK> LaserJock: Really? The MOTU Council need to be diagnosed with it?
* StevenK runs away
<TheMuso> StevenK: rofl
<LaserJock> :p
<ScottK> LaserJock: Have you finished (either completed or as much, if any as you have time for) looking at http://revu.tauware.de/details.py?upid=4194? If you have, I'm going to go to bed (it's getting late here).
<LaserJock> I just left my comment
<ScottK> Thanks.
<ScottK> LaserJock: I gather you think it should be optional (vice extra)?  I debated that when I did it.
<LaserJock> optional is normal
<ScottK> OK.
<ScottK> Fixing now...
<LaserJock> extra is for something the conflicts with the packages in the other Priorities
<LaserJock> *that
<ScottK> OK.
<ScottK> It depends on a package that's in extra.
<LaserJock> I don't think that should matter
<ScottK> OK.
* ScottK is thinking that one's probably wrong too.
<LaserJock> oh
<LaserJock> "Packages must not depend on packages with lower priority values "
<ScottK> I did that one too.
<ScottK> That one exists in Debian.  I'll go double check what the last Debian package did and match that.
<ScottK> The package from Debian is in extra, so I think I'm stuck with that.
<LaserJock> yeah
<ScottK> LaserJock: http://revu.tauware.de/details.py?upid=4201 is ready for another look if you would...
<ScottK> bddebian: How about I take a shot at merging Courier?
<bddebian> Didn't I already do that?
<bddebian> Or is it an updated one?
<ScottK> It's an updated one.  You did it last.
<ScottK> Looks like all of the changes have to stay.
<bddebian> Sure
<bddebian> If someone wants to look at tamil-gtk2im.. If you know shell/POSIX stuff it should be pretty easy.  For some reason in debian/rules it does sh compile-gtk2im.sh.  Inside compile-gtk2im.sh it does sh libtool ....  For some reason dash doesn't like it.
<ScottK> bddebian: Just about done with courier.  If you wouldn't mind relooking at http://revu.tauware.de/details.py?upid=4201?, I'd appreciate it.
<bddebian> I'll take a look tomorrow.  I have GOT to get to bed.
<ScottK> OK.
<ScottK> Thanks
<bddebian> NP
<bddebian> Gnight folks
<LaserJock> arggg
<LaserJock> I was just going to tell him to upload his package
<somerville32> crimsun, can you upload https://launchpad.net/ubuntu/+source/mousepad/+bug/56161 ? Please :)
<Ubugtu> Malone bug 56161 in mousepad "Segfault when saving files on AMD64" [Medium,In progress]  
<ScottK> LaserJock: Thanks for taking another look and advocating.
<LaserJock> ScottK: np
<crimsun> somerville32: uploaded.
<somerville32> ty :)
<ScottK> courier is going to take a while to build.  I think I'm going to bed...
<ScottK> Good night everyone.
<ademan> ah, i'm back
<ademan> does http://www.codeblocks.org work for you guys?
<ademan> course as soon as i get back LaserJock is gone :-p
<Simon80> http://revu.tauware.de/details.py?upid=4203
<Simon80> review me :)
<Simon80> I'm going to bed
<Simon80> please and thank you
<ademan> Simon80: wish i could but i suck haha
<ademan> can anyone tell me why my package wants to install it's libs to /usr/share/codeblocks/*  ?
<ademan> and more importantly, where should it go (/usr/lib/codeblocks/* ?)  and what file controls this?
<afflux> ademan: if I'm not wrong, libs should go to /usr/lib. You can control this by "make install"ing them to debian/<packagename>/usr/lib
<ademan> yeah but i don't see anything like that in debian/rules or makefile.am
<lucas> Adri2000: on alioth, project name is pkg-multidistrotools
<ademan> how might i change wherre it installs to?
<imbrandon> hrm
<imbrandon> crimsun / ajmitch , do you know how a menu like this would be created ( it launches automaticly on ssh login ) http://www.imbrandon.com/misc/ssh-menu.png
<imbrandon> i have looked in the ~/.bash* and seen nothing that starts it , or even what it is ( e.g. bash script or a actual program etc )
<imbrandon> but i wanna make something like it myself
<imbrandon> any clues?
<imbrandon> ( or anyone ^^ )
<coNP> imbrandon: maybe it is the login shell?
<imbrandon> zomg, your right
<imbrandon> thanks
<imbrandon> haha
<imbrandon> i should have thought of that
<coNP> yw :)
<Amaranth> ooh, shiny
<coNP> hey, MOTUs, bug 2415 seems to be fixed
<Ubugtu> Malone bug 2415 in openbox "windows do not appear in gnome-panel workspace switcher" [Medium,Confirmed]  https://launchpad.net/bugs/2415
<coNP> however it is assigned to MOTU, may I switch it to fix released?
<imbrandon> where did you test it coNP 
<imbrandon> e.g. on feisty or edgy ?
<imbrandon> and if on edgy i would say yes, fix released
<coNP> imbrandon: I guess on dapper, edgy, feisty
<coNP> I use openbox
<coNP> on all of these
<coNP> and no problems with gnome-panel
<coNP> okay, imbrandon I will make it fixed, if you don't mind
<coNP> should I assign it to nobody?
<imbrandon> no
<imbrandon> never assign a bug to anyone 
<imbrandon> but yes mark it fixed if you wish or ask the reporter to confirm it was fixed now
<coNP> imbrandon: so leave it assigned to MOTU?
<imbrandon> yes, you should never change the assignment of a bug if you are not the person thats doing it, e.g. unless you are assigning a bug to your self you never never never change that fienld
<imbrandon> field*
<coNP> okay, imbrandon
<coNP> I understand
<coNP> now, finally :)
<imbrandon> heh
<afflux> review me please :) http://revu.tauware.de/details.py?upid=4200 -- thank you
<Amaranth> coNP: The problem was on amd64
<Amaranth> coNP: you say it's fixed on x86, that's not the bug :)
<coNP> Amaranth: oh. My mistake.
<coNP> Amaranth: isn there a way to assign this bug to amd64 build (and not to the source package)?
<Amaranth> no
<Amaranth> it's a bug in the source package
<neutrinomas1> can somebody please take a look at bug 57875 ? It seems to affect a lot of people ... (it's not an issue for me and I'd fix it myself if I could )
<Ubugtu> Malone bug 57875 in azureus "Azureus does not start" [High,Confirmed]  https://launchpad.net/bugs/57875
<AnAnt> hello
<AnAnt> may someone remove the softbeep package that I just uploaded
<AnAnt> I uploaded it by mistake to REVU
<Hobbsee> AnAnt: to revu?
* Hobbsee will
<AnAnt> Hobbsee: thanks
<Hobbsee> AnAnt: hasnt hit revu yet - how many min ago did you upload?
<AnAnt> Hobbsee: few secs
<Hobbsee> ah, that's why
<Hobbsee> cypher1: are you cypherbios too?
<geser> coNP: I just wanted to your replaces/conflicts for xchat-systray
<geser> but I can't get it installed as xchat-systray is gone in feisty
<coNP> geser: okay
<coNP> geser: however, I am not sure, that this will clean old xchat-systray packages making a dist-upgrade
<geser> we still need it for the upgrade
<geser> I'm considering to upload it but I can't test it
<coNP> geser: okay I see, I guess noone can
<coNP> geser: except someone using e.g. herd2
<coNP> with no updates since
<geser> fortunately LP has still the old debs
<coNP> nice :)
<geser> coNP: here are my test results:
<geser> dpkg: considering removing xchat-systray in favour of xchat ...
<geser> dpkg: yes, will remove xchat-systray in favour of xchat.
<geser> ic  xchat-systray          2.4.5-6ubuntu1         xchat systray notification icon
<geser> only the config-files are left
<coNP> geser: what do you think? Is it right?
<coNP> Did you --purge-d them? Or is it supposed to to do?
<geser> I don't know but I'd say it's ok
<coNP> thanks geser
<geser> np
<co-NP> geser: can you take a look at bug 45171? It is not urgent, of course.
<Ubugtu> Malone bug 45171 in openbox "openbox cannot catch gnome-screenshot shortcut" [Low,Confirmed]  https://launchpad.net/bugs/45171
<siretart> when changing the source of an yet unmodified debian package in ubuntu, are we supposed to change the maintainer field now?
<ScottK> Good morning.
<ScottK> Last night I started working on merging courier.  I'm afraid I may have bitten off more than I can chew at this point.  I'd appreciate it is someone experienced in doing merges would look at the list of errors lintian threw when I built the binary: http://pastecode.com/12715 - I'm guessing that I need to fix the missing build dependency, but I have no idea which, if any of the warnings would need to be fixed as part of the 
<ScottK> Note that with the missing build-dep installed the package appears to have built successfully.
<Liberax> anybody with pptp network manager on an ubuntu 64bit?
<ScottK> Adri2000: Thanks for the kick in the head about Bug #81795 - I think I stayed up to late last night trying to do merges.  It's fixed now.
<Ubugtu> Malone bug 81795 in endeavour "endeavour: merge (2.7.5-1ubuntu1)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81795
<Adri2000> :)
<pochu> hi guys!
<pochu> I've a problem while building a package
<pochu> the package builds fine, but it says this:
<pochu> 
<pochu> dh_gencontrol -ptracker 
<pochu> dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
<pochu> dh_md5sums -ptracker 
<pochu> dh_builddeb -ptracker 
<pochu> dpkg-deb: construyendo el paquete `tracker' en `../tracker_0.5.4-0ubuntu1_i386.deb'.
<pochu> 
<pochu> what do you think about that?
<pochu> unknow substitution variable...
<coNP> hi phanatic 
<phanatic> hey coNP 
<coNP> Hey! Any sponsors up to fix bug 45171?
<Ubugtu> Malone bug 45171 in openbox "openbox cannot catch gnome-screenshot shortcut" [Low,Confirmed]  https://launchpad.net/bugs/45171
<crimsun> I see you're volunteering.
<ScottK> Heh
<coNP> crimsun: I did what I could do. Cannot go any further without the blessing of a MOTU
<coNP> I need the MOTU power now :)
<ScottK> CoNP: Until I looked at the bug, I didn't realize you'd already done a patch and wanted someone to apply it.  I thought you were looking for someone else to develop the fix.  
<coNP> ScottK: Sorry, I was not clear enough, for sure.
<ScottK> At this point I'd just sit back and wait.  IME they usually get around to applying such patches reasonably quickly.  
<ScottK> Maybe find a MOTU to bug if it's not applied tomorrow.
<coNP> Okay, thanks.
<givre> Hello all
<ScottK> Hello
<givre> how can i get a new version of a package in main. Should i use the Sponsorship Process or should i go to REVU ?
<givre> the package in question is fuse
<givre> version in debian is 2.5.3 but latest version is 2.6.1
<crimsun> this question has arisen before, and I asked the person to check the dependencies.
<crimsun> there was no response.
<givre> crimsun: dependencies of 2.6.1 are the same of 2.5.3
<crimsun> does it integrate with fuse's rdeps?
<givre> of course
<givre> i didn't fully test, but i don't see why there should be a problem
<crimsun> it's a main package; regression testing is ... encouraged.
<jdong> is it backwards-compatible with existing fuse stuff?
<jdong> and you mean fuse-utils?
<jdong> and libfuse2...
<jdong> the userspace stuff....
<givre> right
<givre> 2.6 is backwards-compatible with 2.5
<givre> i can ask Miklos to be sure, but all virtual fs i use works with 2.5 & 2.6
<crimsun> givre: although a few of us have the ability to update it, none of us are going to update it without seeing positive testimony and the most recent uploader's blessing
<crimsun> givre: in this case, ask fabbione if he considers an update to 2.6.1 a priority
<givre> crimsun: right
<givre> crimsun: ok, so i guess what i have to do is :
<givre> - put my package in revu
<givre> - explain why it should be update
<givre> - ask fabbione to have a look at it
<givre> thanks crimsun
<ScottK> crimsun: Have you got a moment to help me with a merge problem?
<ScottK> OK.  I guess he's really away...  Anyone?  How much packaging fixing is one expected to do when merging?  My merge of courier builds, but lintian is extremely whiny: http://pastecode.com/12719 Should I just leave this package for someone more experienced?
<pirast> crimsun, moved
<gnomefreak> guys crimsun is away atm please see /whois crimsun for more details
<pirast>  /whois crimsun
<pirast> ugh
<pirast> gnomefreak. thanks
<gnomefreak> yw
<geser> ScottK: the more you differ from Debian the more has to be merged the next time, so only fix real problems
<ScottK> geser: Any thoughts on if any of those problems - http://pastecode.com/12719 - qualify as real?
<geser> ScottK: I don't know any details about this warnings
<ScottK> OK.  Thanks for looking.
<crimsun> pirast: which?
<pirast> crimsun, dos one for vlc 0.8.6a..
<pirast> works against my patched vlc
<crimsun> we need to get http://sam.zoy.org/zzuf/ into universe.
<LaserJock> crimsun: I'm a little sketchy on what exactly it does
<LaserJock> crimsun: how does adding random bits to user input help find bugs/security holes?
<crimsun> LaserJock: it helps identify which functions need to have input validation fixed.
<ScottK> LaserJock: I'm try to merge courier and am getting a huge number of lintian warnings when I build the binary.  I'd appreciate it if you would take a look and give me some advice of which of those issues are significant enough that I should add an Ubuntu change for it - http://pastecode.com/12719
<siretart> crimsun: zzuf is on its way to debian. we can sync it from there then
<LaserJock> ScottK: holy cow
<LaserJock> that is a lot
<ScottK> Yeah.
<LaserJock> they are all Warnings though
<ScottK> Yes.  I fixed the errors.
<ScottK> So do I say builds with no errors and call it good enough or do I need to fix some of that stuff?
<LaserJock> well, we try to minimize divergence
<LaserJock> you should look for Debian bugs for those
<LaserJock> a compat of 2 and standards version of 3.5 sounds like it's not even being maintained
<LaserJock> but that hardly seems possible, courier is a very common app
<ScottK> Yes.  And the Debian update is a Debian only change, so someone is maintaining it.
<LaserJock> well, I personally leave Debian stuff alone unless I really know what I'm doing
<LaserJock> perhaps couriers build system doesn't behave nicely or something
<ScottK> A couple of the issues have bugs, including one filed by siretart over a year ago...
<LaserJock> geeze, the BTS page looks aweful
<enyc> hrrm debian always seem to have phun getting rid of RC bugs...
<enyc> people keep adding more rc bugs as fast as they are going away lol
<LaserJock> 143 bugs, 1 Fixed or Pending
<LaserJock> 15 patches in BTS
<LaserJock> he hd 12 uploads in 2006 and still all that?
<LaserJock> *had
<ScottK> Any suggestions?
<LaserJock> ScottK: minimize divergence, try to poke upstream
<LaserJock> that's about all I've got
<ScottK> OK.  I think I'll go with "builds with no errors and call it good enough" and provide a patch for the merge.  Then see about bugs for upstream.  Hopefully enough courier users will try it out before Feisty gets released to uncover any serious excitement...
<ademan> my package wants to install libraries to /usr/share/codeblocks/*, it should be /usr/lib/codeblocks/*    where might i change this?
<ScottK> ademan: I think you want to look at man dh_install.
<geser> ademan: check the Makefile
<tsmithe> could someone do a quick revu for me?
<ademan> geser: i'll paste Makefile.am?
<ademan> or do i want Makefile.in?
<ademan> hrm, there is no Makefile.in
<ScottK> Howdy bddebian
<ademan> http://rafb.net/p/mMjkEm70.html   i don't see anything that would affect that do you?
<bddebian> Heya gang
<bddebian> Hi ScottK
<LaserJock> hi bddebian 
<ScottK> bddebian: Congrats on your package...
<bddebian> Heya LaserJock
<bddebian> ScottK: What package is that?
<LaserJock> bddebian: did you read your REVU emails yet?
<ScottK> bddebian: The lib whatever it was you've been messing with.
<geser> ademan: me neither
<ScottK> Apparently not.
<ademan> wanna see debian/rules?
<ScottK> bddebian: After you read your REVU e-mail, would you please relook at http://revu.tauware.de/details.py?upid=4201?  It's now looking for you to be 2nd advocate.
<bddebian> The only one I saw was aptoncd
<ademan> http://rafb.net/p/4Bw55Y47.html  i don't see where it might happen here either
<LaserJock> bddebian: I acked libticables and told you to upload it ;-)
<ademan> man dh_install seemed to suggest there should be a debian/package.install  but i didn't see one
<LaserJock> bddebian: about 2 minutes after you left last night
<bddebian> LaserJock: Ah cool thanks.  Now I can do tilp2 :)
<LaserJock> ademan: do you have an install?
<LaserJock> debian/install I mean
<ScottK> bddebian: After you catch up on my stuff, OK?
<bddebian> ScottK: Sure :-)
<ademan> LaserJock: nope
<LaserJock> ademan: well, it get's the dir for somewhere, grep for "share"
<ademan> in rules? or what?
<LaserJock> I'm guessing that it's setting the lib dir the same as data dir
<LaserJock> no, the source
<geser> ademan: check the defaults where it wants to install 
<LaserJock> as long as debian/rules isn't actually moving those files it's determined by the Makefile
<ademan> i posted the makefile above though, or are there more makefiles in src?
<geser> a good start would be the Makefile (the install target)
<LaserJock> ademan: grep it though, trying to find anything in the whole Makefile is difficult
<geser> ademan: you need the one created by automake
<ademan> LaserJock: how would i grep file contents? (sorry)
<ademan> geser: oh, so no Makefile.am?
<LaserJock> grep src *
<LaserJock> ademan: no
<LaserJock> look at configure, etc.
<tsmithe> anyone? anyone at all? (revu'age, please)
<LaserJock> just grep the whole darn thing
<coNP> tsmithe: you need a MOTU, don't you?
<LaserJock> ademan: grep share * , my bad
<ademan> hrm, well it seems to clean up Makefile(s) during clean in rules
<tsmithe> coNP, yup
<tsmithe> :)
<ademan> don't you think?  because there definitely aren't any Makefile(s) laying around
<LaserJock> ademan: you're looking for things like PREFIX or DESTDIR or LIBDIR
<LaserJock> ademan: I said grep *
<ademan> k
<bddebian> tsmithe: Which package?
<tsmithe> bddebian, thanks; you've done it already ;)
<ademan> i got a bunch of cbp and bat files, aren't those windows specific?
<bddebian> ademan: Did you say that there are configure.am files?
<ScottK> bddebian: Did you upload it?
<ademan> none, did you mean Makefile.am?  definitely no configure.am
<bddebian> ScottK: Not yet
<ademan> no configure.in either
<bddebian> ademan: There is a Makefile.am?
<ScottK> bddebian: OK.  I like the yet.  I'll be patient.
<ademan> there's a lot of them, but none contain "share" apparently
<ademan> "grep share * | grep -i Makefile.am" would get me that no?
<bddebian> ademan: Have you run autoreconf -f -i?
<ademan> in rules or just straight up? i've done neither though
<ademan> unless its in rules and i missed it
<ademan> it's not in rules for sure
<bddebian> No I mean from the source dir.  Do you have your files posted somewhere?
<ademan> bddebian: no, how could/should i?
<ademan> i could upload the dir to my webserver, would that work?
<bddebian> Have you gotten it to create the .dsc and .diff.gz?
<ademan> yep
<ademan> i've build the entire package
<ademan> i've got a deb sitting around
<ademan> but lintian errored all over my face
<ademan> thats how i found out about the /usr/share libraries
<ScottK> bddebian: Thanks.
<ScottK> Laserjock: Are you up for another review while I'm wrestling with the courier merge patch? http://revu.tauware.de/details.py?upid=4179
<bddebian> ademan: Just post the .orig.tar.gz, .diff.gz and .dsc somewhere
<ScottK> hey bddebian: Thanks again.
<bddebian> NP
* ScottK is down to one package waiting for REVU.  VERY cool.
<Simon80> hey, bddebian, sorry, but can you rereview my package? I added some modifications from Gentoo to add support to the MX300 and MX518, and I changed the description slightly
<bddebian> From Gentoo?  Why? :-)
<Simon80> lol
<Simon80> yes? no?
<Simon80> :)
<bddebian> Which package?
<ScottK> bddebian: It's http://revu.tauware.de/details.py?upid=4203
<ScottK> Simon80: Don't advocate your own packages.  MOTUs are the one that are supposed to do that.
<Simon80> hehe, I can delete that
<Simon80> my logic was that if it were wrong, the system wouldn't let it happen :)
<ScottK> In the system it doesn't matter, it just makes it harder for a MOTU to decide if the package is ready for upload, AFAICT.
<Simon80> oh
<ScottK> OTOH, maybe it annoys them and they review my package instead, so wait, go ahead and do that ;-)
<ademan> bddebian: alright will do
<bddebian> ScottK: hehe
<pirast> Nafallo, ping
<ScottK> I've taken merging courier as far as I can go.  bddebian: Since you merged it last time, you might want to have a look.  Bug #81799.
<Ubugtu> Malone bug 81799 in courier "Courier version courier_0.53.3-3ubuntu1 requires merge" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81799
<Simon80> anyone else available for review?
<Simon80> bddebian: thanks, btw
<bddebian> Simon80: NP
<luckyone> hello Masters of the universe
<bddebian> Hello luckyone
<luckyone> does anyone know of any problems with sane or libsane in 32-bit edgy?
<luckyone> I am having this problem - http://ubuntuforums.org/showthread.php?t=299347&page=2
<luckyone> and, I have no clue how to debug it
<Adri2000> Simon80: why do you use this hack in debian/rules to install the man page?
* luckyone wonders where he should take his question?
* luckyone thought this would be it because motu builds all of his wonderful binaries
<bddebian> luckyone: libsane is a main package
<ademan> bddebian: i can't get into my web host for some reason, any reccomendations?
<Simon80> Adri2000: I don't know a better way to do it
<luckyone> so, ubuntu main channel would be where I need to get help
<luckyone> ok, thank you MOTU
<luckyone> keep up the great work
<Adri2000> Simon80: DEB_INSTALL_MANPAGES_logitech-applet := debian/logitech_applet.1
<Simon80> I'll try that now
<Adri2000> Simon80: also, 0.4test1 means there will be 0.4test2 ... and finally the final stable 0.4?
<Simon80> Adri2000:no maintainer
<Adri2000> :-/
<Simon80> so, yes, but no
<Simon80> it's ok, there's another package that has maintainers, but I'll package it for feisty+1
<Adri2000> if yes, version should be 0.4~test1
<Simon80> ah
<Simon80> I can do that
<Simon80> see, the manpage hack, I totally blame lack of docs
<Simon80> it's frustrating, really
<Adri2000> grep /usr/share/cdbs/, all the doc is there
<Simon80> $ grep manpage /usr/share/cdbs/ -ri
<Simon80> /usr/share/cdbs/1/rules/debhelper.mk:   dh_installman -p$(cdbs_curpkg) $(DEB_INSTALL_MANPAGES_$(cdbs_curpkg))
<Simon80> that's surprisingly the fastest documentation ever, if you happen to grep for the right thing
<Simon80> lintian's complaining about my version
<Simon80> bad-version-number 0.4~test1-0ubuntu1
<Simon80> I don't think that's the first time though
<bddebian> ademan: Upload it to REVU, we can look at it there if you want
<Simon80> done
<Adri2000> Simon80: you are using edgy?
<Simon80> yeah
<Adri2000> that's why
<Simon80> oh, you weren't talking to me, bddebian, lol
<Adri2000> your lintian is too old
<Simon80> yep
<Simon80> I figured
<Simon80> k, I just have to wait for revu to update
<ScottK> Simon80: You might want to make a Feisty chroot to work in - https://wiki.ubuntu.com/DebootstrapChroot
<Simon80> maybe
<Simon80> I'll look into it for feisty+1
<Simon80> cause I'm only packaging new apps
<Simon80> and the deadline is whenever it is, like, right now :)
<Simon80> for upstream freeze
<Simon80> ok, bddebian, Adri2000: http://revu.tauware.de/details.py?upid=4207
<Simon80> thanks
<Simon80> errr, I should delete the hack instead of commenting it out :(
<Simon80> http://revu.tauware.de/details.py?upid=4208
<Simon80> last one!
<Simon80> lol
<pirast> could anyone who is in ubuntu-qa approve the nominations in bug 76094?
<Ubugtu> Malone bug 76094 in tor "Tor 0.1.1.26 fixes HttpProxyAuthenticator privacy flaw" [Undecided,Fix released]  https://launchpad.net/bugs/76094
<pirast> ,please ;-)
<LaserJock> pirast: I'm not sure who can approve nominations
<Adri2000> core-devs
<pirast> mhm
<Adri2000> ubuntu{qa,dev} can't
<pirast> i though that all people who are in ubuntu-qa can
<Adri2000> motu-sru neither
<pirast> :-(
<LaserJock> I can't
<LaserJock> and I'm ubuntu-dev
<pirast> because the security bug should be nominated for edgy, dapper and breezy..
<pirast> thanks anyway.. ill ask in ubuntu-devel
<somerville32> pirast: For security issues, see pitti
<LaserJock> it shouldn't have a Feisty nomination though I shouldn't think
<keescook> pirast: got it, one sec
<pirast> keescook, thanks..
<keescook> no problem!  thanks for tracking the problem.  :)
<pirast> keescook, new mail at security-review ;-)
<keescook> pirast: hehe okay, I'll check it out
<pirast> it somehow does not really makes sense to fix universe security bugs in breezy, does it?
<LaserJock> pirast: btw, I think in the future more people will be able to accept nominations (they might allow anybody to nominate in the future)
<LaserJock> pirast: why not?
<pirast> LaserJock, they already had I think..
<LaserJock> sorry, I mean you wouldn't have to get them accepted
<LaserJock> people could just set a target release
<pirast> LaserJock, that was possible some time ago
<LaserJock> yes
<LaserJock> and they are thinking of bringing it back
<pirast> ah okay..
<keescook> pirast: if it's easy, go for it, but I tend to recommend focusing on LTS and current stable.
<LaserJock> not sure quite yet
<pirast> sorry, somewhat tired
<pirast> LaserJock, http://fridge.ubuntu.com/node/721/results.. It would be nice if LTS + Edgy universe had less bugs first.. And we should concentrate on that first,  I think
<LaserJock> well sure, but there's no inherent reason to not fix something in Breezy
<LaserJock> pirast: well, that vote is also very inaccurate
<pirast> yeah.. there are probably lots of ubuntu fans which want to have the latest and greatest..
<pirast> see how many feisty users there are ;-)
<LaserJock> pirast: that poll only shows 154 Feisty users ;-)
<pirast> LaserJock, but that are 14% of all voters :-P
<LaserJock> ah, but that's where it get's sticky
<pirast> yeah..
<pirast> you're right
<LaserJock> lies, damn lies, and statistics ;-)
<gouki> I'm having trouble deciding which 'section' I should enter. Any links to help me out?
<gouki> Sorry, I'm creating a package from scratch.
<Adri2000> http://packages.debian.org/unstable/
<gouki> Adri2000: Thank you.
<Simon80> so, can any two MOTUs review my package again?
<Simon80> http://revu.tauware.de/details.py?upid=4208
<Adri2000> Simon80: are you sure that DEB_INSTALL_CHANGELOGS_ALL      := ChangeLog is needed?
<Simon80> uh
<Simon80> not sure actually
<Simon80> thanks, dh_make :)
<Simon80> well, without it, the changelog probably wouldn't get into the docs
<Simon80> so I'm going to say yes
<Adri2000> have you actually tried without it?
<Simon80> I'll try now
<Simon80> seems to work without it
<Simon80> new upload?
<Adri2000> wait, I'm checking if I have not missed anything
<Adri2000> looks fine
<pirast> if now a package gets updated in debian, will it arrive in feisty?
<Adri2000> not automatically
<Adri2000> !seen Fujitsu
<ubotu> I last saw Fujitsu (n=root@ubuntu/member/fujitsu) 1d 18h 41m 50s ago, quiting: "leaving"
<Adri2000> uhuh, "root", that's bad :)
#ubuntu-motu 2007-01-28
<|KingFish|> hello everyone
<|KingFish|> anyone home?
<Adri2000> hi |KingFish| 
<|KingFish|> hey adri
<|KingFish|> i'm seeking some help with my kubuntu
<|KingFish|> installed kubuntu 6.06 last week
<|KingFish|> first time i've installed linux since a way old version of mandrake
<Adri2000> did you try #kubuntu ?
<|KingFish|> room was busy but nobody helped me
<|KingFish|> it's not a kubuntu specific question i have though
<|KingFish|> has nothing to do with kde desktop
<Adri2000> #ubuntu-motu is not a support channel
<|KingFish|> ok, sorry for the bother
<|KingFish|> thanks
<Adri2000> np
<afflux> review me please :) http://revu.tauware.de/details.py?upid=4200 -- thank yoy
<afflux> *you
<Adri2000> afflux: version should be 20061204-0ubuntu1 and distro feisty
<afflux> ups.
<pirast> Adri2000, wargh
<Adri2000> afflux: src/Makefile and README.html are modified without using a patch system and that's bad
<afflux> src/Makefile contains a note about this, README.html wasn't on purpose
<Adri2000> afflux: I see +++ sauerbraten-20061204/debian/patches/01_makefile.dpatch but also +++ sauerbraten-20061204/src/Makefile
<Adri2000> don't change sauerbraten-20061204/src/Makefile and put all of the changes you want in the patch
<Adri2000> same for README.html
<somerville32> Adri2000, Are you using grep?
<afflux> Adri2000: yes. I had to change a dependency in the makefile because the make clean process (which is run by debuild -S -sa) would have created a makefile (which would have been added to the diff.gz)
<Adri2000> somerville32: currently I'm reading the diff.gz in firefox :)
<somerville32> Adri2000, ah, ;] 
<pirast> could anyone please review zatacka on revu? http://revu.tauware.de/details.py?upid=4209
<pirast> it's a new upstream release
<Adri2000> pirast: version: 0.1.6dfsg1-0ubuntu1, distro: feisty
<pirast> ugh..
<afflux> extreme stupid question: where to set the distro?
<Adri2000> in the changelog
<somerville32> afflux: changelog
<afflux> doh.
<pirast> Adri2000, uploaded, thanks
<afflux> instead of the "unstable"?
<Adri2000> package (version) distro; urgency
<afflux> alright.
<Adri2000> afflux: yes
<Adri2000> afflux: debian/dirs is probably useless
<pirast> Adri2000, any other suggestions to zatacka?
<Adri2000> looking
<Adri2000> pirast: you added dh_install --list-missing ?
<pirast> Adri2000, yup
<pirast> because I want to install the .desktop file
<pirast> via zatacka.install
<somerville32> Question: If I upload a version of a package that is newer then what is in debian, do I put the debian version as 0?
<Adri2000> pirast: ok
<Adri2000> somerville32: yes
<somerville32> Adri2000, And, like the same with merges, make minimal changes?
<Adri2000> yes, or forward your changes to debian
<somerville32> Adri2000, I should note that I'm doing this instead of merging. Is there anything else that I should do special?
<Adri2000> why are you doing this instead of merging?
<Adri2000> pirast: I think zatacka if fine
<Adri2000> s/if/is/
<somerville32> Adri2000, Debian package fails to build
<pirast> Adri2000, great :-)
<Adri2000> somerville32: name of the package?
<somerville32> Adri2000, xfce4-wavelan-plugin
<somerville32> Adri2000, I've already conferred with gpocentek
<somerville32> Adri2000, I just want to make sure I do it right all right :)
<Adri2000> yeah, nothing special to do, version 0.5.3-0ubuntu1, "new upstream release" and whatever else you change
<somerville32> Perfect.
<Adri2000> somerville32: hmm, but I don't see any FTBFS, at least on i386 on the buildd
<pirast> Adri2000, thanks.. sorry I am tired so I forgot to say ;-)
<Adri2000> np :p
<somerville32> Adri2000, It failed for bbdebian, gpocentek, and myself
<somerville32> Adri2000, Did you try building it?
<Adri2000> ah ok, in a feisty chroot, I was looking at the debian buildd
<somerville32> :)
<Adri2000> I'm trying to build it
<somerville32> imbrandon, Any updates? :)
<Simon80> anyone want to review?
<somerville32> Simon80, Depends on what it is ;] 
<Simon80> lol
<Simon80> can you? it's painless
<somerville32> I can review but not advocate it for ya
<Simon80> oh
<somerville32> Link?
<Simon80> don't bother then
<Simon80> it's been reviewed
<somerville32> Pfft.
<somerville32> Oh :)
<Simon80> it's the advocation I need
<somerville32> Simon80, New package?
<Simon80> logitech-applet
<somerville32> Oh, right
<Simon80> yeah
<somerville32> Whats the link anyhow?
<Simon80> http://revu.tauware.de/details.py?upid=4208
<Adri2000> somerville32: FTBFS... but why do you believe it won't FTBFS if you package it yourself?
<somerville32> Adri2000, gpocentek led me to believe that
<Adri2000> ok, try, we'll see :)
<somerville32> Adri2000, I'm going to upload 0.5.3+svn2458
<somerville32> :)
<Adri2000> ah, that's different
<somerville32> Ok
<somerville32> Adri2000, How so? :)
<somerville32> ie. What do I have to do differently?
<Adri2000> no, I meant that's different from uploading 0.5.3, and it may work better and not FTBS :)
<Adri2000> +F
<somerville32> :D
<coNP> ! FTBFS
<ubotu> Sorry, I don't know anything about FTBFS - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<Adri2000> !google define:FTBFS
<chillywilly> Results for define:FTBFS on Google:
<chillywilly> --
<Adri2000> ahah: <ubotu> Error: I am only a bot, please don't think I'm intelligent :)
<coNP> Adri2000: you are a human, what does FTBFS mean? :)
<Adri2000> coNP: FTBFS stands for Fail(s|ed) To Build From Source
<coNP> oh, thanks
<ash211> I'm trying to build an amarok package with an extra compile options but don't have debuild
<ash211> what should I install to get it?
<coNP> ash211: devscripts
<afflux> Adri2000: Any idea about my makefile issue in sauerbraten? Problem is, that make clean would create a makefile in the debuild -S -sa process which would also go to the diff.gz.
<ash211> coNP: thanks
<coNP> yw, ash211 
<Adri2000> afflux: it's ok to edit the Makefile for that, but not directly, use dpatch
<afflux> the problem with dpatch is that these patches aren't applied while debuild -S -sa but later when building the binary package. It's too late.
<Adri2000> ahhh, yes, you're right
<TheMuso> afflux: Are you using debhelper?
<afflux> yes
<TheMuso> I don't see why you couldn't patch the relevant files before you clean, and after you clean, unpatch them.
<TheMuso> But I may be missing something here, coming in half way.
<Adri2000> can't you just remove the Makefile in the clean rule in debian/rules?
<afflux> huh, this doesn't sound that bad. i gonna try.
<TheMuso> Does the package use configure/make/make install to build?
<afflux> the package contains a source and a library-source (which is used for static-linking). the library source uses configure, the main source only uses a makefile.
<TheMuso> Thats... um... a little messy.
<afflux> definetly.
<TheMuso> afflux: If you have an interest in the package, over time you may want to work with upstream to change that.
<afflux> i'll contact them, but not now... going to bed now.
<afflux> thank you for your help.
<ademan> ugh, does anyone have a place where i can upload files for the time being? my webserver seems to have locked me out (i wonder if my account expired)
<ademan> (specifically i want to upload a orig.tar.gz and a diff and a *.dsc)
<LaserJock> revu? ;-)
<ademan> hey, actually scratch that, maybe their server was down
<ademan> LaserJock: i'd have to sepukku again if i uploaded this pile of crap to revu :-p
<ademan> i still haven't fixed the libs into /usr/share yet
<ademan> its actually why i need to upload it
<ademan> cause i can't figure out where its happening
<Simon80> http://revu.tauware.de/details.py?upid=4211
<Simon80> when's the freeze deadline anyway?
<Adri2000> FeatureFreeze, see FeistyReleaseSchedule
<Simon80> ah, I have more time than I thought
<Simon80> but still, please review it :) it's done
<LaserJock> yeah, I'd rather people focus on merges and syncs right now
<LaserJock> we have more time for REVU after UVF
<ademan> does something have to be submitted to REVU before the feature freeze? or approved before it?
<ademan> to make it into fiesty that is
<Adri2000> approved
<LaserJock> should be *at least* uploaded to Universe before
<somerville32> Do merges and updated merges have equal priority or do merges have greater priority then updated merges (or vice versa)?
<LaserJock> merges have higher priority
<LaserJock> update merges means we've already merged the package once this release
<TheMuso> So really we should get the outstanding merges done first.
<LaserJock> it's possible that packages need to be approved by ubuntu-archive by FF to make it in
<LaserJock> usually they make a push to get the queue cleaned by the freeze
<TheMuso> Wow. Either merges.ubuntu.com is really slow, or the file I am fetching with grab-merge.sh is taking AAAGES
<TheMuso> cause its big
<LaserJock> some of them are
<LaserJock> hi Hobbsee 
<Hobbsee> hey LaserJock!
<somerville32> Hiya Hobbsee and LaserJock
<Hobbsee> hey somerville32 
<LaserJock> hi Cody
<TheMuso> Heya Hobbsee!
<Hobbsee> hey TheMuso!
<Simon80> LaserJock: my package isn't in universe yet, that's why I need it reviewed
<LaserJock> Simon80: I know :-)
<Simon80> ah
<Simon80> reviewed before UVF* I mean
<LaserJock> I'm just saying we have more time for REVU than for getting merges/syncs done
<Simon80> oh, I see
<Simon80> misread that completely
<Simon80> wait, no I didn't
<Simon80> you said more time for review AFTER UVF
<LaserJock> yes
<Simon80> but if my package isn't reviewed until then, it can no longer get in, correct?
<LaserJock> no
<LaserJock> you have until Feature Freeze
<LaserJock> which is 2 weeks after UVF for Universe
<Simon80> heh, that's the same time
<Simon80> oh
<crimsun> siretart: ok, thanks!
<Hobbsee> siretart: what do i have to do to get an account on REVU, again?
* Hobbsee has forgotten
<LaserJock> how do you mean?
<crimsun> Hobbsee: you have one (you're a member of ubuntu-dev)
<Hobbsee> LaserJock: crimsun a shell account?
<crimsun> Hobbsee: do you mean a shell acct on tiber?
<Hobbsee> crimsun: er, yes.
<Hobbsee> sorry :(
<crimsun> Hobbsee: oh, ask Reinhard, I presume.
<somerville32> Has anyone tried tamil-gtk2im?
<somerville32> (for merge)
<crimsun> Hobbsee: although any of him, Stefan, Andrew, and Raphael could add you
<TheMuso> Is it common for packages.ubuntu.com to be out of date?
<crimsun> yes.
<TheMuso> Thought as much.,
<bddebian> Heya gang
<LaserJock> hi bddebian 
<bddebian> Heya LaserJock
* ScottK is curious if anyone had a change to look at his courier merge patch mess yet (Bug #81799)?
<Ubugtu> Malone bug 81799 in courier "Courier version courier_0.53.3-3ubuntu1 requires merge" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81799
* ScottK will pick an easier one next time (and run screaming next time courier needs to be merged).
<crimsun> ScottK: most of those are acceptable.
<crimsun> 0700 is more strict than 0755, so if that's what the Debian source package uses, and there aren't grave bugs open about it, then it's arguably correct.
<ScottK> OK.
<crimsun> the missing debconf dependency should be corrected, though
<ScottK> Will double check BTS (didn't see any first time I looked).  
<ScottK> OK.
<crimsun> the initscript/LSB interaction should be double-checked, too
<superm1> crimsun, did you get to mythtv/mythplugins yesterday?
<ScottK> OK.  I'm pretty sure that all existed in the previous package, but will look into it.
<crimsun> superm1: no, I've been configuring an three hundred-person engineering lab all yesterday evening and weekend so far, so I've not had much time
<bddebian> Wuss :-)
<superm1> crimsun, ot a big deal
<superm1> crimsun, 300 ppl? thats crazy big
<superm1> most of my labs have been <15 people
<crimsun> it's huge, and I've been going batty as a result
<Simon80> bddebian: thanks for the review :)
<superm1> crimsun, would you mind if i tried to get bddebian to look it over in effort to get this made sooner, or did you want to still be the one looking it over?
<crimsun> superm1: the more eyes the better
<superm1> ok.. bddebian would you like to look over mythtv/mythplugins then?
<somerville32> Why does mom sometimes put "Remaining changes:\n -" and other times it doesn't?
<LaserJock> what?
<LaserJock> I don't think it does ever does it?
<somerville32> It does, I swear it : P
<TheMuso> Some merges that are listed on the page are older than others. The newer ones have the remaining ubuntu changes thing added in the changelog.
<TheMuso> For example, I think you will find that most of the updated merges will have it.
<bddebian> superm1: Where are these?
<superm1> bzr branches for the debian directories are here: https://code.launchpad.net/~ubuntu-mythtv/+branches, and upstream versions are here:  http://www.debian-multimedia.org/pool/main/m/mythtv/mythtv_0.20-svn20070122.orig.tar.gz & http://www.debian-multimedia.org/pool/main/m/mythplugins/mythplugins_0.20-svn20070122.orig.tar.gz
<bddebian> bzr?? WTF? :-)
<superm1> hehe
<somerville32> superm1, How is the bzr package development coming along?
<bddebian> somerville32: Why did you stick wavelan-plugins on REVU?
<superm1> somerville32, i haven't touched the packaging for some time, just been needing a motu to look it over 
<somerville32> bddebian, For gpocentek 
<somerville32> gpocentek, He is going to upload it for me
<bddebian> somerville32: Ah, OK
<somerville32> bddebian, Want an easy merge? 
<somerville32> Oh wait
<somerville32> nvm
<crimsun> bddebian: want a difficult merge?
<crimsun> ;)
<bddebian> crimsun: You need something?
<crimsun> several. We'll start with sleep, beer, and a life.
<crimsun> aside from that, not really.
<bddebian> Heh, well I can't help ya there, sorry
<bddebian> superm1: I really don't know bzr yet :-(
<superm1> bzr pull BRANCHNAME 
<superm1> will get you a copy of it
<superm1> so for mythtv it will be this
<superm1> bzr pull http://bazaar.launchpad.net/~ubuntu-mythtv/mythtv/ubuntu
<crimsun> I'd think he'd want export instead of pull.
<crimsun> oh, n/m me.
<somerville32> superm1, You have to branch, not pull
<superm1> oh, i've always pulled
<superm1> so bzr branch BRANCHNAME
<bddebian> Hah, got 3 different answers already, must be good shit
<somerville32> superm1, You pull AFTER you branch
<somerville32> bddebian, What is the third answer?
<bddebian> pull, export, and branch
<jdong> ok, I just walked in but....
<crimsun> well, it doesn't make sense for bddebian to export, since he doesn't have the repo
<jdong> export is not even in the same league of commands as pull/branch
<crimsun> superm1: would export.
<superm1> okay well whats the difference with pull and branch then?
<crimsun> e.g., export ../blah.tar
<jdong> crimsun: does export work with a transport url as the branch? ;-)
<jdong> superm1: pull is to update an existing branch
<superm1> oh pull needs an existing branch
<superm1> i see
<jdong> superm1: branch (aka clone, get) actually gets it
<superm1> then somerville32 is right, "bzr branch LOCATION"
<jdong> for the first time
<somerville32> haha
* somerville32 smacks jdong.
<jdong> somerville32: whoa, that didn't come out the way I meant it
<jdong> somerville32: superm1 interjected my 2-line statement :)
* jdong has nothing against you ;-)
<somerville32> hehe
<somerville32> ok
<superm1> lol 
<jdong> yay for bzr
* somerville32 gets jdong some ice.
<jdong> somerville32: I need it bad... I just rebooted from reiser4 :)
<somerville32> hehe
<crimsun> jdong: apparently, as of 0.13, yes.
<somerville32> crimsun: Btw, the new kernel seems to fix my kernel panic fun
<jdong> crimsun: lol :) so in a twisted way it'd kinda work :D
<crimsun> * ``bzr export`` allows an optional branch parameter, to export a bzr tree from some other url. For example: ``bzr export bzr.tar.gz http://bazaar-vcs.org/bzr/bzr.dev`` (Daniel Silverstone)
<crimsun> from the 0.13 announcement.
<jdong> interesting
* jdong wonders if it's faster than doing a complete branch operation
<jdong> for those who just want the latest pristine sources from a bzr branch
* jdong goes to benchmark
<bddebian> superm1: What have you changed from the Debian-multimedia package?
<bddebian> <sarcasm>Wow, this bzr branch crap is MUCH faster than wget foo</sarcasm>
<jdong> bddebian: *sigh* performance is improving
<jdong> with the addition of smart servers
<jdong> but for now there is an additional roundtrip for every file in .bzr
<jdong> so at minimum it's `find .bzr | wc -l` * latency
<bddebian> This is nuts.  I could have downloaded .dsc, .orig.tar.gz, diff.gz and built them by now..
<somerville32> I find bzr branch rather quick
<somerville32> You can always do a light-weight checkout
<somerville32> Which is very quick
<jdong> somerville32: a lightweight checkout is a nightmare to work with in the long run
<jdong> somerville32: esp. when the other side is across a network transport
<crimsun> well, everything's a nightmare on my 56kbps dialup.
<crimsun> so I don't really see what y'all are bellyaching 'bout!
<bddebian> Uhm, this is a cable modem and it's not even half way done
<somerville32> bddebian, The first branch is always the longest
<somerville32> But after that, it is pretty quick
<bddebian> Jesus and that was just for the Debian dir, not even a tarball?
<jdong> bddebian: the first branch takes a long time...
<jdong> worst if your ping is really high to their server
<bddebian> It doesn't take that long for me to cvs checkout the entire gnumach kernel source or hurd sources
<jdong> bddebian: that's because they have various servers that took a poor admin hours and hundreds of grey hairs to set up
<jdong> and now you're exaggerating.... or have satellite connection that pings @ 1500ms
<bddebian> No I am not.  I can pull an iso that fast.
<LaserJock> yep
<LaserJock> I did a branch of the doc team bzr repo and it took 1 hr
<somerville32> ...
<jdong> it'll all get better with smart servers
<jdong> that's why the other VCS'es branch so fast
<jdong> and for the record it was a LOT slower with weaves
<jdong> (the old repo format)
<LaserJock> yeah
<bddebian> Well I don't want to be a jerk but it better get significantly better or I won't be using it.
<TheMuso> Will smart servers allow for easier colaboration between users?
<LaserJock> bddebian: it's very good for local revision control
<jdong> bddebian: the first pull is the most painful one
<LaserJock> I don't use it much for remote work though
<jdong> bddebian: subsequent operations will be very fast (incremental)
<jdong> and local work is just bliss
<jdong> TheMuso: kind of... it provides a simple bzr serve command that can be used to set up makeshift code sharing setups
<jdong> without the need to set up an HTTP/FTP or SSH stack
<jdong> jdong@jdong-laptop:/tmp$ time bzr export test.tar.gz http://bazaar-vcs.org/bzr/bzr.0.14/
<jdong> 
<jdong> real    3m56.831s
<jdong> branch: real    12m0.656s
<jdong> so if you only need one revision, exporting is faster than branching
<jdong> good to know :)
<LaserJock> does it actually save it as a tarball?
<jdong> yes
<jdong> it's smart like that
<jdong> or you can tell it to export to a directory
<jdong> it reacts to what extension you provide as the destination
<LaserJock> that'd rather cool
<TheMuso> To me, bzr doesn't sound useful in colaborative environments outside of launchpad.
<TheMuso> Unless you can set up the user infrastructure to give access to the directories you need for the branches.
<TheMuso> via ssh
<LaserJock> I like it
<LaserJock> because I can drop a .bzr in http and it's all good
<LaserJock> but it does take getting used to
<TheMuso> I like it too. Easy to work with, sane command set etc.
<TheMuso> The ability to just publish repos on http is great I agree.
<LaserJock> but yeah, so far most of the collaborative utility I see is with big areas like say LP or sourceforge
<Hobbsee> haha @ the quit message
<LaserJock> yeah, quite interesting
<TheMuso> I have hosting with dreamhost, and while I could set up a project on my webspace with a domain and bzr, I'd have to waste user allocations to allow ssh access for people to push branches.
* Hobbsee pokes TheMuso 
<TheMuso> Whereas their subversion offering doesn't require that you have users allocated from your limit to set up colaboration.
<LaserJock> well
<LaserJock> but the point of bzr is more individualistic I think
<LaserJock> so *each* person should maintain their own branch
<LaserJock> so you don't need to allow people to push to your branch
<TheMuso> True.
<LaserJock> I think it takes a different mentality
<LaserJock> I'm not sure which I like better
<LaserJock> probably depends on the project
<LaserJock> hi minghua 
<minghua> Hello LaserJock
<ademan> how might i go about making one source package create multiple binary packages?
<ademan> obviously debian/control would have multiple packages in it (multiple source and binary?), but what would i do for rules? multiple rules? would i have to sort into different debian/tmp files and whatnot?
<LaserJock> ademan: in debian/control there is one section for source then you can have as many binary sections as you want
<LaserJock> you only have 1 debian/rules file
<ademan> ah, alright, so then i divy the files up into multiple debian/packagename/ dirs?
<LaserJock> you can have <binarypackagename>.install to tell which one
<ademan> ah
<ademan> where might i find a description of this file?
<ademan> or an example
<LaserJock> you can also have <binarypackagename>,dir etc.
<LaserJock> .dir
<LaserJock> it's just a file
<LaserJock> that lists the item to install and where to install it
<ademan> like
<LaserJock> ademan: I'd recommend looking at the packaging guide
<ademan> MySharedObject.so /usr/lib/MyCrap/  ?
<ademan> i did a bit, i suppose it bears looking at it again huh?
<LaserJock> usr/lib/MyCrap/ but yeah
<ademan> no leading slash?
<LaserJock> no
<LaserJock> because it's not installing to /
<ademan> ah, interesting, doesn't make too much sense to me, but it's an easy rule to follow
<ademan> (cause i mean if everything is relative to /  that's logically the same as an absolute path, blah blah blah blah)
<LaserJock> right, but you aren't installing to /
<LaserJock> in fact you have no idea where you are installing to
<LaserJock> so it needs to be relative
<ademan> ah i get it, why not ./usr/lib/MyCrap then?  just usr/lib/MyCrap is preffered?
<LaserJock> it make more sense to me
<LaserJock> *makes
<LaserJock> ./usr/lib/MyCrap would me `pwd`/usr/lib/MyCrap wouldn't it?
<LaserJock> *mean, my spelling is really bad tonight
<ademan> yeah i think that is what it would evaluate to, but wouldn't that be correct? oh i guess not since its not the pwd it's the install dir
<LaserJock> well, you are actually installing to `pwd`/debian/<packagename>/
<LaserJock> or sometimes `pwd`/debian/tmp/
<ademan> LaserJock: about debian/rules when something gets built, does it go into your pwd or the directory of the makefile?
<ademan> (i mean normally, i'm sure it can be dictated by the makefile)
<LaserJock> I think when things are built it's pwd
<LaserJock> for example, when building from a tarball, you can build from a seperate build dir
<LaserJock> with a debian package
<ademan> hrm, i wish i could just break out of the debian/rules so i could take a look around at the directories
<ademan> right before clean
<LaserJock> what do you mean?
<ademan> like, halt the "execution" of the debian/rules so i can see what files are made and where they are
<LaserJock> if you want you can run the whole thing manually
<LaserJock> debian/rules is just a makefile
<ademan> how? just make the individual targets by hand?
<LaserJock> yeah
<LaserJock> do it from the source dir
<LaserJock> so make -f debian/rules clean
<LaserJock> for instance
<ademan> yeah, i guess i'd do make debian/rules build and then make debian/rules clean ?
<LaserJock> well, whatever you want to do
<LaserJock> you should try install too
<LaserJock> anyway, time for bed, goodnight all
<mikeg41> is anyone here?
<mikeg41> topic
<mikeg41> oops
* ..[topic/#ubuntu-motu:mikeg41] : Im new here, have no idea whats going on!
<Lathiat> uh
<mikeg41> good evening
* ..[topic/#ubuntu-motu:Lathiat] : #ubuntu-motu to: Ubuntu Masters of the Universe: Universe Repository Maintainers | http://wiki.ubuntu.com/MOTU | http://wiki.ubuntu.com/MOTU/Documentation | Add yourself to http://tinyurl.com/fgpgy to upload to REVU
<Lathiat> Leave the topic alone, thanks :)
<mikeg41> sorry :)
<mikeg41> never used IRC before
<mikeg41> i was just following some tutorial
<Lathiat> join a scratch channel if you want to try that out :)
<Lathiat> like #mikeg41 or something :)
<mikeg41> so how does this irc channel relate to the MOTU project
<mikeg41> I was reading about it in the wiki last night, and I'm interested in getting involed
<ademan> mikeg41: well this is where people talk about packaging problems
<ademan> (so i talk quite a bit :-) )
<ademan> also people ask for REVU (new packages must be revu (review)ed before they can make it into the repositories)
<Q-FUNK> how do we UNsubscribe ourselves form a bug?
<Q-FUNK> launchpad only seems to have a way of adding people, not removing.
<Q-FUNK> /whpois mpitt
<Q-FUNK> argh
<siretart> Q-FUNK: in the left portlet, there is an edit subscriptions link to unsubscribe yourself or some group
<Q-FUNK> it only seems to allow adding
<Q-FUNK> siretart: there is NO _edit_ subscribtion, in the first plac.e there is only Add yourself or Add others.
<Fujitsu> You can subscribe anyone, but you can only unsubscribe yourself or a group you're a member of.
<Q-FUNK> myself is precisely who i'm trying to unsubscribe.
<siretart> Q-FUNK: for me, there is a link called 'subscribe/unsubscribe'
<siretart> Q-FUNK: it is the same /+subscribe link
<Q-FUNK> clicking on that only shows an option to add me.
<Q-FUNK> actually, looking at the bottom of the bug's page, it seems that what i get are notices, not subscribtions.  I still want out of this bug, though.
<siretart> Q-FUNK: aah, so you are not subscribed to this bug
<Fujitsu> Are you assigned/subscribed to the bug or any of it's dupes?
<siretart> Q-FUNK: which bug is that?
<Q-FUNK> in a way, i am. i still get spammed every time someone adds something to the bug
<Q-FUNK> 81721
<siretart> bug #81721
<Ubugtu> Malone bug 81721 in upgrade-system "6.06-to-6.10 Upfailed" [Undecided,Rejected]  https://launchpad.net/bugs/81721
* Fujitsu faints.
<Fujitsu> We've passed 80000 already?
<siretart> Q-FUNK: no, you are indirectly subscribed to this bug, but I don't really understand why
<Q-FUNK> Fujitsu: I thought i had reassigned to the correct package, but it seems that clicking on the package name and changing it creates a dupe for the other package, nowadays.
<siretart> Q-FUNK: I think that could be a bug in launchpad. you should ask in #launchpad about this
<Q-FUNK> I later rejected the ug on my own package, but kept on receiving copies of everything there.
<Q-FUNK> previously, clicking on the Affects link with the package name allowed to reassign. now, it instead creates a dupe.
<siretart> *sigh*
<imbrandon> Fujitsu, hehe yea
<imbrandon> 80000+
<afflux> I uploaded something to revu last night but my system went down during the upload. now I have parts of my package in revu.tauware.de/incoming, but it's incomplete and reuploading gives an error ('553 Could not create file.'). Any idea how to fix this?
<Adri2000> ask an archive admin
<Adri2000> to remove the files from incoming
<Adri2000> err, not an archive admin, a revu admin
<afflux> so someone of the "REVU Team" group for example in launchpad, right?
<Adri2000> https://launchpad.net/~revu-hackers
<afflux> eh, found it...
<afflux> siretart, ajmitch, raphink: could you please remove the sauerbraten* packages and the dcut.Kjell_Braden*.commands files from incoming? thanks a lot.
<siretart> afflux: you work on sauerbraten? 
<siretart> afflux: are you in touch with the debian games team? Fuddl just asked me to look at his sauerbraten packages to upload them to debian.
<Hobbsee> siretart: how does one get an account on tiber?  (to resync the keyring) - i've forgotten :(
<siretart> Hobbsee: you write me an encrypted and signed email with your initial credentials
<siretart> Hobbsee: hi, btw ;)
<Hobbsee> siretart: initial credentials?  meaning?
<Hobbsee> siretart: heya!
<siretart> Hobbsee: your username and password
<Hobbsee> ahhhh
<siretart> and in general, some explanation why you need the account and what for
<siretart> resyncing the keyring is a good reason, since you are way more often on irc than me
* Hobbsee nods
<Hobbsee> siretart: for destruction purposes.  duh :P
<siretart> ;)
<StevenK> "So I can run 'rm -rf /' and blame you entirely"
<afflux> siretart: I just built the ubuntu package, yes. But I'm not a sauerbraten dev. No, I'm not in touch with debian.
<afflux> (sry for slow answer, tor is lagging atm.)
<siretart> afflux: I know that Fuddl from the debian games team is working hard on getting it ready for debian
<siretart> afflux: please get in touch with him, so that we don't end up with 2 seperately maintained packages
<afflux> okay, i'll try. I just read about some license problems with the data content which caused the debian guys to stop this stuff.
<siretart> afflux: the same reason will also cause us ubuntu guys to stop uploading the package
<afflux> i didn't take the data files in the package.
<siretart> so you can't do anything useful with it?
<afflux> the engine is open-source and my package only contains the engine.
<siretart> the debian approach is to package the engine for contrib and the data to non-free
<siretart> we could sync both packages to multiverse, I think
<siretart> afflux: so again, please join the debian games team and work on the package in their svn. 
<Adri2000> Laser_away: please take a look at my debdiff http://adrishost.homeip.net/~adri2000/ubuntu/toupload/genesis_2.2.1-11ubuntu1.debdiff to fix the genesis bugs
<afflux> siretart: joining a channel takes a moment. :/
<siretart> afflux: it's #debian-games on oftc (e.g. irc.debian.org)
<afflux> thank you
<siretart> afflux: 15:48:07 < Fuddl_> btw, the ubuntu sauerbraten package is non-free - the zlib license only applies to the src directory. neither to docs, nor to README.html - that guy ships it within his package
<afflux> yes, thank you for your help. as i said before: i'm going to contact this guy soon, i have no time now.
<siretart> k
<bddebian> Heya gang
<Adri2000> hi bddebian 
<nixternal> boo
<bddebian> Heya Adri2000, nixternal
<nixternal> howdy
<nixternal> you buying breakfast?
<bddebian> nixternal: Sure
<nixternal> awesome, actually I will wait for lunch, then you get me a cheese steak
<bddebian> mmmm
<nixternal> Pat's or Ginos?
<nixternal> I remember those 2 places
<bddebian> Honestly.  I haven't been to either one yet. :-)
<nixternal> when I had to work at the shipyard there for about a month, I remember going to them, they are like right next to each other I think
<bddebian> nixternal: Yeah they are, I just avoid Philly whenever possible :_)
<Adri2000> geser: can I merge greylistd?
<Adri2000> actually there is nothing to do :p
<geser> sure
<geser> I will sponsor it if you need one
<Adri2000> ok, thanks :)
<Adri2000> argh, .po files in the debdiff
<Adri2000> I have often that but I don't understand why :(
<coNP> Adri2000: if you have time, please have a look at bug 45171 :) (I committed a patch for it)
<Ubugtu> Malone bug 45171 in openbox "openbox cannot catch gnome-screenshot shortcut" [Low,Confirmed]  https://launchpad.net/bugs/45171
<Adri2000> coNP: maybe using dpatch or something would be better than editing directly openbox-3.3/data/rc.xml.in
<coNP> Adri2000: why do you mean this?
<Adri2000> coNP: you shouldn't change a file from the orig tarball like that, it causes problem when updating to a new upstream version and it's not clean
<coNP> Adri2000: I think https://wiki.ubuntu.com/Bugs/HowToFix states not to use a patch system if the packages does not use one
<Adri2000> so you can put your patch(es) in debian/patches and use a patch system like dpatch to apply them during the build
<geser> I wouldn't introduce a patch system for such a small change
<coNP> okay, for me it seemed it is forbidden for me, because I am not the package maintainer
<Adri2000> right, it creates an important diff with debian
<Adri2000> coNP: listen geser :
<coNP> Adri2000: sorry I don't understand; geser said no patch system for this
<Adri2000> yes
<Adri2000> you should listen him rather than me :)
<geser> coNP: I'm uploading the debdiff as is
<geser> introducing a patch system would be ok if you need to apply some rather longly patches
<coNP> okay, thank you both Adri2000, geser
<coNP> you are quite good in frightening motu-wannabees :)
<Adri2000> geser: http://adrishost.homeip.net/~adri2000/ubuntu/toupload/greylistd_0.8.3.3ubuntu1.debdiff, I have removed the .po changes from it
<ScottK> geser: Did you ever get a chance to look at my package that we discussed on Friday? http://revu.tauware.de/details.py?upid=4179
<geser> ScottK: not yet
<ScottK> OK.  No problem.  Understand that merging is the priority at the moment.
<ScottK> Thanks.
* ScottK goes back to wrestling with his courier merge...
<geser> Adri2000: uploaded
<Adri2000> thanks
<Adri2000> geser: is there anything decided about the maintainer field?
<Adri2000> because \sh changed it in some packages
<geser> Adri2000: not that I know of
<Adri2000> geser: http://adrishost.homeip.net/~adri2000/ubuntu/toupload/wysihtml_0.13-4ubuntu1.debdiff
<geser> Adri2000: uploaded
<Adri2000> re-thanks :)
<siretart> afflux: sauerbraten just hit the debian NEW queue: http://ftp-master.debian.org/new.html - feel free to file a sync request (or hit me or some other MOTU to do that) for ubuntu
<afflux> siretart: excellent. should i test build it or just mention in the sync request that it built fine on your feisty pbuilder?
<siretart> afflux: if I aren't in ubuntu-dev yet, you'll need some MOTU to testbuild and ACK the request
<siretart> I tested the package locally here, works fine for me on feisty/amd64. no idea about i386 and ppc though
<pirast> keescook, hi
<afflux> siretart: query?
<givre> Hello all
<givre> just a question
<siretart> afflux: siretart@jabberme.net is fine as well
<givre> if i have a package with an init script, and if i want to adapt this init script for ubuntu (basicly make it LSB compliant)
<givre> is it better to patch the init script
<givre> or simplu don't install the upstream init script, but instead install the modified init script
<givre> since the changes are big, i would go for the second solution, but i'm not sure.
<ajmitch> morning
<ScottK> good afternoon.
<Zic_> hi
<zul_> 3 ~76h 0
<zul_> \
<Zic_> hello, I have a problem with my launchpad account : http://launchpad.net/~zic/
<Zic_> My email is .. gone :|
<Zic_> When i'm loging, I see my e-mail with a "cadena"
<Adri2000> lock
<Zic_> In fact, I have change my GPG key, because I have lost it :/
<Adri2000> padlock*
<Adri2000> Zic_: try #launchpad
<Zic_> good idea :>
* Adri2000 loves that:
<Adri2000> $ wc -l gnucash_2.0.2-2.1ubuntu1.patch
<Adri2000> 789442 gnucash_2.0.2-2.1ubuntu1.patch
<stgraber> :)
<ScottK> As some of you may recall, I'm having lots of 'fun' over here trying to merge the latest courier from Debian....  All the binaries have a "init.d-script-missing-lsb-section" warning that crimsun said needed to be investigated.  If someone would point me in the direction of an appropriate reference for Ubuntu LSB and init scripts, I'd really appreciate it.
<welshbyte> ScottK: http://wiki.debian.org/LSBInitScripts
<ScottK> Thanks.
* ScottK is in way over his head.
* ScottK presses on...
<welshbyte> ScottK: that's the spirit
<Adri2000> geser: still here?
<ScottK> Thanks.
<ScottK> Learning new things is good, even if it hurts a bit at the time...
<geser> Adri2000: yes
<Adri2000> geser: gnucash merged: http://adrishost.homeip.net/~adri2000/ubuntu/toupload/gnucash_2.0.2-3ubuntu1.debdiff but haven't yet built it
<geser> Adri2000: I'm currently not at home and can't upload now
<Adri2000> ok, then I will file a bug once it is built
<ScottK> How does one unmark a bug a duplicate.  It seems I got ahead of myself...
<crimsun> which?
<ScottK> Bug #69143
<Ubugtu> Malone bug 69143 in courier ""/etc/init.d/courier-pop-ssl start" does nothing (dup-of: 69140)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/69143
<Ubugtu> Malone bug 69140 in courier "The script /etc/init.d/courier-imap-ssl restart does nothing" [Undecided,Unconfirmed]  https://launchpad.net/bugs/69140
<ScottK> It's a different init script the bug is about and I didn't notice until after I pulled the trigger.
<crimsun> click "Mark as Duplicate", remove the bug number, and click Change
<ScottK> Ah.
<ScottK> Thanks.  That little bit of UI was not intuitive for me.
<crimsun> LP has quite some ways to go
<crimsun> I've kinda fallen into its sort of unintuitiveness, so I know some of those nasties
<ScottK> As such things go it's not bad.
<ScottK> Appreciate the help.
<ScottK> Certainly much less counter-intuitive than clicking on something marked 'Start' to turn off a computer.
<crimsun> argh
<ajmitch> argh?
<crimsun> why are people assigning sync requests to u-u-s?
<crimsun> and then, of course, not following sync req policy?  (bug 82035)
<Ubugtu> Malone bug 82035 in Ubuntu "Please sync pam-keyring (0.0.8-1) from debian unstable (main)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82035
<Adri2000> it means YOU have to file a correct sync request :)
<crimsun> uh yeah, I'll get right on that.
<ScottK> Heh.  The person that filed the bug, bigon, is even on this channel now....
<ajmitch> how annoying
* ajmitch should remember to file that sync request..
<ajmitch> if only lp weren't so slow
<coNP> thanks Adri2000 
<ajmitch> there, filed
<Adri2000> hmm, for what coNP? :)
<coNP> Adri2000: oh, nothing :); I guess geser was the one who uploaded my package
<Adri2000> eheh, yes, I can't upload :)
<geser> coNP: yes I uploaded openbox
<coNP> oh, I tought you were a MOTU, Adri2000 
<coNP> geser: thanks
<Adri2000> coNP: I hope soon :p
* ScottK waves goodbye to bigon...
<Adri2000> ScottK: :D
* ScottK concludes the courier is a PITA, but presses on....
<Adri2000> LaserJock: \o/
<LaserJock> Adri2000: hi, did you try that genesis-start script out?
<Adri2000> of course
<Adri2000> LaserJock: is my debdiff ok?
<siretart> jdong: I just sponsored your ffmpeg patch (the x264 linkage patch)
* ScottK is ready to pass the buck to or get some serious advice on Bug #81799.  Dunno if that's good enough to merge or not.
<Ubugtu> Malone bug 81799 in courier "Courier version courier_0.53.3-3ubuntu1 requires merge" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81799
<crimsun> ScottK: The source package lintian warnings can be ignored.
<crimsun> ScottK: Is it really out of your way to LSB-ify the initscript?
* ScottK has never done it before.
<ScottK> It doesn't look that hard.
<ScottK> The real question is, is that worth adding to the diff from debian?
<ScottK> If the answer is yes, then I'll go take a shot at it.
<crimsun> It's not difficult. See any of the main packages that ship an initscript.
<crimsun> Yes, it's worth it if for no other reason than to shoot patches into Debian BTS.
* siretart agrees
<ScottK> OK.  I do note that there are patches for courier that have been sitting in BTS for a LONG time (including one from siretart).
<siretart> ScottK: did you actually test your merged courier?
<ScottK> I'll go work on that.
<ScottK> Not yet.
<ScottK> I'm having some issues with the courier-authdaemon and my feisty chroot that I'm trying to figure out.
<siretart> ScottK: filing patches to the bts is a good idea in any case for several reasons: the maintainer could wake up somewhen, the maintainer could change or some other DD could feel like NMUing the package
* ScottK will be filing a bunch of bugs in BTS once he gets done with courier...
<siretart> err, the only things that have been done are only translation updates, no?
<ScottK> Yes.
<ScottK> That's why when I started on this one I thought it would be an easy merge to do.
<ScottK> I'm dealing with stuff that was pre-exisitng.
<ScottK> existing...
<ScottK> btw, the current courier-authdaemon init scripts aren't lsbified either.
<ScottK> If someone more experienced wanted to jump in and take over on this, I'd be thrilled.
<enyc> Hrrm... I am running into trouble with edgy and console.. osmething is a bit wrong as the capslock light does not get lit when active (normal PS/2 keyboard fully working) after "setting preliminary keymap" message at boot ...  note that num/caps LEDs work as is normal on X-server....  I have already reset the keymap with "sudo dpkg-reconfigure console-setup" btw... this does not help
<crimsun> I'm pretty sure you meant that for #ubuntu.
<enyc> o
<enyc> kk
<raphink> hi guys
<raphink> anyone to review http://revu.tauware.de/details.py?upid=4221 ?
<muzzol> hi
<muzzol> LaserJock, crimsun ping
<raphink> hi muzzol
<muzzol> hi raphink 
<muzzol> raphink, are you aware about the problem of cinelerra?
<raphink> which problem?
<muzzol> licensing problmes
<raphink> I guess that means "no I'm not aware"
<raphink> no I'm not
<muzzol> ok
<raphink> what kind of licensing issues are these?
<muzzol> well, basically we wanna be sure what is inside cinelerra
<muzzol> because heroin warrior, the main developers
<muzzol> use code from other projects
<muzzol> so we want to be sure we dont have any problems with that derived code
<raphink> ic
<raphink> yep
<raphink> that's good
<muzzol> for example
<muzzol> cinelerra uses code from toolame
<crimsun> toolame is in Ubuntu universe, so that's a non-issue.
<raphink> are you working on the cinelerra package?
<muzzol> i got the package actually compiled for feisty
<muzzol> i think it needs a revision
<muzzol> but i have no idea about revo
<muzzol> revu
<raphink> I thought cinelerra was already in Debian/Ubuntu
<muzzol> what?
<muzzol> thats not possible
<raphink> might be wrong
<raphink> haven't used it
<muzzol> cinelerra had lot of packagers before
<raphink> no i was wrong
<raphink> did you look for packages for Debian already?
<muzzol> but none taked the job to do it permanently
<raphink> or previous packages on REVU?
<muzzol> im pretty sure cinelerra is not on the repos
<raphink> it could be somewhere on apt-get.org
<raphink> at least it's not on revu
<raphink> is there an ITP/RFP filed already in Debian?
<muzzol> please, be kindly with a noob
<muzzol> itp?
<muzzol> request for package
<raphink> itp = intent to package
<muzzol> ok
<raphink> rfp = request for package
<raphink> http://groups.google.fr/group/linux.debian.bugs.dist/browse_thread/thread/1d6745998c8eddb/958040073398d4cb?lnk=st&q=cinelerra+itp&rnum=2#958040073398d4cb
<_MMA_> raphink: I saw one a while ago for Ubuntu but no one has done it.
<raphink> http://groups.google.fr/group/linux.debian.devel/browse_thread/thread/6cfeb05bd874f0ee/b27b755cc08a78ce?lnk=st&q=cinelerra+itp&rnum=3#b27b755cc08a78ce
<raphink> _MMA_: ITP/RFP for Ubuntu :O
<_MMA_> LaserJock at one time showed me a link. Ill try to dig it up.
<raphink> you might want to contact these guys too, muzzol
<_MMA_> Point is nobody has done it.
<raphink> _MMA_: we don't use ITP/RFP in Ubuntu
<raphink> unless it has changed while I was not looking :)
<_MMA_> raphink: At this moment we're just trying to sort out the license issues. Can yo uhelp?
<_MMA_> *you help..
<raphink> well right now it's midnight
<raphink> so I think I'll go help my bed getting flatter
<raphink> :)
<_MMA_> Besides the time...
<raphink> otherwise if I have some time and you still have issues I might help
<raphink> :)
<_MMA_> Do you have the proper knowlege?
<raphink> knowledge for what?
<raphink> for the license issues?
<_MMA_> yes
<raphink> I'm not a lawyer
<raphink> but I've been confronted to licensing issues quite a few times
<raphink> last time was a few minutes ago with PDFedit ;)
<muzzol> raphink, that links you showed me are from several years ago
<_MMA_> More to get Cinelerras licenses inline with Debian packaging rules.
<raphink> muzzol: that does not mean that the package sources have disappeared
<raphink> if they have existed
<raphink> or that the people who did the packages at the time don't remember them
<_MMA_> Thats where _some_ of the issues are. ie: They give 1 license in the root dir for all of the files.
<raphink> _MMA_: yes
<raphink> I know of such issues _MMA_
<raphink> I'm dealing with the same kind of issues with PDFedit today
<muzzol> mmm, im close to cinelerra-cv developers so i dont think that people even work on that package
<muzzol> i knew
<raphink> and sent an email to upstream for that
<muzzol> ok
<muzzol> i can do that
<raphink> ;)
<muzzol> what is the protocol i case some of that guys are still there?
<raphink> they include the source code of several projects in their code (kpdf, xpdf, etc.) and don't use any GPL headers in their code
<raphink> nor any copyright line anywhere
<raphink> and only include a LICENSE.GPL file
<raphink> in doc/
<raphink> ;)
<raphink> muzzol: contact them and talk :)
<_MMA_> raphink: Whats the protocol if the apps devs are less than cooperative?
<raphink> _MMA_: it's their program, their work
<raphink> they do what they want with it
<raphink> if they want ot put it under a proprietary license, they can
<muzzol> is not the case
<muzzol> let me explain
<raphink> provided it does not break dependencies on other licenses
<muzzol> raphink, 
<muzzol> cinelerra have two friendly forks
<raphink> mhm
<muzzol> the main is from heroin warrior
<_MMA_> raphink: We have a email stating we can add the license headers but upstream will not do it themselves.
<raphink> _MMA_: that's not fine
<raphink> _MMA_: add the headers, make a patch
<raphink> and send it back to upstream
<raphink> if they're too lazy, they can at least include your patch with proper headers
<raphink> if it's something else, you might contact the FSF
<_MMA_> raphink: We've been told in so many words that the license they provide is fine. They (heroine) wont change it just because it doesnt conform to Debian packaging rules.
<raphink> Debian licensing rules are conform to the FSF ones
<raphink> that are pretty strict
<_MMA_> The Cinelerra-CV guys are a friendly fork but they seem slow to change alot.
<raphink> there are rules to use the GPL, described on the GNU website
<raphink> _MMA_: as I said, if you're in a hurry, make the changes yourself, send them a patch and let them type "patch -p 0 < yourpatch.diff"
<raphink> not like it's gonna take them hours
* LaserJock is reading backlog
<raphink> ><> LaserJock
<LaserJock> _MMA_: do you actually know yet how many files need  license?
<_MMA_> I dont think its a time thing. Some of it I get the felling they just dont care.
<_MMA_> LaserJock: muzzol said at one time 2/3rds.
<raphink> _MMA_: if they don't care, it still doesn't take much to apply an existing patch
<_MMA_> I think theres about 3000 or so? muzzol?
<muzzol> yes
<muzzol> about that
<raphink> otherwise, ask for a CVS/SVN access :)
<_MMA_> Thats true.
<muzzol> raphink, is there any problem with using a generic advise license?
<muzzol> instead of changing every file?
<muzzol> were confortable about GPL of the code
<muzzol> the problem is manually adding gpl to each file
<_MMA_> muzzol: I thought we could script that?
<muzzol> we can try
<LaserJock> at the very least have  list of the files and explicitly say that those files are under the GPL
<muzzol> thats what we wanted to do
<muzzol> at least for this first package
<muzzol> and ask developers to add it from now on
<muzzol> and help them for the next release
<raphink> muzzol: try?
<_MMA_> There just seems to be some politics there also we need to work through.
#ubuntu-motu 2008-01-21
<\sh> somerville32, why is gtkfilechooser in the source?
<somerville32> \sh: Because the developers put it that there?
<\sh> somerville32, in trunk it's not there anymore :)
<\sh> http://svn.xfce.org/svn/goodies/thunar-svn-plugin/trunk/thunar-svn-plugin/
<\sh> #
<\sh> argl wrong dir
<\sh> no chance to patch it somehow away?
<somerville32> It would be pretty invasive
<somerville32> Plus I don't know how stable trunk is
<\sh> na..
<\sh> was the wrong dir
<\sh> but it's strange, really, because: gtkfilechooser.c:#include "gtkfilechooser.h" localversion included
<\sh> but gtkfilechooserentry.h:#include <gtk/gtkfilechooser.h>
<\sh> without having a libgtk-2.0-dev dependency somewhere
<somerville32> libgtk-2.0-dev is brought in automatically
<\sh> libthunar-vfs-1-dev ?
<somerville32> right
<\sh> I wonder if it would be a good idea to add those build-deps directly, because they are direct build-deps..
<somerville32> I was already told to remove pkg-config
<somerville32> because it was dependency of a dependency of a dependency
<LaserJock> afternoon MOTU Land
<tritium> Hi LaserJock
<\sh> that's crap
<LaserJock> heh
<\sh> for me build-deps are need to be named for things which the source depends on it
 * LaserJock hopes \sh wasn't talking about him
<\sh> dbus-dev is not even a direct dependency
<\sh> LaserJock, na
<LaserJock> tritium: good to see you
<tritium> You too, LaserJock :)
<\sh> so when someone things about removing pkg-config from dbus-dev or from any other indirect build-dep because they don't need pkg-config anymore this packages still needs it
<LaserJock> tritium: I haven't had a chance to respond to the -motu-science emails but it looks like there's some good stuff to be done
<tritium> LaserJock: no problem.  You saw mine?
<\sh> gpocentek, ping why do you think those build-deps are not necessary?
<LaserJock> tritium: yep
<tritium> Cool, thanks, LaserJock.  Like I said in the mailing list post, I'd like to help as I can.
<LaserJock> tritium: yeah, I think there are some things that you could do to kinda get the rust out ;-)
<somerville32> \sh: I'm certainly not opposed to your line of thought.
<tritium> LaserJock: I'm sure I am quite rusty :)
<LaserJock> tritium: well, I'm in the middle of writing papers/dissertation and getting things finished off
<LaserJock> but I can do a fair amount of sponsoring
<tritium> LaserJock: I completely understand :)
<\sh> somerville32, I noted something...after all the package looks ok for me, just fix those direct build-deps...
<rexbron> http://revu.tauware.de/details.py?package=ubuntustudio-controls
<rexbron> opps
<rexbron> Need the pitch first
<rexbron> If someone has time for a review I would really appreciate it :) http://revu.tauware.de/details.py?package=ubuntustudio-controls
<rexbron> hey Hobbsee
<Hobbsee> hiya!
<LaserJock> hi Hobbsee
<Hobbsee> LaserJock!
<StevenK> PONI .... Oh, damn.
<LaserJock> StevenK: heh
<LaserJock> so was I the one that got the complex or you? ;-)
 * StevenK shrugs
<jdong> crimsun: thanks (re: transmission)
<LaserJock> StevenK: how's work?
<StevenK> LaserJock: It's fine.
<\sh> why can't upstream follow rules..e.g. not editing directly aclocal.m4?
<LaserJock> \sh: rules?! what rules? :-)
<jdong> \sh: bu.. but it's open source! they can if they want!
<jdong> :D
<\sh> jdong, not if everything breaks after aclocal
<\sh> and not putting their local macros inside a dir which can be included via aclocal call
<LaserJock> detail details
<jonnymind> Goodnight to everyone.
<jonnymind> I sign off.
<\sh> LaserJock, well, if someone wants to rebuild the whole source he/she's fcked
 * RAOF tries to puzzle out why he suddenly needs to add "acpi=off" to his kernel parameters for all kernels.
<jdong> \sh: but why does anyone want to do that when they can just download the .autopackage, run it with sudo sh, and go!
<StevenK> RAOF: Because your machine doesn't like ACPI or Matthew Garret any more?
<LaserJock> heh
<StevenK> Garrett, even
<jdong> RAOF: have you seen the weather around here? contribute a watt or two towards warming the planet! sheesh!
<RAOF> StevenK: Apparently so.  Either 2.6.24-4 has messed with some bios stuff, or there's something wrong in initramfs-tools, because it's affecting previously-working kernels too. :(
<jdong> ok, /usr/share/dict/words really sucks for playing hangman
<\sh> somerville32, the reason why they ship gtk code inside their sourcetree is
<\sh>  * alternate GtkFileChooser implementations; no stability guarantees
<\sh>  * are made at this point
<\sh>  */
<zul> thats why you never reboot
<jdong> deuteronomistic
<jdong> hmm...
<jdong> is that a religious term?
<RAOF> I wonder if #ubuntu-kernel would like to hear about this.
<zul> RAOF: everyone is traveling on -kernel
<jdong> RAOF: have you looked in LP for a bug? usually people are fast to whine about these kinds of bugs
<zul> RAOF: best open a bug
<RAOF> jdong: Yeah, I've looked at LP and nothing seems to fit.
<\sh> RAOF, well, I wonder why bugs in our kernel are getting fixed but without closing any bug report...
<RAOF> Aww, man.  /apps/metacity/general/application_based has the sounds awesome, right up until you read the final words of the long descripiton: "largely unimplemented ath the moment" :(
<\sh> I wonder which package it was about the new way of understanding pushd and popd (see Lucas Nussbaums Blog Article) ;)
<\sh> ok now to bned
<\sh> aeh bed
<\sh> good night :)
<RAOF> If anyone's interested in the travails of my poor laptop, bug #184712 is the good stuff.
<ubotu> Launchpad bug 184712 in linux "[regression] Asus F3Jm fails to work correctly without acpi=off" [Undecided,New] https://launchpad.net/bugs/184712
<LaserJock> hmm, so maybe we should retire dgetlp
<LaserJock> from ubuntu-dev-tools
<Hobbsee> it doesn't work for ppa
<jdong> LaserJock: what does dgetlp do?
<jdong> LaserJock: is it the same thing as my lpget script?
<LaserJock> jdong: you have a lpget script?
<jdong> LaserJock: yeah, a simple ruby script that scrapes LP
<LaserJock> LP is dgettable now so we shouldn't need to bother
<jdong> LaserJock: well you still need to scrape to determine what to dget, right?
<LaserJock> no
<LaserJock> oh, well kinda
<LaserJock> I mean it's the same as Debian
<LaserJock> you need the url of the .dsc
<jdong> LaserJock: like if I wanted Gutsy's libfoo...
<jdong> I still need to find the URL to it, right?
<jdong> by scraping +source/gutsy/libfoo?
<LaserJock> well, you can create the URL
<pochu> jdong: add deb-src for gutsy and apt-get source it ;)
<LaserJock> pochu: that's often not what you want
<jdong> pochu: well then you add a slow 5000kb file to each apt-get update run..
<jdong> pochu: and it's not always up to date
<jdong> pochu: as a backporter it's irritating I have to download like 30MB of sources files just to apt-get source :)
<pochu> I see.
<jdong> so for now I'm just URL mining LP
<jdong> until I have a more humane way
<LaserJock> I guess it's /ubuntu/<release>/+source/<package>/<version/+files/<package>_<version>.dsc
<Hobbsee> LaserJock: if that bug is fixed, probably
<jdong> LaserJock: <version> is the annoying one to build, wouldn't you say? :D
<LaserJock> jdong: yes, but it's easy from webUI
<LaserJock> which I guess it was more designed to do
<jdong> might as well regex for a dsc at /ubuntu/release/+source/package
<pochu> jdong: file a wishlist against python-launchpad-bugs :)
<LaserJock> that's not a very appropriate place to do that is it?
<pochu> LaserJock: it now has blueprints support, so why not package support? ;)
<LaserJock> although it might be the easiest for now
<LaserJock> pochu: because that's hackish
<LaserJock> ;-)
<pochu> LaserJock: I suggested to rename p-l-b to python-launchpad :)
<LaserJock> well wait
<LaserJock> the LP dget behavior is just the same as for Debian
<LaserJock> if you're gonna use dget for anything else you still need the .dsc URL
<LaserJock> so I think it's pretty consistent
<pochu> Sure.
<Hobbsee> so then there's a script required for .dscget
<Hobbsee> :)
<LaserJock> yeah
<LaserJock> the issue is not dget'ing but in an automatic way to find the .dsc
<jdong> wget https://edge.launchpad.net/ubuntu/hardy/+source/gtkpod/ -O- | sed -n 's/<a href="\(.*\.dsc\)">.*<\/a>/'
<somerville32> \sh_away: you posted your comment on my package twice. Just thought I'd let you know if you wanted to delete one
<jdong> that'll do it
<jdong> wow, irssi expands escape chars on input?
<jdong> that's retarded
<jdong> that's >/\\1/p
<jdong> err, single \
 * jdong tries to write a 1-liner script :D
<jdong> VICTORY
<LaserJock> :-)
<jdong> http://paste.ubuntu.com/3741/
<jdong> the nastiest one-liner in the word :D
<jdong> call like lpget gtkpod hardy
<jdong> don't ask me what it does with nonexistent packages or distros
<StevenK> Ewww
<StevenK> You should use $() instead of `` anyway
<jdong> StevenK: yeah yeah :)
<jdong> StevenK: that was just for fun... I have no intention of using this version :D
<joejaxx> jdong: haha maybe we should team up :) i have already written a number of launchpad crawlers lol
<LaserJock> joejaxx, jdong: if you guys could send me your launchpad screen-scrapers sometime I'd appreciate it
<gpocentek> \sh_away: then you need to B-D on gtk, libxfce* etc, and if I do is crap feel free to take care of the review
<gpocentek> if whwta I do*
<jdong> joejaxx: rofl what other kinds of scrapers do you use? :D
<joejaxx> LaserJock:  :D
<joejaxx> jdong: well no one could tell me where to get build logs
<joejaxx> jdong: so i built a crawler to download them
<joejaxx> loool
<joejaxx> lp-crawler buildlog <source\ package\ name\ here>
<joejaxx> LOL
<LaserJock> jdong, joejaxx: seriously though, I need to collect screen-scrapers
<jdong> joejaxx: haha
<jdong> LaserJock: what kind of scrapers, and what kind of quality level, what preferred language, etc
<LaserJock> jdong: doesn't matter, as long as you use it
<LaserJock> the point being, LP devs want to eliminate the need for screen-scrapers
<LaserJock> so I collect things that people actually use and get them to add that functionality, where possible
<jdong> LaserJock: the main kind of screenscraper is for dgetting the latest source package of a given distro
<jdong> LaserJock: so if they can have a static dsc URL, like /ubuntu/hardy/+source/gtkpod/+dsc, that'd be great
<jdong> I can poitn dget to that URL and have it fetch that
<jdong> should be relatively easy for the LP team to add
<LaserJock> yeah
<ScottK> It would be really nice if dget worked on Launchpad.
<jdong> LaserJock: and along those lines, I'd love to see a meta dget in ubuntu-dev-tools too :)
<jdong> LaserJock: I don't know exactly what that means, but I'd like to be able to track source packages in LP, packages.qa.debian.org, REVU, debian-multimedia, etc from a single utility
<LaserJock> ScottK: well, it does, as long as you get the .dsc URL
<ScottK> LaserJock: Not in my experience.  Let me give it a try
<LaserJock> ScottK: I had kiko add it relatively recently
<jdong> ScottK: yeah, if you grab a LP dsc URL now, dget will work with it now
<jdong> ScottK: unfortunately you still need to go hunt around LP's lightning fast interface to find that link :)
<LaserJock> oh, and you need --insecure if you don't have LPs cert
<jdong> apt-get install ca-certificates should suffice too
<jdong> and it's good to have anyway
<ScottK> Ah.  Well that's definitely progress then.
<jdong> indeed
<Megaqwerty> I had a (hopefully) quick question about cdbs. I was trying to package a program that used setup.py by using cdbs' python-distutils.mk (I'm assuming that was the right .mk file) and when I tried to debuild -S -sa the source, it gave me this: /usr/share/cdbs/1/class/python-distutils.mk:72: *** package uses the new Python policy; DEB_PYTHON_SYSTEM must be set to "pysupport" or "pycentral".  Stop.    Any idea what I did wrong?
<ScottK> Megaqwerty: You didn't tell it which to use.
<ScottK> Megaqwerty: Which are you using?
<Megaqwerty> ScottK: I'm not sure. It's not my program. I'll look into that though. When I do find out, do I just put that variable in debian/rules?
<ScottK> Yes.  It's a Debian packaging specific question, so if you're the packager, it's up to you to decide.
<ScottK> Megaqwerty: pyspf is a package you can look at for an example
<Megaqwerty> ScottK: oh. Where can I find out about the differences between the two?
<RAOF> And you might want to check up on the cdbs documentation, http://tinyurl.com/23x2xc
<Megaqwerty> thanks guys.
<nenolod> crimsun, i'm in the process of taking over bmpx in debian.
<nenolod> crimsun, thanks for the ubuntu patches. ;)
<nixternal> oi, the weekend is over...way to quick
<StevenK> nixternal: That's how it usually goes
<nixternal> shoot, all day I was stuck with LUG duties
<nixternal> yesterday, well that was to long ago, I already forgot what I did
<LucidFox> Hardy will ship with brasero and transmission by default? Awesome!
<wallyweek> g'morning all!
<wallyweek> could anyone please review sdlmame? http://revu.ubuntuwire.com/index.py
<wallyweek> could anyone please review sdlmame? http://revu.ubuntuwire.com/details.py?package=sdlmame
<LucidFox> wallyweek> no need to double-post :)
<wallyweek> LucidFox: right, when you post the right link ;)
<LucidFox> ah
<LucidFox> I see
 * wallyweek hopes irc@work works this morning or he won't be back until 6pm UTC :(
<warp10> Heya
<vemon> morning
<vemon> is there a tool to generate the debian/rules file?
<vemon> or some kind of a simple template for it?
<vemon> and by generating i mean with some user input :)
<LucidFox> vemon> dh_make
<LaserJock> vemon: not a reliable one
<LaserJock> and pretty much nothing for debian/rules specifically
<crimsun> unless you count cdbs, and even that's a bit of a stretch.
<LaserJock> hmm, that's somewhat a point
<LaserJock> although I would suggest that it's often gonna take more work
<LaserJock> but that's basically what cdbs is I suppose
<LaserJock> crimsun: you have MLK Day off?
<crimsun> LaserJock: no, I work later
<LaserJock> ah, too bad
<LaserJock> I'll be working on a paper/dissertation/presentation
<LaserJock> but it's kinda like time off
<crimsun> nah, I choose to.  Holiday pay is pretty nice.
<LaserJock> I bet
<LaserJock> I "get" to teach this semester
<AdamSun> hey everybody
<crimsun> LaserJock: fun!
<LaserJock> crimsun: it is, although it means I have to have some sort of schedule
<LaserJock> I'm also in charge of the department computer lab this semester
<AdamSun> i've been trying to fix a bug in a package... running into some trouble
<AdamSun> i made a fix.. but when i try to build with pbuilder it has errors
<AdamSun> this is my first attempt at packaging :)
<AdamSun> any help would be very much appreciated
<crimsun> AdamSun: a bit more verbose, please
<crimsun> LaserJock: indeed.  A schedule can be helpful.
<crimsun> AdamSun: (hint: we can't assist if we don't know what the error is...)
<AdamSun> sorry... I uploaded the output to the web
<AdamSun> http://paste.ubuntu-nl.org/52872/
<AdamSun> the problem with the package is that the desktop file is improperly installed
<AdamSun> so my attempt at a fix was to use the gnome.mk script from the cdbs
<crimsun> AdamSun: are you certain your pbuilder apt cache includes the universe component?
<AdamSun> no.. i'm not
<AdamSun> how would you go about that?
<crimsun> AdamSun: did you simply execute `sudo pbuilder create`?  By default, that does not add the universe component.
<AdamSun> i used sudo pbuilder build
<crimsun> AdamSun: no, before executing 'build'
<AdamSun> ahh.. yeah that is what i used
<crimsun> ok, so you need this:  echo COMPONENTS="main universe" >> ~/.pbuilderrc
<crimsun> (do that as your unprivileged user, of course)
<AdamSun> ok.. i will try that.. thanks
<crimsun> then, afterward, sudo pbuilder update --override-config
<AdamSun> i was just going to ask if i had to recreate or update :)
<AdamSun> ok.. wonderful it is working as it should now..  simple mistake it seems
<crimsun> good.
<AdamSun> ok.. ran into another problem.. sorry for the bother
<AdamSun> the deb gets built correctly.. or so it seems
<AdamSun> however when i open it with gdebi.. it says that Dependency is not satisfiable: libc6
<AdamSun> which seems very strange to me
<crimsun> are you running gutsy?
<AdamSun> yeah.. i was thinking that was the problem
<crimsun> then that's expected.  Your pbuilder is hardy.
<AdamSun> is there a proper way to test the package?
<crimsun> there are suggested methods; all involve testing in some sort of hardy install, chroot, vm, etc.
<AdamSun> i see
<AdamSun> chroot or vm seems like it'd be the easiest for me
<AdamSun> any personal reccomendation?
<crimsun> I use chroots or full-blown installs.
<AdamSun> ok.. i'll work on that.. thanks for all of the info
<jonnymind> Hello
<AdamSun> hello
<AdamSun> crimsun: I believe i got everything working.. and I think I solved the bug in the package as well
<jonnymind> I ask if someone may have a look at http://revu.tauware.de/details.py?package=falconpl
<jonnymind> Everythin should be fine now.
<LucidFox> Stupid Debian, always reinventing the wheel.
<LucidFox> Couldn't the qtcurve maintainer look at my packaging first? I think it was better. :/
<geser> good morning
<asabil> hi all
<asabil> anyone to review please : http://revu.tauware.de/details.py?package=libgee
<LucidFox> asabil> It's better to link to the specific LGPL version
<asabil> LucidFox: it is 2.1 or later
<asabil> so ...
<smarter> Can someone please review this package? http://revu.tauware.de/details.py?package=extremetuxracer
<LucidFox> since the copyright blurb in debian/copyright is for LGPL 2.1, consider linking to /usr/share/common-licenses/LGPL-2.1
<asabil> LucidFox: are you sure, because the /usr/share/common-licenses/LGPL is the one that conforms the most
<LucidFox> LGPL is a symlink, it currently points to LGPL-2.1 but it may change
<LucidFox> you can mention something like "LGPL-2.1 for version 2.1 or LGPL-3 for version 3"
<LucidFox> but it's not a blocker, I believe
<LucidFox> so feel free to leave it unchanged if you disagree
<asabil> LucidFox: It is not about agreeing/diagreeing
<asabil> I want to see this package accepted and that's all
<man-di> LucidFox: in Debian the package gets rejected when its ...or later and links a specific license like you say
<asabil> am not really very interested in packaging
<LucidFox> man-di> sorry then
<LucidFox> smarter> every package I've seen uses (LP: #xxx) rather than (Closes LP: #xxx)
<smarter> LucidFox: ok
<LucidFox> I'll write more
<geser> man-di: if a package build-depends on ibm-j2sdk1.6 in Debian is it safe to build it with sun-java6 (or is it sun-java5?) in Ubuntu?
<selckin> yes
<LucidFox> smarter> posted
<smarter> LucidFox: thanks
<man-di> geser: normally yes, but needs to be tested to be 100% sure
<man-di> geser: what package is it?
<TheMuso> c
<TheMuso> ugh wrong tab
<geser> man-di: libjibx-java
<man-di> geser: a patch to Debian would be cool
<LucidFox> geser> Does it build with icedtea?
<emgent> heya
<man-di> geser: as ibm jdk is not in archive
<LucidFox> jonnymind> looking at falconpl
<jonnymind> LucidFox: thanks
<geser> man-di: what would be the correct build-depends for Debian?
<man-di> e.g. sun-java6-jdk
<man-di> dont forget to adjust debian/rules to use that
<smarter> LucidFox: new version uploaded ;)
<LucidFox> smarter> ok, but IANAMOTU, so I can't advocate it :)
<LucidFox> (if I could, I would subject it to more thorough review)
<geser> man-di: nice, somehow I missed that Debian has now also the sun-java packages
<man-di> geser: since a long time
<man-di> geser: afaik at the same time as Ubuntu
<LucidFox> jonnymind> Commented
 * LucidFox pings dholbach
<dholbach> hi LucidFox
<LucidFox> You should probably write on the "Packaging from scratch" page in big bold letters: "This is only a demonstration of what occurs under the hood of debhelper, DO NOT USE THIS" :)
<LucidFox> otherwise we end up with a debian/rules like this: http://revu.ubuntuwire.com/revu1-incoming/falconpl-0801202000/falconpl-0.8.8/debian/rules
<dholbach> LucidFox: which page are you referring to?
<LucidFox> in the packaging guide
<jonnymind> LucidFox: I cannot understand.
<LucidFox> "Packaging from scratch", hello without debhelper
<LucidFox> jonnymind> What isn't clear? I'm happy to explain :)
<jonnymind> The comment on Packaging from scratch
<jonnymind> in irc
<LucidFox> ah... that's not directed to you :)
<dholbach> LucidFox: I made a note on my todo list, but it's a wiki after all, you could do the change too :)
<LucidFox> ah
<wallyweek> g'morning all!
<dholbach> LucidFox: thanks for letting me know
<jonnymind> LucidFox: Ic. are theese stoppers?
<LucidFox> jonnymind> Thiese are just my recommendations, I'm not a MOTU, so my reviews aren't "binding"
<jonnymind> I.c. Thanks; about level 4, I picked that becasue level 5 was warned by lintian...
<LucidFox> jonnymind> If you set "debhelper (>= 5) in debian/control, lintian wouldn't complain about compat 5
<jonnymind> Ah, I see
<jonnymind> thanks
<jonnymind> LucidFox: the document you pointed out as changelog doesn't open up; may you please provide another one?
<wallyweek> is revu ko to your knowledge?
<LucidFox> wallyweek> What do you mean?
<jonnymind> I have problems getting there too
<LucidFox> jonnymind> Basically, I just meant that the standard form for the initial debian/changelog is "Initial release (LP: #xxx)"
<jonnymind> IC
<jonnymind> Conforming.
<wallyweek> I can't reach it
<LucidFox> wallyweek> It's slow, yes
<wallyweek> LucidFox: ah, thanks
<jonnymind> LucidFox: I have cleaned typos and deb depends; about other debhelpers, I would prefer not to use them if this isn't a stopper.
<LucidFox> jonnymind> Why not? It's cleaner
<jonnymind> LucidFox: It's obscurer; especially to just copy files in the right place. And it would require me to recheck the whole build and install process.
<jonnymind> Last time I added a couple of debhelpers it didn't change the package and required me 8 hours to make them work.
<jonnymind> Maybe my fault, but as long as theese are not stoppers...
<LucidFox> Is upstream packaging that screwed up? o_O
<jonnymind> Eh?
<LucidFox> never mind :)
<jonnymind> No, it's the overall documentation that's missing.
<jonnymind> There's the policy which says how things should be, and there's the man pages that say how to use small tools.
<jonnymind> A big plan of how to do things right is missing. You learn it here by osmosis, but it requires a bit of time.
<jonnymind> And there's the wiki pages, with small samples that show how things are done, usually fail to explain why, and to help doing the harder (real-world) things.
<LucidFox> I see.
<LucidFox> It's partially the Packaging Guide's fault, it doesn't explain that debhelper is the preferred way. You could probably evade your problems if you started with a package generated by dh_make
<jonnymind> Which, btw, is said not to work with cmake.
<jonnymind> Also, falcon sources are kept on different source projects for administrative reasons.
<jonnymind> Different servers, different developers, different commit policy, different security.
<broonie> Well, it will generate a template for autofoo stuff but it's not particularly difficult to change for some othe rbuild system.
<jonnymind> So, the source package merges different repositories, having different build system, through a unifying builder.
<jonnymind> broonie: you know it. But it's not said in docs.
<jonnymind> Nor is said WHAT it does, exactly, and HOW it can fit non-autofoo needs.
<jonnymind> So, it is natural to avoid it when you're not in the simpe ./configure;make;make install case.
<dholbach> the 'reference packages' section could do with some beefing up :)
<jonnymind> It's just natural, as you'd have to study a different meta-tool and all its weirdness before even to decide that, hey, with a bit of tricks it could work also fro you...
<broonie> jonnymind: What documentation would you look for?
<broonie> An explanation of what each of configure, make, make install does might help...
<jonnymind> broonie: docs on debian packaging are missing all the time "context information". Which is what makes effective and productive a workflow, btw.
<jonnymind> It's managerial theory.
<jonnymind> Very non-IT. So I understand.
 * broonie always found the Debian documentation well above average :)
<cyberix> revu down?
<LucidFox> cyberix> No, just very slow
<jonnymind> It's fun how revu tends to get ill on revu days
<persia> LucidFox: Are you sure it's up?  I've not had a web page load for > 300 seconds, and while I can ping, interactive access also doesn't respond.
<LucidFox> Hmm... now it doesn't seem to load at all anymore
<LucidFox> persia, since you previously sponsored the qtcurve packages, could you please look at bug #183435?
<ubotu> Launchpad bug 183435 in kde4-style-qtcurve "Please sync gtk2-engines-qtcurve and kde-style-qtcurve 0.55.2-1 from Debian unstable (main), sponsor kde4-style-qtcurve 0.55.2-0ubuntu1" [Wishlist,Confirmed] https://launchpad.net/bugs/183435
<persia> LucidFox: You posted your tar.gz and links to the package to the ITP, right?
 * persia is annoyed at the removal of a known working get-orig-source
<LucidFox> yes, it was frustrating, the DD came out of nowhere after four months of absence and discarded all my changes
<LucidFox> I mailed them to him for possible merge
<persia> LucidFox: Is there nothing worth keeping in a merge?
<LucidFox> There are three changes that I consider an improvement over the Debian version: the get-orig-source script, the new FSF address in debian/copyright, and a cleaner way to invoke cmake in debian/rules
<LucidFox> but since they don't affect the build at all...
<persia> OK.  I think the address thing is a fairly important bug, and should definitely be in the BTS.  get-orig-source and cleaner rules are nice, but not so critical.  I'm still catching up on things, but will definitely look at this first in my queue.
<vemon> anything i should know before using cdbs for packaging? already know to avoid the auto generation of debian/control :)
<LucidFox> vemon> Did you read the CDBS section of the packaging guide?
<vemon> lucidfox, yes i did. and read some parts of the official cdbs docs too
<vemon> seems like a handy tool but i was wondering if there are any drawbacks
<vemon> (there always are :D)
<jonnymind> LucidFox: well, to be slow, revu seems a bit stopped:
<jonnymind> ####
<jonnymind> U 192.168.1.3:32776 -> 192.168.1.1:53
<jonnymind>   .............revu.tauware.de.....
<jonnymind> #
<jonnymind> U 192.168.1.1:53 -> 192.168.1.3:32776
<jonnymind>   .............revu.tauware.de..................sparky...-............(^
<jonnymind> ####
<jonnymind> T 130.239.18.172:6667 -> 192.168.1.3:44582 [AP]
<jonnymind>   :vemon!n=vemon@hoasb-ff03dd00-157.dhcp.inet.fi PRIVMSG #ubuntu-motu :+lucid
<jonnymind> This is a ngrep after having launced dput...
<geser> vemon: the only drawback with cdbs is that when you need something unusual you need to read deep into the docs or cdbs itself
<vemon> ok. thanks! at the moment my needs are so primitive that cdbs will probably do fine
<tarzeau> can i get some packages from debian synced to ubuntu?
<tarzeau> or is it still automatic?
<vemon> tarzeau, the automatic sync for hardy is already done
<vemon> you should request sync with a launchpad bug
<tarzeau> vemon: i don't know how to use launchpad, i used to just ping people on irc, but i lost my irssi window for it
<geser> tarzeau: what do you want synced from Debian?
<tarzeau> geser: ttf-marvosym
<geser> tarzeau: bug #184790
<ubotu> Launchpad bug 184790 in ubuntu "Please sync ttf-marvosym 0.1+dfsg-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/184790
<tarzeau> geser: thank you
<vemon> is it still possible to get new packages & patches in to hardy?
<vemon> i have a few coming this week
<persia> vemon: packages are permitted for a couple more weeks.  patches are permitted for a couple more months.
<vemon> ok. great :)
<vemon> so i should conscentrate on the new packages first
<amarillion> revu is completely down now...
<wallyweek> is revu day already ended?
<LucidFox> wallyweek> no
<LucidFox> (I think)
<LucidFox> just REVU happens to be down
<Hobbsee> siretart: any idea why it's down?
<jonnymind> ...
<jonnymind> revu is up again
<Hobbsee> feature freeze already?
 * Hobbsee tries to think what's new in the way of ubuntu feature development
<jonnymind> well, afaik none of the packages in the lis
<jonnymind> well, afaik none of the packages in the list has been uploaded...
<Hobbsee> i meant main, but true
<jonnymind> I uploaded a new version of http://revu.ubuntuwire.com/details.py?package=falconpl with issues fixed. Waiting for it to appare...
<jonnymind> Ok ppl; later
<slytherin> does anyone have any diea how stable is grub2 on PC platform?
<man-di> slytherin: hello
<mruiz> hi all
<slytherin> man-di: hi.
<man-di> slytherin: do you found a fix for lucene2 FTBFS? I team member can reproduce it in Debian too (I cant)
<slytherin> man-di: Is the error same?
<slytherin> man-di: I mean same as the one seen in ubuntu build logs?
<man-di> yes
<slytherin> man-di: I have the solution but that also needs a fix to w3c-dtd-xhtml package
<LucidFox> hmm, REVU is back up
<man-di> slytherin: what is the solution for lucene2?
<LucidFox> slytherin> Well, I used grub2 without any problems
 * sistpoty|work is away: coffee break
<persia> REVU is somewhat back for now.  Still experiencing issues.
<frafu> Hello, could anybody please review mousetweaks on motu: http://revu.tauware.de/details.py?package=mousetweaks ?
<TheMuso> frafu: Sure, I'll take a look.
 * Hobbsee attempts to ssh into revu
<zul> nooo...you are going to break it
<TheMuso> haha
<TheMuso> I just managed to pull a package form it with no problems.
<slytherin> man-di: Sorry I was away. A small patch to source and some packaging changes are needed to use DTDs from w3c-dtd-xhtml. The problem is that one of the unit tests tries to validate an xml using DTD on internet but since it doesn't get net access form inside pbuilder, the test suite fails with error.
<frafu> TheMuso:  Thanks; I hope mousetweaks will make it into hardy, because the gui of mousetweaks is shipped as the Accessibility tab of the Mouse control panel since GNOME 2.21.5.
<TheMuso> frafu: Nice. Hopefully we can also get included in Ubuntu proper in hardy+1.
<TheMuso> s/get/get it/
<wallyweek> Hello, could anyone please review sdlmame on revu? Thanks :) http://revu.ubuntuwire.com/details.py?package=sdlmame
<slytherin> LucidFox: Thanks for confirmation. Any visible changes from user's point of view?
<frafu> TheMuso: As soon as it is in Universe, I will write a main inclusion report.
<TheMuso> frafu: Ok.
<LucidFox> not really, still the same ugly text-mode menu
<LucidFox> even with gfxterm
<pochu> Is wiki.u.c down?
<LucidFox> pochu> opens for me
<persia> pochu: works for me
<amarillion> works for me
<man-di> slytherin: can you show me the changes you did?
<slytherin> man-di: Sure. I will paste debdiff somewhere. Give me 5 minutes
<TheMuso> iii/c
<pochu> whassup with freenode? :)
<mruiz> pochu, kernel panic ;-)
<broonie> There was a wall message about planned maintainance until (IIRC) ~1400
<zul> someone keeps tripping over the plug
<StevenK> broonie: 1400 sounds right
<slytherin> Hi all, how can I use some passphrase caching using seahorse so that I don't have to enter password every time I try to create source package?
<persia> slytherin: Configure seahorse-agent.
<jpatrick> pochu: some servers falling of the inet
 * jpatrick hides from persia's @
<persia> jpatrick: ?
<slytherin> persia: done now how to let debuild know to use agent?
<jpatrick> persia: op status ;)
<persia> jpatrick: I'm not sure how that happened.  Thanks for pointing it out.
<jpatrick> "07:04 ** ServerMode/#ubuntu-motu [+o persia] by irc.freenode.net"
<persia> jpatrick: What timezone?
<pochu> persia: you are opped for at least 15 hours ;)
<jpatrick> odd, must of been the split
<persia> Not if it was 15 hours.  I was in deep idle then.
<pochu> ( That's when I started irssi, and you were +o )
<jpatrick> happened ~30 minutes ago
<geser> slytherin: I only sign when I want to upload and don't sign during debuild or dpkg-buildpackage
<persia> Anyone good with IRC want to find who lives at LPuteaux-151-41-37-62.w217-128.abo.wanadoo.fr. ?
<zul> someone who is french? :0
<slytherin> geser: I am not sure if it will work for me. let's see. Anyway I got the caching working
<slytherin> man-di: Please check this debdiff - http://pastebin.com/m2a5afb22 It will only work if this bug us fixed - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=423087
<ubotu> Debian bug 423087 in w3c-dtd-xhtml "w3c-dtd-xhtml: path to entity sets is wrong" [Normal,Open]
<Kmos> persia: do whois 217.128.89.62 at console
<man-di> slytherin: what about including xhtml1-transitional.dtd temporaily in the package until the bug is fixed?
<geser> slytherin: I use it also as a safety guard to not accidental upload stuff
<persia> Kmos: Thanks.  Perhaps it's not a mistake by someone here then.
<amarillion> I think I fixed the problem with alex4 on 64 bit. I'm not running 64 bit though, so I can't confirm myself. Would somebody care to give it a try? http://revu.tauware.de/details.py?package=alex4
<slytherin> man-di: What about license mix up (?) and we will also need to include the entity sets and all other files that the DTD depends on. I would prefer the bug fixing. It is not that hard, the problem making a decision as to which way to fix it.
<man-di> slytherin: was just a short idea, I dont know much about this stuff
<slytherin> man-di: Can you push for the bug fix? :-)
<man-di> slytherin: I can try
<jpatrick> persia: they're probably all +i, so you won't see them
<Hobbsee> who *.151-41-37-62.w217-128.abo.wanadoo.fr
<Hobbsee> persia: there's no one on there from that IP
<persia> Hobbsee: That was what I found.  I was hoping someone just ran wget --mirror expecting that to be useful.  It seems it's something deeper.  Maybe it will stop soon.
<asabil> hi all
 * sistpoty|work is back
<geser> man-di: can you look at the changes to libjibx-java? http://members.ping.de/~mb/tmp/debian.debdiff
<LucidFox> amarillion> upstream is under GPLv2 or later, and the packaging is under GPLv3 only
<sistpoty|work> Hobbsee: do you have root@sparky?
<geser> man-di: is this debdiff acceptable for debian before I submit a bug?
<Hobbsee> sistpoty|work: yes
<LucidFox> amarillion> it's better to license packaging under the same conditions, so patches can be sent upstream
<Hobbsee> sistpoty|work: i'm currently playing with it, with persia
 * Hobbsee knows slightly more about apache now
<sistpoty|work> Hobbsee: can you blacklist that ip? (cannot login from work, since my work key still didn't get picked up with lpkeys)
<persia> sistpoty|work: That's the plan.
<sistpoty|work> :)
<slytherin> geser: Can you please make build depends as sun-java5-jdk. Thsi will make sure that program will run with both java5 and java 6. Also adjust 'Depends' and JAVA_HOME in rules accordingly.
<Hobbsee> sistpoty|work: yeah.  done that :)
 * Hobbsee watches the load drop
<sistpoty|work> Hobbsee: thanks
<geser> slytherin: sun-java5-jdk instead of sun-java6-jdk? or as an alternative?
<amarillion> LucidFox, ok, I'll change that
<amarillion> I thought you can't use sun-java5-jdk in build-depends
<man-di> geser: in general yes, but I wouldnt declare it as NMU from the start
<slytherin> geser: instead. it's like you may not be able to use program built with java6 with a runtime of java 5 (depends on ant build script). but you can surely use program built with java 5 with runtime of java 6
<amarillion> you definitely can't on ppa
<man-di> slytherin: sun-java6-jdk is IMO better
<man-di> slytherin: and the package needs to use target/source anyway
<amarillion> the automated build system of ppa doesn't work with sun-java5-jdk
<geser> amarillion: it should, at least for hardy
<man-di> geser: you see: two people, three opinions :-)
<amarillion> oh I'm glad it's fixed
<slytherin> man-di: yes but aren't we always in favour of maintaining backward compatibility. :-) So unless the program uses any java 6 specific feature it is better to build it with java 5
<man-di> slytherin: the source setting takes care of this
<man-di> slytherin: source/target setting....
<slytherin> man-di: Then it is ok.
<Hobbsee> right, revu is fixed.
<slytherin> geser: By the way, did you try if that package can be built using GCJ? Just curious. :-)
<zul> Hobbsee: yay
<persia> REVU is working again, thanks to Hobbsee and sistpoty.
<geser> slytherin: no, what need I change for testing?
<Hobbsee> and persia
 * persia only griped
 * Hobbsee is still incompetent with apache.
<slytherin> geser: build dependency as 'java-gcj-compat-dev' instead of any sun-java package
 * sistpoty|work only pressed one button so far *g*
<persia> It was an important button :)
<Hobbsee> it was the "this is how you fix it" button
<slytherin> geser: and run time dependency as java2-runtime. If the package builds with GCJ then it will run with any VM. And all JVM package 'Provides' java2-runtime. :-)
<geser> slytherin: and what set I JAVA_HOME_DIRS to?
<slytherin> geser: /usr/lib/jvm/java-gcj
<sistpoty|work> Hobbsee: heh, and the reset button g
<Hobbsee> yeah, that too
<slytherin> man-di: Going home. See you tomorrow.
<man-di> slytherin: have fun
<geser> man-di: should I use directly -2 as debian revision for the debian debdiff?
<man-di> geser: yes
<geser> btw: it doesn't build with gcj
<man-di> I will add more changes anyway
<geser> man-di: is http://members.ping.de/~mb/tmp/libjibx-java.debdiff enough for you or should I file a bug and attach it?
<yamal> MOTUs, an improved sabnzbd package is awaiting review @ http://revu.tauware.de/details.py?package=sabnzbdplus
<man-di> geser: please mail me personally: konqueror@gmx.de
<man-di> geser: with the debdiff attached
<civija> guys, can someone sponsor this please https://bugs.launchpad.net/bugs/184261?
<ubotu> Launchpad bug 184261 in slrnface "slrnface doesn't display X-Face header" [Undecided,In progress]
 * LucidFox wonders why everyone links to revu.tauware.de rather than revu.ubuntuwire.com
<Hobbsee> LucidFox: ubuntuwire was down for a while, and revu preceeded ubuntuwire anyway.
<yamal> and all mail from revu has links to tauware.de, not ubuntuwire
<LucidFox> ah
<LucidFox> yamal> commented
<yamal> LucidFox: tx
<RainCT> hey
<bddebian> Heya gang
<sistpoty|work> hi bddebian
<geser> Hi bddebian
<emgent> heya
<bddebian> Hi sistpoty|work, geser, emgent :)
<LucidFox> RainCT> Looks like your MOTU application is going to succeed :)
<LucidFox> 6 support voices so far
<RainCT> LucidFox: yes :D
 * RainCT is happy
<foolano> hi
<\sh> apachelogger_, check your revu libksquirrel :)
<\sh> apachelogger_, and please fix ;)
<apachelogger_> meh
<apachelogger_> KDE 4 ftw!
<\sh> apachelogger_, nix fix it and let's get it out of revu
<\sh> apachelogger_, revu day now
 * apachelogger_ notes that wednesday would be a much better revu day
<TheMuso> c
<TheMuso> ugh
<cyberix> dh_clean doesn't remove substvars?
 * apachelogger_ restricts the build of ksquirrel to i368
<cyberix> I now use dpkg-shlibdeps to create substvars.
<apachelogger_> uhhhhhhh, god I hate that man page policy
<apachelogger_> as if any normal user would have a look at the manpage
<cyberix> Should I have a substvars template in my package or should the file be created by dpkg-shlibdeps?
<bddebian> cyberix: Let debhelper create it
 * LucidFox wonders if anything is going to clean up NEW today
<LucidFox> * anyone
<cyberix> bddebian: dh_shlibdeps is in some way equivalent to dpkg-shlibdeps?
<LucidFox> cyberix> it's a wrapper
<LucidFox> around dpkg-shlibdeps
<TheMuso> frafu: Comments left.
<frafu> TheMuso: thanks
<TheMuso> frafu: You're welcome, I really want to see us get this in.
<\sh> anybody using eclipse with pydev as IDE?
<LucidFox> I periodically see binary packages named something like "libfoo1c2"
<LucidFox> what does c2 mean?
<slangasek> "C++ ABI verision c2"
<cyberix> http://revu.tauware.de/revu1-incoming/malbolge-0801211640/malbolge-0.1.1/debian/copyright
<cyberix> Does this look ok?
<\sh> if  a package on revu has two advocates...it can be uploaded, right? who is doing the upload the last advocator?
<LucidFox> \sh> depends
<Hobbsee> \sh: usually, i think
<Hobbsee> unless there's an agreement otherwise
<sistpoty|work> \sh: yes, than it can be uploaded, but one of the advocates should do it (at least I wouldn't upload s.th. I didn't review myself)
<sistpoty|work> s/than/then
<\sh> sistpoty|work, that's what I mean..the last advocator can do the upload....
<sistpoty|work> \sh: sure
<\sh> ok mmdb uploading
<frafu> TheMuso: In one comment in the mousetweaks review you say to use Standards 3.7.3. In debian/control, Standards is already 3.7.3. Do I have to set it elsewhere, too?
<\sh> gpocentek, ping
<TheMuso> frafu: Hrm hang on, let me have a look. i don't know how that came about.
<TheMuso> frafu: Ok you're right. I think I was looking at an older revision of the package. Don't mind me. :p
<frafu> TheMuso; ok.
<asabil> anyone to review : http://revu.tauware.de/details.py?package=libgee ?
 * apachelogger_ throws http://revu.ubuntuwire.com/details.py?package=libksquirrel at \sh
<\sh> apachelogger_, give me some mins..need to check flpsed ,-)
<\sh> sistpoty|work, new upstream addressed all our changes btw of flpsed
<apachelogger_> pffft
 * apachelogger_ scuttles off to read latest issue of linuxuser
<\sh> apachelogger_, added the man page?
 * ScottK does  a victory dance.
 * ScottK has working versions of all relevant packages on Dapper for a clamav backport of the current version.
<gpocentek> \sh: pong
<TheMuso> ScottK: Nice.
<\sh> gpocentek, http://revu.tauware.de/details.py?package=thunar-svn-plugin why do you think direkt-build-deps are not necessary?
<frafu> TheMuso: I just uploaded the corrected version: http://revu.tauware.de/details.py?package=mousetweaks
<gpocentek> \sh: like I said, it's brought by the othe B-D
<gpocentek> other*
<TheMuso> frafu: Thanks, I will have a look shortly.
<\sh> gpocentek, but what when a build-dep package changes the deps to not include a direct-build-dep anymore? let's say libdbus-dev is removing pkg-config from it's package because they are using something else ... this package  which indirectly-depends on it would FTBFS it
<frafu> TheMuso: thanks
<gpocentek> \sh: why? if dbus-dev doesn't use pkg-config anymore, the thunar plugin will not use it either
<\sh> gpocentek, hehe...but it needs it
<\sh> gpocentek, not dbus-dev but pkg-config ;)
<gpocentek> \sh: I need to have an other look but doesn't it need pkg-config to get compilation flags of dbus?
 * LucidFox is worried by the sudden emergence of packages using the (Closes LP: #xxx) syntax. Where did they even find it/
<gpocentek> anyway keeping it in B-D is not such a bug problem
<gpocentek> big*
<cyberix> I'm looking after first advocate for my package Malbolge. I've fixed all broblems that have been brought up. http://revu.tauware.de/details.py?package=malbolge
<\sh> gpocentek, nope...it needs it for their aclocal.m4 stuff to check if a package is there or not...the same applies for GTK and friends
<gpocentek> \sh: you're certainly right
<\sh> gpocentek, that's why I was wondering that you think, not having direct-build-deps noted in control...
<gpocentek> \sh: pkg-config is usefull to get the compilation conf for libs
<gpocentek> so it needs to be a dep of the -dev packages IMO
<gpocentek> but again, you're certainly right
<\sh> apachelogger_, why didn't you add ghostscript to the build-deps?
<\sh> apachelogger_, and netpbm check fails too ;)
<apachelogger_> \sh: doesn't work, there is an issue in the detection system
<\sh> apachelogger_, elaborate?
<sistpoty|work> \sh: excellent about flpsed :)
<\sh> sistpoty|work, requested a sync
<sistpoty|work> :)
<apachelogger_> \sh: nah, ain't worth it... upstream will take care of this, once I get hold of him ;-)
<\sh> apachelogger_, and don't advocate your own packages ;)
<apachelogger_> \sh: persia told me to, apparently it appears rather strange when I don't advocate my own package ^_^
<\sh> anyways looks ok...advocated...
 * apachelogger_ uploads
<apachelogger_> \sh: can you archive?
<\sh> apachelogger_, done
<apachelogger_> \sh: thanks for your time :)
<\sh> TheMuso, did you upload "jaaaa"?
<\sh> make it -a ;)
<\sh> TheMuso, got it...
<TheMuso> \sh: yes I did. I know it technically should have gotten a second advocate, but the changes to the latest upload were to address Peris'a comments, which weren't blockers.
<\sh> TheMuso, it had two ads anyways...at least one for the first upload ,)
<TheMuso> Yeah I know
 * LucidFox looks at the growing NEW apathetically
<TheMuso> Lure: It will be checked. Don't panic.
<TheMuso> LucidFox: even
<LucidFox> heh
 * sistpoty|work needs to go
<sistpoty|work> cya
<frafu> TheMuso: I just did an error and uploaded a wrong version to revu; the correct version is the version that I uploaded January 21 17:20
<TheMuso> frafu: Ok.
<\sh> guys, anyone who is using hardy + eclipse + pydev (gcj variant) could you check this out: have a python source opened, do a Ctrl+L (goto line) enter a line number and jump there and then do something else like editing etc. is eclipse closing unexpectedtly?
<pochu> StevenK: did you forward the liferea hildon patches upstream?
<TheMuso> pochu: You likely won't get a response from him for another 5 hours at the least.
<pochu> TheMuso: it can wait, as long as he answers :)
<TheMuso> pochu: Fair enough. I just couldn't remember whether you idle or not.
<vemon> could someone point out my mistake in this debian/rules file: https://ukuti.mine.nu/temp/rules
<vemon> when i build the package it doesn't include the binary though it's built
<vemon> and i only have one Makefile which just builds one binary
<vemon> this is the first package i've made from scratch so i'm a little bit confused about what to try next :)
<geser> vemon: check the contents of the subdirs in debian and check the contents of the debian/pkgname.install file
<geser> vemon: btw your certificate expired
<vemon> well i was just too lazy to type in my password :D the cert should be fine
<vemon> the debian dir contains two dirs after "dpkg-buildpackage": 1. lash-wrap (contains docs) 2. tmp/bin (contains the binary)
<geser> vemon: lash-wrap is the package name?
<vemon> yes
<cyberix> Does revu have a freeze for new packages before the actual FeatureFreeze?
<vemon> the lash-wrap dir actually has /usr/share/doc/lash-wrap -dir which has README
<geser> have you a lash-wrap.install file listing which files belong to it? see man dh_install
<geser> cyberix: no, you can still upload packages to revu after FF but don't expect them to get reviewed timely
<vemon> no i don't have that file (.install)
<vemon> hmm... actually it seems the contents of debian/lash-wrap get installed when installing the built .deb
<vemon> so maybe i have to change the rules file to set PREFIX to $(CURDIR)/debian/lash-wrap
<vemon> the PREFIX parameter which is used in the Makefile
<vemon> geser, now it seems to create a working package when i changed the install PREFIX. but should i still care for the .install file you mentioned?
<vemon> don't want my package to get rejected :)
<geser> the reviewer will tell you, but right of my head it should be ok
<cyberix> geser: Actually I was more worried about new packages going past my package in line.
<cyberix> :-)
<cyberix> But revu isn't a line of course. It is actually more of a
<cyberix> well
<cyberix> never mind
<vemon> is it ok for a package name to contain an underscore (_) ?
<vemon> since the binary built is named lash_wrap it would be consistent to have a package called lash_wrap
<geser> vemon: no, as _ is the seperator between the components in the filename
<vemon> geser, well that's what i thought :)
<vemon> i'll use - instead
<cyberix> vemon: how about lashwrap
<cyberix> if you have to change it anyway
<vemon> cyberix, maybe i'll do it like that then
<vemon> is there a problem if the original source (.orig.tar.gz) unpacks to a different directory than <packagename>-<upstream version>?
<vemon> in this case the package name is lashwrap but the original source unpacks to lash_wrap-0.8
<ion_> No. dpkg-source ignores the name of the topmost directory when unpacking it.
<vemon> ok. great! thanks :)
<vemon> smart move from dpkg-source :D
<blueyed> Where should I install icons so that they get used for the desktop file?
<_MMA_> blueyed: /usr/share/pixmaps is a common place.
<blueyed> _MMA_: thanks, it's probably just plasma which does not get it anew after I've moved it there.
<_MMA_> np
<blueyed> Which resolution should I chose (.png)? 16, 32, 48, 128 - no svg..
<_MMA_> 128 is common but might look weird @48 if the detail is too high.
<blueyed> Do I have to quote the whole "Creative Commons Attribution-ShareAlike 2.5 License Agreement" in debian/copyright?
<geser> blueyed: yes, as it isn't included in /usr/share/common-licenses
<blueyed> ok, but it's really long.. but that's life.. ;)
<blueyed> for the copyright: do I have to cite the different copyright holders for all source files? e.g. main package is (c)foo, but ./src/util/io/NtpMessage.java is (c)bar - (both are gpl2+).. so I must list this special?
<geser> yes
<blueyed> well, this looks to get nasty then.. ;)
<jonnymind> Hello all.
<jonnymind> I am in search for advocates on http://revu.tauware.de/details.py?package=falconpl
<jonnymind> is there anywhere else I should notify the upload and advocate request?
<cbx33> where can I find the latest packging guide?
<vemon> why do i get "dpkg-genchanges: not including original source code in upload" when running "debuild -S" and what does it actually mean?
<vemon> what is it referring w/ "upload"?
<geser> vemon: that only .dsc and the diff.gz is listed in the .changes file and uploaded
<geser> when you actually upload it e.g. with dput
<vemon> how can i include the original source? that's probably necessary when uploading to revu?
<geser> debuild -S -sa
<vemon> thanks!
<blueyed> We need more licenses in /usr/share/common-licenses I'd say..
<wallyweek> hello, could anyone please review sdlmame? thanks! :) http://revu.ubuntuwire.com/details.py?package=sdlmame
<LaserJock> afternoon MOTU Land
<bddebian> Heya LaserJock
<geser> Hi LaserJock
<LaserJock> wow, lots of REVUing done yesterday
<LaserJock> hi bddebian, geser
<LaserJock> phew, quite a lot left though :/
<jonnymind> Including mine :_(
<jonnymind> Switching on my main pc. Later.
<LaserJock> jonnymind: but you didn't tell use which package was yours ;-)
<jonnymind> :-) Sorry
<jonnymind> falconpl on revu
 * \sh is off
<blueyed> JFI: please don't review tvbrowser yet. /me is still in the licensing jungle..
<LaserJock> jonnymind: ahhh, right. the "famous" falconpl ;-)
<LaserJock> jonnymind: how is it going in Debian?
<jonnymind> Well, the package is the same.
<jonnymind> Just, with the 0ubuntu stripped off.
<LaserJock> jonnymind: yes, but the falcon namespace issue
<jonnymind> The ones having taken a look at it said it was ok, but debianers seems less strict than motus in judgment.
<LaserJock> it depends on the Debianers
<jonnymind> I said once the falcon namespace was decided I would have renamed falcon to falconpl in debian; so I did.
<jonnymind> I have the agreement of ppl involved that they won't upload falcon in debian till the file name clash is resolved, so I renamed the package.
<LaserJock> hmm, I was hoping it would be resolved in Debian since we sync our packages from them
<jonnymind> well, the issue raised here. Of all distros, I picked the only one having a guy with a project, still unpacked, but with the same name.
<jonnymind> If I started from debian, this all would just have never happened.
<pochu> LaserJock, jonnymind: ScottK ITP'd Seveas' falcon repo, and has renamed /usr/bin/falcon to /usr/bin/falcon-start to avoid the clash
<jonnymind> yes, so it seems we have an agreement. My package is named falconpl, his binary is named /usr/bin/falcon-start (a -start thing cannot be possibly confused with something concerning a scripting language).
<jonnymind> So, as things seems have been sorted out, I am searching for advocates...
<LaserJock> cool
<cbx33> hey hey LaserJock
<cbx33> howz it going
<LaserJock> woah! ghost from the past! ;-)
<LaserJock> hi Pete
<smarter> hi
<smarter> could someone please review my package? ;) http://revu.ubuntuwire.com/details.py?package=extremetuxracer thanks!
<blueyed> debian/copyright only applies to source, correct? So if there's a .jar/library in the source package itself, do I need to include copyright/license info in debian/copyright?
<LaserJock> blueyed: debian/copyright needs to account for all files in the source package
<jpatrick> blueyed: yes, all
<smarter> I can't recover my password in revu :/ http://revu.ubuntuwire.com/lostpw.py?email=smarter@ubuntu.com is empty
<geser> blueyed: and the jar should be rebuild so it's known that it builds and matches the source
<blueyed> geser: rebuild? no, most of them are only shipped, without any source..
<geser> blueyed: bad
<blueyed> For quite a lot of the libraries it's (partial) missing. E.g. there's a poi_license.txt file, but no copyright around?! :/
<blueyed> too bad, yes.
<jpatrick> smarter: debian/copyright should say which version of GPL the package is licensed under
<geser> blueyed: or do you plan to put it into multiverse (if the jars are redistibutable)
<vemon> i now have a [needs-packaging] bug and have successfully created the source package, built it in pbuilder and it seems to work when installed. is the next step to upload it to REVU?
<vemon> or should i attach the source package to the launchpad bug?
<jpatrick> vemon: REVU
<vemon> ok!
<smarter> jpatrick: seems to be under gplv2, I just have to s/, or (at your option) any later version.//g ?
<jpatrick> smarter: it just says: "is licensed under GPL" you must be specific, archive admins won't "seem to think" :)
<jpatrick> smarter: "under the GPL version 2 of (at your option) any later version." :)
<smarter> COPYING contains gplv2 so I assume that's the license
<jpatrick> smarter: I mean the Debian packaging part
<smarter> jpatrick: oh, ok
<smarter> but /usr/share/common-licenses/GPL links is gplv2
<blueyed> bleh.. there are files licended with "Common Public License Version 1.0", which is incompatible to GLP.. therefore I think I can stop packaging until this is resolved upstream, correct?
<smarter> can I put my debian packaging under gplv2+ ?
<jpatrick> smarter: yes
<smarter> ok
<jpatrick> smarter: package looks good apart from that
<blueyed> smarter GPL links to v3 on Hardy.
<smarter> jpatrick: thanks
<amarillion> Hi there. My packages http://revu.tauware.de/details.py?package=alex4 and http://revu.tauware.de/details.py?package=speed-game are ready for review please!
<amarillion> I've fixed the 64-bit hang bug in alex4
<smarter> jpatrick: uploaded ;)
<jpatrick> smarter: hmm, I promise to look at it tomorrow, it's too late right now
<smarter> jpatrick: okay, I think I'm going to go to bed too ;)
<jpatrick> smarter: bonsoir! :)
<smarter> jpatrick: buenas tardes ;)
<jpatrick> noches*
<smarter> bonne nuit* :P
<stgraber> Gute Nacht :)
<stgraber> any other language ? :)
<jpatrick> bona nit
<Adri2000> good night? :)
<jonnymind> oyasumi nasai?
<rexbron> Hey everyone! Got one ack and looking to double up :) http://revu.tauware.de/details.py?package=ubuntustudio-controls
<bddebian> persia: You up yet? :)
<jscinoz> where is ubuntu's libjpeg62 stored?
<geser> I've /usr/lib/libjpeg.so.62 in libjpeg62 (hardy)
<jscinoz> alright cheers
<persia> \sh, apachelogger: About self-advocation.  I only think this is useful when the packager (who is also a MOTU) is sure (as with something that has everything fixed).  It oughtn't be done for an early upload.
<persia> cyberix: Last scheduled REVU day is 4th February.
<rulus> I updated gtkvd yesterday (http://revu.ubuntuwire.com/details.py?package=gtkvd), please review, I'd really like to have it in the archive for Hardy.
<jscinoz> how would i change this makefile http://pastebin.ubuntu-nl.org/52935/ to use ubuntu's libjpeg62 rather than compile its own?
<james_w> jscinoz: first guess, delete lines 1715-1716
<ryanakca> how would one merge a package into the other? Would that mean take two packages and combine them into one?
<mok0_> jscinoz: It will take major surgery on the makefile
<jscinoz> >_<
<bddebian> persia: Hey, wtf man? :-)
<james_w> jscinoz: and then you probably need to add -ljpeg62 to one of the LDFLAGS, but I don't know which actually needs it.
<persia> bddebian: ?
<mok0_> jscinoz: perhaps you can try to delete $(JPDIR)/*.c from line 1715
<james_w> ryanakca: these are packages already in Ubuntu? They are built from the same source?
<jscinoz> hmm
<bddebian> persia: You are ignoring me :)
<persia> Hi bddebian!
<bddebian> persia: j/k.  Did you say you have wx2.6 patches for survex and trustedsql?
<mok0_> jscinoz: This is one of the most spaghettish makefiles I have ever seen. Geeez
<persia> bddebian: No.  I don't remember the trustedsql solution: I'll track it down.  I was working on some survex patches with upstream, but got distracted some months back.
<ryanakca> james_w: yes and no
<bddebian> persia: You're fired ;-P
<ryanakca> james_w: *figured it out*
 * persia demands appropriate notice and severance pay
<bddebian> hehe
<bddebian> persia: Somehow I've gotten tasked with tracking wx2.4 removal in Debian :-)
<persia> bddebian: I thought you might :)
<persia> bddebian: The solution for trustedqsl (*not* sql) is just to change the build-deps.  At least that's how I did it for gutsy.
<jscinoz> mok0_ i didnt make the makefile, its from upstream >_<
<mok0_> jscinoz: I figured
<mok0_> jscinoz: otherwise you wouldn't be asking :-P
<bddebian> persia: Ah nice, thx
<persia> bddebian: for survex, upstream is picky.  They don't want any WX getting into the engine, but only for display.  The main issue is that the porter has to understand the API between the engine and the interface well enough to do the casts at the right points.  I'm not convinced upstream will stay with WX, but it's a lot of work to port to something else.
<mok0_> ScottK: good you nailed that avscan! Congrats
<persia> So survex-aven should depend on WX, but survex itself would only use the standard C libraries.
<jonnymind> ppl, is someone planning to have a look on falconpl in this REVU day? -- otherwise I am going to log off and have some sleep...
<jscinoz> mok0, simply removing all lines referencing libjpeg, and remove it from the source, it seems to still compile and run
<jscinoz> >_<
<persia> jonnymind: There's been lots of REVU activity today (more than for many past ones).  If your timezone calls for sleep, check the package status when you wake.
<bddebian> persia: Oh joy
<jonnymind> persia: thanks. I need a bit of sleep, just I wanted to help in case of troubles.
<jscinoz> this is really strange >_<
<persia> bddebian: Yep.  That's part of why I got bogged down.  freqtweak took me about a week, and I expected the same for survex until I was in contact with upstream about it.  There was also another interested party: I'll dig up some mail and forward it.
<jscinoz> either libjpeg62 is optional for the game engine, or it's automatically finding the system provided one
<bddebian> persia: You ROCK man
<mok0_> jscinoz: What's in Makefile.local?
<jscinoz> one sec.
 * persia has been ignoring WX for eight months, and thinks that's a bit of time between downbeats to be called "rocking".
<jscinoz> there isn't one?
<RainCT> was there a users clean-up or something on REVU? (it says my email isn't in the database..)
<jscinoz> jmemdos.c builds jmemdos.o right?
<jscinoz> argh
<RainCT> well, anyways, how can I get a new account? just upload some crap or is there a better way? :P
<persia> RainCT: When did you previously create your account?
<RainCT> persia: last summer :P
<blueyed> RainCT: then you need to reupload something.. :)
<persia> RainCT: Ah.  All the accounts were wiped in September or so.
<RainCT> ah ok
<persia> RainCT: Do you want an account to upload, or to comment?
<RainCT> to comment
<jscinoz> why is it so important that it uses the ubuntu included libjpeg instead of compiling its own?
<persia> No need to upload something then.  @ubuntu address?
<RainCT> yes :)
<blueyed> jscinoz: for security/performance/space..
<jscinoz> i have no idea how to rework this makefile to make it work >_<
<blueyed> jscinoz: change the call to configure?
<jscinoz> it doesnt have a configure >_<
<LaserJock> jscinoz: pastinbin'ing the makefile or relevant files might help
<jscinoz> already did, its at  http://pastebin.ubuntu-nl.org/52935/
<mok0_> jscinoz: on line 44 and 1912 that makefile includes some others that may have important clues
<jscinoz> there isnt a makefile.local to include and ill have a look at the other thing
<azeem> jscinoz: you're supposed to write on on your own if you disagree with the upstream defaults, AFAICT
<jscinoz> >_<
<azeem> one*
<jscinoz> ahh crap
<jscinoz> that was the wrong makefile, thats the server one >_<
<jscinoz> ill pastebin the correcto ne in a sec, firefox decided to segfault again
<jscinoz> alright heres the makefile http://pastebin.ubuntu-nl.org/52941/
<jscinoz> :(
<RainCT> good night
<jonnymind> Good night, people.
<blueyed> jscinoz: can't you use Makefile.local? Tried setting JPDIR or something else to use the shared library? Otherwise just removing the included one before building might help (at first)
<jscinoz> where is the shared library located
<azeem> jscinoz: just autotoolize the thing
<jscinoz> i see that it later references numerous .o files related to libjpeg and i'd assume these are source?
<jscinoz> autotoolize?
<mok0_> autoscan
<azeem> jscinoz: well, I wasn't serious.  Autotoolizing is the verb for porting a build system to autoconf/automake/libtool
<jscinoz> oh
<jscinoz> are the libjpeg *.o files included somewhere in /lib?
<jscinoz> or /usr/lib
<mok0_> jscinoz: nope
<jscinoz> thoguht so
<jscinoz> because the only file i can find included are the libjpeg.o.62 etc
<jscinoz> .so*
<jscinoz> and the make file wants a whole bunch of *.o's
<emgent> heya people
<mok0_> jscinoz: you need the -dev package
<jscinoz> ah.
<mok0_> jscinoz: it has header files and devel libs
 * jscinoz feels stupid.
<jscinoz> strange...
<jscinoz> i already have libjpeg-dev and libjpeg62-dev
<ScottK> mok0_: Thanks.
<mok0_> ScottK: good idea to replace that .c file
<jscinoz> the commenter on revu said " static copy of system library: please change the upstream Makefile to link against Ubuntuâs libjpeg62 instead of using the static copy inside the sources" wouldnt using the headers from the -dev package be just as bad?
<mok0_> jscinoz: the headers are just used when the source is compiled
<ScottK> mok0_: Looking at it, it didn't seem to do anything but talk to clamav, so as long as I added the appropriate #ifdef, it seamed likely to work.
<jscinoz> in the libjpeg source included with the upstream package, it has a number of headers that dont seem to be included in libjpeg62-dev...
<jscinoz> is this going to be a problem?
<mok0_> ScottK: ha!
<geser> jscinoz: this could be internal headers which programs using that lib shouldn't use
<mok0_> jscinoz: not necessarily. Those headers may not be part of the exposed interface of the library
<jscinoz> hmm alright gonna try build again here goes :)
<jscinoz> argh
<LaserJock> ScottK: evening
<jscinoz> this isnt gonna work
<jscinoz> if you look at the makefile i pasted, when it changes to JPDIR it just builds every thing it finds, so if i gave it /usr/include where libjpeg62-dev puts its headers it wouldnt work >_<
<ScottK> Good evening LaserJock
<blueyed> Is the "Creative Commons Attribution-ShareAlike 2.5 License" (CC-BY-SA) compatible to GPL? Or doesn't it matter because icons are not code/documentation (for distribution)? It's about tango and shipping it with a java package which is mostly GPL.
<mok0_> jscinoz: that's right.
<mok0_> jscinoz: there is no indication in that makefile where libjpeg is being linked into the source
<LaserJock> blueyed: hmm, I'm not really sure. I think there may have been packages rejected for that but it could have been just that they didn't properly include the CC-By-SA part
<LaserJock> blueyed: I don't think the GPL and CC-By-SA are compatible
<blueyed> LaserJock: that's difficult, yes. http://www.gnu.org/licenses/license-list.html says so for 2.0 (but it's 2.5 and 3.0 is current). Also it only says to not use if for code/doc.
<blueyed> There's another icompatibility (CPL 1.0) anyway (with code) and we might get away by depending on the tango-package and only ship new/additional or changed icons. "changed" may become difficult again though..
<LaserJock> blueyed: you might do some searching of ubuntu-motu and ubuntu-devel{-discuss}
<LaserJock> blueyed: or maybe ask an archive admin
<jscinoz> mok0_ what should i do, im completly lost now >_<
<jscinoz> hmm, what is a .o file?
<jscinoz> is it source, or a compiled thing
<mok0_> jscinoz: Hmm, what you are trying to accomplish is not easy. Your skills are perhaps not quite up to the task I am afraid
#ubuntu-motu 2008-01-22
<mok0_> jscinoz: the .o file is the compiled files, they need to be linked to generate the program
<LaserJock> it's an object file
<jscinoz> and these are not included with libjpeg62-dev?
<LaserJock> no
<LaserJock> .o files get linked to create the program
<mok0_> jscinoz: well, they are assembled into a library
<LaserJock> .so are what would be shipped in a library
<jscinoz> alright, so when someone says " static copy of system library: please change the upstream Makefile to link against Ubuntuâs libjpeg62 instead of using the static copy inside the sources" what do i need to change the make file to reference? the headers? the actual source or what?
<mok0_> jscinoz: the makefile, in principle
<jscinoz> >_<
<jscinoz> ok.
<jscinoz> so.
<LaserJock> you want it to build against the headers I believe
<mok0_> jscinoz: it looks like the program gets linked to the set of .o's from the jpeg subdir
<jscinoz> included with the upstream package is libjpeg source, ie .h and .c, it builds these into a bunch of .o it needs to compile, now the libjpeg62-dev package contains no .c, and only a few headers compared to those in the upstream
<mok0_> jscinoz: yes, and those headers are being included by other parts of the source
<jscinoz> so... in the makefile, i've commented out where it compiles libjpeg from the source in the .c files.
<mok0_> jscinoz: you need to define to the compiler where to find those headers (if not in the subdir), and also where to find the library
<jscinoz> /usr/lib/libjpeg.so.62 yes?
<mok0_> the first is usually with a -I switch, and the latter with a -ljpeg switch to the linker
<mok0_> jscinoz: yes, that's the one that replaces the .o files
<jscinoz> oh
<mok0_> jscinoz: i.e. gcc -I/usr/include program.c -ljpeg -o program
<jscinoz> so instead of the multitude of .o files on line 1000-1033, i just need the one .so?
<mok0_> jscinoz: yup
<jscinoz> ugh
<jscinoz> wish i found that out earlier.
<jscinoz> the -ljpeg is all i need?
<jscinoz> i dont need it to be -l/usr/lib/libjpeg.so.62?
<mok0_> jscinoz: no
<mok0_> jscinoz: -ljpeg
<jscinoz> thank you
<mok0_> by default, the linker knows to look for libraries in /usr/lib
<mok0_> it knows their names always start with 'lib' and end in '.so'
<mok0_> so you only need to specify the "variable" bit = jpeg
<ryanakca> hmm... what does this do "common-binary-predeb-arch" ?
<ryanakca> and "common-binary-predeb-indep::" ?
<jscinoz> mok0_, with -ljpeg can lines 1000-1033 be removed/commented out? or do they need to be changed somewhat
 * mok0_ looks
<jscinoz> and also line 153, and lines 1553-1554
<mok0_> jscinoz: it's not that simple
<jscinoz> >_<
<mok0_> jscinoz: you need to put it in the LDFLAGS variable, and in fact it looks as if you can do that when calling make
<mok0_> jscinoz: make "LDFLAGS=-ljpeg"
<jscinoz> make[2]: *** No rule to make target `build/release-linux-i386/client/jcapimin.o', needed by `build/release-linux-i386/ioUrbanTerror.i386'.  Stop
<jscinoz> as i said, should line 1k-1033 be commented out?
<mok0_> jscinoz: yes that has to go
<mok0_> jscinoz: but this makefile is full of ifeq... endif sections so be sure to fix it the right place
<jscinoz> new output: http://pastebin.ubuntu-nl.org/52947/
<mok0_> jscinoz: looks like it's missing -lGL
<jscinoz> hmm
<jscinoz> because it didnt have that output before i removed its own jpeg stuff..
<jscinoz> same output with -lGL aswell >_<
<mok0_> Hmm
<mok0_> jscinoz: do you have someone where you live that knows about programming?
<jscinoz> no.
<jscinoz> hmm
<mok0_> jscinoz: Like I said earlier, what you are trying to accomplish is not easy
<jscinoz> if i have it still compile its own libjpeg, but remove the lines referncing the *.o's, it gives this same output
<jscinoz> so what i think is that -ljpeg isnt linking it properly or something
<jscinoz> aye, same output with or without "LDFLAGS=-ljpeg"
<mok0_> jscinoz: it could be that it's a modified libjpeg
<jscinoz> gah
<mok0_> jscinoz: I suggest you tell the motu that you looked into the problem with help on IRC and that it does not seem to be possible to use Ubuntu's libjpeg as a replacement
<jscinoz> alright thanks
<mok0_> jscinoz: you can say you got indefined references and urbanterror
<mok0_> s version seems to be modified
<jscinoz> alright
<LaserJock> hi Hobbsee and minghua
<Hobbsee> heya LaserJock
<minghua> Good evening LaserJock.
<jscinoz> hmm whats a way to count the amount of lines output by grep/cat
<StevenK> grep -c
<StevenK> wc -l < file
<StevenK> Either works fine
<ryanakca> should I write a patch to fix two dozen lines of this? "dpkg-source: warning: file qyoto/csharp/qyoto/core/QObjectExtras.cs has no final newline (either original or modified version)" ?
<jscinoz> thanks
<ryanakca> s/two/a/
<StevenK> pochu: I haven't, it's a little complicated.
<ryanakca> hmmm. Ok, so I've got qyoto merged into kdebindings, I'm just wondering how to generate the dsc since I'm getting these errors http://paste.ubuntu-nl.org/52952/ when I run debuild -S -sa -kE95EDDC9
<cyberix> I'm looking after first advocate for my package Malbolge. I've fixed all broblems that have been brought up. http://revu.tauware.de/details.py?package=malbolge
<LaserJock> ryanakca: it looks like it's from source files and if it doesn't cause a bug I certainly wouldn't worry about it.
<ryanakca> LaserJock: was that to the patch question or how to generate the dsc question?
<LaserJock> patch question
<ryanakca> okies, thanks :)
<LaserJock> ryanakca: hmm, it kinda looks to me like there's a lot of stuff going on in the .diff.gz there
<ryanakca> LaserJock: yes, well, I copied all of the qyoto sources into kdebindings-3.5.8
<minghua> ryanakca: The building error question -- the real problem are the two "cannot represent change" errors.
<LaserJock> oh, that's going to be a bit difficult
<LaserJock> right, what minghua said
<LaserJock> you're trying to add source when packaging is not meant for that
<ryanakca> yes... then what would be the appropriate way?
 * ryanakca was asked to merge qyoto into kdebindings... generate a new .orig.tar.gz ?
<LaserJock> ryanakca: I guess so
<LaserJock> is qyoto distributed separately?
<pochu> StevenK: Alright. Would be nice though if possible.
<ryanakca> LaserJock: okies. take out the debian dir?
<LaserJock> ryanakca: hmm?
<ryanakca> LaserJock: yes, but kdebindings is just an assortment of libraries which are distributed seperately
<ryanakca> take out the debian/ dir when making the .orig.tar.gz ?
<LaserJock> how is it distributed?
<LaserJock> ryanakca: first we need to figure out how you get the kdebindings .orig.tar.gz
<ryanakca> how are they distributed? umm... part comes from http://www.kde.org/download , another comes from the xparts website, some from qyoto.org, kjsembed... umm.. unsure how it was all pieced together originially
 * ryanakca reads the changelog
<LaserJock> ryanakca: are you working on KDE3?
<ryanakca> yes
<LaserJock> k, I'm grabbing the source
<ryanakca> I was originally supposed to merge the KDE3 package with the KDE4 package from debian, and then merge in qyoto into that merged thing, but then it was decided to just merge qyoto into kdebindings kde3 since the debian kde4 packaging wasn't advanced enough
<ryanakca> LaserJock: step by step, what I did was copy the qyoto source dir to kdebindings-3.5.8/qyoto, merge kdebindings-3.5.8/qyoto/debian/* with kdebindings-3.5.8/debian/*, then remove kdebindings-3.5.8/qyoto/debian
<LaserJock> right, and I think that's wrong
 * ryanakca tars up kdebindings-3.5.8/debian and puts it on his webserver
<ryanakca> hmmm.
<LaserJock> the problem is that packaging isn't meant to add source to
<LaserJock> so your .diff.gz can't represent binary files
<LaserJock> and really, you don't want to do that
<bddebian> Heya gang
<LaserJock> you want to add qyoto to kdebindings
 * ryanakca nods
<ryanakca> LaserJock: http://blog.ryanak.ca/kdebindings-3.5.8.debian.tar.gz
<ryanakca> hey bddebian
<LaserJock> so kdebindings is distributed upstream as a tarball
<ryanakca> LaserJock: ok, to add qyoto, I'd have to generate a new orig.tar.gz?
<bddebian> Hello ryanakca
<ryanakca> hmmm
<ryanakca> and in that new .orig.tar.gz, I would have to remove debian/, then readd it, debuild, etc ?
<LaserJock> well
<LaserJock> hmm
<LaserJock> this is a bit funky
 * ryanakca nods
<LaserJock> you want to take the kdebindings upstream tarball
<LaserJock> unpack it, add your qyoto source, and retar it
<ryanakca> ok.
<LaserJock> but that means you're creating a new .orig.tar.gz for the same version of kdebindings
<ryanakca> can I do that to the current .orig.tar.gz?
<LaserJock> which is not great
<ryanakca> hmm... Riddell is probably asleep atm...
<LaserJock> ryanakca: I honestly don't know why you're not adding this as a separate package
<ryanakca> LaserJock: it currently is a seperate package...
<LaserJock> ah ....
<ryanakca> LaserJock: *gets the logs from this afternoon describing what he has to do*, just a sec.
<ryanakca> LaserJock: http://blog.ryanak.ca/kubuntu-devel.log
<ScottK> LaserJock: Do you have time to do some source backports for me (I need a core-dev to upload)?
<LaserJock> ryanakca: well, honestly, you've got to talk to Riddell about that. That looks really odd/suspicious to me
<LaserJock> ScottK: what do you need
<LaserJock> ?
<ScottK> LaserJock: I need to you upload the 3 packages with debdiffs in But #183914.
<ScottK> Urgh
<ScottK> Bug #183914
<ubotu> Launchpad bug 183914 in dapper-backports "Please Backport clamav-0.92~dfsg-2 from Hardy to Dapper" [Wishlist,In progress] https://launchpad.net/bugs/183914
<ScottK> The won't get published until an archive admin accepts them, but I can't upload them...
<ScottK> The/They
<ryanakca> LaserJock: ok, will do
<RAOF> superm1: Re bug #134197 - as far as I can tell, monodevelop doesn't need a build-dep on firefox at all (but it does need a dep on firefox, & I've filed a debian bug about that).
<ubotu> Launchpad bug 134197 in monodevelop "Please merge monodevelop 0.18.1+dfsg-1 from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/134197
<mcisbackuk> Hi all, I'd like to get involved in packaging, but a lot of the wiki's are confusing
<superm1> RAOF, i didn't want to change things with the way it worked (it build-depends fine with it in there)
<RAOF> superm1: Quite true.  It doesn't care whether or not you've got a firefox-dev build-dep or not :)
<mcisbackuk> Can anyone help me get started please?
<ryanakca> mcisbackuk: the Ubuntu Packaging Guide is a good starting place...
<RAOF> mcisbackuk: What would you actually like to do?
<RAOF> (Packaging is a broad field ;))
<superm1> RAOF, :)
<ryanakca> mcisbackuk: http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html
<mcisbackuk> i've had a look at the guide, but it's too broad, as you say, and I'll be honest I'm not that good on linux, but know pc's well (notdeveloper level) and would love to help out, maybe get rid of some on the wishlist to help you guys out :)
<LaserJock> !packagingguide > ryanakca
<RAOF> superm1: Did you try to xul-1.9ify it at all?
<ryanakca> LaserJock: oh? hmm... *checks the new link*
<superm1> RAOF, i did not.
<ScottK> LaserJock: What do you think, are you up for it?
<superm1> RAOF, i was more looking to get the merge done (given the time frame for the impending freeze)
<ryanakca> LaserJock: heh, interesting.
<ryanakca> mcisbackuk: ignore me :)
<mcisbackuk> i havent used irc before how do i reply lol sorry i must sound really stupid now
<RAOF> superm1: Yeah, fair enough.  I'll add that to my moderately large "before FF todo" list.
<superm1> RAOF, yeah i'm looking for any other big ones that i know people are going to be annoyed by here if they aren't done at this point
<mcisbackuk> ryanacka
<mcisbackuk> oops
 * RAOF would like to fix debian bug #461353 before FF, for example.
<ubotu> Debian bug 461353 in monodevelop "monodevelop: Fails to start without Gecko" [Normal,Open] http://bugs.debian.org/461353
<RAOF> Argh, wrong one.
<ryanakca> mcisbackuk: to reply, put the persons name : message.
<mcisbackuk> Am I still connected?
<RAOF> mcisbackuk: Yes.
<mcisbackuk> RAOF : Thanks
<mcisbackuk> RAOF: Thanks
<RAOF> It's just that no one is saying anything much :)
<RAOF> That happens.
<mcisbackuk> Ahh I see :)
<mcisbackuk> I really wann get my hands dirty in linux lol
<mcisbackuk> Are packages added to the repositories after the feature freeze do you know?
<RAOF> Only with a good reason.
<mcisbackuk> So not anything silly like someone wants a game then
<RAOF> The only really hard freeze is at the end.  All the other freezes mean that you need to make a good argument for why $PACKAGE should be an exception.
<ScottK> mcisbackuk: If you are just starting now, you probably want to start learning packaging through bugfixing and merges and then do new packages starting with Hardy +1
<mcisbackuk> What if it's built for 7.10 for example though?
<mcisbackuk> Ahh I see...
<ScottK> 7.10 is done.  Packages can be added/updates from Hardy in gutsy-backports, but that's it.
<mcisbackuk> ok
<mcisbackuk> I get it now :)
<mcisbackuk> So I take it the only time software gets updated is with a new release, and its only bugfixes/security updates until then?
<minghua> If you mean "after that" by "until then", basically yes.
<RAOF> Pretty much.  And not just any bugfixes; they need to be important (for a certain definition of important).
<minghua> From a user's point of view, at least.
<mcisbackuk> Like data loss, corruption I take it?
<RAOF> That'd certainly qualify.  Also regressions from previous versions (it works in Feisty, but not Gutsy) often qualify.
<mcisbackuk> I see
<LaserJock> mcisbackuk: you might want to read http://wiki.ubuntu.com/StableReleaseUpdates
<ScottK> Up until the beta, my usual definition of sufficiently importatant is someone thougth it was worth the trouble to come up with the fix.
<RAOF> Basically the risks of touching a package increase the closer to the release date we are.  *After* the release date the risk is considered very nearly infinite, so you need a *very* good reason for touching anything.
<mcisbackuk> Since everything is pretty much working at that point?
<zul> evening
<ScottK> That's the theory.
<ScottK> evening zul.
<zul> how is going ScottK
<mcisbackuk> Theory's nice lol :)
<ScottK> zul: Pretty good.  LaserJock's uploading the source backports for Dapper so we can get the current clamav into dapper-backports.
<zul> nifty
 * RAOF needs to write a blog post on what "stable" means in the context of Ubuntu releases/archives.
<ScottK> I feel like I just did a masters thesis in packaging, testing, and release management.
<mcisbackuk> So, sorry guys, what about bug #182693, it says needs-packaging, but its under mentoring available? Does that mean the maintainer is willing to help out someone new with doing it? Sorry you must all think I'm a pain in the backside.
<ubotu> Launchpad bug 182693 in ubuntu "[needs-packaging] monkeystudio" [Wishlist,In progress] https://launchpad.net/bugs/182693
<ScottK> mcisbackuk: Part of what we do is help people get started.
<ScottK> mcisbackuk: You're fine.
<RAOF> mcisbackuk: The "in progress" status of that bug suggests that someone is actively working on it, so it might not be a good place to start.
<mcisbackuk> ScottK: Thanks :) I just want to learn and help out
<ScottK> Then you're in the right place
<mcisbackuk> Well I was looking at bug #184791, and it looked like a simple one to start off with, an alarm clock....but none of the guides tell you how to compile the binary/deb in python
<ubotu> Launchpad bug 184791 in ubuntu "[needs-packaging] Alarm Clock" [Undecided,New] https://launchpad.net/bugs/184791
<mcisbackuk> Or vice versa
<ScottK> mcisbackuk: We're pretty close to feature freeze.  It's really unlikely that if you start a new package it would make it into Hardy, but you're certainly free to give it a shot if you want.
<mcisbackuk> ScottK: Well I'd like to at least have a go, and try refining the skills needed to package.
<RAOF> mcisbackuk: It's much easier to start with bugfixing.  Then you learn bits of packaging at a time.
<mcisbackuk> RAOF: Don't you need to know more about the actual code then?
<ScottK> mcisbackuk: If you really want to take a shot at that one, find a similar package and see how they did it.
<ScottK> mcisbackuk: Do you code at all?
<mcisbackuk> Nope - I think that may be the problem lol
<ScottK> It's not needed to package.
<mcisbackuk> Thank god
<ScottK> look for bugs tagged packaging and bitesize
<RAOF> mcisbackuk: You don't have to understand the code in many cases.  Some bugs are just in the packaging.  Sometimes you can follow the bug to the upstream bug tracker, where there's a patch to fix it.
<mcisbackuk> As in the original from the developers website?
<RAOF> Yes.
<mcisbackuk> OK, maybe I'll start there :)
<mcisbackuk> Can either of you point me to an idiots guide, if there is such a thing?
<mcisbackuk> lol
<LaserJock> mcisbackuk: and idiots guide to what?
<mcisbackuk> LaserJock: Packaging, or as RAOF said re-packaging upstream versions
<LaserJock> mcisbackuk: I think the best we've got really is the packaging guide http://wiki.ubuntu.com/PackagingGuide
<mcisbackuk> LaserJock: OK I'll have to grit my teeth and buckle down and see if I can work it out, I won't let it get the better of me :)
<LaserJock> mcisbackuk: packaging is not all that hard, but does require patience
<LaserJock> there is a lot of stuff to remember
<LaserJock> but it's definitely learnable
<mcisbackuk> I have the patience and the time to do it definately, and I learn quick
<jscinoz> well i managed to bork my system >_<
<mcisbackuk> Doesn't sound good.....
<ScottK> jscinoz: This isn't a support channel.
<jscinoz> i know :P just saying it casually lol
<jscinoz> and zomg someone check the latest uploads of my urbanterror and urbanterror-data packages, i fixed some more stuff
<wolfger> one of my review comments mentions the "python packaging policy". but Google isn't helping me find that. Anybody have a link?
 * bddebian would if it wasn't a 300+Mb data package :-)
<bddebian> wolfger: http://wiki.debian.org/DebianPython/NewPolicy
<wolfger> thx
<LaserJock> man, busy day today. Got almost nothing done that I wanted to :)
<bddebian> ajmitch: You around at all?
<vemon> good morning!
<vemon> should i add "Uploaded to REVU: http://...." comment to a [needs-packaging] bug when i do a revu upload?
<LaserJock> wouldn't hurt
<vemon> if there is someone who knows that LASH is then here's one for review: N:   The source package refers to a 'Standards-Version' that is starting to
<vemon> N:   get out of date, compared to current Policy. You can safely ignore
<vemon> :D
<vemon> N:   this warning, but please consider updating the package to current
<vemon> well not that
<vemon> N:   Policy.
<vemon> http://revu.tauware.de/details.py?package=lashwrap
<vemon> sorry for flooding :D middle clicking can be a little hazardous sometimes
<LucidFox> vemon> commented
<warp10> Heya
<yamal> mornin
<yamal> MOTUs, your comments please, for the latest and greatest sabnzbd package: http://revu.tauware.de/details.py?package=sabnzbdplus
<theseinfeld> cprov: how long does it take to revu to get your dput and email you?
<amarillion> Please be so kind to review one of my packages http://revu.tauware.de/details.py?package=alex4 and http://revu.tauware.de/details.py?package=speed-game. These packages are in a good state, all previous comments have been addressed
<amarillion> theseinfeld, you won't get an email...
<amarillion> but revu is updated once every 12 minutes
<theseinfeld> amarillion: yes, I can see that it was received, but I was waiting for the password so I could login...
<theseinfeld> amarillion: or did i get it all wrong?
<theseinfeld> :(
<amarillion> The password won't get emailed either. Just fill out your email address, and press login. It fails, then gives you the option to get a new password
<theseinfeld> Once you have uploaded a package to REVU, a password will be created for you. To get it, enter your e-mail address into the login box, leaving the password field blank, and click Login. Click Recover, and REVU will display an encrypted message with your password in it.
<theseinfeld> yes
<theseinfeld> amarillion: you are right...
<amarillion> yeah, do you get a password now?
<theseinfeld> amarillion: the problem is that i get this
<theseinfeld> No REVU account for theseinfeld@users.sf.net exists yet.
<amarillion> Did you sign up for the universe contributors team?
<theseinfeld> yes
<amarillion> also, do you have a GPG key uploaded to launchpad?
<theseinfeld> since yesterday
<theseinfeld> the key must be 2 years old
<theseinfeld> :D
<theseinfeld> yes yes yes
<amarillion> oh, it may take a day before the keys get copied to revu
<amarillion> so that may be the problem
<amarillion> ask persia to do a sync
<theseinfeld> whois persia
<theseinfeld> ok
<theseinfeld> I can wait also...
<amarillion> yeah, both will work :)
<theseinfeld> I was puzzled that the package is uploaded
<amarillion> did you upload a package?
<theseinfeld> http://revu.tauware.de/details.py?package=libdc1394-22
<amarillion> which one?
<philn> hi
<theseinfeld> amarillion: libdc1394-22
<amarillion> theseinfeld, would you like me to review it?
<theseinfeld> amarillion: on phone...just a sec
<philn> i created a bug to sync a package in hardy, do i need subscribe someone special so that it's taken care of?
<minghua> philn: Yes, read https://wiki.ubuntu.com/SyncRequestProcess and follow instructions.
<philn> ok; thx
<TheMuso> Hey MOTUs.
<TheMuso> and MOTu hopefuls. :p
<Hobbsee> hi deity
<TheMuso> Hobbsee: lol
<Hobbsee> TheMuso: or is that info not public yet?
<TheMuso> Hobbsee: Lets just say its not common knowledge.
<Hobbsee> fair enough
<Hobbsee> we'll just call you a deity without saying the reason tehn
<vemon> is the backports repository the only place to get new upstream versions after an ubuntu release?
<vemon> meaning: are bug fixes the only changes which are uploaded to the normal repos after release?
<minghua> vemon: Yes, unless the new upstream version is a bugfix-only release, and fix important bugs.
<Hobbsee> !sru | vemon
<ubotu> vemon: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<slytherin> hi all. Does anyone know if the java license related debconf preseeding on buildd works for both java5 and java6?
<geser> slytherin: yes, as both use the same debconf question
<slytherin> geser: One more question. Are 'arch: all' packages built on i386 only?
<theseinfeld> amarillion: back
<geser> slytherin: yes, the i386 buildd builds also the arch:all packages
<geser> Hi dholbach
<dholbach> hey geser
* dholbach changed the topic of #ubuntu-motu to: Masters of the Universe: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Unmet Deps time! http://qa.ubuntuwire.com/debcheck/ | QA resources from http://qa.ubuntuwire.com
 * TheMuso can't see any major change in that topic.
 * StevenK bites his tongue
<TheMuso> StevenK: hardy hardy gar
<TheMuso> s/gar/har/
<theseinfeld> Please be so kind to review the following package: http://revu.ubuntuwire.com/details.py?package=libdc1394-22 . It should be in a good state as it has been discussed with some Debian people. Thank you
<psicus78> hi
<geser> slytherin: do you know if with sun-java[56] compiled code runs with kaffe? I'm looking at the statcvs package now.
<slytherin> geser: Not sure, never used kaffe. But if the code itself doesn't use any sun specific apis/extensions then it should run with any VM. And I guess kaffe supports Java 1.5 apis, but I will have to confirm.
<slytherin> geser: What is the problem by the way?
<geser> slytherin: no problem, just checking if depends line is still correct after changing build-depends
<geser> statcvs depwaits currently on sun-j2sdk* and I want to change it to the available compilers
<slytherin> geser: Why not try java-gcj-compat-dev?
<geser> I did, doesn't build with it
<slytherin> geser: can you paste the error somewhere?
<geser> btw: libjibx-java from yesterday doesn't build with gcj either
<slytherin> hmm.
<slytherin> geser: looks like kaffe is far behind other Free JVMs. http://www.kaffe.org/~stuart/japi/htmlout/h-kaffe-jdk14.html
<geser> slytherin: http://paste.ubuntu.com/3773/
<psicus78> hi!
<psicus78> do you know if it exist any tool that allow to find out (and then install) all the build-dependencies of a package which is not debianized yet? I mean get all the libblabla-dev required at build time?
<geser> psicus78: no, try and error
<slytherin> geser: Check error number 8, It uses sun specific apis.
<geser> psicus78: you can read the README and/or INSTALL file and hope that it contains a list of requirements
<minghua> psicus78: There are tools to help, but nothing like "apt-get build-dep"
<psicus78> minghua: yes, autotools should help
<geser> psicus78: you can also look which packages configure looks for
<psicus78> geser: correct, that's what I was thinking
<DaveMorris> \me plugs his package for revu - http://revu.tauware.de/details.py?package=opensg It's an OSS distributed scenegraph API for doing some cool 3D graphics across multiple machines or single machines.  Has support for sort 1st and sort last.  I'm currently using it to power a cluster with a 46 million pixel display.  It's cool so please revu it.
<psicus78> I was wondering if it would be possible to automate that
<geser> slytherin: so build-depend on sun-java[56]-jdk. is kaffe still a good candidate for depends?
<psicus78> I believe it is possible
<geser> psicus78: you could also check the included headers files
<slytherin> geser: No. Obviously in this case since the runtime should also contain those sun specific apis, only Sun JRE qualifies
<geser> slytherin: so I change "Depends: classpath, kaffe | java2-runtime" to "Depends: sun-java6-jre | java2-runtime"?
<slytherin> geser: only "sun-java5-jre | sun-java6-jre".
<geser> slytherin: thanks
<psicus78> geser: mmm...if the developer uses autotools he should check everything in configure.ac
<psicus78> geser: or configure.in
<geser> psicus78: yes, if the developer uses autotools
<psicus78> geser: I was wondering if there is something cannot be discovered automatically
<vemon> now that you're talking about Depends... what does the {sh:Depends} (probably not typed correctly) actually do?
<vemon> i've seen that in many packages and it seems it's not necessary to explicitly define deps for those packages
<vemon> i'n debian/control i mean
<psicus78> geser:  for instance in network-manager there is some code to check for wireless-tools but not using pkg-config, that could be a problem
<geser> vemon: dh_shlibdeps computes the runtime dependencies (by looking at the needed libs) and replaces the the placeholder with it
<psicus78> vemon:  I'm not sure 100% but I think {sh:Depends} includes all the packages that contain the shared libraries required at runtime
<psicus78> vemon: what I want is build-time depends instead
<psicus78> geser: I must suppose that autotools is used, otherwise is impossible
<slytherin> Can someone explain to me process of merge?
<geser> slytherin: simplified: you take the latest debian revision and the Ubuntu changes, check which are still needed and apply them again
<geser> slytherin: you can use the output of MoM as a starting point for most merges
<slytherin> geser: Ok. And then which debdiff should I submit? Or should I submit interdiff?
<geser> slytherin: debdiff, between the debian revision and the new ubuntu revision
<slytherin> ok, thanks.
<vemon> are there cases where sh:Depends is not enough? (i guess when some package is only suggested?)
<geser> vemon: it works only for libraries (lib*.so.*), so if your app is written in perl/ruby/python/etc. you need to figure the depends yourself out
<geser> vemon: another examples are -dev packages, where you want to install the correct version of the lib the headers belong to
<vemon> can give me an example?
<geser> vemon: an example for what?
<vemon> geser, for a dev package which requires a certain version of the lib it gives headers to
<geser> vemon: e.g. http://revu.tauware.de/revu1-incoming/libmirage-0801202040/libmirage-1.0.0/debian/control any other package on revu building a -dev package should have it too
<slytherin> geser: Are you able to search packages in debian unstable from http://packages.debian.org ? It times out for me for last few days.
<man-di> slytherin: works fine here
<geser> slytherin: here too
<vemon> geser, now i understand. i think i missed the part where you said the package to be built is a dev- package. :)
<rexbron> Hey everyone! Got one ack and looking for a second: http://revu.tauware.de/details.py?package=ubuntustudio-controls
 * Hobbsee has a look
<zul> morning
<Hobbsee> rexbron: surely setup.py should have some form of copyright notice too?
<Hobbsee> if the rest does?
<rexbron> Hobbsee: perhaps, but that is just calling a function. If by convention setup.py should have a copyright notice, I will include one
<Hobbsee> rexbron: will leave it, and see what the other archive admins say
<rexbron> ok
 * Hobbsee acks, uploads
<rexbron> :)
<rexbron> thanks Hobbsee
<Hobbsee> rexbron: you're welcome
<slytherin> Can anyone give me any debian package's .dsc url? I wish doe download source for libjcalendar-java but I can't search it due to timeout problems.
 * TheMuso hugs Hobbsee 
 * Hobbsee hugs TheMuso :)
<mok0> whole lotta huggin' going on
<geser> slytherin: I use the PTS for such things: http://ftp.debian.org/debian/pool/main/libj/libjcalendar-java/libjcalendar-java_1.3.2-2.dsc
<slytherin> geser: Please excuse my ignorance, what is PTS?
<geser> slytherin: Debian's package tracking system: http://packages.qa.debian.org
<slytherin> geser: Thanks.
<geser> slytherin: it has also a nice redirect: http://packages.qa.debian.org/libjcalendar-java will redirect you to the correct page
<frafu> Could anybody please review the following package: http://revu.tauware.de/details.py?upid=1379 Thanks
<frafu> Please ignore the package from January 21 18:30;  its upload was an error.
<ion_> It might be best to reupload the correct one.
<frafu> ion_: reuploading does not work: package already uploaded error
<slytherin> frafu: use 'dput -f' option
<persia> frafu: delete your .upload fle
<frafu> thanks for the tips
 * ion_ cringes. From the postinst of a third-party deb:
<ion_> cp /usr/share/retroshare/retroshare.desktop "$HOME/Desktop"
<LongPointyStick> ...blink
<persia> It recreates that wonderful "launcher on the desktop on install" feature, except that the install doesn't actually run as the user :)  Perfect for those scenarios where you run X as root.
<StevenK> Which gdm doesn't permit, if I recall
<persia> StevenK: There are ways around gdm, and gdm can be configured to allow it, but in most cases you are correct (as usual)
<frafu> persia: where can I find the .upload  file?
<persia> frafu: should be in the same directory as the .changes you uploaded.
<frafu> persia: ok; I understand now; I searched for it in my home directory. Thanks again.
<persia> Java question: If upstream has mixed-case in their .jar file, I know we flatten for the package name, but do we also flatten the .jar file?
<slangasek> I can't see any reason why you would, surely that would induce incompatibility with upstream?
<theseinfeld> anybody for reviewing http://revu.tauware.de/details.py?upid=1391 ?
<theseinfeld> thanks
<persia> slangasek: That's what I was thinking, but I'm a little fuzzy on Java policy.  Thanks for the confirmation.
<persia> theseinfeld: There tends to be a significant lull in reviewing just after REVU day (ended 99 minutes ago).  If your package was submitted before REVU day, and nobody looked at it, it will be included in the post-REVU day summary mail, and may get a review.
<slytherin> persia: I would recommend not do do that. What if the package has some demo program which uses jar file. The program won't find the file in that case.
<persia> slytherin: It shan't be done then :)
<slytherin> geser: A little help needed, libhibernate3-java has manual dep wait on libcglib2.1-java, but I can't find that package in Ubuntu as well as Debian.
<slytherin> geser: oops, my mistake, it is present in both
<mok0> I am still looking for a collaborator to help with torque
<mok0> ... I guess not many are interested in cluster computing
<persia> mok0: The best way to get help is to ask in the right forum, but it appears you've already done that with https://lists.ubuntu.com/archives/ubuntu-motu-science/2007-November/000010.html :(
<mok0> persia: yes
<slytherin> Can anyone confirm that package aspectwerkz2 is not synced from debian. I seem to be making search at wrong places today.
<tjaalton> can someone with fglrx + amd64 confirm that 32bit GL apps work currently?
<persia> slytherin: I don't see it in the Ubuntu repositories.  rmadison might be a tool worth investigating
<slytherin> persia: Can absence of a package cause depwait packages that depend on it? looks like cglib2.1 has a depwait for same reason and in turn causes depwait in hibernate3
<persia> slytherin: Yep.  depwait only means the build dependencies cannot be satisfied.  This can be a typo, a needed update, a side effect of a removal, or a build failure somewhere else in the chain.
<Aloha> its cool that the servers automagically build the binaries
<Aloha> woot pbuilder install almost done
<slytherin> persia: rmadison returns zero results for aspectwerkz2 as well as libaspectwerkz2-java.
<geser> slytherin: bug #184278
<ubotu> Launchpad bug 184278 in ubuntu "[Sync request] Please sync aspectwerkz2 2.0.dfsg.1-2 (universe) from Debian unstable (contrib)" [Wishlist,Confirmed] https://launchpad.net/bugs/184278
<slytherin> geser: thanks. :-)
<Hobbsee> when will someone write a script that gets the address of the .dsc for the latest package in debian?
<geser> Hobbsee: start coding :)
<persia> Hobbsee: apt will do that, if you like.  I wrote a dirty hack to do it, but these days I find it most convenient to keep an up-to-date sid chroot around and just use apt-get source with /home bind-mounted.
<Hobbsee> hm
<persia> If you use mk-sbuild-lv from ubuntu-dev-tools to generate the sid chroot, it takes care of all the mounting stuff for you.  You just need a couple gig free for the volume group for the LV in which the chroot lives.
<geser> Hobbsee: shouldn't apt-get source -t unstable do it if you have a deb-src line in your sources.list?
<Hobbsee> geser: probably.  if i had the deb-src line
<AnAnt> man-di: Hello
<AnAnt> man-di: I have a couple of questions
<AnAnt> man-di: 1. why are you worried that people would depend on IcedTea and forget about gcj, isn't IcedTea free ?
<AnAnt> man-di: 2. any news about IcedTea debian package ?
<persia> AnAnt: Are you planning to update the ubuntume packages?  I'd really like to see them get into hardy, but I'm getting worried about timing.
<jdstrand> emgent: I have uploaded the drupal5 fixes, but please see my comment in bug #181984
<ubotu> Launchpad bug 181984 in drupal5 "Drupal5: SA-2007-031, SA-2008-005,SA-2008-006: SQL injection and XSS " [Undecided,Fix committed] https://launchpad.net/bugs/181984
<jdstrand> emgent: thanks!
<man-di> I am worried because icedtea is currently i386/amd65/powerpc and people woll forget about the other archs
<man-di> AnAnt: its currenly uploading
<StevenK> amd65. I've not heard of that arch
<slytherin> AnAnt: apart from what man-di said, icedtea is not complete yet, may not be stable enough.
 * man-di paints StevenK a big 4 into his hand
<man-di> *g*
<StevenK> Gimme 4?
<man-di> AnAnt: slytherin is right. Its a big moving target, nobody knows what Java7 really will include
<man-di> StevenK: Its the successor of amd64 with one more address bit to make it possible to address more memory
<AnAnt> persia: well, I don't think so. I really dunno what to do about modifying gdm.conf & grub.conf
<AnAnt> persia: also the request to host the packages in LP's SVN
<Aloha> woohoo!
<Aloha> my pbuilder install is done
<persia> AnAnt: Hrm.  Have you tried asking one of the other derivatives about it?  Maybe #xubuntu or #ubuntustudio or #icthux would have some pointers.
<\sh> persia, mk-sbuild-lv just has this nasty debootstrap->find distro in /usr/lib/debootstrap bug ;) it's fixed in our bzr branch of ubuntu-dev-tools
<\sh> moins btw
<persia> AnAnt: That was more that either the packages oughtn't be native, or be in LP bzr.  LP accounts are free, but I can understand if there are issues with the service.  The other option is not to publish any Vcs-*, but that can affect maintenance.
<persia> \sh: Why is it only fixed in bzr?  Shouldn't it be fixed where we can use it?
<\sh> persia, well it would be a good idea to release a new version of ubuntu-dev-tools
<Aloha> how do you import signature for apt-get source?
<persia> \sh: You have the power...
<Aloha> i mean key
<persia> Aloha: There's no easy way.  You have to collect the keys of all the developers.
<\sh> dholbach, any reasons not to upload ubuntu-dev-tools from trunk?
<Aloha> persia, nevermind not worth it. i believe its valid ;)
<ScottK> \sh: Does pbuilder-dist work yet?
<ScottK> \sh: Also, IIRC it was geser, someone was working on requestsync and I'm not sure they got it done/comitted/merged.
<geser> ScottK: I've already committed my changes to bzr
<Aloha> whats bazaar used for? is it like PPA?
<\sh> ScottK, oh I never used pbuilder-dist ;) I have my own pbuilder framwork
<geser> Aloha: have you heard of cvs or svn? bzr is an other version control system
<Aloha> geser, gotcha. is it ubuntu specific?
<\sh> Aloha, nope
<Aloha> oh. never heard of it before
<\sh> Aloha, bug canonical sponsors the development of bzr and so it's our default VCS
<jdstrand> emgent: I also added a comment on bug #181416
<ubotu> Launchpad bug 181416 in wordpress "SQL injection vulnerability in wp-includes/query.php in WordPress CVE-2007-6318" [Undecided,Confirmed] https://launchpad.net/bugs/181416
<mok0> persia, and in https://lists.ubuntu.com/archives/ubuntu-motu/2008-January/003046.html
<Aloha> gotcha
<ion_> Itâs just orders of magnitude slower than git. :-(
<Aloha> so its made by "ubuntu"
<\sh> Aloha, nope
<\sh> Aloha, it's sponsored by canonical ;)
<Aloha> oh sponsored, gotcha
<persia> mok0: Yes, but that wasn't the ideally targetted forum (although still a good request).
 * \sh 's busy with gnucash
<\sh> ScottK, what wasn't working in pbuilder-dist?
<mok0> persia: working in this communtity has taught me that patience pays off :-)
<ScottK> \sh: I'm not sure, but laserjock was saying he wrote a new script because it wasn't working for him.
<ScottK> \sh: Something wrong with create, so if you can make a new pbuilder, then I think it's fine.  Might be worth a quick test.
<\sh> ScottK, ok...I'll test after gnucash
<ScottK> OK.
<\sh> and if anybody has experience with crystalspace, I would like to ask for some testbuilds of new upstream....looks like it's broken somehow but I don't have any clue about it
<mok0> There's actually a build machine called "hooker"...
 * \sh has his own build machine ;)
<ScottK> mok0: I choose to assume it's named after General Hooker.  http://en.wikipedia.org/wiki/Joseph_Hooker
<mok0> ScottK: Oh, of course :->
<ion_> One of my keyboards (as in, the ones with black and white keys that play sound) has a controller titled âBenderâ.
<\sh> ion_, I think the "Bender" name for the "make sound keyboards" are older then the name of Futuramas Bender ;)
<\sh> "Good News Everyone" !
<mok0> "Building bender in hardy on hooker" :-P
<ion_> Itâs just called âPitch Bendâ in every other keyboard iâve seen. :-)
<\sh> well...looks like we get a new gnucash version soon....after the gconf fix it's building again ;)
<Aloha> in apt-get source how do i get an earlier package version, such as hello-debhelper-2.1.1 instead of 2.2?
<persia> ion_: I've seen "mod" and "twist" as well.
<\sh> ScottK, do you still want to have quilt introduced in gnucash fixing *.desktop* files?
 * persia encourages fixing .desktop files, but wonders if it is really worth quilt
<\sh> persia, I agree...packages without any patch system where we have to add some trivial fixes could be still be made inside diff.gz
<\sh> but I asked better ScottK because he introduced quilt in gnucash ;)
<persia> \sh: Depends on the maintainer.  If a maintainer always uses patch system X, and we know that, and we introduce a change, using patch system X is the best way to do that.
<\sh> persia, there was no patch system before and after ;)
<AnAnt> persia: so, all I have to do is remove the Vcs-* fields ?
<\sh> and there are two changes left...libungif4-dev -> libgif-dev and the desktop fixes
<AnAnt> persia: and still keep the package source in the current SVN repository ?
<persia> AnAnt: That would suit me.  My objection is to specifically asking people editing the package to use the VCS repo, and not granting them access by default.
<AnAnt> persia: ah, ok
<persia> With LP, it's easy to add the ubuntu-dev group, but externally, it's hard.  If the packaging isn't listed as being in a VCS, people just commit changes to the repo.  Maybe a little harder for you to track, but less confusing for normal package maintenance.
<Aloha> wohoo almost done building my first source package
<AnAnt> persia: ok, and the svn URL would be mentioned in copyright ?
<persia> AnAnt: Well, that gets back to whether it is a native package.  If you downloaded it from some upstream, it isn't native, and shouldn't be treated as such.  If it is native, then there's no upstream from which to download it, and it wouldn't get put in debian/copyright.  Personally, I don't like native packages (and really appreciate the way the mythbuntu team does their packages)
<StevenK> Grumbles.
 * StevenK wonders how to join lines from stdin
<jpatrick> stdin: you around?^^
<persia> StevenK: Do you mean like a zipper mixing stdin and a file, or just push a stream onto a single line?
<StevenK> persia: Not exactly. I have 1 2 3 4 on seperate lines, and I want to end up with 12 34 on seperate lines.
<StevenK> I thought paste could it, but it seems it can't
<persia> StevenK: awk can do that.  Now I have to go look for my scripts.  Given your preferences for newfangled human-readable languages, you might find perl easier (only chomp every other input line)
<StevenK> Since the script is in shell, I'd rather not pipe to Perl
<\sh> awk != human readable ?
<StevenK> Since if I'm going to end up piping to Perl, I may as well rewrite the script in Perl
<persia> StevenK: awk '/$/ {sub(/\\$/,""); getline t; print $0 t; next}; 1'
<persia> Note that this works by accident in a way, as it just grabs the second line when the first terminates, and then skips the actual processing of the second line, as it was already grabbed.
<ScottK> \sh: You can be confident that if I introduced a patch system, it wasn't quilt.
<StevenK> Haha
<\sh> ScottK, ohj well...it was siretart indeed...sorry scott ;)
<zul> heh dpatch is worse
 * persia suggests that the best patch system is that which allows the person adding patches to have an easy workflow, and is rarely the same for any two parties.
<ScottK> Well without dpatch-edit-patch it'd be painful, but with it is pretty easy.
<\sh> ScottK, quilt is also not so difficult .. well, when you understand how it works, sure
<ScottK> \sh: Yes.  I think if I used it regularly it would be OK.
<StevenK> Agreed. I sat down and fleshed out how to write a quilt patch
 * TheMuso prefers dpatch.
<\sh> not forgetting to set  QUILT_PATCHES=debian/patches that is ;)
<\sh> but I set this shell var now as default in ~/.bashrc
<siretart> \sh: I did what?
<\sh> siretart, introduced quilt in gnucash
<LucidFox> persia> Sorry, I was away
<siretart> bad siretart
<AnAnt> I use quilt
<LucidFox> I will try running combinediff right now and see if I can reproduce your problem
<\sh> siretart, but you never activated it, that was pkern ;)
<siretart> lol
<\sh> well, I'd remove it again, because the fixes are trivial...
<\sh> oh pbuilder-dist is so broken
<\sh> ah
<\sh> fixing it ,)
<\sh> oh nice
<\sh> how to fix this
<\sh>  $( [ -z $BINARCH ] || echo "--debootstrapopts \"--arch\" --debootstrapopts \"$BINARCH\"" ) gives
<\sh> --debootstrapopts '"--arch"' --debootstrap '"i386"' which failes
<mruiz> jono: Hi!  Any advance about LoCo Council ?
<mruiz> ups... wrong channel
<\sh> gnucash new upstream uploaded
<\sh> and hopefully found a fix for pbuilder-dist create
<norsetto> heya all
<slytherin> man-di: Did you forwarded info about lucene2 to whoever was facing the problem?
<mok0> yo, norsetto!
<ScottK> Hello norsetto.
<norsetto> hey guys
<Aloha> what is acceptable in the "section" area of my .changes file?
<TheMuso> Hey mok0, norsetto.
<norsetto> hey TheMuso
<Aloha> i can't figure it out. i put unknown and gutsy and the ppa rejected them both
<frafu> Hello, the last version of mousetweaks in revu is again the correct one. Could anybody please review it. Thanks in advance. http://revu.tauware.de/details.py?package=mousetweaks
<Aloha> 4311a61ec1e32bc027b27736d858e6be 518 gutsy extra hello-debhelper_2.2-1.dsc for example
<man-di> slytherin: yes
<slytherin> man-di: Thanks. :-)
<man-di> slytherin: and I have a plan when nothing happens in some timeframe
<man-di> the package is really outdated anyway
<slytherin> man-di: So what is the plan exactly. :-)
<norsetto> would anybody have any pointer re. ubuntu/debian udev policies?
<Aloha> ok changed to devel, lets see if that works
<man-di> slytherin: NMU if really relly needed as it fixes an RC bug
<slytherin> man-di: Which bug are you referring to?
<man-di> slytherin: that w3c-dtd-xhtml bug
<slytherin> man-di: Oh. I didn't know that was RC bug. :-)
<man-di> that but is not
<man-di> but it needs to be fixed to make lucene2 not FTPFS
<man-di> so its indirectly RC
<slytherin> ah, ok
<\sh> well...what should I do now with a wrong /etc/pbuilder/pbuilderrc that's another reason why pbuilder-dist create failes...
<\sh> looks like I have to imrpove the script...
<slytherin> man-di: I am not sure if I already mention but lucene2 may build with GCJ. At least the core part built when I disabled the unit tests. I will try again once the dtd bug is solved and package synced in Ubuntu.
<persia> slytherin: please subscribe me to the lucene2 sync bug if you get it fixed.  I have a personal interest in seeing that work.
<slytherin> persia: Sure. once the w3c-dtd-xhtml package is fixed in debian and man-di uses my fix for lucene2 in debian. :-)
<Hobbsee> oh noes, it's dholbach!
<ion_> :-((((
<mok0> Anyone know of a good versatile benchmark suite, that runs from a script?
<persia> mok0: There aren't any.  Or, there are lots, but nobody agrees.
<tuxmaniac> Hobbsee, dholbach
<Hobbsee> hiya tuxmaniac
<mok0> persia: I tried lmbench, but it requires a lot of interactive input
<bddebian> Heya gang
<mruiz> hi all!
<mok0> I have the old Byte Magazine benchmarks in a tar.gz file. I don't think it's in the archives
<bddebian> Hello mruiz
<persia> Hey bddebian.  Did trustedqsl work for you?  Is survex the last one?
<bddebian> persia: survex and ctsim are the hold-outs :(
<bddebian> persia: Oh, and Hi :-)
<persia> Right.  Have you tried survex 1.1?  I think ctsim is a lost cause, given the upstream response.  Similar reasoning led to dropping a few other packages (or just not building the WX GUI).
<bddebian> persia: Not yet.  I asked wookey about it when I filed the RC bug ;-)
 * persia cheers the power of RC bugs, and misses ajmitch
<norsetto> heya dholbach !
<persia> bddebian: Probably worth a shot.  Olly was at least interested, even if neither Phillip or I actually sent him a patch.
<bddebian> persia: Well get to work man.. :-)
 * persia is currently assigned 6 bugs, a library upgrade (and ensuing transition), REVU, and some upstream community work.  Maybe in a couple weeks, but FF nears...
<bddebian> :)
<emgent> malone  173153
<ubotu> Launchpad bug 173153 in audacity "[CVE-2007-6061] Denial of service and deletion of an arbitrary directory tree via symlink attack" [Undecided,Confirmed] https://launchpad.net/bugs/173153
<frafu> In fact, feature freeze is nearing and mousetweaks has not even passed revu yet. As the gui of mousetweaks is in the GNOME Mouse control panel, I wonder how long the main inclusion process will take!? I wonder whether there is a chance for mousetweaks to be shipped with hardy!?
<kdub> anyone know of a program that still needs packaging, or a program that needs repackaging because the current version is too old? I have experience with making deb's but i might still need to look at the ubuntu standards page
<LucidFox> kdub> you can look at needs-packaging bug in Launchpad
<LucidFox> * bugs
<kdub> LucidFox: hrm, thanks. i always seems to get lost trying to navigate around launchpad...
<LucidFox> kdub> https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&search=Search&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_contact=&field.bug_commenter=&field.subscriber=&field.component-empty-marker=1&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.tag=needs-packaging&field.has_cve.used=&field.has_no_package.used=
<LucidFox> find a package you like for which the bug is not assigned, assign it to yourself, and begin packaging
<persia> There's a shorter URL: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=needs-packaging
<kdub> thanks LucidFox and persia, its funny how i didnt find this in 20 minutes of looking for it
<kdub> and this is a motu-newbie question, but once i get it packaged, i can come back here and have someone look over the package to get it in the repos?
<persia> bddebian: Tracking down a reference shows Debian bug #418713 for your amusement
<ubotu> Debian bug 418713 in trustedqsl "Please build against wxWidgets 2.6" [Wishlist,Open] http://bugs.debian.org/418713
<LucidFox> kdub> You can upload it to REVU
<persia> !revu > kdub
<kdub> ah, very nice. i suppose i'll get to work then :-D
 * persia notes that the last REVU day for hardy will be 4th February, so it may not be the best time to start as a new packager.
<nixternal> hehe
<persia> kdub: You may find the learning path easier with bugfixing (although you'll need to learn launchpad for that)
<bddebian> persia: I know, I actually have an NMU prepared for it already ;-)
<nixternal> boo
<persia> bddebian: OK.  You just asked me before about the fix, and I happened across an old mail while searching for something else, and wanted to make sure the apparent closure in ~test1 hadn't kept it from your sight.
<kdub> persia: i've been sifting through bugs already, but i've been mostly just trying to eliminate bugs people report that arent really bugs
<LucidFox> Ubuntu has the concept of NMUs?
<LucidFox> Or are you talking about Debian?
<persia> LucidFox: When they are uploaded to Debian, yes :p
<LucidFox> ah
<jeromeg> hello
<jeromeg> i'm trying to get an SRU for klavaro in Gutsy
<jeromeg> bug 184112
<ubotu> Launchpad bug 184112 in klavaro "[SRU] klavaro crash" [Wishlist,New] https://launchpad.net/bugs/184112
<jeromeg> is my proposal ok ?
<persia> LucidFox: And in a looser sense, when the Maintainer is set to a specific team (e.g. media, xubuntu, mozilla, etc.) it is considered good form to check with a member of the team before uploading for any significant changes.
<LucidFox> I see.
<persia> jeromeg: You probably want to subscribe ~motu-sru to that bug
<persia> Further, you likely want to prepare a debdiff (or convince someone else to do so) for review.
<jeromeg> persia: ok
<jeromeg> i sucribed the wrong team
<jeromeg> *suscribed
<LucidFox> *subscribed :)
<persia> jeromeg: It gets a little confusing.  Both teams are likely interested, although only one is actually responsible for reviewing the change.
<jeromeg> persia: ok
<jeromeg> LucidFox: thank you :)
<norsetto> ping superm1
<LucidFox> On an unrelated note, does it make sense to sync -1 from Debian if it's identical to -0ubuntu1? Or if it contains functionally the same changes?
<persia> LucidFox: Little benefit to such a sync.  I usually skip those.  Some people like to sync them to make the Ubuntu variance appear less.
<danbhfive> hello all, is this the correct channel to ask about MIME types and packaging?
<\sh> hmmm
<LucidFox> In this case, I'll wait for the new upstream release of SMPlayer, which comes in a week or two, get it into Debian first, and then sync.
<\sh> some pakcages I uploaded are not showing up in hardy...strange
<LucidFox> doko> I see you have uploaded icedtea to Debian - excellent work!
<LucidFox> hopefully more Java packages can move to main now
<persia> danbhfive: It is a reasonable forum to ask questions, but not the best place to ask for changes in handling.
<nixternal> I am becoming more and more impressed with icedtea every day...I can build most of my standard java apps with it now, which is good
<persia> nixternal: Try using it on ARM or Sparc
<nixternal> hehe, no thanks!
 * persia touts gcj
<nixternal> gcj won't build any of my java apps
<zul> what hangman? :)
<nixternal> and if I forget to update-alternative and I have gcj, I am constantly cussing trying to figure out why it is broke :)
<danbhfive> persia: I have a project that I created, and it needs packaging, and it needs a file-type association.  Knowing that, would you say this is the place?
<persia> danbhfive: Depends on what you want.  You can ask a question here, but the actual mechanisms that drive it aren't managed by MOTU.
<danbhfive> persia: I'm not sure I follow
<persia> danbhfive: Just ask a question.
<DaveMorris> persia: if the last Revu day is the 4th, how many are there between here and then.  Or have you got a link to a site with the dates on?
<danbhfive> how do I set it up so that, when I double click certain text files, they are opened in my python script?
<persia> DaveMorris: Happens every Monday, so there are two more.
<dx9s_work> been stumped on this (have qt4-dev-tools 4.2.3-0ubuntu3 installed) "qt4-dev-tools:
<dx9s_work>   Depends: libqt4-core (=4.3.2-0ubuntu3) but 4.3.2-0ubuntu3.1 is to be installed" when it wants to upgrade
<persia> danbhfive: Assign them a MIME type, register the MIME type, and report that your app handles the MIME type in the .desktop file.
<dx9s_work> is there a qt4-dev-tools 4.3.2-0ubuntu3.1 ?
<persia> dx9s_work: Yes.  In gutsy-updates.
<danbhfive> persia: well, I don't know how to do any of that, is there documentation on that stuff?  or can you explain it?
<dx9s_work> persia, I have that in my source (did an upgrade from 7.04 Feisty) .. I suspect I am missing a line in /etc/apt/sources.list then...
<persia> danbhfive: I'm not the best person to ask (I don't tend to do new packages).  The dh_installmime manpage suggests the mime-support and shared-mime-info packages may have some documentation.  The freedesktop.org website can help with the .desktop file.
<persia> dx9s_work: Perhaps the line is missing in the chroot in which you are building?
<dx9s_work> not a .deb maintainer.. end user here
<danbhfive> persia: cool, thanks, I'll look into those
<persia> dx9s_work: In that case, yes, likely /etc/apt/sources.list.
<dx9s_work> persia, here is my current sources.list -> http://rafb.net/p/N7Nubr53.html
<persia> dx9s_work: Strange.  I have no explanation.  Might check with someone who looks at those more frequently (possibly in #ubuntu) or register a question.
<dx9s_work> persia, funny thing is similar setup at home ... and the dev-tools updated.. so it's weird
<dx9s_work> I thing -motu was targeted at .deb packaging issues
<dx9s_work> (and dependencies)
 * persia encourages someone to review awn-extra-applets or opensg, even though it's not REVU day, because they have now missed two REVU days, and really need another pair of eyes.
<dx9s_work> persia, do you know how to search the gutsy offical repos for .deb files then I can try to back trace it to a line that I might need to uncomment... those tools might be a part of a backport
<jeromeg> pochu
<\sh> ScottK, improve pbuilder-dist a bit so it's working now
<jeromeg> :
<\sh> s/improve/improved/
<persia> dx9s_work: They should all be in Packages.gz
<jeromeg> pochu: sorry. I was able to test scribes 0.3.3.3-1 and it seems to work fine.
<persia> \sh: Any leftovers still broken?
<jeromeg> pochu: may I ask for a sync ?
<dx9s_work> persia, heh ... sorry to ask .. where is that file?
<\sh> persia, I'll check the bug list before I push my changes
<persia> dx9s_work: There should be one in every path three levels down from http://archive.ubuntu.com/ubuntu/dists/.  The correct answer depends on what you want.
<LucidFox> Finally! mpeg4ip has passed NEW!
<pochu> jeromeg: sure. Let me know the # and I'll ack it.
<dx9s_work> persia, ty (semi-new to the whole .deb thing -- if you ask me anything about Slackware .tgz's I can answer it :) )
<LucidFox> libmp4v2 builds unbroken at long last!
<pochu> jeromeg: thanks for testing it!
<jeromeg> pochu: np
<persia> dx9s_work: Is there a semi-automated system to produce a .dsc from a .tgz?
<jeromeg> pochu: oh I'll just test printing before submitting it
<\sh> persia, fixed pbuilder-dist create, provide a sane source.list for --aptconfdir and remove $COMPONENTS_LINE which sadly didn't work (I wonder why) , added --http-proxy support and changed the $ARCHIVE workflow a bit, so it's possible to set $ARCHIVE before the pbuilder-dist call
<persia> \sh: Although I have never used pbuilder and don't really intend to start, I commend your attitude towards fixing everything for a new upload :)
<\sh> persia, hehe :)
<ScottK> \sh: Good.  It's nice when stuff actually works.
<LucidFox> no kde4libs on hppa? that's a shame
<LucidFox> looking at the build log, it just segfaulted for no apparent reason
<dx9s_work> persia, okay I can't answer that.. .dsc description files? mainly there is no standard method for dependency checking ... 3rd party tools that do okay but nothing perfect...
<persia> dx9s_work: :)  That's OK.  I didn't really expect there to be one.
<jeromeg> pochu: the print dialog causes the following erros in terminal but works: http://paste.ubuntu-nl.org/53036/
<pochu> Do we need a bulb next to the new packages in REVU? It makes the rows too high
<pochu> jeromeg: please go ahead. I don't think that's a regression, and I can't say that's scribes' fault...
<persia> pochu: source is in LP :)
<dx9s_work> persia, yeah, different methods for updates... some just hack the changelog file and apply them in order (slack-apt) and so forth.. but without dependency checking -- lot of tgz maintainers try to link the binaries to generic (symlinked) libs so instead of libBLAH.so.0.1.123 .. it's libBLAH.so.0 (or *.0.1) so updates don't break because of specific versioning.
<pochu> jeromeg: and since it works ;)
<jeromeg> pochu: ok :)
<persia> pochu: If you're hacking, I'd like to see hearts for >1 advocates, bulbs for 1 advocate, glasses for 0 advocates, and hammers for rejections.  The two icon bit was more important when updates were going to REVU as well (now we use debdiffs & interdiffs).
<pochu> persia: how do you reject a package in REVU?
<mok0> persia: don't tell him
<persia> pochu: A rejection happens when someone who is registered as a reviewer (as opposed to a contributor) leaves a comment without advocating.
<persia> mok0: Better to tell him: otherwise he'll be rejecting my accident :(
<jeromeg> pochu: bug 185106
<ubotu> Launchpad bug 185106 in scribes "Please sync scribes 0.3.3.3-1 (universe) from Debian (unstable)" [Wishlist,New] https://launchpad.net/bugs/185106
<pochu> jeromeg: thanks
<jeromeg> pochu: np
<mok0> :-)
<smarter> hi
<pochu> persia: I see, thanks
<smarter> could someone please review my extremetuxracer package? :) http://revu.ubuntuwire.com/details.py?package=extremetuxracer
<mok0> smarter: what's extreme about it?
<persia> mok0: It's extremely better than the aging nearly abandoned upstream tuxracer we have in the archives
<smarter> mok0: it crashes your computer if it doesn't like your graphic card :P
<dx9s_work> persia, fixed it.. gonna compare the pasty to what I have now... not exactly sure which lines I've changed (used the gui -- which is nice, but text files are forever! *lol* )
<smarter> tuxracer is not in the repo
<smarter> ppracer is in the repo
<smarter> and is dead
<mok0> smarter: nice excuse for getting a new one :-)
<persia> Ah.  Right.  We have planetpenguinracer
<smarter> tuxracer is commercial now IIRC
 * persia points at Debian bug #461911 as justification for extremetuxracer
<ubotu> Debian bug 461911 in planetpenguin-racer "planetpenguin-racer is deprecated, please package Extreme Tux Racer" [Wishlist,Open] http://bugs.debian.org/461911
<smarter> and bug #53299
<ubotu> Launchpad bug 53299 in ppracer "RFP: Extreme Tux Racer" [Wishlist,In progress] https://launchpad.net/bugs/53299
<TheMuso> How many changes does that game have to go through?
<TheMuso> First tuxracer, then planet penguin racer, and now this.
 * persia corrects the link relationship
<persia> TheMuso: Better than most games.  At least in this case, someone always picks up the ball (or hill, depending on how you look at it)
<dx9s_work> persia, think it was in universe someplace
<TheMuso> persia: True.
<\sh> bug #175183 also fixes
<ubotu> Launchpad bug 175183 in ubuntu-dev-tools "pbuider-dist fails to create chroot" [Medium,Confirmed] https://launchpad.net/bugs/175183
<\sh> -s+d
<mok0> smarter: the first thing I do when playing with a new program is to look at the man page. I think your etracer.6 is very short and you may want to sell the program better.
<\sh> and bug #172943
<ubotu> Launchpad bug 172943 in ubuntu-dev-tools "pbuilder-dist: Optionally allow to use gksudo instead of sudo" [Wishlist,Triaged] https://launchpad.net/bugs/172943
<smarter> mok0: well, I basically copy&paste the ppracer man page
 * dx9s_work thanks persia  (even tho not much help, it still was enough)
<smarter> I'm not very good at doing that ^^'
<mok0> smarter: add some of your own enthusiasm for the program
<smarter> mok0: I can try ;)
<mok0> smarter: why is it better than tuxracer? Is the graphics good? Sound? Music?
<mok0> smarter: game play? tell about how tuxracer is cult
<mok0> smarter: tell the story of tuxracer, how it developed into extreme
<mok0> smarter: what graphics cards are supported
<smarter> that's a manpage, not a complete review :o
<mok0> smarter: brief description of key bindings
<sistpoty|work> mok0: why should that be in a man page?
<smarter> and I don't think there's a list of supporter graphic card
<mok0> sistpoty|work: because it's nowhere else and he should sell the program
<mok0> IMHO anyway...
<sistpoty|work> mok0: the (long) discription is for that... in the man page I expect to find information on how program options, eventually directories or controls of it
<persia> sistpoty|work: There are lots of manpages with amusing history.
<smarter> Is there a good (Qt) manpage editor?
<mok0> sistpoty|work: I am not saying that information should not be there
<pochu> persia: hearts for >1 or >=1 advocates? I think the later is better, don't you?
<mok0> smarter: if you don't like to edit manpages, check out asciidoc, you can generate man pages from a simple layout
<mok0> smarter: it's just my opinion, anyway, and I am not a MOTU ;-)
<persia> pochu: adv<0:hammer, adv=0:glass, adv=1:bulb, adv>1:heart would be my thought.  "Needs work", "Needs a look", "Turned someone on", "We love it"
<pochu> persia: hmm, advocates < 0 ? Does REVU adv -= 1 when you don't advocate a package?
<sistpoty|work> pochu: nope, adv=0 can never hapen
<persia> pochu: Not really, but when a MOTU leaves a comment and doesn't advocate, it counts as negative advocation in a way (and no, this isn't how the code works)
<sistpoty|work> +p
<persia> sistpoty|work: Hrm?  Do you mean to say that when a MOTU comments, the state changes (and this cannot be prevented), or that there can never be 0 advocations for a candidate?
<frafu> TheMuso: I would like to let you know that I managed to upload the correct version of mousetweaks a second time to revu. So if you still intend to review it (which would be nice), you can simply pick the most recent upload.
<sistpoty|work> persia: no, I just wanted to say that my brain (which says kvirc as irc client->german keyboard layout) is making me heavy trouble here at work, where I have a us layout *g*
<TheMuso> frafu: I know, I will do my best to get to it, however I am somewhat busy.
<persia> sistpoty|work: I completely understand.  My current client has a US layout, which means I tend to pair "*...(" far too often :)
<sistpoty|work> persia: so there can never be adv<0, but negative advocations add the hammer (= motu comments w.o. advocate flag set) iirc
<persia> sistpoty|work: Right.  pochu's point was that double icons made the page too long.  Given that we discourage existing packages on REVU now, I agreed it made sense to consolidate, and suggested trying for a patch.  (While I'm sure you've enjoyed your recent monopoly on REVU work, I suspect you wouldn't mind a bit of help)
<frafu> TheMuso; thanks; should I perhaps ping dholbach, who is also motu and a member of the accessibility team (at least I think so) ?
<persia> frafu: You just did :)
<TheMuso> frafu: He doesn't do accessibility stuff any more.
<dholbach> frafu: I'm a bit busy right now, sorry
<sistpoty|work> persia: sure, every patch is welcome :)
<TheMuso> dholbach: I will get to it in due course.
<dholbach> frafu: I'm not member of the team anymore
<jeromeg> persia: could you please have a look at bug 185112 ?
<ubotu> Launchpad bug 185112 in torcs "Please sync torcs 1.3.0-2 (universe) from Debian (unstable)" [Wishlist,New] https://launchpad.net/bugs/185112
<frafu> dholbach; I just got informed about it; thanks nevertheless for your willingness to do it if you had time; TheMuso: thanks for you doing it. I won't disturb you (both) any longer
<jeromeg> persia: i think that the delta you introduced in 0ubuntu1 has been applied to -2 in debian
<DaveMorris> can you make a package the same across multiple releases.  i.e. I have a almost 1GB doc package, can you make it so it appears only once in the repo?
<persia> jeromeg: I can still crash torcs with a broken sound configuration despite the supposed fix for Debian bug #445806.
<ubotu> Debian bug 445806 in torcs "Torcs can crash if OpenAL is unable to open a sound device" [Wishlist,Fixed] http://bugs.debian.org/445806
<smarter> I can make a cooler manpage if it's really important but if someone could review my package before I upload again the ~30MB I'll appreciate :) http://revu.ubuntuwire.com/details.py?package=extremetuxracer
<jeromeg> persia: but it looks like the patches are the same
 * persia looks again
<pochu> DaveMorris: I don't think so.
<desertc> Greetings grand MOTU.  Thank you for your support of Ubuntu.  It continues to be the best operating system anywhere.  May I ask your attention on a package issue?
<desertc> http://packages.ubuntu.com/gutsy/graphics/scribus
<desertc> The standard operating procedure in #scribus is to instruct all Ubuntu users to this page, when they say the packaging for Scribus is incorrect in Ubuntu:
<desertc> http://wiki.scribus.net/index.php/Getting_Scribus_on_Ubuntu/Kubuntu_up_and_running
<persia> jeromeg: Ah.  Yes.  I previously played with the xrandr change, and didn't sync because I didn't think the try/catch clause was also included.  Thanks for bringing it to my attention.
<cyberix> persia: Does my new copyright file look ok to you? http://revu.tauware.de/revu1-incoming/malbolge-0801211640/malbolge-0.1.1/debian/copyright
<jeromeg> persia: shall i suscribe ubuntu-universe-sponsors or you will take care of the ACK ?
<persia> cyberix: Yep.
<persia> jeromeg: I'm building it now :)
<persia> (plus I get to fix it when it breaks, so ...)
<jeromeg> persia: i know i should have asked you before filling the bug but i id things the other way round :)
<jeromeg> persia: ok
<desertc> The channel admins have said they were unable to get MOTU managers to correct these issues, and they are requesting all Ubuntu users to obtain different versions of the program, instead of the Ubuntu packaged software.
<persia> jeromeg: Don't worry about asking me for any of my syncs or merges.  I'm subscribed to bugmail for any packages I'm actually interested in, so I see them anyway, and I'm not very concerned about the size of my +packages
<desertc> Is there a representative who can seek clarification in #scribus?  I can see you look very busy, of course.
<jeromeg> persia: ok
<persia> jeromeg: On the other hand, feel free to ask me any questions about said syncs or merges :)
<jeromeg> persia: i just wanted to train a little and do a merge, but in fact I realised it could be synced :)
<persia> desertc: I'll visit (although I may not be able to provide a satisfatory explanation)  Please introduce me
<desertc> persia: right
<zul> StevenK: ping
<persia> jeromeg: Processing a merge and discovering a sync is a great way to do that :)
<jeromeg> persia: yep, but to not for training to merge packages :)
<TheMuso> zul: another 7 hours or so I'd say and he'll be around
<zul> damn it
<persia> jeromeg: I recommend checking the Debian list of recently closed RC bugs in combination with multidistrotools to find a good source of merge bugs.  The RC bugs tracker is down right now, so it's a bit manual.
<jeromeg> persia: i use DaD or MoM
<jeromeg> persia: got to go
<jeromeg> persia: please let me a comment on the bug report if something is wrong, but for me it builds fine
<persia> jeromeg: Those are also useful tools, but not so good at finding the ones that really need the merge.
<jeromeg> persia: ok
<persia> jeromeg: I'll be advocating after a couple laps (after scribus).  Thanks again
<jeromeg> persia: np, thanks.
<jdong> LucidFox: I see mpeg4ip pushed thru NEW, have you commenced rebuilds yet? (I'd be happy to do em right now)
<jdong> superm1: ooh oooh oooh! new monodevelop!!!!!!! THANKS!!!
<jdong> (yeah yeah I just got some dental word done, so deal with intoxicated jdong for a while)
<LucidFox> jdong> mpeg4ip hasn't reached the archive yet
<LucidFox> gtkpod-aac briefly exited and re-entered depwait when it hit DONE
<jdong> LucidFox: ah, ok
<LucidFox> faac is also in depwait, so both it and gtkpod-aac should be rebuilt automatically
<jdong> LucidFox: ok, let's wait for faac to build, then I'd like to prod through mpeg4ip again with libfaac-dev enabled
<LucidFox> ah
<jdong> I'm afraid pushing it through right now would put us back at circular dep world :D
<LucidFox> you could also sponsor avidemux 2.4.0 :)
<LucidFox> after faac builds, that is
<jdong> LucidFox: sure, we'll take a look at that soon :)
<jdong> ok looks like I should take this shiny new loaner car out for another spin (literally) in the snow :)
<jdong> hopefully in an hour when I get back there'll be productive things to do :)
<emgent> hello people
<sistpoty|work> hi emgent
<TheMuso> persia: You're up late.
<persia> TheMuso: Far too late :(
<superm1> jdong, :)
<LucidFox> Well, at least it appears I have an excuse for the removed build-dependency of f-spot on beagle.
<LucidFox> "f-spot is in main, and beagle has been demoted to universe"
<RainCT> Hi
<TheMuso> Hey RainCT.
<\sh> RainCT, I fixed some stuff in pbuilder-dist and added some new functionality...(sudo replacements included)
<RainCT> mruiz: is it still necessary to modifiy gnome-chess.install now that you've patched the Makefile?
<RainCT> \sh: I know. If it was already commited I'd have told you that you're my hero ;P
<\sh> RainCT, just testing the packaging...included even the bash completion;)
<mruiz> RainCT, I don't think so... I'll fix it
<RainCT> \sh: great! :) (but next team please ping me if you work on some bug assigned to me.. if I hadn't had exams I would have already started working some of those)
<\sh> RainCT, I tried...;)
<\sh> RainCT, ok...I'll push the changes now to bzr
<RainCT> (altough I realize they shouldn't be assigned to me until I really start working on them :P)
<RainCT> heh
<\sh> and if someone has time please test them...before I create a new upload thx :)
<RainCT> I'll do so now :)
<\sh> ok..rev 60 is just coming up :)
<\sh> RainCT, but if you checkout...check your COMPONENTS_LINE code it doesn't work...I fixed it through introducint --aptconfdir with sane sources.list
<foolano> hi
<foolano> what's the next step after uploading a package to REVU?
<foolano> waiting for review?
<sistpoty|work> foolano: yep
<sistpoty|work> foolano: you can also post a link to your upload right here, maybe s.o. is interested in reviewing ;)
<foolano> ok i c
<pochu> sistpoty|work, persia: I'm with the REVU patch, and I have a little question. Actually for a package, new = True if it has >= 2 advocates in case it's a new package, or >= advocates in case it's an update. Since we don't want package updates in REVU anymore, does it still make sense to do that distinction?
<\sh> RainCT, should be up now...but I don't see the changes on LP until now
<RainCT> foolano: yes. if it's Monday somewhere on the world annoy people here asking for review (but only a little bit :P), and if it isn't Monday you can ask anyways :P
<sistpoty|work> pochu: feel free to drop that
<persia> pochu: Not really.  All the more so because the NEW package checking is a little odd (it only checks at the time of the first upload, so any package first on REVU shows as NEW)
<foolano> I've just uploaded two perl modules to REVU we are using in eBox:
<foolano> http://revu.tauware.de/details.py?package=libnet-cups-perl
<foolano> and http://revu.tauware.de/details.py?package=libtree-perl
<sistpoty|work> persia: heh, the complete codebase is a little odd *g*
<persia> sistpoty|work: For most use cases (especially when people follow the guidelines (which ought be properly written somewhere rather than passing as textual tradition here)) it works perfectly.
<\sh> btw...we don't have this "don't advocate your own packages anymore", right?
<pochu> sistpoty|work, persia: sorry, I meant isReady = True if ... So I'll change it to "isReady = advocates > 1" always (without checking whether it's a new package or not). I think that will discourage people to submit updates to REVU, as that means the need 2 acks to get a heart and not 1 as now :)
<persia> pochu: Maybe, but the fact that someone checks the packages once every couple weeks, and rejects all the non-NEW packages with a comment helps too :)
<persia> pochu: And thanks for helping with the code :)
<roderik> I'm having a litte problem creating a rules file that compiles one mono .exe file and installs it in /usr/bin. In build I do " gmcs -out:$$(pwd)/debian/tmp/usr/bin/mmcl.exe" but when running in binary-arch " install -m 755 -T debian/tmp/usr/bin/mmcl.exe  /usr/bin/mmcl.exe" i get a permission denied when building it in pbuilder? This seems strange since the thing uses fakeroot?
<\sh> RainCT, and for the --debootstrapopts subshell call, it wasn't working, too, just setting it by default helps a lot and doesn't matter even for the main arch
<pochu> persia: my pleasure :) I hope I do more reviews after this is applied... And next thing will be the cookies issue ;)
<\sh> btw..when someone reviewed and added a comment, please redirect them to the very same page, if not, press "reload" in your browser, and you have another comment send ;)
<RainCT> \sh: I see it's currently priting everything it does (set -x).. forgot to remove this? :P
<\sh> argl
<\sh> moment
<\sh> well...if it works I'll remove it with the next push;)
<\sh> oh wow..build failures in gnucash, something I didn't see on amd64
<RainCT> \sh: and.. are you saving the sources.list in $BASE_DIR/etc for some reason? (unless I'm overlooking something, I think it would be better to just create it in /tmp and remove it afterwards)
<\sh> RainCT, nope...I added --aptconfdir for it...it gives the user the possibility to add even alien archives ;)
<sistpoty|work> pochu: sorry, was afk for a moment... as persia wrote: just get rid of that code fragment, I don't think we'll need it any longer
<\sh> RainCT, depending on the ubuntu release...for hardy just the default line, for dapper|edgy|feisty|gutsy it enables even the security and updates archive for the pbuilder
<RainCT> \sh: Â«it gives the user the possibility to add even alien archivesÂ»   wouldn't the file be overwritten before running pbuilder anyways?
<\sh> RainCT, ha...fixing ;)
<RainCT> \sh: heh.. now it makes more sense :)
<\sh> RainCT, ok..fixed
<RainCT> \sh: a last complaint (well, actually it's a suggestion).. what's about looking at $PBUILDAUTH before $DESKTOP_SESSION, to allow people to use arbitrary commands (like using sudo even if they are in GNOME, or run gksudo with -g)?
<\sh> RainCT, where is pbuildauth coming from?
<rzr> hi
<RainCT> \sh: it would be a new variable, that users could set in .bashrc or wherever (like there is $PBUILDFOLDER already)
<\sh> RainCT, ah :)
<rzr> i was wondering, how command reportbug  is working on ubuntu ?
<\sh> RainCT, good idea :)
<RainCT> \sh: in bash_completion: Â«options='create update build login execute dumpconfig'Â» => Â«options='create update build clean login execute'Â»  (and you forgot to change the header) :)
<RainCT> \sh: ok, that's all; now I'm happy :P
<\sh> RainCT, fixing :)
<\sh> RainCT, cool...ok PBUILDAUTH support added
<pochu> sistpoty|work, persia: bug 185133 :)
<ubotu> Launchpad bug 185133 in revu "Improve package images so that there is just one image per package" [Undecided,New] https://launchpad.net/bugs/185133
 * LucidFox pings nixternal
<LucidFox> nixternal> looking at the kblogger-kde4 package, cmake.mk has been integrated into cdbs proper, so there's no need to ship it with the package
<\sh> RainCT, pushing
<jpatrick> LucidFox: I believe the all KDE4 packages se a different version
<nixternal> LucidFox: they have fixed the bug then? the reason behind including cmake.mk in debian/cdbs is because of that...all of our KDE 4 packages come with that cmake.mk
<LucidFox> ah
<nixternal> there is a bug in debian, or was a bug in debian, that broke cmake builds
<mruiz> RainCT, I uploaded a new debdiff
<RainCT> mruiz: seen it :)
 * nixternal checks out debian kde4/cmake repo
<\sh> if nobody has objections, I will create a new upload for ubuntu-dev-tools
<sistpoty|work> pochu: excellent, thanks...
<sistpoty|work> pochu: I'm not entirely sure, if I'll find the time to look at the patch in detail this evening though
<\sh> dholbach, ping do you have something for ubuntu-dev-tools which needs to be bushed to trunk?
 * sistpoty|work needs to go home now
<sistpoty|work> cya
<_MMA_> ScottK: Is bzrtools set to be backported from hardy as well?
<ScottK> _MMA_: I don't know.  I haven't been doing that one.
<foolano> I've just realised that I uploaded the package as a debian-native package. I already fixed that with the proper .orig.tar.gz  and stuff. How should I proceed to update the one which is uploaded in REVU?
<dholbach> \sh: no, I don't
<\sh> dholbach, ok...preparing a new package then
<_MMA_> Ok. Ill have to find out who.
<emgent> heya dholbach
<ScottK> foolano: Just upload the new package should be enough.
<foolano> ScottK: do i have to increase the package version?
<ScottK> foolano: No.
<foolano> ok thanks
<AnAnt> persia: Hello, I just uploaded a new versio of ubuntume-gdm-themes, I hope you would review it
<AnAnt> brb
 * norsetto -> dinner
<desertc> If an application developer wants to work with Ubuntu to improve their packages, what is the official channel of communication?
<desertc> Is there a better way to communicate than just submitting a bug-fix request?
<ScottK> desertc: Is it in Universe or Main?
<\sh> Accepted: ubuntu-dev-tools 0.25 (source)
<desertc> Universe, please
<ScottK> desertc: Show up here and discuss it has worked in the past (spe being the most recent example).
<desertc> Thank you.
<\sh> hmm...
<\sh> how can I fix this: /usr/bin/ld: .libs/Transaction.o: relocation R_X86_64_PC32 against `mark_split' can not be used when making a shared object; recompile with -fPIC
<ScottK> Add -fPIC to the compiler options?
<\sh> ScottK, already did...
<ScottK> Oh.
<\sh> no change...added it to the makefile.am as well, rerun autofoo
<\sh> no change
<\sh> ah wait..-fPIC is LDFLAGS or CFLAGS?
<ScottK> Does the package that provides R_X86_64_PC32  need to be recompiled with -fPIC?  Don't recall.
<\sh> ScottK, problem is , how do I determine this?
<\sh> which package or which lib ;)
<broonie> That's not a name of a symbol, it's a type of relocation but yes, check that whatever it links against isn't busted.
<CyberMatt> https://bugs.edge.launchpad.net/ubuntu/+bug/164213 Is there somthing i can do about this
<ubotu> Launchpad bug 164213 in ubuntu "[need-packaging] burnstation" [Wishlist,Triaged]
<\sh> broonie, what's the easiest way? I think it was introduced in a gnome* upload today somehow
<CyberMatt> upstream debian/ upstream = AFK
<CyberMatt> freeze soon
<broonie> \sh: Off the top of my head, peer at things with readelf -a
<\sh> broonie, thx :)
<\sh> ok...it looks like on i386 it's not failing...only amd64
<broonie> i386 will never get this sort of error, there are so few registers that everything ends up being PIC anyway.
<\sh> broonie, I think something was broken by the new gconf upload...which fixed a pkgconfig bug
<\sh> broonie, to early for success: ../../src/engine/.libs/libgncmod-engine.so: undefined reference to `mark_split'
<warp10> If upstream ships a debian/ within the tarball, what's the best to do if I want to package it?
<CyberMatt> warp10, you ask upstream to rm it and if thet don't...
<CyberMatt> thats what i'm trying to figure
<blueyed> warp10: https://wiki.ubuntu.com/UbuntuDevelopment/FAQ#head-bfd54122250e4e424158dd506e4117dab25f0d21
<CyberMatt> i suppose you could hack up getorig-source but I'm lazy
<warp10> blueyed: yeah... I was looking for that page, read the whole Pacakging Guide and forgot UbuntuDevlopment/ :-S
<warp10> CyberMatt, blueyed: thanks
<CyberMatt> blueyed, thanks for finding that
<jdong> ooh looks like faac is built in several arches already
<CyberMatt> i knew it was there
<jdong> well onwards and upwards!
 * jdong breaks the rest of the media stack
<CyberMatt> warp10, what are you packing just curious
<\sh> ok...found why gnucash ftbfs
<CyberMatt> \sh, now i can die happy :)
<CyberMatt> not really
<\sh> CyberMatt, well, I hope it's what I think is buggy ;)
<warp10> CyberMatt: Bug #185125
<ubotu> Launchpad bug 185125 in ubuntu "[needs-packaging] AutoZen" [Undecided,New] https://launchpad.net/bugs/185125
<CyberMatt> cool
<blueyed> sounds interesting.. :)
<jdong> superm1: what are your rhoughts on restoring faad and faac build deps on mpeg4ip?
<superm1> jdong, i'm scared
<jdong> superm1: shall we just sit quietly and don't do it till someone figures it out and complains on LP?
<warp10> CyberMatt, blueyed: indeed. I didn't think such a software could exist :)
<superm1> i dont like circular dependencies
<jdong> superm1: Marillat had them both enabled for ages without any significant complaints
<jdong> (circular deps aren't my friend either :D)
<superm1> well in my last email to him he is dropping one of them
<superm1> i forget whihc
<jdong> superm1: he dropped faac
<jdong> superm1: honestly I don't care about either :D
<superm1> are faac and faad rebuilt yet?
<jdong> superm1: so let's just sit tight and see if anyone on LP complains about its absence
<jdong> superm1: they are partially rebuilt (not all arches)
<superm1> oh okay
<superm1> jdong, you going to handle queuing rebuilds for other stuff?
<superm1> or you want me to grab anything?
<jdong> superm1: you just keep mplayer happy, idn where you keep track of all that stuff, I'll try to grab the rest ;-)
<superm1> jdong, haha okay
<superm1> i'll upload it with a versioned build depend then
<jdong> okies
<ScottK> jdong: Clamav backport to Dapper is kicked off.
<superm1> bah... someone updated mplayer without updating bzr
 * ScottK listens to the Dapper Buildd's groan as they wake up.
<\sh> G_INLINE_FUNC was the bugger for gnucash
<pochu> \sh: are you working on gnucash? Did you see bug 179104?
<\sh> bug #179104
<\sh> hmm
<ubotu> Launchpad bug 179104 in gnucash "Please merge gnucash 2.2.3-1 from debian unstable" [Wishlist,New] https://launchpad.net/bugs/179104
<pochu> My syntax was fine ;)
<\sh> pochu, gnucash_2.2.3-1ubuntu2.dsc
<\sh> pochu, already done...but forgot to set the closes syntax...please set it to fix commited
<jdong> superm1: hmm maybe you should do a build check for forgetting to update the VCS and scream loudly :D
<jdong> superm1: that would earn evil package of the year award :)
<superm1> jdong, haha
<superm1> yeah i like idea a lot
<jdong> :D
<superm1> i'm trying to find out who sponsored this right now
<jdong> superm1: funny how LP really doesn't easily tell that :D
<superm1> yeah
<jdong> gpg: Good signature from "Jonathan Riddell <jriddell@ubuntu.com>"
<jdong> superm1: ^^ :)
<superm1> argh.
<superm1> he should have known better
<jdong> superm1: hard to yell at him though :D
<superm1> yeah i know
<jdong> superm1: though it'd be helpful to drop him a polite heads-up in case it comes up again
 * superm1 really considers the VCS check during build
<jdong> superm1: but the more I think about it, the more I think a debian/rules VCS check is a good idea
<superm1> the problem is that no single package uses a VCS the same
<superm1> and mplayer is a lot different than many
<superm1> the way it does things
<jdong> yeah
<\sh> LaserJock, pbuilder-dist is working now ;)
<ScottK> jdong and superm1: Since mplayer is maintained by MOTU and there's no MOTU workflow that requires VCS use, I think you've got nothing to complain about.
<superm1> ScottK, its maintained by MOTU-media
<jdong> ScottK: it's less about complaining/blaming than about wanting to make sure people are aware of the preferred process...
<ScottK> superm1: OK.  I saw that and assumed it was MOTU (since that's how MOTU gets displayed in LP).
<LaserJock> \sh: oh? good to know
<superm1> jdong, i'm almost thinking of doing a check using bzr diff
<ScottK> LaserJock: Riddell is executing the clamav backport now.  So far so good.  Thanks again.
<\sh> LaserJock, pushed a new package to the archive...should be there soon
<LaserJock> ScottK: awesome
<\sh> ScottK, please let riddell do some syncs...;)
<jdong> superm1: easier, bzr cat :)
<jdong> superm1: just compare debian/changelog version numbers
<superm1> that requires a filename
<jdong> superm1: a diff would take too long
<superm1> jdong, bzr diff is very fast
<jdong> superm1: not if you don'w have the full version history
<superm1> oh.  which i do :)
<jdong> superm1: i.e. if I apt-get source mplayer, then you want to diff it to bazaar.lp.net, it'll take a century and a half
<jdong> superm1: however, if you just cat the debian/changelog on bzr and diff it to the local one, that is pretty fast
<superm1> yeah i was thinking locally, but that would take ages, and annoying to need the whole tree
<superm1> can the buildd's access the intarweb during builds?
<jdong> superm1: I'm thinking just md5sum the changelogs. requires no version history
<jdong> superm1: skip the check if DEBMAIL is unset?
<jdong> like what the maintainer spec does
<superm1> so perhaps this is better added to devscripts directly
<superm1> something to check for the vcs line in debian/control
<jdong> superm1: that'd be nice
<jdong> superm1: or if lintian can be modified to check VCS tags
<superm1> jdong, okay i'll fix this and think about that some more
<superm1> i'd rather a big fail than a lintian warning
<superm1> people easily overlook lintian stuff
<jdong> superm1: well sponsors are typically more paranoid :)
<mok0> Hey the new queue is empty
<superm1> we can't have that.  quick, everyone upload some NEW stuff :)
 * jdong uploads prevu2 :D
<mok0> :)
<jdong> nice; gtkpod-aac finally rebuilt on most arches
<CyberMatt> well ill have somthing in REVU soon so you guys can put somthing in the que or laugh at my mistakes whichever
<cbx33> ok guys I've totally forgotten how to submit to revu
<cbx33> anyone got any ideas
<AnAnt> dput revu <changes file>
<cbx33> thanks
<cbx33> done
<AnAnt> np
<the_belgain> hi there - i was wondering whether any MOTU might be able to review my fuppes package in REVU?  I uploaded it a couple of days ago, and would ideally quite like to try and get this accepted in time for hardy...
<ScottK> the_belgain: It's not a bad idea to include a link to the package on REVU in your request.
<ScottK> CyberMatt: ^^^ - You too.
<the_belgain> good point... here it is: http://revu.tauware.de/details.py?package=fuppes
<CyberMatt> i don't have it up yet
<CyberMatt> finishing touches
<smarter> could someone please review my extremetuxracer package? http://revu.ubuntuwire.com/details.py?package=extremetuxracer thanks in advance ;)
<vemon> hi! just updated a package in REVU according to the comments: http://revu.tauware.de/details.py?package=lashwrap
<vemon> anyone up for re-review? :)
<Kmos> vemon: revu day is over.. more next monday.
<ScottK> Kmos: There's nothing wrong with asking when it's not a revu day, just less frequently.
 * ScottK revu's when he has time, revu day or not.
<LaserJock> exactly
<nixternal> LaserJocky! HOLA!
<LaserJock> nixternal: yo yo, homeskillet
<nixternal> damn you, I went with hola cuz you stole it, now you are stealing homeskillet :p
<Kmos> ScottK: ok =)
<LaserJock> nixternal: yo, u check out the KDE4-izzle my shizzle? ;-)
<ajmitch> LaserJock: make the pain stop
<nixternal> I have been running KDE 4 fully since October pretty much...I haven't been in KDE 3 since probably the beginning of December...forgot what it looks like :)
<nixternal> ajmitch: howdy!
 * ajmitch runs
<LaserJock> ajmitch: pain? that was nothin'
<LaserJock> ScottK: does this look like an OK rules for a python app: http://revu.tauware.de/revu1-incoming/memaker-0801222130/memaker-0.9.4/debian/rules
 * ScottK2 looks
<ScottK2> LaserJock: Depending on what's in the make file, probably yes.
<LaserJock> ok, I just wasn't sure about the use of pyversions
<LaserJock> when using pycentral it seems to be a bit more work than necessary
<ScottK2> LaserJock: The key thing is to end up with the Python modules in /usr/share/python-central.  Any app goes in /usr/bin as usaul.
<tjaalton> hmmh, pbuilder claims that libmozjs-dev is a virtual package, which it isn't. What am I missing?
<cbx33> LaserJock, ogra showed me that way
<cbx33> ;)
<selckin> its amasing how many people give the exact same awnser on some mailing lists
<selckin> too lazy to read replies i guess
<jdong> selckin: you can't really blame them... I have 500 incoming mails to go through every day, I'm sure I'd sometimes fire back a duplicate reply
<selckin> isn't that way more work then quickly glanse over 3 replies?
<jdong> selckin: not always when you read the original question and are 1000% confident you have the correct solution
<jdong> selckin: you'd be surprised at some of the mailing list blind-leading-the-blind threads how quickly they can wander off to another galaxy :)
<selckin> supose
<jdong> selckin: but as an asker, I'd feel BETTER about a solution too if more than one person suggest it
<jdong> so I don't think multiple replies are entirely useless, unless the OP has replied the problem was solved
<selckin> ok, you convinced me
<CyberMatt> a few more adjustments
<huats> norsetto: Hey Hey hey
<huats> :)
<huats> such a long time without talking to you :)
<apachelogger> anyone knows if I have `libgif-dev | libungif-dev` as build-deps, whether it will prefer libgif over libungif?
<LaserJock> yep
<LaserJock> if neither are already installed I believe
<ScottK> apachelogger: Yes it will if neither is installed.  If libungif-dev is installed, it won't install libgif-dev.
 * ScottK high fives LaserJock
<LaserJock> ;-)
<huats> anyone can tell me who to ask to mentor me to fix this bug 146710
<ubotu> Launchpad bug 146710 in hal "backlight brighness control does not work (Samsung Q45 with Nvidia GForce 8400M)" [Undecided,Confirmed] https://launchpad.net/bugs/146710
<apachelogger> ScottK: excellent, thanks :)
<huats> since I got this laptop at work today and it really bother me...
<norsetto> hey huats, how is it!?
<nxvl_work> norsetto: hi!
<norsetto> hey nxvl_work
<nxvl_work> norsetto: how is it going
<jdong> anyone know if there's any work towards packaging clutch (transmission remote control UI) or if it's past deadline(s) to do so?
<norsetto> nxvl_work: fine thanks, hope you too?
<jdong> I think it'd be a great package for Hardy universe to complement our new BT client :)
<nxvl_work> norsetto: good, with lots of work, and a little concern about what happens on Bug #18256, but i hope it was just a mistake
<ubotu> Launchpad bug 18256 in ubuntu "gpsd: new changes from Debian require merging" [Wishlist,Fix released] https://launchpad.net/bugs/18256
<cbx33> hey guys
<cbx33> how come I can't advocate on revu
<cbx33> Logged in as petesavage@ubuntu.com ( Contributor )
<cbx33> I am a MOTU
<TheMuso> cbx33: Probably because revu has been down, and has had a db rebuild since the last time you logged on.
<cbx33> ahh
<cbx33> who is an admin?
<TheMuso> cbx33: I'm not sure. I think I have ssh access to the box, but beyond that I don't think I can do much else to help revu.
<norsetto> nxvl_work: hmmm, perhaps you mean a more recent bug and dropped a digit?
<imbrandon> cbx33: http://people.ubuntuwire.com/~uwsa/
<imbrandon> ^^ REVU admins
<imbrandon> cbx33: what do you need ?
<nxvl_work> norsetto: heh, yes
<nxvl_work> norsetto: Bug #182567
<ubotu> Launchpad bug 182567 in samba "smb.conf example: Configuration Directive Inconsistencies" [Wishlist,Fix released] https://launchpad.net/bugs/182567
<cbx33> can I be able to advocate on revu please imbrandon
<emgent> hello there
<imbrandon> cbx33: can you login successfully ?
<cbx33> yes
<emgent> persia, ping
<cbx33> i can comment
<imbrandon> ok lemme check it
<cbx33> just not advocate
<cbx33> thanky
<emgent> heya imbrandon norsetto
<imbrandon> ello
<norsetto> hey emgent
<norsetto> nxvl_work: why concerned? whats the problem?
<nxvl_work> norsetto: that i make a debdiff with some changes, then chuck add some more changes and removes mi name from changelog
<norsetto> nxvl_work: oh I see, that kind of concern
<norsetto> nxvl_work: well, don't let it bother you, must have been an oversight
<emgent> persia, audacity bug it'snt fixed in hardy.
<emgent> persia,    defaultTempDir.Printf(wxT("/tmp/audacity%d.%d-%s"),
<emgent>                          AUDACITY_VERSION, AUDACITY_RELEASE, wxGetUserId().c_str());
<emgent> see too: http://people.debian.org/~nion/nmu-diff/audacity-1.3.4-1_1.3.4-1.1.patch
<norsetto> nxvl_work: I think that the problem is that he was asked to look at the bug, so he fixed it, he didn't consider your patch at all
<nxvl_work> norsetto: nop, take a look at the changelog entries, those are the ones i wrote
<nxvl_work> norsetto: also dholbach always ask for someone of the team to check the diff before sponsoring them
<norsetto> nxvl_work: thats right, but since the package is in main and I guess chuck is maintaining it, he did it the fast way
<nxvl_work> norsetto: yep, and thats why i hope it was just a mistake
<nxvl_work> norsetto: but not less angry
<norsetto> nxvl_work: I'm quite sure it was, what is important is that you don't let it bother you, its not really worth it
<nxvl_work> norsetto: btw, i see there are calling for net MC Members, would you apply yourself, didn't you?
<CyberMatt> are http://revu.ubuntuwire.com/ and revu.t.d the same
<norsetto> nxvl_work: why should I? I'm a new guy on the block here, plenty of people more adequate than me for the post
<LaserJock> CyberMatt: I think so yeah
<nxvl_work> norsetto: because i think you have what it needs to make people happy working on MOTU, a really helpful and nice person
<nxvl_work> norsetto: and those things are more important than technical skills
<CyberMatt> i've been so busy contributing to debian its been quite awhile
<nxvl_work> norsetto: and more for the management of a community
<bddebian> Yeah instead of an old crotchedy jerk like me ;-)
<LaserJock> lol
<nxvl_work> norsetto: and as i think you don't know, it was you who gives me what i needed to make the effort on becoming a MOTU and don't quit :D
<nxvl_work> norsetto: since you where so patient, nice and helpful
<CyberMatt> good news is my packaging is like 70-80% better bad news is debian-policy = the-bible now
<norsetto> nxvl_work: you better stop here before I cry ;-)
<norsetto> nxvl_work: I'm also worried about bddebian, he has a tendency to vomit on my shoes if he is not at ease ....
<LaserJock> haha
<LaserJock> that's a looooong ways to go
<LaserJock> transatlantic vomit
<bddebian> hehe
<norsetto> LaserJock: hmmm, try with the b word and see if it still has the same effect on him
<LaserJock> hmm
<LaserJock> maybe we should find a pic to put on his wiki page
<cbx33> heheh
<LaserJock> alright guys, I'm out for a while.
<nxvl_work> norsetto: heh
 * nxvl_work HUGS norsetto
 * norsetto hugs nxvl_work
<CyberMatt> HAHA REVU's lintian and linda are out of date
<norsetto> nxvl_work: keep going mate, you have a good future ahead ;-)
<ScottK> imbrandon: Are you around?  I need some source backport help...
<nxvl_work> norsetto: i hope, i have just stop a little with packaging to make my python skills better
<Ubulette> which tag should I use to ask for sponsorship in main ?
<cbx33> man
<Kmos> Ubulette: subscribe to ubuntu-main-sponsors ?
<cbx33> it was fun being a motu again
<cbx33> ;)
<CyberMatt> http://revu.ubuntuwire.com/details.py?package=jailkit
<nxvl_work> Ubulette: ubuntu-main-sponsors
<Kmos> :)
<Ubulette> no tag ?
<CyberMatt> could someone take a look
<Ubulette> ok
<Ubulette> bug 185178
<ubotu> Launchpad bug 185178 in libpng "Please sponsor libpng 1.2.24" [Undecided,New] https://launchpad.net/bugs/185178
<norsetto> ok, time to go for me, see you all around
<TheMuso> cbx33: Was, or is?
<cbx33> TheMuso, is
<cbx33> I just havn't been around for a while
<TheMuso> cbx33: Right. Glad to have you bac.
<nxvl_work> Ubulette: you are asking for a merge?
<ScottK> cbx33: Welcome back then.
<Ubulette> no
<Ubulette> nxvl, debian is as behind as ubuntu
<nxvl_work> Ubulette: or the inclusion in hardy?
<cbx33> hehe
<cbx33> I just did my first actual upload to universe
<cbx33> heheh
<cbx33> I've made pacakge before
<cbx33> but someone else always uploaded them
<Ubulette> nxvl_work: isn't my description in the bug clear enough ?
<Ubulette> 1st line
<nxvl_work> nope
<nxvl_work> :D
<TheMuso> cbx33: What? You became a MOTU, and have never uploaded anything till now?
<nxvl_work> heh
<nxvl_work> really it is
<nxvl_work> :P
<Ubulette> ?
<Kmos> TheMuso: done by himself :)
<vemon> i though only motus have upload rights?
<vemon> besides uploading to revu
<cbx33> TheMuso, yup
<cbx33> funny eh
<TheMuso> Kmos: Yes, I know that.
<cbx33> ogra did a lot of my uploading
<cbx33> cos most of my stuff was going to main
<nxvl_work> Ubulette: its almos 5:17 pm here, my brain is turned upside
<TheMuso> cbx33: Yeah it is kinda funny.
<nxvl_work> i need to sleep
<cbx33> but it was great to hit that button
<cbx33> ;)
<TheMuso> cbx33: Was it a package update you uploaded, or a new package?
<cbx33> new
<Ubulette> nxvl_work, np, i know the feeling far too much
<TheMuso> Well don't forget to announce it to ubuntu-motu@lists.ubuntu.com
<cbx33> oh
<cbx33> i do?
<TheMuso> cbx33: Just a copy of the email you got from the ubuntu archive system is fine
<cbx33> oh i see
<TheMuso> it allows us to track new package uploads more easily
<cbx33> alright
<cbx33> will do that tomorrow
<TheMuso> Ok.
<nxvl_work> well, back to the conversation before
<nxvl_work> bah! norsetto is gone
<TheMuso> heh
<CyberMatt> why do i still have this nick
<RainCT> good night
<emgent> persia, ping
<persia> emgent: You need someone from SWAT to review that, not me.
<persia> (and I don't play virtual table tennis)
<emgent> persia, done. my debdiff it's attached :P
<emgent> heheh ;)
<emgent> for gutsy it's ok now, this night i will review for feist, dapper etc.
<emgent> :)
<rzr> persia: thx it's uploaded https://launchpad.net/ubuntu/+source/jaaa
<rzr> now let's sync it to debian
<the_belgain> hi - a maybe slightly OT question: I've accidentally uploaded a package to my PPA which doesn't have any ~ppaversion number appended to it.  is there any way for me to remove it from the archive in order to be able to upload multiple version of the package?
<the_belgain> i don't want to just bump the main version number, because that would prevent people from being able to just remove the PPA if the package was added to the main ubuntu repo
<Flare183> the_belgain: as far as i know you can't remove a package from your ppa yet...
<the_belgain> that's quite problematic, because making a single mistake can basically mean that your archive becomes somewhat unusable
<Fujitsu> the_belgain: With the next release of Launchpad, you should be able to delete packages easily. For now, you can ask a question on the launchpad project on Launchpad to have it removed.
<emgent> Fujitsu, heya!
<Fujitsu> emgent: Hi, about to run off again (I'm on holiday with limited Internet connectivity).
<the_belgain> Fujitsu: I tried that, but the IRC channel didn't seem to be very responsive.  oh wel
<emgent> Fujitsu, hehe np :)
<Fujitsu> the_belgain: You obviously didn't - ask a question on the launchpad project on Launchpad, not on IRC.
<Laibsch> Hi, I am fairly new to packaging for ubuntu.  I wonder what the recommended procedure is for creating a package from the information for a debian package (not an official debian package)
#ubuntu-motu 2008-01-23
<Laibsch> I tried the easiest route, just debuild the tree and upload to my ppa, but the package was rejected (obviously) because the information was for the unstable distribution which does not exist in ubuntu
<Fujitsu> Laibsch: Change the distribution in the changelog to an Ubuntu release.
<geser> Fujitsu: Hi, how are holidays?
<Fujitsu> geser: Pretty good, thanks. I'm about to head off again.
<Laibsch> Fujitsu: This is for openembedded.org.  The information is maintained in a version control system upstream.  Is there no easier way than duplicating all information and keeping it in sync?
<Laibsch> How does ubuntu handle debian packages for import?
<Laibsch> There must be some more elegant way, right?
<Fujitsu> Laibsch: The script does special evil things that modify the distribution in the .changes file, I believe, but that's bad, and is to be avoided.
<Fujitsu> One should not do that for manually uploaded packages.
<Fujitsu> Anyway, I have to go now.
<the_belgain> Fujitsu: thanks, I've asked for that package removal in the appropriate place now
<StevenK> RAOF: Bug 185099
<ubotu> Launchpad bug 185099 in apt "apt output in all caps on amd64 when stdin is /dev/null" [Undecided,Triaged] https://launchpad.net/bugs/185099
<RAOF> StevenK: Oh, cool.  That's the actual sbuild trigger?
<soren> Yeah, sbuild calls schroot blahbalhbalhbab 'apt-get -y install foo < /dev/null' or something to that effect.
<RAOF> Cool.
<soren> and due to weirdness in apt's termios handling that sets the pty to spew all uppercase stuff.
<StevenK> RAOF: Which makes keescook The Man.
 * RAOF prostrates himself before The Man
<StevenK> Haha
 * ryanakca grumbles at having to write a copyright file for a package (a compilation of libraries/bindings) with 50+ authors...
 * ryanakca grumbles at people not giving their email address in Copyright (C) 2007 John Smith
<DarkSun88> Mmh, nautilus crashes on my Hardy.
<crimsun> dist-upgrade
<DarkSun88> crimsun: Yes, I knew but there are packages that the dist-upgrade wants to remove.
<crimsun> using aptitude safe-upgrade ?
<crimsun> sorry, and* using aptitude safe-upgrade ?
<DarkSun88> I'll try it.
<RAOF> crimsun: Are you still a Debian ALSA teamer?  If so, or even otherwise, is my thinking in debian bug #436201 reasonable?  I'd like to get that done before FF.
<ubotu> Debian bug 436201 in libasound2-plugins "libasound2-plugins: Could we get an ia32 package for amd64?" [Wishlist,Open] http://bugs.debian.org/436201
<DarkSun88> crimsun: It works. Thanks a lot.
<crimsun> RAOF: yes, it's reasonable.  I read the e-mails earlier, but I don't like to post from yahoo since it's spam-nasty.
<RAOF> crimsun: Ta.  I'll look at that tonightish then.
<DarkSun88> crimsun: But that command doesn't update the packages?
<crimsun> DarkSun88: hmm?
<crimsun> safe-upgrade Upgrades installed packages to their most recent version. Installed packages will not be removed unless they are unused (see the
<crimsun> direct from hardy's aptitude(8)
<DarkSun88> crimsun: After that command, return me the prompt.
<crimsun> DarkSun88: well, if you've already executed aptitude safe-upgrade, it's likely it won't do anything but exit successfully if it completed successfully prior :-)
<DarkSun88> crimsun: Yes, I've already executed aptitude safe-upgrade but I repeat: It doesn't upgrade my packages. It said me that there are 84 packages not updated.
<ryanakca> do you put copyright for install-sh in debian/copyright?
<ScottK> ryanakca: Is it the same license as the rest of the package?
<ryanakca> ScottK: no, its MIT vs GPL
<andresmujica> helo motu`s .  i wonder if there's some guidance docs or suggestions at the wiki  in order to create a development enviroment for my laptop,  i want to develop and package some things for ubuntu but don't want to make my desktop a complete mess....
<ScottK> ryanakca: Then you need to mention it.  Not mentioning all licenses is an automatic reject.
<ScottK> andresmujica: Install build-essential, devsrcripts, and ubuntu-dev-tools and never compile outside of a chroot.
<ryanakca> ScottK: or no... wait... *checks* I'm not sure its MIT, I'll pastebin
<ScottK> ryanakca: As long as it's not GPL, it needs to be in there.
<LaserJock> andresmujica: chroots and pbuilder/sbuild are very helpful
<ryanakca> ScottK: http://paste.ubuntu-nl.org/53101/ ... what do I put it as?
<LaserJock> ScottK: clamav backport still going?
<ryanakca> ScottK: surprising thing is that the package got into universe /without/ a copyright file.
<ScottK> LaserJock: Yes.
<LaserJock> ryanakca: what package?
<ScottK> LaserJock: Riddell had connectivity problems so not all of them got kicked off properly.
<ryanakca> ScottK: well, the file was there, but it was still the default dh_make <Insert upstream issues>
<LaserJock> ScottK: ah, I see perhaps Hobbsee is coming to the rescue
<ryanakca> LaserJock: kdebindings-kde4
<Hobbsee> arrr!
<ScottK> Unfortunately the rest aren't source backports, so IIRC they can't be done through the web ui.
<Hobbsee> what are the rest?  binary backports or something?
<ScottK> Hobbsee: There the ones that they use their automagic script to pull them straight out of soyuz.
<ScottK> They are source, but no new source is uploaded.
<Hobbsee> ahhh
<ryanakca> ScottK: would something along these lines work as a copyright files (incomplete, yes...) http://blog.ryanak.ca/copyright ?
 * ScottK looks
<ryanakca> simply since there are quite a few copyright holders, each "owning" a section/branch/tree in kdebindings-kde4-4.0.0 ?
<LaserJock> ryanakca: ummm, that's messed up
<ScottK> Yeah.
<ryanakca> crap... so where do I put all the authors?
<ryanakca> all in a list, without saying who did what?
<ScottK> ryanakca: Collect each license together and say foo is copyright bar, alpha is copyright omega, and they are distributed under the terms of the blankety blank license
<ScottK> Also you need the bit like you have with LGPL 2.1.
<andresmujica> ok, thanks, i'm gonna explore those packages.
<LaserJock> andresmujica: for having chroots the schroot package is very helpful
<ryanakca> ScottK: ok, so would it be like the top or bottom part of http://blog.ryanak.ca/copyright2 ?
<bddebian> Heya gang
<LaserJock> hi bddebian
<bddebian> Hi LaserJock
<ScottK> ryanakca: Sorry.  I'm busy with $WORK and can't really focus on it.
<ScottK> ryanakca: As long as it's clear what license/copyright goes with what files and all the licenses are listed in reasonably compact and clear way, it should be fine.
<ryanakca> ScottK: ok, thanks :)
<LaserJock> shesh, my uni is getting crazy
<LaserJock> I keep getting tons of emails about safety
<StevenK> LaserJock: Ah, so they noticed your lab practices?
<LaserJock> apparently the answer to several rapes and a kidnapping is to have "Personal Safety Awareness Training"
<LaserJock> StevenK: no, my lab's not to horrible
<LaserJock> I've actually gotta brush up on lab safety for teaching next week
<bddebian> Here's one to make you shudder folks: https://nm.debian.org/nmstatus.php?email=bddebian%40comcast.net  ;-)
<bddebian> StevenK: haha
<LaserJock> bddebian: \o/
<bddebian> ajmitch would probably have a heart-attack :-)
<ScottK> bddebian: Congratulations.  Prepare to get a lot of practice waiting.
<bddebian> ScottK: Yeah I figure I'll be dead and buried before I actually get in but what the hell :-)
<LaserJock> does the AM actually have to meet with you?
<bddebian> I hope not :-)
<LaserJock> I see "ID to be checked by AM"
<jdong> what's a small package with an init script...
<jdong> ddclient? *checks*
<jdong> I just spent 20 minutes getting a watchfile to work on a new package :)
<nenolod> LaserJock, becoming a DD ?
<nenolod> LaserJock, if so can i whore you for uploads? (:
<bddebian> jdong: "Fun" sometimes aren't they? :-)
<LaserJock> nenolod: hah, no
<nenolod> LaserJock, no to which?
<LaserJock> both
<jdong> bddebian: and better... upstream doesn't provide an indexed downloads directory (403 forbidden)
<nenolod> LaserJock, then what application manager? :o
<jdong> bddebian: so I'm scraping the FRONT PAGE, the only place with an AJAXified download link
<bddebian> Ugh
<jdong> bddebian: so I'm betting $100 that by the time next upstream release comes, THIS WATCHFILE WONT WORK :)
<LaserJock> nenolod: bddebian is going for DD
<nenolod> oh. right.
<nenolod> LaserJock, i already knew that (:
<jdong> but there's some personal satisfaction in writing one
<nenolod> i'd go for DD but no debian person has signed my key. :(
<bddebian> Boy, that will just make ari's year.. :-)
<nenolod> i think being a ubuntu member would provide more value.
<nenolod> bddebian, oh yes. ari would love it if i became a DD (:
<bddebian> or 2 years, or 3 years... :-)
<nenolod> he'd probably have a heartattack
<bddebian> nenolod: No, I meant me.  We have a long "interesting" relationship :-)
<jdong> I can't find a file with an init script!
<nenolod> ah.
<jdong> forget it, let's look at apache
<nenolod> the only relationship with ari i have is a cooperative trolling one.
<nenolod> (;
<LaserJock> I don't think I'm really interested in DD, I think DM is enough for me
<nenolod> which reminds me
<bddebian> LaserJock: Are you on NM for DM ?
<nenolod> can i whore someone for an upload in a while? (:
<LaserJock> bddebian: not quite yet, gotta sen in my app
<LaserJock> *send
<bddebian> Ah
<nenolod> i'm packaging up a default skin for audacious for ubuntu
<nenolod> \:D/
<LaserJock> but I got everything I need
<nenolod> or do i need to upload it to revu
<ScottK> jdong: Just grab a randome tarball and run dh_make on it.  It'll give you a shell for an init.
<jdong> ScottK: yeah, actually I'm working from the dh_make examples
<jdong> ScottK: unsure whether to use init.d.ex or init.d.lsb.ex, I think the LSB variant
<ScottK> Use the LSB one.
<jdong> ScottK: then also I wanted to ask what to name it, but I figured that out by myself :)
<jdong> wow, debianizing a new daemon is so much fun :)
<jdong> (not)
<ScottK> Yeah.
 * ScottK is working on one too.
<nenolod> also, which is better, audacious-skin-human or audacious-theme-human ?
 * RAOF would go with theme.
<nenolod> nifty, thanks
<nenolod> (:
<jdong> skin-human sounds mean
<jdong> ;-)
<DarkMageZ> skin-cat =D
<nenolod> DarkMageZ, actually i may need your expertise with something in a bit (:
<rzr> hi
<rzr> are there some resources on backporting to dapper ?
<ScottK> rzr: What are you after?
<ScottK> !backports | rzr
<DarkMageZ> rzr, as in getting a package into backports or as in you backporting a package for yourself?
<ubotu> rzr: If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
<rzr> unicorn is broken in dapper
<ScottK> !SRU then.
<ubotu> Sorry, I don't know anything about sru then. - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<ScottK> Argh.
<ScottK> Stable Release Update.
<rzr> DarkMageZ: no i want to replace the one in repo .. I'll read this
<ScottK> rzr: If the one in the repositories is broken, we can do a stable release update to fix it.  Backports is for new features, not for serious bug fixing.
<ScottK> rzr: https://wiki.ubuntu.com/StableReleaseUpdates
<rzr> ScottK: the version in hardy is ok
<ScottK> rzr: Right, but backports is not enabled by default.  If a package is totally broken, we should try to fix it in updates so more people can benifit.  It's more effort, but worth it.
<rzr> ok i note this down for next weekend
<DarkMageZ> i heard rumors that debian was obsoleting gtk1.2 and removing it. is this true and if so is ubuntu following the same path?
<RAOF> Was that gtk1.2 or all the gnome-1 stuff?  Because I remember someone saying that they're finally reaching the bottom of the gnome 1 stack :)
<RAOF> It's possible that gtk1.2 will be included in that master plan.
<bddebian> It is suppose to go the way of the dodo
<bddebian> One of the reason xmms is scheduled for removal
<zul> crap i still use xmms
<Elly> use mocp instead =)
<bddebian> So do 12,000 other people according to popcon :)
<DarkMageZ> so i could reject a "needs-packaging" because it depends on gtk1.2?
<DarkMageZ> zul, use audacious.
<bddebian> DarkMageZ: I would unless they are willing to port it
<DarkMageZ> zul, it's similar to xmms and is still maintained.
<RAOF> What needs packaging and is dependent on gtk1.2?
<ScottK> Hopefully nothing.
<ScottK> New gtk1.2 sutff now isn't where we want to be going.
<ScottK> For Gutsy I had to stop something building a gtk1.2 variant to get it into Main.
<DarkSun88> Hi all.
<ScottK> Hi DarkSun88
<DarkSun88> Hi Scott.
<bddebian> Heya DarkSun88
<DarkSun88> Mmh, nautilus continues to crash.
<DarkSun88> bddebian: Hi. :)
<DarkMageZ> RAOF, AutoZen
<ScottK> DarkSun88: Think KDE.
<bddebian> Think xfce! ;-P
<DarkSun88> ScottK, bddebian: I think that now, I'll go to sleep. :D Gute Nacht.
<ScottK> Gute Nacht
<bddebian> Gnight DarkSun88
<jdong> does apache (1) have its config files in /etc/apache?
<Hobbsee> jdong: /etc/apache2/
<jdong> Hobbsee: apache 1.3.x uses /etc/apache2 too?
<Hobbsee> oh, i thought you were talking about apache(1), ie the manpage.
<Hobbsee> no idea then, sorry
<jdong> Hobbsee: well I'll guess it uses /etc/apache till someone screams at me otherwise :D
 * jdong is packaging the shiny clutch bittorrent webui
<ScottK> jdong: What apache1?
<ScottK> We don't have that anymore.
<jdong> ScottK: we don't have it anymore?
<ScottK> Nope.  Just apache2
<jdong> ScottK: pfft well that's even better!
<jdong> *happily removes apache1 references*
<nenolod> i don't know. am i going in the wrong direction for this: http://nenolod.net/audacious-theme-human.png -- it's intended to be the default theme for audacious in ubuntu.
<RAOF> Dear git: go faster.
<StevenK> Hah
<nenolod> git sucks honestly :/
<nenolod> take mercurial, make it use gitweb theme. problem solved :P
<bddebian> And bzr ROCKs..
 * bddebian hides
 * nenolod can't stand bzr
 * bddebian either
<StevenK> But bzr is great
 * StevenK can understand it
<nenolod> great for humans
<nenolod> i need revision control for nenolods instead (;
<nenolod> nenolods are only one human see :P
<StevenK> Understanding of git still eludes me, but I use it like once every three weeks
<StevenK> nenolod: What doesn't make sense about bzr?
<bddebian> Other than being slower than my grandparents? :-)
<StevenK> bddebian: Try 1.0
<nenolod> StevenK, it's not that bzr doesn't make sense, it's that bzrweb and loggerhead are awful
<StevenK> Ah.
<nenolod> hgweb just works, and with some tweaking works on mod_python.
<StevenK> I tend to not use web frontends to VCSs
<nenolod> bzr works great if you push your branch to for instance launchpad
<nenolod> but i don't think canonical would appreciate me using their resources for internal development
<nenolod> (;
<StevenK> Well, I admit I use bzr for Launchpad stuff only, like code hosted there, and the seeds
<nenolod> outside launchpad, bzr kinda sucks :/
<nenolod> at least for publishing branches
<StevenK> I thought you could just push to ~/public_html?
<nenolod> yes, but then you don't get searchable branches and all that other nifty stuff launchpad has via loggerhead
<AdamSun> Hello everyone, got a quick question
<StevenK> Ah, you also miss the nice lists of branches, and so on
<AdamSun> I'm working on packaging Handbrake and during the build process it uses wget to download libraries and compile them
<bddebian> ugh
<AdamSun> yet all of these libraries are available in ubuntu repositories
<RAOF> AdamSun: Please kill the devs for us, then.
<AdamSun> haha... i wish
 * nenolod hands AdamSun a shotgun, "you know what to do."
<jdong> AdamSun: the handbrake build system is retarded
<RAOF> And how hard would it be to patch this out of their build system.
<AdamSun> so i'm guessing my thoughts were true?
<jdong> AdamSun: you're gonna have to strip out their build system and make your own
<jdong> AdamSun: I recalled looking at this earlier :)
<AdamSun> I don't think it will be too hard
<nenolod> sounds fantastically crap
<jdong> RAOF: their entire build system specializes in fetching deps from random URL's
<jdong> it's a living nightmare
<AdamSun> Looks like I'll have some fun cleaning it up :)
<jdong> it's not make, it's some other system
<bddebian> crikey
<RAOF> Aaah, the unadulterated joy that is apt.
<AdamSun> yeah
<AdamSun> it uses jam
<nenolod> at any rate, no comments on audacious-theme-human? :P
<jdong> AdamSun: well, your task is to write a new buidl system for handbrake
<AdamSun> actually though, it switches back and forth between the two... extremely sad
<AdamSun> ha.. great fun
<jdong> AdamSun: I know, but we'll all be thankful
<jdong> AdamSun: (I'm the other transcoding nut around here) :D
<RAOF> Shouldn't be too hard to autotoolify it :P
<AdamSun> jdong: well.. i'll think of you as i go through hell :)
<RAOF> jdong: Excited about Dirac hitting 1.0, then?
<AdamSun> this is actually my first attempt at packaging a new app
<jdong> RAOF: meh no time for getting excited :)
<AdamSun> in terms of packaging this... would it be best to try to just alter their build system, or just scrap it all and start fresh?
<jdong> AdamSun: how familiar are you with jam?
<AdamSun> I quickly acclimated myself to it when i started, so i'm comfortable with it
<jdong> AdamSun: cool, does it look easy to strip off the other build-dep fetchers from their jamfile?
<jdong> AdamSun: I mean, I'd hate to see their code for building the actual transmission program go to waste
<AdamSun> yeah.. actually that is the main complexity of the build process
<AdamSun> my only concern was how to work around the need to download
<AdamSun> it'd be nice to just leave them their horrible build process and then use the nice one only with this package
<jdong> AdamSun: maybe ship your own jamfile in debian//
<AdamSun> jdong: possibly, it actually starts the whole process off with make though
<AdamSun> jdong: make then calls jam
<AdamSun> jdong: ( cd .. ; ./configure ; cd contrib ; cp -f ../config.jam . ; jam )
<AdamSun> jdong: that wonderful line there is called from make
<jdong> AdamSun: that might work, what's your clean line gonna look like though? ;-)
<jdong> AdamSun: can you not specify an explicit jamfile to jam?
<AdamSun> jdong: yeah.. i do believe
 * jdong laughs at dpkg
<jdong> _i386 is picked over _all
<jdong> well there's my problem
<jdong> I was WONDERING why that fix wouldn't propagate after 10 rebuilds!
<AdamSun> jdong: the jamfile that gets used from that line is basically useless, except that it runs patches to the source... otherwise it's only function is to build the libraries
<jdong> AdamSun: ah, ok
<AdamSun> jdong: would it be better to create a new rule that builds without wget, or just to alter their rule
<jdong> AdamSun: if you alter their rule, do so from a patch
<LaserJock> nixternal: ping
<ScottK> LaserJock: That's two of us looking for him.  I pinged him about 5 minutes before you did in #kubuntu-devel.
<Hobbsee> he's popular, clearly
<AdamSun> jdong: looks like i'm going to need to package libdca first :)  luckily it should be easier
<LaserJock> heh
<LaserJock> well I  don't need him anymore
<LaserJock> I lost my plasma panel and wondered how to get it back
<nixternal> LaserJock: pong
<LaserJock> hah
<LaserJock> nixternal: just actually logged into KDE 4
<LaserJock> lost my panel
<nixternal> that's a scary thought
<LaserJock> but figured it out
<nixternal> logged out and then logged back in?
<LaserJock> yep
<LaserJock> I had to kill plasma and then remove the config and it came back
<nixternal> ya, that will be fixed with the next release due out in about 2 weeks
<nixternal> actually, there have been a lot of fixes for KDE 4.0 already
<LaserJock> I wonder though if the icon stuff had been figured   out
<nixternal> most of it has
<nixternal> apachelogger_ actually patched quite a bit of it already
<LaserJock> has it made it to gutsy?
<crimsun> DarkSun88: so, are those related to dist-upgrade?  :-)
<nixternal> dunno if stdin has updated the gutsy ppa or not yet
<superm1> has anyone else been running into some weird FTBFS today related to stat64?
<superm1> for example, see this log: http://launchpadlibrarian.net/11491264/buildlog_ubuntu-hardy-i386.mythplugins_0.20.2%2Bfixes15096-0ubuntu3_FAILEDTOBUILD.txt.gz
<LaserJock> hmm, KDE desktop effects are pretty sweet
<RAOF> LaserJock: Do you not play with compiz much? :).  I found them pretty... jerky isn't really the right word, but it'll have to do.
<RAOF> I think it's something to do with the animations.  Effects in compiz tend to go: accelerate, move, decelerate.  Whereas kwin's seem to be all the same speed.
<LaserJock> RAOF: well, I guess I'm  just impressed you can even use it
<RAOF> LaserJock: What?  Compiz?  Or kwin?
<LaserJock> well, both actually
<LaserJock> but kwin specifically
<RAOF> Heh.
<LaserJock> I got a new laptop with an intel graphics card
<LaserJock> and my previous laptop had ATI and didn't really do 3D desktop well at all
<RAOF> Ah.  Sweet open source drivers.  Without TTM, sadly.
<LaserJock> I didn't really know that KDE had made any advancement in 3D desktop
<RAOF> I'm currently playing with the metacity compositor.  Which isn't too bad.  But isn't anything like kwin, and has most of the bugs that xcompmgr had.
<LaserJock> but the expose and virtual desktop switching is nice
<RAOF> I'd played around with it at some point.
<RAOF> ExposÃ© is the best new window-manager feature is a long, long time.
<RAOF> Oh, dear.  Multiarch is quite a lot harder than I'd hoped.
<RAOF> Why can't we have a ia32-libs-dev package :(
<StevenK> I thought we did?
<RAOF> Not according to aptitude search ia32
<StevenK> Hrm. I see that.
<RAOF> So I get to play around with fun like -l:libpulse.so.0
<warp10> Heya all!
<LucidFox> Why couldn't they just use compiz, anyway?
<RAOF> LucidFox: Because it's not written in C++ :P
<LucidFox> heh
<RAOF> LucidFox: I'm not really sure.  I remember one of the reasons being that the plugins were not sufficiently isolated; one bad plugin can bring compiz down.
<RAOF> Although that should change reasonably soon.
<RAOF> (With the landing of the object-framework branch)
<RAOF> Or, rather, it'll make it easier to not bring down compiz.
<RAOF> I think that their reasons, while valid at the time, aren't any more.  At least those reasons that I was aware of.
<LucidFox> "...And at about the same time, the GNU developers found a fatal flaw in Poppler: they didn't write it! They decided to create GNU PDF, which is like Poppler but different..."
<RAOF> Yup, pretty much.
<RAOF> It's true that they'd have to introduce a bunch of window manager bugs, but by starting from compiz they would have had fewer compositing manager bugs :)
<vemon> i just found this phrase from the packaging guide under KDE section: "remember debian policy implies that every single application has a man page!". so is it mandatory for new ubuntu packages to include a man page?
<vemon> and if there isn't one should it be somehow generated from the README file?
<RAOF> Yes.
<RAOF> That's one way, yes.
<vemon> any links or "googlewords" to help with that? :)
<LucidFox> I usually use help2man to create the initial draft
<RAOF> Well, there's the help2man program.
<RAOF> Heh.
<LucidFox> and then tweak it in a text editor
<vemon> ok. thank you!
<RAOF> crimsun: Still here, and willing to be a foil for multi-arch alsa-plugins?
<vemon> i should probably generate some kind of faq from all the answers you guys have given me :D
<LucidFox> vemon> Actually, that would be a good idea. I'm thinking of writing one on the wiki.
<vemon> LucidFox, when it's up&running i'm more than happy to contribute
<vemon> i usually write small instructions for everything new i learn to be able to re-do it later
<LucidFox> Would an empty debian/docs (rather than just a lack of it) be a blocker for a REVU package?
<RAOF> You know what'd be _awesome_?  Frikkin proper dpkg/apt supported multiarch.
<vemon> oh. forgot to ask how can i package the man page properly? the packaging guide seems to be lacking that information
<vemon> found it. if it's as simple as adding this to rules: DEB_INSTALL_MANPAGES_myapp = myapp.1
<LucidFox> vemon> um
<LucidFox> I think it's better to add it to debian/manpages than edit debian/rules
<vemon> if i add it there will it be magically included in the package and install correctly without adding any (for example) cdbs includes/params to rules?
<RAOF> That's right.  dh_installman is automatically run by CDBS, and will look at that file.
<vemon> thanks again :)
<jackdaw> hello, i want to get involved!
<LucidFox> jackdaw> Excellent! :)
<jackdaw> great! well that was easy
<LucidFox> Do you have any specific interests?
<jackdaw> numeric / scientific code is what i'm good at
<jackdaw> so it'd be good if there was something i could use that for that would be helpful
<LucidFox> Is the software you're interested in already in Ubuntu, or do you want to get it there?
<jackdaw> yeah i was just reading the wiki article, so you lovely folks are loosely the package maintainers?
<rzr> LucidFox: yea go for waste.sf.net
<rzr> it compiled well
<jackdaw> i think i was more looking to join something more like a specific dev team
<LucidFox> There is a list of MOTU teams here: https://wiki.ubuntu.com/MOTU/Teams
<rzr> LucidFox: oops forget what i said , i didnt got the context :)
<LucidFox> But generally, the people here will help you with any area
<LucidFox> jackdaw> Here is the page for the MOTU Science team: https://wiki.ubuntu.com/MOTU/Teams/Science
<jackdaw> thanks! i just got to that myself
<jackdaw> ok, i'll lurk for a bit
<wallyweek> hello world! :)
<man-di> can someone explain https://bugs.launchpad.net/ubuntu/+source/axis/+bug/150081 to me? Whats wrong with the package?
<ubotu> Launchpad bug 150081 in axis "autopkgtest gutsy axis: erroneous package!" [High,New]
<huats> morning everyone
<foolano> HI
<slytherin> foolano: hi
<foolano> one of the two packages i uploaded to REVU yesterday is already in hardy. how should i proceed to cancel it?
<man-di> slytherin: hello, can you please reproduce or close https://bugs.launchpad.net/ubuntu/+source/axis/+bug/150081?
<ubotu> Launchpad bug 150081 in axis "autopkgtest gutsy axis: erroneous package!" [High,New]
<man-di> slytherin: I guess it can be closed as I cannot reproduce it here in Debian.
<slytherin> foolano: let me check
 * DaveMorris plugs his package for revu - http://revu.tauware.de/details.py?package=opensg It's an OSS distributed scenegraph API for doing some cool 3D graphics across multiple machines or single machines.  Has support for sort 1st and sort last.  I'm currently using it to power a cluster with a 46 million pixel display.  It's cool so please revu it. (Since it's been missed the last 2 revu days)
<TheMuso> foolano: What do you mean cancel it?
<foolano> TheMuso: I mean, as it is already in hardy i dont want it to be reviewed or anything
<TheMuso> foolano: Oh you mean on revu, I can archive it if thats what you want. Whats the package?
<foolano> TheMuso:  libnet-cups-perl
<TheMuso> Ok, I'll fix it up on revu.
<foolano> TheMuso: thanks
<joejaxx> Good Morning All :D
<TheMuso> Hey joejaxx.
<TheMuso> foolano: Ok, it has been archived. If you wish to make it appear on the revu main page again, simply upload a new revision of the package.,
<foolano> TheMuso: great :)
<geser> good morning
<joejaxx> hello geser
<geser> Hi joejaxx
<slytherin> can anyone please ack this sync request? bug 185016
<ubotu> Launchpad bug 185016 in groovy "Please sync latest version from Debian" [Undecided,New] https://launchpad.net/bugs/185016
<slytherin> man-di: there? I need to discuss something.
<geser> slytherin: did you test-build groovy? I ask because: Dependency is not satisfiable: libxstream-java
<man-di> slytherin: yes, got around to test axis?
<slytherin> geser: Looks like I didn't pay attention to that. I was assuming that the build dependencies are present in Ubuntu. :-)
<geser> slytherin: you should test-build it with pbuilder. Just because the build-depends are there, doesn't mean that it also builds in Ubuntu.
<slytherin> geser: Sorry for that. I should have confirmed before I logged the bug.
<slytherin> man-di: Any idea what can I do about debian bug 423087 Please read the latest comment and let me know how should I frame the response.
<ubotu> Debian bug 423087 in w3c-dtd-xhtml "w3c-dtd-xhtml: path to entity sets is wrong" [Normal,Open] http://bugs.debian.org/423087
<man-di> slytherin: sorry, I dont know much about this XML stuff
 * wallyweek points out he's not away, but that stupid online irc clients keeps disconnetting him
<slytherin> man-di: No the problem I have is why can't we simply add symlinks for entity sets? Do we really expect everyone to add an additional library in classpath / dependencies just because the path in dtd is wrong?
<man-di> slytherin: as I said: I have no clue about XML
<slytherin> man-di: Ok. I will reply to the bug.
<vemon> how can i test a manpage without installing it first?
<ion_> man foo/bar.1
<persia> nroff -man < file | $PAGER
<jcastro> bigon`: thank you for taking care of d-feet!
<slytherin> man-di: I have replied to that bug. And if it is not fixed by this weekend I will add a patch in Ubuntu.
 * persia wonders if it is acceptable to list a corporation under "Author:" in debian/copyright if the corporation no longer has records about who worked on the software before it was publically released.
<slangasek> "author" is not a field we're legally required to include in debian/copyright
<slangasek> just "copyright holder" and "license"
<persia> So we just use "Author" to be nice?  Dropping it makes it easy.  Thanks :)
<thp> can someone please sync the new gPodder 0.10.4 release from Debian Unstable to Ubuntu Hardy? https://bugs.launchpad.net/ubuntu/+bug/185317
<ubotu> Launchpad bug 185317 in ubuntu "Please sync gPodder 0.10.4-1 from Debian unstable" [Undecided,New]
<persia> slangasek: Also, thanks for one more step to make hardy WX2.4 free :)
<thp> oh ;)
<slangasek> persia: ah? you're working on wx2.4 removal stuff theN?
<persia> thp: Please subscribe ubuntu-universe-sponsors to request someone to look at it?
<thp> ok i'll do that
<persia> slangasek: Actually, I haven't done anything beyond passing Barry hints in about eight months, but it was one of my release goals for Gutsy.
<slangasek> ah :)
<persia> thp: Thanks.
<slytherin> geser: you were right. libxstream-java is not present in Ubuntu. And that in turn has dependency on libcglib2.1-java. :-)
<vemon> last manpages
<vemon> whops :D
<dholbach> Hobbsee: ROCK ON
<Hobbsee> dholbach: :)
<dholbach> hey sistpoty|work, hey persia
<sistpoty|work> hey dholbach
<persia> hey dholbach.
<dholbach> how are y'all doing?
<persia> dholbach: Fairly well.  You?
<sistpoty|work> debugging my ugly code... otherwise fine
<dholbach> persia: very good thanks :)
<theseinfeld> dholbach hi
<dholbach> hey theseinfeld
<theseinfeld> dholbach i am a bit in a hurry to get that thing done
<dholbach> theseinfeld: aren't we all? :)
<theseinfeld> dholbach yeah
<theseinfeld> dholbach too much coffee :)
<theseinfeld> dholbach am I supposed to fill a bug report in the main-sponsors/
<theseinfeld> ?
<dholbach> theseinfeld: no, it's a NEW package - the sponsoring teams don't do them
<theseinfeld> dholbach so it is only in REVU?
<slangasek> is there an existing wiki page to link useful universe QA resources from?
<dholbach> slangasek: ROCK - it's http://wiki.ubuntu.com/MOTU/TODO or http://wiki.ubuntu.com/MOTU/Bugs
<theseinfeld> dholbach i think the package should go in main, and that is what makes me worry about february deadlin
<theseinfeld> e
<theseinfeld> s/dedlin/dedline/
<dholbach> theseinfeld: what would link against it?
<persia> slangasek: For test-oriented QA, it'd be nice to list at qa.ubuntu.com.  For developer-oriented QA, it'd be nice to list at qa.ubuntuwire.com
<theseinfeld> dholbach: what packages?
<dholbach> theseinfeld: yeah
<theseinfeld> dholbach in hardy?
<slangasek> persia: <whimper> why do we have a wiki if everything gets moved elsewhere?
<theseinfeld> dholbach well, i have an issue with the Doxygen building when using PPA
<dholbach> theseinfeld: you said it should be in main: if there's nothing linking against the library there's no need for it in main, right?
<persia> slangasek: Err..  We like using DNS rather than URL parsing?  What do you have?  I'll get it somewhere.
<theseinfeld> dholbach: the libdc1394 was in main...
<dholbach> theseinfeld: so it's an update of the libdc1394 package?
<theseinfeld> dholbach don't remember which packages are linking, but there are some libraries...
<theseinfeld> dholbach that's the trick
<dholbach> theseinfeld: why do you intend to rename the source package at all?
<theseinfeld> dholbach it is a new API and we did it to work such that it can work with libdc1394 version 1.1
<dholbach> theseinfeld: why isn't it an update of the libdc1394 source package?
<dholbach> theseinfeld: wouldn't it be enough to just rename the binary package?
<dholbach> libdc1394-13 to libdc1394-22 and libdc1394-13-dev to libdc1394-22-dev
<slangasek> persia: which "we"?  Having half the info in the wiki and half the info on other sites drives me crazy, because, er, the wiki's search doesn't index other sites
<theseinfeld> dholbach no. because then if you use -22 you get conflict with -13
<theseinfeld> etc...
<persia> slangasek: Which wiki?  We've three of them last I looked :)
<slangasek> persia: wiki.ubuntu.com :(
<dholbach> theseinfeld: where's the problem with that? is there any need for two source packages containing the library?
<dholbach> theseinfeld: it's something that happens all the time: libraries change the soname, binary package names are updated
<theseinfeld> dholbach it is a new branch
<slangasek> persia: well, I see that the NBS list is linked from qa.ubuntuwire.com, but I wouldn't have thought to look there
<theseinfeld> dholbach it is in a way a new library
<dholbach> theseinfeld: ah, are all the apps ported to use it already?
<persia> slangasek: I don't remember the details, but someone got annoyed by that back in Dapper, and created some other wikis (help and later community).  After that, w.u.c got steadily worse until late feisty, when some cleanup started.  qa.* exist because wikis can't run code.
<theseinfeld> dholbach some apps like coriander will be ported to use it
<theseinfeld> dholbach but not all
<theseinfeld> dholbach and that is why we still need the -13 while we get -22
<slangasek> persia: ok, so for things that don't involve running code, are we in agreement that they should be linked from the wiki and not just from ubuntuwire.com? :-)
<dholbach> theseinfeld: OK
<theseinfeld> dholbach coriander will come later...
<theseinfeld> dholbach so far the efrfort is to get the library in
<theseinfeld> dholbach than the coriander will freeze maybe in february
<theseinfeld> early february
<dholbach> I'd somehow prefer the name to be something like "libdc1394-2" or something
<theseinfeld> dholbach if i get time i could do the coriander before 14
<theseinfeld> dholbach the -22 for the source is coming from the discussions with debian guys
<dholbach> oh ok
<persia> slangasek: I'm honestly not sure.  Last time we decided that, MOTU/TODO page got a lot of activity adding resources, and then people started putting them in UbuntuDevelopment/Resources, and then...
<theseinfeld> dholbach I try to be in sync with them
<dholbach> it fails to build for me
<theseinfeld> more like to sync them with the dev. process
<theseinfeld> dholbach the libdc?
<persia> slangasek: There's also some confusion as some of the tools only run on main (lack of resources available within Canonical), and there have been arguments about how they should be listed.
<theseinfeld> dholbach from revu?
<theseinfeld> dholbach: we have the team PPA where we did the gutsy binaries earlier here: https://launchpad.net/~libdc1394-dev/+archive
<dholbach> theseinfeld: yeah
<dholbach> building the docs fail
<theseinfeld> dholbach: i already filled a bug why it fails: let me check the problem again
<theseinfeld> dholbach: http://launchpadlibrarian.net/11473870/buildlog_ubuntu-hardy-i386.libdc1394-22_2.0.1-1ubuntu5_FAILEDTOBUILD.txt.gz
<sistpoty|work> in case revu is a little bit unresponsive atm: I'm just doing a backup of sparky
<dholbach> yeah, same problem here
<theseinfeld> dholbach: it fails because ! LaTeX Error: File `a4.sty' not found.
<theseinfeld> in hardy
<theseinfeld> dholbach: in gutsy it works
<theseinfeld> dholbach: prbably the cjk-latex package forgot the a4.sty to include or something...
<dholbach> theseinfeld: try adding texlive-latex-recommended to Build-Depends
<theseinfeld> dholbach: question is: how do other doxygen packages that export the HTML/PDF/PS file manage?
<theseinfeld> dholbach: should it replace the cjk-latex?
<DaveMorris> theseinfeld: what do you mean?  I've a package which uses doxygen for html
<dholbach> theseinfeld: I don't know - I don't know the code or what it was put in in the first place
<theseinfeld> DaveMorris: what is the build-depends list for latex?
<theseinfeld> DaveMorris: in debian/control Source...?
<DaveMorris> mine doesn't make use of latex
<dholbach> theseinfeld: why is it necessary to call the binary package libdc1394-22-dev instead of libdc1394-dev?
<emgent> heya *
<theseinfeld> different API
<dholbach> oh yeah right
<theseinfeld> dholbach: it has binary
<dholbach> the thing is it will earn you having to rename it every time and having to add conflicts/replaces all the time
<dholbach> it has a symlink
<dholbach> upstream calls it libdc1394-2 (in ./usr/lib/pkgconfig/libdc1394-2.pc) - I think that's much more sensible over all
<DaveMorris> theseinfeld: the a4.sty style file is shipped with texlive-latex-recommended AFAIK
<theseinfeld> DaveMorris: thanks
<dholbach> also libdc1394-22-utils - you will rename that with every ABI break
<dholbach> and you'll always have to add conflicts/replaces
<dholbach> I'd talk to the debian maintainers about that again
 * persia is confused by the possible differences between icepick and icedtea
<theseinfeld> dholbach: yes. libdc1394-2.pc is for libraries pkgconfig thinggy
<dholbach> in libdc1394v2-doc you have the different pattern already
<theseinfeld> dholbach: i use the virtual package libdc1394-dev so that user can choose which to pick for development
<dholbach> that will probably break the builds of packages that are not ported to the new API yet
<dholbach> they are not interchangeable
<theseinfeld> dholbach: that v2 is to conform with debian-policy for naming
<dholbach> but the v2 naming is not consistent in the binary packages
<theseinfeld> if it was just libblablah with no number my life would be much easier now
<theseinfeld> :D
<theseinfeld> that 1394 is killing me :))
<emgent> keescook, jdstrand malone 173153
<ubotu> Launchpad bug 173153 in audacity "[CVE-2007-6061] Denial of service and deletion of an arbitrary directory tree via symlink attack" [Undecided,Confirmed] https://launchpad.net/bugs/173153
<emgent> gutsy debdiff it's ready
<theseinfeld> dholbach: i am just making the new dsc for revu and ppa
<dholbach> I added a few comments to the page
<theseinfeld> revu page?
<emgent> http://thc.emanuele-gentili.com/packages/security_fix/gutsy/audacity/
<emgent> deb too avaiable.
<theseinfeld> dholbach: uploaded 1ubuntu6
<dholbach> added another comment
<dholbach> I need to leave now... sorry
<theseinfeld> dholbach: thanks. I let you know by email...
<dholbach> just follow up on the REVU page so everybody else is notified too
<ScottK> dholbach: I just volunteered for motu-uvf.
<dholbach> ScottK: I just noticed - that's great - thanks
<ScottK> dholbach: I do think we need to follow pitti's suggestion to rename it.
<dholbach> ScottK: that makes sense - I think we should name it motu-ff though (to not raise expectations about a 'motu release team')
<TheMuso> dholbach: Gee your email sounds so much like a sales pitch. :p
<dholbach> TheMuso: it worked though ;-)
<dholbach> ScottK: and have the discussion about 'motu release team' separately (gather ideas about it first)
<dholbach> sorry guys, need to leave for lunch now and a meeting afterwards - ttyl
<RainCT> Hey
<jdstrand> emgent: thanks!
<emgent> jdstrand, np :)
<emgent> wordpress too fixed hehe
<jdstrand> emgent: cool thanks
<emgent> np :)
<emgent> jdstrand, today i will work to malone 181853
<ubotu> Bug 181853 on http://launchpad.net/bugs/181853 is private
<emgent> upstream reply to me.
<jdstrand> emgent: sounds great
<slangasek> persia: heh, in regards to some tools only being run on main, I was just discussing yesterday with dholbach that it would be good to have a britney run for universe to show out-of-date packages
<Hobbsee> slangasek: for the ones who aren't from debian, which is britney?
<slangasek> Hobbsee: britney is the tool that generates http://people.ubuntu.com/~ubuntu-archive/testing/
<slangasek> (it does other things in Debian, it's just a reporting tool in Ubuntu)
<Hobbsee> slangasek: ah right
<persia> slangasek: We asked liw at UDS, and were told there were insufficient resources.  debcheck on ubutuwire is the current means we use to chase that.  If you can convince someone to run against universe regularly, that'd be great.
<slangasek> persia: hmm, this was about insufficient resources for britney specifically?  I'll look into it; I haven't tried to have that end of the conversation yet
<\sh> moins
<emgent> persia, ping
<emgent> \sh, hi!
<persia> slangasek: I'm not sure: I wasn't physically present during the conversation.  There were a few things under discussion, and it may be that britney got lost as being considered linked to other things.
<slangasek> k
<slangasek> well, for what Ubuntu uses britney for, I can't imagine it being a resource issue; the resource-intensive parts of britney aren't used at all
<persia> slangasek: That was my thought.  I've been hoping we could be running that also for universe since feisty, but it needs higher-level pokes than me.
<slangasek> :)
<persia> Separately, do those testing runs provide any extra information above that provided by debcheck?
<ScottK> dholbach: At least in the last cycle we pretty well acted as the MOTU release team.  I don't thik we need a separate team for that.
<persia> I only remember about half the motu-uvf team being involved in the final release efforts, and I do remember some non-uvf people being involved.  I think it's worth discussion about what motu release would mean before deciding we don't need a team (and similarly before deciding to create a team).
<slangasek> persia: ok, I checked with liw and he doesn't think britney was ever discussed; the resource-intensive stuff that's a problem are the automated install/upgrade testing, which is quite a bit differently than britney which just acts on a Packages file
<persia> slangasek: In that case it's a case of the telephone operator game.  Clearly I need better audio in my spy satellites :)  Thanks for following up.
<ScottK> slangasek: Would you be up for doing some backports.  RIddell started the clamav backport to Dapper yesterday, but had connectivity problems and so dapper-backports is about half on the new clamav and half on the old one right now.
<slangasek> persia: I'm not familiar with debcheck; output looks familiarly like some stuff I've seen in Debian, which I don't think handles conflicts->depends loops.  I also don't see that debcheck lists out-of-date binaries
<slangasek> ScottK: heh, connectivity problems, a likely story :-)
<ScottK> https://bugs.launchpad.net/dapper-backports/+bug/183914/comments/12 is the list if you're up for it.
<ubotu> Launchpad bug 183914 in dapper-backports "Please Backport clamav-0.92~dfsg-2 from Hardy to Dapper" [Wishlist,In progress]
<slangasek> ScottK: yeah, today's seb's archive day, but since I failed to be useful on mine I can have a look
<persia> slangasek: Ah.  Some commonality, but perhaps sufficient differences to make both worthwhile.  I know there was some talk about running britney on UbuntuWire, but it didn't happen in favor of debcheck.  Likely best to run both.
<ScottK> slangasek: If he was faking, he managed to be a good IRC simulation.
<ScottK> slangasek: Thanks.  All the source backports are done, all those should be just the regular backports script.  The only tricky bit being the two that have to come from Feisty.
<emgent> persia, http://thc.emanuele-gentili.com/packages/security_fix/gutsy/audacity/    :-)
<\sh> hmm...is it possible to tell sbuild to delete old build logfiles and just leave the last build log?
<ScottK> slangasek: After the pain he did get through yesterday, I wouldn't blame him much for hiding out anyway.
<slangasek> ScottK: well, yes :)
<persia> emgent: Great.  As I said 14 hours ago, you need someone from SWAT or security to look at those (and they will likely look at the bug instead).  Thanks for looking into it, and good luck with the other releases.
<emgent> persia, sure.
<emgent> security people know.
<slangasek> ScottK: looks like clamcour,clamtk,dansguardian,klamav just needed flushed out, so that's done now
<ScottK> slangasek: Great.  Thanks.
<slangasek> libetpan,etpan-ng are going to take me a minute longer as I haven't done a backport myself yet and need to be sure I know what I'm doing on a feisty->dapper backport
<ScottK> OK.  Sounds reasonable.
<theseinfeld> dholbach: you back?
<dholbach> theseinfeld: going to be in a meeting in a bit - so best to just ask the question in here
<dholbach> theseinfeld: probably somebody else will answer your questions
<theseinfeld> dholbach: thanks
 * persia believes that people who upload packages to PPAs with broken addresses in the changelogs should be summarily shot.
<theseinfeld> dholbach: i need you :) so I can wait for later :)
<theseinfeld> dhobach: it should compile now
<ScottK> slangasek: I got the 4 accept mails, so that's all good.
<dholbach> theseinfeld: there are much cleverer people than me around here :)
<\sh> emgent, why is different in
<\sh> +-   defaultTempDir.Printf(wxT("/tmp/audacity1.2-%s"), wxGetUserId().c_str());
<\sh> ++   defaultTempDir.Printf(wxT("/tmp/audacity%d.%d-%s"),
<\sh> ++			AUDACITY_VERSION, AUDACITY_RELEASE, wxGetUserId().c_str());
<\sh> as just adding version and release to the /tmp/ dir?
<man-di> dholbach: only the clever people say that *g*
<\sh> emgent, it doesn't match your explanation in changelog
<\sh> Fix insecure directory creation in /tmp by moving the directory
<\sh> +      to the users home directory (CVE-2007-6061; LP: #173153).
<ubotu> Audacity 1.3.2 creates a temporary directory with a predictable name without checking for previous existence of that directory, which allows local users to cause a denial of service (recording deadlock) by creating the directory before Audacity is run.  NOTE: this issue can be leveraged to delete arbitrary files or directories via a symlink attack. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6061)
<persia> theseinfeld: Please ask questions generally.  There's usually someone with time or inclination to help, and seeking specific people tends to reduce the time they have for other things, and thereby reduce help for everyone.
<theseinfeld> ok
<emgent> \sh, nope i saw debian && ubuntu hardy patch
<theseinfeld> the issue is with the libdc1394
<theseinfeld> and the namings proposed by dholbach in his comments
<theseinfeld> http://revu.tauware.de/details.py?upid=1427
<\sh> emgent, well, the explanation is wrong ;) so the patch does not do what you explained ;)
<persia> emgent: Also, anything defaulting to /tmp in a predictable way remains vulnerable to the attack.  It needs to be moved to ~ or made unpredictable.  If hardy is still broken, please fix that as well.
<emgent> uhm wait
<\sh> emgent, the original gentoo patch is also different :)
<\sh> http://bugs.gentoo.org/attachment.cgi?id=141581
<emgent> well
<\sh> -   defaultTempDir.Printf("/tmp/audacity1.2-%s", wxGetUserId().c_str());
<\sh> +   defaultTempDir.Printf("/%s/.audacity1.2-%s", home.c_str(), wxGetUserId().c_str());
<emgent> debian use this
<emgent> http://people.debian.org/~nion/nmu-diff/audacity-1.3.4-1_1.3.4-1.1.patch
<\sh> emgent, but the gentoo patch is doing that what you explained :)
<\sh> emgent, which is correct :)
<emgent> but, in hardy (it's patched) and use other method
<\sh> ember, but http://thc.emanuele-gentili.com/packages/security_fix/gutsy/audacity/gutsy_audacity_1.3.3-1ubuntu0.1.debdiff shows something different
<emgent> defaultTempDir.Printf(wxT("%s/.audacity%d.%d-%s"), home.c_str(),
<persia> emgent: That would be my fault (and part of why I'm not in SWAT).  Please fix it.
<slangasek> ScottK: ok, libetpan/etpan-ng on their way as well; anything else or is this bug ready to be closed?
<\sh> s/ember/emgent/
<emgent> uhm ok i will review it
<emgent> just a moment
<ScottK> slangasek: That should be it.  Thanks.
<\sh> emgent, even the debian patch is wrong
<\sh> emgent, missing a / < in the beginning of the string ;)
<emgent> yes i saw gentoo patch
<\sh> emgent, use the gentoo patch please, they are correct
<ScottK> slangasek: Now I cross my fingers and wait for bugs.  ;-)
<emgent> sure \sh thanks.
<slangasek> right. :)
<\sh> emgent, I'll tell nico that he is wrong ;)
<ScottK> slangasek: This is, by a fair margin, the most complex backport that's been done so far, but I think it'll all work out.
<slangasek> eh, what could go wrong
<emgent> \sh, cool :)
<theseinfeld> how long does it take to get a reviewer for my package?
<ScottK> theseinfeld: The reviewers are all volunteers.  It varies depending on availability and interest.
<DaveMorris> depends if they like you :)  REVU day is monday, it'll prob be looked at then
<\sh> emgent, you see, it's quite important to not trust everyone, even when persia is a person to be trusted ;)
<persia> theseinfeld: Are you repackaging as an update, rather than a new source?
<theseinfeld> it is a new API for an old library
 * persia is not always a person to be trusted for Debian syncs for RC bugs.
<theseinfeld> hard to qualify it as an update
<slangasek> persia: because sometimes you fail to introduce RC bugs?
<persia> theseinfeld: Ah.  Too much porting.
<theseinfeld> persia: porting?
<persia> slangasek: Rather because I tend to pull syncs for anything without Ubuntu variation for which I know an RC bug was closed, without much review beyond builds & installs.
<theseinfeld> persia if i do that, i quit my job and family
<slangasek> persia: ah :)
<theseinfeld> persia: more like life
<theseinfeld> :D
<persia> If the Debian maintainer didn't actually fix it, it breaks my workflow.
<persia> theseinfeld: Right.  Hence the decision for a second source.  Makes sense to me.  Is this the new juju stuff?
<theseinfeld> the juju will come a bit later
<theseinfeld> when it should detect if the kernel has the juju or old legacy
<theseinfeld> persia debian maintainer to fix what?
<persia> theseinfeld: cross conversations: debian maintainer for whichever random package claimed to have fixed an RC bug.
<theseinfeld> persia: sorry...
<theseinfeld> persia: maybe in the 2.0.2 we manage to make the juju stack awareness in the library
<theseinfeld> persia: also coriander needs packaging...but i am blocked now in the libdc1394...
<theseinfeld> persia: besides, coriander is not yet final for the new api version 2.0
<persia> emgent: Don't forget to fix in hardy first (and reopen the task as I was mistaken).
<emgent> ok
<persia> theseinfeld: Likely not on track for hardy then :(  Only three weeks to Feature Freeze.
<theseinfeld> persia: the libdc1394 is ready
<DaveMorris> only 3 weeks left :(
 * DaveMorris wonders if his package will make it
<theseinfeld> persia: if i get this thing out of my table (the motu bureacracy :)) I can get on the coriander
 * emgent joint time..
<persia> theseinfeld: I've a fairly long review queue right now.  You'd do better to advertise your URL for general review.  I'm interested, and will take a look outside of REVU day if I have time, but don't count on me to get your package in.
<emgent> persia, i will fix all this night
<theseinfeld> persia: how do you advertise?
<theseinfeld> just post the url on revu?
<vorian> When I debuild a python package, it generates a debian/pycompat.  how do I avoid this?
<vorian> and good morning :)
<DaveMorris> theseinfeld: post the url here with a line or 2 describing the package
<persia> theseinfeld: Ask for a review in this channel, including the URL on REVU, a short (5-10 word) description of the package, and the current REVU status.  Please limit yourself to one advertisement each 24 hours when it's not REVU day.
<persia> vorian: Why do you want to avoid it?  It's part of python package building.
<persia> emgent: Thanks.  Don't forget to sleep :)
<vorian> persia: dktrkranz is asking me to remove it from a revu package
<theseinfeld> ok: libdc1394 API version 2.0 is ready. The library version 1 was in main, and this new package should work in parallel with it. The REVU page is http://revu.tauware.de/details.py?package=libdc1394-22 and you can also check the binary packages in the PPA: https://launchpad.net/%7Elibdc1394-dev/+archive
 * persia defers to Dktrkranz, not knowing python packaging deeply, but has seen that in every python package touched
<vorian> hmm
<theseinfeld> I've been working with couple of guys on the debian so the review should be quite straigh forward and fast :)
<vorian> okie dokie, thanks persia :)
<persia> \sh: Why change the sbuild bug from triaged to confirmed?  Is the cause not understood?  I thought the explanation was clear, and there's a fix available in a branch.  Does the fix not work for you?
<ScottK> vorian: It's a bug in pysupport if you're using that.  If you're using pycentral, it is needed.
<ScottK> vorian: What package (REVU link please)?
<vorian> ScottK: http://revu.tauware.de/details.py?upid=1423
<vorian> ok, changing to pycentral
<ScottK> vorian: No need to change
<vorian> alrighty
<ScottK> You're choice.
 * ScottK is going to comment that it's a: Not your fault.  b: Harmless.
<vorian> lol
<ScottK> vorian: Commented.
<vorian> in debian/pyversions, is it ok to use 2.4 and 2.5?
<vorian> thanks ScottK
<theseinfeld> god dammit
<theseinfeld> they have the package already in fedora
<ScottK> vorian: What does the package require?
<vorian> just says python, no specific version
<vorian> it builds either way
<vorian> and with each
<ScottK> Does it work with Python 2.2 or 2.3?
<ScottK> The upstream documentation SHOULD say.
<persia> So, about the requirement that upstream include the licensing in the tarball.  If upstream includes a tarball containing only a zip file, and includes the licensing in the zip file, is that acceptable as well?
<ScottK> persia: Why wouldn't it be?  Compressed or not, it's present.
<persia> ScottK: Thanks.  I just like to seek second opinions when I'm unsure.
 * persia also has a general distaste for compressed-archives-in-compressed-archives, but that is separate
<ScottK> persia: Agreed.  That's a question of the pain involved, not the legality.
<persia> Right :)
<sladen> persia: uncompress the inner archive!
<persia> sladen: That would break cryptographic match to upstream, which would be worse than compressed-archives-in-compressed-archives.  Complaining to upstream won't do any good, as they distribute .zip to be more cross-platform compliant, but also distribute tar.gz containing the .zip to make a watch file easy (which I appreciate).
<lifeless> persia: tarballs in tarballs are really very bad
<persia> lifeless: Worse than mismatched md5sums?  In general I agree, but in this special case, I think I'll just complain to upstream that not zipping before they make the tar.gz would be nice.
<lifeless> persia: yes, definately worse
<lifeless> persia: we routinely have different orig tarballs
 * persia is hyper-picky about being able to demonstrate reliability of orig tarballs
<lifeless> its a false optimisation
<lifeless> a recursive sha of the contents will be identical; thats what matters
<lifeless> the only folk that /look/ at orig tarballs are other distro developers
<persia> lifeless: Hrm?  I'm optimising for only needing to look through diff.gz when I don't trust the packager, rather than optimising for processing time.  Human effort vs. machine effort.
<lifeless> users that check the source matches and then use a binary build are - well, fill in the adjectives
<lifeless> persia: uhm, write a trivial script to unpack and sha recursively; call it 'tarball fingerprinter'
<lifeless> then you can just fire that off with both tarball urls and go read the diff
<persia> lifeless: Hrm.  Maybe I ought do that.  Of course my use case is likely fairly skewed from most, as I routinely inspect sources from packagers I don't know or trust, and who are not known or trusted by any distribution.
<lifeless> blobs in the source are bad because it makes using a vcs on the package nasty
<lifeless> and vcs benefits >>>> checking the orig tarball hasn't been hacked
<cbx33> hey guys
<cbx33> what's the LP address for the NEW build queue
<persia> lifeless: Maybe.  I'm not sold on the whole VCS maintenance thing yet, and in the few cases where I do VCS maintenance, only debian/ is in the VCS.
<geser> cbx33: https://edge.launchpad.net/ubuntu/hardy/+queue
<lifeless> persia: I can see why youa re not sold then ;)
<persia> cbx33: There isn't a NEW build queue.  You likely want one of https://launchpad.net/ubuntu/hardy/+queue or https://launchpad.net/ubuntu/hardy/+builds.  Also edge is edgy.
<cbx33> ok
<cbx33> i just uploaded memaker there
<cbx33> well yesterday
<cbx33> did I upload the right thing?
<persia> lifeless: Well, also because I almost never pull from upstream, and have optimised my workflow for debdiffs.
<lifeless> persia: this is called accomodation
<lifeless> persia: you are accomodating a different toolchain
<slangasek> psst, a VCS shared between Ubuntu and Debian makes merging easier ;)
<lifeless> golly gosh you thinkn?
 * lifeless slaps himself
<slangasek> lifeless: that was addressed to persia
<persia> slangasek: Yes.  That's where I do VCS stuff.  Still, it doesn't change the debdiff handling I do as a sponsor, and it's not worth pushing all the packages in a VCS just for that.
<slangasek> persia: right; it's worth pushing all the packages into a VCS because it also makes merges between Debian/Ubuntu and *upstream* easier
<geser> cbx33: did you got a mail?
<lifeless> persia: it would change it if you reviewed using bzr not debdiffs :)
<cbx33> yes i did
<cbx33> but my package seems different to everybody elses
<cbx33> mine is a source pacakge
<persia> lifeless: For every package?  Show me the 15000 bzr repos :)
<lifeless> persia: pateince kemosabe
<cbx33> none of the others are
<geser> cbx33: both source NEW and binary NEW are in that queue
<lifeless> s/patein/patien/
<cbx33> ok
<geser> cbx33: memaker is listed
<cbx33> yes
<cbx33> did i upload all I should have?
<persia> slangasek: Sure.  I don't disagree.  On the other hand, I try for 3 uploads a day from debdiffs, and I'm completely unfamiliar with most of those packages, and most aren't in VCS anywhere.
<geser> cbx33: yes, just wait till an archive admin processes the NEW queue
<cbx33> ok
<cbx33> someone said I need to send a mail to the motu list?
<persia> lifeless: Even when you get there, it'll likely be 6-12 months before all the workflows are caught up, but I do hope there'll be less cause for this discussion :)
<persia> cbx33: You should have gotten a NEW report from Soyuz.  You should forward that to the MOTU list.
<cbx33> ok
<cbx33> heheh would you believe I've never actually uploaded to the queue before
<persia> cbx33: There's a first time for everything :)
<cbx33> and i think i became a motu before some of you guys here
<cbx33> hehehe
<ScottK> Fundamentally though, the canonical source for the distro is the source package.  Unless you can move everyone off that and into a common VCS, then all you have is two places to keep the data and one will be wrong.
<ScottK> I think packaging in a VCS works in small teams, but I've yet to see evidence it's scalable.
 * persia agrees with ScottK, but remains unconvinced that is a complete block to no-more-source-packages.  On the other hand, it's not soon.
<slangasek> so does the Debian perl team count as a "small team"? or what level of scalability is required here?
<persia> ScottK: Just for purposes of discussion, s/upload/commit/ with a easily branched DVCS.  Of course, it helps if everyone uses the same VCS.
<ScottK> slangasek: Universe would be a not small team.
<slangasek> well, ok
<ScottK> slangasek: I use the Debian Python Modules/Applicaton's Teams svns on alioth routinely and I think it works well.
<slangasek> I fail to see the reasons that it wouldn't scale; other than the fact that most folks who /use/ vcses for packages currently do so because they are "small" teams that need that coordination
<persia> On the other hand, I'm unconvinced that the bzr-svn-git-hg cross VCS tools work anywhere near well enough for it to be reasonable, but some people might consider those bugs.
<StevenK> Who uses irssi? I'm trying to change the colour the topic on the top of the window appears in, and I can't find anything.
<slangasek> I use irssi, I don't fiddle with colors though
<ion_> Having the packaging as a branch from the upstream archive also makes it possible to have the distro patches as commits in the VCS, and the VCS would be able to intelligently merge new upstream releases so that updating the changes would be much less work.
<StevenK> My topic is black on blue, which isn't very readable, and I'm finally motivated to change it.
<ion_>   # background for topicbar (same default)
<ion_>   #sb_topic_bg = "%4";
<slytherin> Does anyone know why suddenly the FTBFS count for multiverse dropped to 34 form yesterdays 60+ :-)
<StevenK> ion_: Does that mean sb_topic_fg also holds true?
<ScottK> slangasek: I think Debian provides very good tools for repository management and packaging.  Personally, I have little interest in using an Ubuntu unique VCS as an alternative (yes, I know bzr is used outside Ubuntu, I've just never run into it anywhere else).
<ion_> stevenk: Dunno. The default theme doesnât seem to contain such string.
<ion_> stevenk: In fact, thereâs no _fg in it.
<StevenK> ion_: Mmmm. Setting sb_topic_bg to "%4%w" made it all good, thanks.
<\sh> emgent, nico was correct...you can leave the beginning slash behind..
<emgent> ok cool
<emgent> i attach new patch.
<geser> slytherin: my guess is that lpia and hppa are in needs building which is only displayed if the package failed on an other arch
<slytherin> geser: thanks for explanation. I also think that the latest faac upload might have reduced many other instances.
<ion_> :screen mutt
<ion_> Whoops
<mcisbackuk> Hi all, can someone help me with uploading a package please? I'm currently packaging scummvm 0.11. What do I need to upload, there is already a bug report requesting it as bug #183976
<ubotu> Launchpad bug 183976 in scummvm "new upstream version 0.11" [Undecided,New] https://launchpad.net/bugs/183976
 * persia is far too slow to suggest bugging bddebian and uploading an interdiff
<mcisbackuk> Hi all I have a problem with packaging and an getting an error, i think its my debian-loicy but how do I update it? error at http://paste.ubuntu-nl.org/53177/ would appreciate one of you guys having a look :)
<mcisbackuk> *debian-policy
<pochu> mcisbackuk: standards -> 3.7.3 in debian/control. the version in debian/changelog should be 0.11.0-0ubuntu1.
<persia> mcisbackuk: 1) Install the lintian from gutsy-backports, 2) If preparing an upload for Ubuntu, use an Ubuntu version (e.g. 0.11.0-0ubuntu1).
<pochu> (or -1ubuntu1 if it's based on a -1 from Debian)
 * persia wonders if policy is also in backports, and if not, if anyone wants to test and push it,as having lintian and policy disagree is sub-ideal
<slangasek> is anyone here interested in helping to rebuild libldap2 reverse-deps for the openldap2.3 soname transition?
<StevenK> slangasek: Sure
<persia> slangasek: Is it mostly rebuilds, or lots of porting?  I've spare machine cycles, but less brain cycles.
<StevenK> slangasek: Throw me a list of source packages, and I'll test rebuild them
<mcisbackuk> Sorry for late reply. thanks a lot guys :)
<ScottK> dholbach: Are you planning on announcing the MOTU Council election on more lists?
 * persia wonders why libldap2 doesn't show in the NBS list
<slangasek> persia, StevenK: should be all rebuilds
<StevenK> slangasek: If you want to split up the list 33/33/33, sounds fine to me.
<ion_> Who gets the 1?
<StevenK> slangasek. :-P
<persia> ion_: You can have newpki-server if you like.
<slangasek> StevenK: grep-dctrl -FBuild-Depends libldap2-dev -sPackage /var/lib/apt/lists/*hardy_universe_source_Sources ? :)
<StevenK> That gives the whole list. :-)
<slangasek> well, yes. :)
<StevenK> slangasek, persia: There's 58 packages, giving ~ 19 packages each, I'll take the bottom 19, sorted alphabetically.
<slangasek> I should get credit for the 20 I'm already doing in main ;P
<TheMuso> What is being done with such a large numbe rof packages/
<persia> StevenK: OK.  I fear wine and emacs, so that makes me happy.  I'll take chunk #3.
<TheMuso> Oh, ldap.
<StevenK> Oh, I missed wine. Oh well.
<StevenK> persia: I've got openswan - zabbix
<_ruben> whats the current targeted version of openswan for hardy?
 * persia claims heimdal - nufw, but offers a special exception on newpki-server if ion_ has already started
<ion_> Iâm not going to get much done today.
<StevenK> slangasek: I guess that leaves you adtool - nss-ldapd
<persia> ion_: OK.  You get to pick a different one then.
<slangasek> StevenK: right, plus the ones in main I'm not done with yet
<mcisbackuk> Hello again guys. I've run 'debuild -S -sa' and 'debuild -us -uc' everything seems fine didn't get any errors, what do i do after I've built it?
<ScottK> jdong: Can we do removals in backports if there's a oops?
<StevenK> slangasek: If you want to give me a few in main, I'm happy to add them to the list
<StevenK> Ew, there's 28 in main
<StevenK> Including such fun like Openoffice.org, Evolution and PHP
<slangasek> StevenK: you can have OOo, enjoy ;)
<dholbach> ScottK: yes I just did - my mistake
<StevenK> Haha. No.
<ScottK> dholbach: No problem.  Such things happen.
<StevenK> That can be calc's penance.
<slangasek> StevenK: I think I have a handle on the ones in main right now anyway, I'm just noting that I'm doing those first so any universe ones assigned to me are going to be queued behind
<StevenK> slangasek: Fairy nuff
<persia> Is there a tracking bug that we should be closing?  (I'm hoping to hear "No")
<slangasek> for libldap? no
<StevenK> Right, version bumped for 19 sources.
 * StevenK kicks off test builds
<mcisbackuk> Anyone? All the packages seem to be built (scummvm-0.11.0ubuntu1) now, I just need to know what to do after running debuild -S -sa and debuild -us -uc?
<persia> mcisbackuk: You want an interdiff.  See https://wiki.ubuntu.com/MOTU/Contributing and https://wiki.ubuntu.com/UbuntuDevelopment/Interdiff
<mcisbackuk> persia: I take it this helps creating the diff file(s) for uploading?
<persia> mcisbackuk: It is a tool used to generate a file that the sponsors can use to reconstruct your package during review.
<persia> See the section in MOTU/Contributing about submitting the candidates for upload.
<mcisbackuk> persia: Cool, thanks I'll have a look :)
<persia> ScottK: Please add to the meeting agenda as well as indicating something should be discussed in the ML.  We need more meeting topics.
<ScottK> persia: I already wrote to the ML.  I'll add it to the agenda.
<persia> Thanks :)
<ScottK> persia: When is the next meeting?
<persia> ScottK: Urgh.  Someone volunteered to update that :(  20:00 UTC 1st Feb.  Fixing now.
<cbx33> where is the motu-tools pacakge now?
<cbx33> I have a nother tool to add
<persia> cbx33: ubuntu-dev-tools
<pochu> What should I do so I'm no longer moderated in ubuntu-devel@l.u.c ?
<frafu> TheMuso: thanks for the new review of mousetweaks. I have a question about the copyright holders: do I also have to include (in debian/copyright) the authors of the manual and the po files? (You only talk about the C source and header files  in your comment.)
<Hobbsee> pochu: bug cjwatson, iirc
<persia> pochu: Subscribe with an address listed on launchpad (or at least I believe that to have worked for me)
<TheMuso> frafu: I am not sure about po files, but documentation I'd say yes as well.
<persia> pochu: Release planning is more than Feature Freeze exception processing.
<pochu> persia: I am.
<pochu> Hobbsee: ok, thanks.
<pochu> persia: but the team is supposed to handle Feature Freeze only, AFAIK.
<pochu> persia: so motu-ff makes sense, whereas motu-release doesn't IMHO.
<persia> pochu: Well, that's what we need to discuss.
<frafu> TheMuso: the documentation author was already listed. ;-)
<pochu> persia: whether the team will handle feature freeze exceptions or something else?
<TheMuso> frafu: Right.
<bddebian> Heya gang
<persia> pochu: Whether there is currently a point to having release planning be separate, and what that would mean
<frafu> TheMuso: I know it because it is me   8-)
<pochu> persia: best to start on what that would mean then :)
<ScottK> persia: I guess the question is if you want actual coordination with the release team or not.  I don't think the way we did it last time was wrong.
<frafu> Could anybody please tell me whether the authors of the po files have to be listed in debian/copyright?
<Hobbsee> persia: it would probably be helpful for universe stuff to get discussed, while slangasek and co plan the main release schedule
<persia> ScottK: I don't think it was wrong either, but I'd like to be involved in release planning, and I'm not a good person to evaluate freeze exceptions.  If it is determined there is enough work to warrant two teams, I don't think two teams is bad.  On the other hand, it's not worth it just for the sake of extra teams.
<persia> Hobbsee: Yes.  Exactly.  Further, it would be good to have some means of getting universe feature goals included and stressed as part of planning.  Examples might be oldlibs cleanup, QA stuff, getting Xubuntu just right, etc.
<ScottK> persia: Personally, I found it a natural evolution.  Basically UVF just got tighter as we got closer.
<Hobbsee> persia: that's something you'll probably need to get slangasek to agree to, as he's the RM, but it sounds sensible.
 * jdong uploads some crack to revu
<jdong> I think this is like the first time I've touched revu
<jdong> (fortunate for you guys :D)
<persia> ScottK from a freeze-exception point-of-view I agree.  From a QA or feature perspective, I'm less sure, especially given when the team once called motu-uvf is selected each cycle.
<lifeless> Hobbsee: sleep!
<persia> Hobbsee: Sure.  I don't imagine many issues as long as we identify the goals early and have sufficient commitment that the RM believes we can meet them.
<Hobbsee> lifeless: will soon.
<Hobbsee> persia: of course, any non-canonical people are stuck with almost always being in the dark - particularly if they don't make it to UDS's, etc.
<Hobbsee> persia: which i don't think many MOTU people will accept, and still be able to do useful stuff with the release team.
<slangasek> persia: hmm, I think commitment from MOTU is more relevant than commitment from the RM
<persia> Hobbsee: I disagree with that.  Perhaps in the shade though.
<persia> slangasek: Well, yes and no.  If MOTU commits to trying to remove gtk1, it is worth holding release by 2 days?  Maybe, but maybe not.  Is the situation the same if MOTU commits to having human themed icons for all universe apps?
<slangasek> persia: identifying goals is great, but they don't get achieved if they aren't worked on, and I don't plan to allow myself to be committed to doing the lion's share of such QA work personally :)
<persia> slangasek: Heh.  Even if I trust the DDs to have actually closed the RC bugs, I do read the changelogs.
<Hobbsee> persia: OK, mostly.  often, one doesn't find out about new procedures at all, or if one does, it's only thru reading irc backlog.  it's rarely published, or if it is, it's not published for ages.
<slytherin> Can anyone confirm that if libpt-1.10.10-plugins-v4l2 is still in universe in hardy? I think it is one of the recommends of ubuntu-desktop but does not get included on CD.
<persia> Hobbsee: Depends on the procedure.  Also, that's a bug that needs fixing.  There are plenty of non-canonical in core and more in MOTU and if we're not all working as a team, we have issues.
<persia> slytherin: rmadison is your freind
<Hobbsee> slytherin: it's in universe
<slangasek> persia: I have a hard time envisioning a scenario where dropping gtk1 would manage to miss a release by two days.  Two days is nothing, when you know the release schedule in advance 6 months at a time; if something is committed to work on something like that, it's not going to come together at the very last minute (or if it is, I would have reservations about the change being made so shortly before the scheduled date)
<slangasek> s/something/someone/
<slytherin> persia: rmadison confirmed
<Hobbsee> persia: indeed it does.  mabye once enough people outside canonical want it to change, it'll happen.  so far, i don't think there's been sufficient interest.
<LucidFox> jdong, could you please look at bug #178845?
<ubotu> Launchpad bug 178845 in avidemux "Avidemux 2.4" [Wishlist,Confirmed] https://launchpad.net/bugs/178845
<Hobbsee> persia: really, if you (or anyone else) want to do release-based stuff, you'd be better to do it on another distro, perhaps debian.
<persia> slangasek: Last couple releases we had one or two broken universe things get in the last couple days.  For gtk1 removal, I would imagine the issue being some last FTBFS that needs sorting.  For icons, I can't imagine it worth the delay (nor accepting uploads after RC release)
<slytherin> Hobbsee: persia: so what would be the process to promote libpt-1.10.10-plugins-v4l2 to main?
<persia> Hobbsee: I think we have different definitions of "release-based" stuff.
<persia> !mir
<ubotu> mir is Main Inclusion Report - see https://wiki.ubuntu.com/MainInclusionProcess for more information.
<Hobbsee> persia: i was meaning ubuntu-release
<persia> Hobbsee: I'm not.  I mean generally making sure universe is in a releasable state at the release date.
<ScottK> Personally, I think release stuff for Universe is pretty much the coordination work we did last time.
<Hobbsee> as in, defining the cycle, sending stuff out, making sure it's ready, and deciding if there needs to be a delay, cd building, etc.
<ScottK> persia: Universe is releasable by definition.
<Hobbsee> ScottK: you've forgotten mobile, etc, already have you?
<LucidFox> persia> What gtk1 removal?
<persia> ScottK: At the end, yes.  I think there is opportunity for front-loading, but I'm not sure that's worth a separate team.
<persia> LucidFox: The one that will be done for hardy+1 or hardy+2, depending on how motivated we feel.
<ScottK> Hobbsee: No, I haven't.  I didn't disagree with you about hidden procedures.
<persia> ScottK: If universe were releasable by definition, we wouldn't need SRUs.
 * persia tries to ignore the main/universe split even harder
<LucidFox> Ah, good. About time.
<ScottK> persia: I disagree.  What would be a Universe bug that would stop the release?
<persia> ScottK: Not really stop, but any uploads after the release candidate are only supposed to be for release critical bugs.  Personally, I feel any FTBFS, cannot-install, doesn't work out of the box, etc. type bug should be closeable in universe during that time.
<Hobbsee> ScottK: something that rated as pretty damn important, and that actually had a person with a fix in sight.
<Hobbsee> ScottK: the latter being the limiting factor
<persia> Also, I think we could do better to not have so many of those open after release candidate release.  On the other hand, I'm not sure a named team would especially help this.
<ScottK> Hobbsee: Would that stop the release or get pushed to updates?
<slangasek> persia: well, if there are just a few final FTBFS needing sorted, and the goal is important enough that someone would want to delay the release for them, doesn't that make it plausible to get them sorted out in advance of the release date if there's really a commitment to them?
<ScottK> Since universe doesn't affect the iso's, there's no real need to wait.
<Hobbsee> ScottK: depends.  probably -updates, as it doesn't affect cds
<ScottK> My thought.
<ScottK> too
<slangasek> persia: I'm shying away from saying "yes, it'd be ok to delay the release if it meant dropping gtk1", even though I think that's a worthwhile goal, because setting a precedent that it's ok invites people to be more lax in their scheduling
<persia> slangasek: Of course.  I was mostly talking about coordination: if the release team doesn't want to support a MOTU release goal, it's maybe harder to promote it cleanly.
<persia> slangasek: Sure.  I neither expect nor want you to say that.
<slangasek> well, ok - I don't see that the release team supporting a MOTU goal or not should make much of a difference, I think the community is able to sort out for itself what it thinks are good goals to prioritize without needing me to tell them
<slangasek> or if it's not able to, we should address that :)
<slangasek> (e.g., better QA tools so that the problem areas are identifiable)
<persia> On the other hand, there were universe packages that went in after the very last really final freeze for both feisty and gutsy, which is more the sort of thing I mean.
 * slangasek nods
<Hobbsee> persia: if the MC supported the release goal..then it has more chance
<persia> slangasek: I'd like to see that, but when you send out a notice, it means more than when I send out a notice.
<persia> Hobbsee: Of course :)  Where's your wiki update?
 * Hobbsee waves the magic wand
<ScottK> persia: However for Gutsy we ended up with all Universe packages built for all architectures.  This is progress from Feisty.
<persia> ScottK: I thought we had 939 FTBFS for gutsy release.
<persia> (which is still progress from feisty)
<ScottK> persia: Sure.  I mean for Feisty we had some archs built on ubuntu1 and others on ubuntu2 for the same package.
<persia> ScottK: Right.  We had all packages in sync.  This time, I think we can have all packages built for at least i386, amd64 and powerpc.
 * persia is prepared to request removal-without-blacklisting for a couple packages to ensure that
<DktrKranz> removal-without-blacklisting?
<ScottK> persia: Out of the last batch of RC syncs that I uploaded for you I think we had only one or two FTBFS on a single arch.  So even piling stuff in at the last minute, we made good progress.
<ScottK> persia: What we needed was more people working it.
<ScottK> i.e. we lacked manpower, not management.
<persia> ScottK: completely agreed.  I'm just not convinced that there is an identity between the people best suited for freeze exception review and the people best suited for release coordination.  As I've said, I'm not convinced we need a motu-release team, in part because of the issues Hobbsee raised with ubuntu-release and documentation.
<ScottK> persia: I think the end game coordination that was done last time had significant value.  I don't think it makes sense to have a whole another team for it.
<persia> DktrKranz: Special type of removal for things that are broken now, but may well be fixed later, but not in time for the next release.  These get pulled back from the next automated sync.
<jdong> REVU should recognize me if I've been a member of MOTU contributors since like 2005, right?
<persia> ScottK: Today, I agree with you.  As we grow, I suspect I won't.  It's about the people not necessarily being the same, and sharing workload.
<jdong> oh nvm
<persia> jdong: No.  It forgot everyone who wasn't a MOTU last September, and hasn't uploaded since.
<persia> (and some other people too)
 * sistpoty|work whistles
<jdong> http://revu.tauware.de/revu1-incoming/clutch-0801231620/clutch-0.2/
<jdong> ROFL
 * slangasek takes sistpoty|work off the stove and pours him out into a teacup
<jdong> err.... revu should not interpret index.html inside packages
<jdong> though admittedly it looks REALLY pretty!
<sistpoty|work> he
<persia> jdong: That's a feature
<jdong> persia: really?
<jdong> well, at least it doesn't try to run the PHP scripts in remote/ :D
<persia> jdong; http://revu.tauware.de/revu1-incoming/clutch-0801231620/clutch-0.2/debian/ works, as does http://revu.tauware.de/revu1-incoming/clutch-0801231620/clutch_0.2-0ubuntu1.diff.gz (the two URLs I tend to check)
<sistpoty|work> jdong: feel free to send me an .htaccess to turn this off :P
<joejaxx> jdong: wth is that? lol is that what revu looks like now?
<jdong> joejaxx: that's the index.html in my package's source root
<joejaxx> Lol
<persia> sistpoty|work: Doesn't need an .htaccess, just turn off directoryindexing in incoming
<jdong> joejaxx: it's Clutch, a sexy AJAX web UI to transmission bittorrent
<joejaxx> oh fun :D
<frafu> @find po
<jdong> joejaxx: yeah, I'm hoping I can squeeze it into universe before we freeze up -- it'd be a great companion to our default torrent client
<sistpoty|work> persia: that would be option indexes?
<sistpoty|work> (too lazy too look at apache docs right now)
<persia> sistpoty|work: Erm.  I was last an apache admin last century.  My advice is certainly outdated.
<sistpoty|work> heh
<sistpoty|work> damn... /me is listed as server admin
<jdong> sistpoty|work: hmm good question....
<jdong> sistpoty|work: lemme look into that
<sistpoty|work> jdong: thanks... just ping me, while I'll get some work done
<jdong> sistpoty|work: wow... this is amazing... there is no way to do it :(
<DktrKranz> persia: regarding QA tools, I should really improve my NBS reverse-tracker soon to be used by a wider audience, time is the matter, though :(
<jdong> I certainly hope I'm wrong!
<sistpoty|work> jdong: there must be a way, I'm quite sure
<jdong> sistpoty|work: the way(s) to do it seem to turn off directory listing too
<jdong> sistpoty|work: except specifying DirectoryIndex a-highly-impossible-filename-or-path
<jdong> actually... that might work
<persia> DktrKranz: Yep.  Once we hit FF, NBS tends to clean up fairly quickly (as there are not supposed to be any more transitions).  On the other hand, the larger audience will appreciate it, and I'd really like it as part of the default set for hardy+1.
<tuxmaniac> after a  long time of not speaking about Alliance package I am back to trouble the MOTus to review http://revu.tauware.de/details.py?package=alliance
 * persia remembers something about apache1 having the ability to set DirectoryIndex for a specific directory on the server, and .../incoming/... is defined in a different stanza then the main application...
<tuxmaniac> loads of changes have gone into this one. the binary is giving a few lintian man page warnings which I am looking into already
<ScottK> StevenK: Do you have a moment for a requestsync bug or should I just put it on LP?
<LucidFox> Whoops, REVU broke
<DktrKranz> It has a couple of bugs to be fixed (it's unable to discriminate {pro,de}motion and counts number of NBS instead of number of packages), but it's quite accurate. And, most of all, it has an horrible look-and-feel...
<LucidFox> I get an internal server error when trying to access the source directory
<jdong> persia: you can set DirectoryIndex for a <Directory> to /some/location/that/really/cant/exist/by/POSIX/permissions
<tuxmaniac> in the meantime if someone could point me other review points, I shall do the needful
<LucidFox> hmm, seems fixed
<jdong> persia: but that sounds like one of those seven deadly apache sins
<rulus> If someone has time, please review http://revu.ubuntuwire.com/details.py?package=gtkvd. Thanks :)
 * persia refrains from remembering any other deprecated practices
<jdong> figured it out!
<jdong> sistpoty|work: in the Directory stanza for incoming, DirectoryIndex __NOFILE__ and then don't allow override
<jdong> sistpoty|work: AllowOverride None, that is.
<jdong> which I hope to god was already in there so users couldn't write their own htaccesses in uploaded packages?
<persia> jdong: Don't ask too many questions about how REVU works :)
<sistpoty|work> jdong: where do you have that __NOFILE__ from?
<LucidFox> tuxmaniac> debian/changelog for alliance is messy
<DktrKranz> slangasek: does debian provide a list of packages which depends on NBS packages somewhere?
<jdong> sistpoty|work: some dude's blog. I tested it to work if I touched __NOFILE__ apache still shows a directory listing
<jdong> sistpoty|work: you should probably verify the same just to make sure I'm not crazy
<LucidFox> tuxmaniac> since there have been no previous Debian or Ubuntu releases, debian/changelog should contain only one entry
<LucidFox> which is -0ubuntu1
<tuxmaniac> LucidFox, hmm ok
<persia> DktrKranz: There's the testing report, and the excuses report, which do some of that.  Not quite the same as pitti's script though.
<slangasek> DktrKranz: I don't believe so.  In Debian, they're usually removed from the archive as soon as they're NBS.
<DktrKranz> thanks.
<LucidFox> tuxmaniac> there are other comments, I will write them
<tuxmaniac> LucidFox, thanks a million
<slangasek> therefore in Debian, you'd really just want a report of uninstallables in unstable
<tuxmaniac> LucidFox, we are working hard to get this into hardy. :-) it will be of great support to us.
<persia> slangasek: That catches more than just packages needing rebuild or porting though: it also catches packages with various annoying bugs.
<persia> The idea of http://people.ubuntuwire.com/~dktrkranz/NBS/ is more to speed library transitions, etc.
<slangasek> persia: in Debian there's no way to distinguish
<sistpoty|work> jdong: http://revu.tauware.de/revu1-incoming/acer-acpi-0711051850/
<sistpoty|work> jdong: doesn't seem to work
<sistpoty|work> (c.f. with __NOFILE__ in that dir)
<persia> slangasek: Well, currently.  One could presumably regularly grab several packages.gz and sources.gz and compare on a daily basis to build a list.
<jdong> sistpoty|work: damn
<slangasek> persia: for that matter, knowing that it depends on an NBS package doesn't tell you it doesn't also have annoying bugs that prevent a rebuild; c.f. http://people.ubuntu.com/~ubuntu-archive/NBS/libglib1.2
<sistpoty|work> jdong: I'll try "." instead
<persia> slangasek: True.
<jdong> sistpoty|work: ooh there's a good idea
<sistpoty|work> heh, infinite recursion... bla
<DktrKranz> mh, I guess there is no common way to catch bugs from NBS list, though
<slangasek> persia: in fact, as a general rule packages that we /know/ have annoying bugs that prevent them from building from source are a subset of the NBS list :)
<persia> DktrKranz: Not really.  The archive management practices differ signficantly.
<jdong> sistpoty|work: related note, is there a purpose to http://revu.tauware.de/revu1-incoming/? it just took me 10 seconds to list that dir which could be DoS
<DktrKranz> persia: what do you mean?
<persia> slangasek: Yes.  I'm hoping to have some means of detecting the rest usefully in place for hardy+1, but I'm not sure we can have something to address the outstanding issues in hardy.
<sistpoty|work> jdong: not too sure right now... but it certainly doesn't cause a DoS (tried that, and apache doesn't really have that much load)
<sistpoty|work> jdong: the reason it's so slow, is because I'm causing heavy io-load atm... (doing a backup)
<persia> DktrKranz: The means and timing of binary package drops.  Ubuntu frequently has leftover binaries for all sorts of reasons that don't appear in Debian.  I don't understand the details well enough to explain properly, and am too tired to dig up all the examples.
<DktrKranz> ah, all clear npw.
<DktrKranz> *now
<persia> DktrKranz: There's also differences in NEW, accepted, etc, but those are less important for NBS.
<jdong> sistpoty|work: ah, ok, that explains it
<DktrKranz> anyway, if there are a need to prepare some new tools for QA, I'll likely give a hand.
<LucidFox> tuxmaniac> Commented alliance
<tuxmaniac> LucidFox, great. thanks.
<persia> DktrKranz: I think http://conflictchecker.ubuntu.com/possible-conflicts/ would benefit from a front end, if you're bored.  On the other hand, I think getting a nice interface on NBS for those who like colored clicky thingies would also be of benefit.
<jdong> sistpoty|work: I'm gonna try a combination of mod_rewrite with DirectorySlash off
<sistpoty|work> jdong: I hope it's much easier... actually I'd just like to disable mod_dir for this directory
<\sh> hmm...any python expert on?
<ScottK> \sh: Sort of.
<\sh> ScottK, trying to import dynamically some modules...
<ScottK> OK.
<\sh> with a construct like this:
<\sh> modconf=__import__('buildservice.'+m.group(1)+'.modulesconf',globals(),locals(),'ModulesConf')
<\sh> (took it from http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52241)
<jdong> sistpoty|work: is there a way to disable modules per directory?
<\sh> it should give me mod=modconf() \ mod.method()
<sistpoty|work> jdong: I hope there is, but I"m not sure
<DktrKranz> persia: colored clicky thingies are sort of things I'm definitely not good at, my sense of fashion is quite bad despite being italian... :)
<\sh> ScottK, I wonder if this works even when I'm calling this construct under buildservice.<module>
<ScottK> \sh: That's making my head hurt to look at, but I think there's at least one to many names in there.
<ScottK> \sh: But once you've done that, isn't it all part of the modconf namespace?
<\sh> ScottK, it should be...
<ScottK> \sh: I revise my answer to no.  No Python experts here.
<\sh> lol
<joejaxx> what is the policy on alpha software in universe?
<Lutin> you might not want it, especially since hardy is going to be LTS
<ScottK> joejaxx: Is it useful to users?  Are you going to support it after release?
<joejaxx> hmm now that you mention the first question i do not think anyone else is going to care for it except me
<joejaxx> lol
<joejaxx> otherwise it would have been in the archive already
<DaveMorris> joejaxx: out of interest what was it?  Someone else cares enough to create it
<geser> \sh: what do you want exactly to achieve? importing the modulesconf module for the  buildservice.<module>?
<jdong> is anyone interested in some REVUing love at http://revu.tauware.de/details.py?package=clutch? :D
<joejaxx> DaveMorris: steganographic filesystem
<\sh> geser, yepp...got it :)
<DktrKranz> vorian: you're welcome, thanks for your patience :)
<DaveMorris> joejaxx: I could have fun with that :)
<vorian> DktrKranz: no worries
<vorian> :)
<vorian> you da best!
<geser> \sh: should relative imports help you?
<joejaxx> DaveMorris: lol
<\sh> geser, nopd
<\sh> geser, nope
<DaveMorris> esp if you could hide files into movies.  Would work well with mythtv :)
<\sh> geser, well, it's working now ;) I just should follow the example :)
<geser> ok
<joejaxx> DaveMorris: it does not exactly work like that :P
<jdong> how do revison uploads into REVU work
<jdong> do I need to bump the version? -sa?
<pochu> jdong: -S -sa
<jdong> pochu: thanks :)
<geser> jdong: you can upload the same revision as often as needed to REVU
<jdong> very good
<ScottK> That and diffs between the uploads are, IMO, REVU's killer features.
<\sh> geser, ok..works now
<frafu> From googling, it seems that the debian/copyright file does not need to list the authors of the po files. The practice seems to be to indentify them in the ChangeLog. Could anybody please confirm?
<yamal> MOTUs, the latest & greatest sabnzbd package is ready for review @ http://revu.tauware.de/details.py?package=sabnzbdplus
<LucidFox> yamal> Hmm, I just noticed your email address ends with .ru, do you happen to be a Russian?
<yamal> nope
<LucidFox> :(
<\sh> who is doing syncs this week?
<geser> \sh: seb128 did some some minutes ago
<emgent> \sh, see my query
<LucidFox> yamal> Looks good to me now. (IANAMOTU, so can't advocate)
<yamal> LucidFox: still, thanks for checking it out :)
<LucidFox> jdong, if you have time, I would like you to look at a Gutsy backport: bug #177353
<ubotu> Launchpad bug 177353 in gutsy-backports "Please Backport SMPlayer 0.5.62" [Undecided,Confirmed] https://launchpad.net/bugs/177353
<LucidFox> * backport request
<joejaxx> if upstream has a version setup that is similiar to debian how do you proceed with the version number in debina /ubuntu?
<joejaxx> as in package-1.0-2beta
<joejaxx> being the upstream version?
<joejaxx> debian*
<joejaxx> :D
<pochu> 2beta means beta2? :)
<pochu> joejaxx: if so, I'd go for 1.0~beta2-0ubuntu1
<joejaxx> ok
<sistpoty|work> joejaxx: I'd substitue the - with another allowed character
<pochu> Or maybe it is 1.0.2~beta-0ubuntu1
<pochu> sistpoty|work: right, but if there's a package-1.0-2 later, he needs to lower this one with ~beta
<joejaxx> hmm
<sistpoty|work> pochu: sure, depends just if upstreams version number is after an 1.0 or before an 1.0 release ;)
<pochu> sistpoty|work: right
<pochu> sistpoty|work: btw were you able to look at my REVU patch? :)
<joejaxx> "Package names must only consist of lower case letters, digits (0-9), plus (+) or minus (-) signs, and periods (.)"
<joejaxx> it does not like the ~
<sistpoty|work> pochu: not yet, sorry
<sistpoty|work> (at least not yet in detail)
<slangasek> joejaxx: there's nothing wrong with having - in an upstream version number, only the last dash is used to delineate the upstream and debian revisions
<pochu> sistpoty|work: ok, no worries :)
<sistpoty|work> slangasek: it's against policy?
<slangasek> sistpoty|work: uh?
<pochu> joejaxx: I've seen lots of packages using ~
<slangasek> it most certainly isn't against Debian policy
<sistpoty|work> slangasek: ups... inverted the condition *g*
<joejaxx> well debhelper is complaining :P
<joejaxx> pochu: ^
<pochu> complaining as in warning?
<sistpoty|work> always these double negations: "If there is no debian_revision then hyphens are not allowed" *g*
<slangasek> joejaxx: if you have a ~ in the package name, you've replaced the wrong -
<slangasek> for that matter, "bwuh?"
<joejaxx> slangasek: 1.0~beta-0ubuntu1 is incorrect?
<slangasek> joejaxx: as a package *name*? you betcha
<joejaxx> no
<joejaxx> :P
<joejaxx> as a versoin
<joejaxx> version*
<slangasek> joejaxx: what error are you getting?
<slangasek> you quoted "Package names must only consist of lower case letters, digits (0-9), plus (+) or minus (-) signs, and periods (.)"
<joejaxx> debhelper things the 1.0~beta is part of the package name
<joejaxx> when it is now
<joejaxx> not*
<slangasek> please give an exact error message
<slangasek> or point to a package that's giving this behavior
<slangasek> er, by "debhelper", do you mean "dh_make"?
<frafu> TheMuso: I just uploaded the fixed version of the mousetweaks debian package to revu. So, if you have time and are still interested,... Let's hope that this time it will be completely correct.  ;-)
<sistpoty|work> pochu: patch looks fine, applied to production. I'll commit it to trunk this evening
<sistpoty|work> pochu: thanks!
<AnAnt> persia: hello
<proppy> hi
<joejaxx> lol nevermind
 * joejaxx has not had any sleep yet and just named the source directory with that version instead of modifying debian/changelog
<AnAnt> dholbach: ping
<joejaxx> haha
<joejaxx> that will error out for sure lol
<joejaxx> slangasek: ^ :P
<pochu> sistpoty|work: yohoo, thanks a lot :-)
<slangasek> joejaxx: well, I guess that means you found your error? dh_make != debhelper, in any case; so I was a little confused about how debhelper would have ever objected
<joejaxx> sorry for the confusion :P
<joejaxx> i forgot they are separate packages :P
<TheMuso> frafu: Will look at it shortly, thans.
<joejaxx> well thanks for being here through my ignorance :P
<frafu> TheMuso: thanks to you.    :-)
<dholbach> AnAnt: pong
<AnAnt> dholbach: could you review the ubuntume-gdm-themes & usplash-theme-ubuntume ?
<dholbach> AnAnt: this shouldn't be blocked on me - just ask in here for somebody to do the review
<AnAnt> dholbach: ok
<LucidFox> If any MOTUs are up for REVU reviews, I would recommend http://revu.ubuntuwire.com/details.py?package=libgee - I reviewed it in the past, among other people, and now all the problems seem to have been solved, I couldn't find any new ones
<LucidFox> and I'm interested in this package :)
<AnAnt> could someone review those:  ubuntume-gdm-themes & usplash-theme-ubuntume ?
<tuxmaniac> LucidFox, if I add Homepage: field to debian/control it gives a warning "Unknown Homepage field" during pdebuild. Is there something I am missing here? This is wrt alliance package that you commented
<LucidFox> tuxmaniac> That's normal
<jdong> gpg -d <<EOF
<jdong> oops
<joejaxx> jdong: lol :P
<ScottK> Does anyone have an example of a daemon that is written in Python/Perl or some other similar language.  I'm having trouble --exec'ing it in the init.
<RainCT> \sh: Hi. Â«pbuilder-dist build xÂ» doesn't work here now (it says Â«Command line parameter [] is not a valid .dsc file nameÂ»)...
<\sh> RainCT, hmmm...
<joejaxx> RainCT: did you specify the release? :D
<joejaxx> or does pbuilder-dist fall back on which ever release it is published on when not specified?
<\sh> joejaxx, he 's right
<RainCT> joejaxx: I use pbuilder-hardy, pbuilder-gutsy, etc. (but also tried with Â«pbuilder-dist hardyÂ»)
<joejaxx> RainCT: i thought you were talking specifically about the `pbuilder-dist` command :)
<joejaxx> Warning: Unknown distribution Â«buildÂ». << for example :D
 * joejaxx stops rambling
<RainCT> lol
<RainCT> \sh: I think I had the same problem when I tried to add gksudo support myself some weeks ago..
<\sh> RainCT, give me a sec...it could be that $@ is wrong
<saivann> Hi, I tried to upload a new package for reviewing to REVU and I got a email saying : Signer has no upload rights at all to this distribution. Can someone help me around that? I try to upload simdock package which I would like to be reviewed for bug #183942
<ubotu> Launchpad bug 183942 in ubuntu "[needs-packaging] simdock" [Wishlist,In progress] https://launchpad.net/bugs/183942
<sistpoty|work> saivann: you seem to have uploaded to ubuntu, not to revu (as revu doesn't write any mails if an upload is dropped)
<sistpoty|work> saivann: check /etc/dput.cf... and iirc a revu section should already be there. If so, you can dput revu <changesfile>
<saivann> sistpoty|work : Thanks for this info, I used default dput configuration, I'll take a look..
<CyberMatt> hello looking for advocates for my package http://revu.tauware.de/details.py?package=jailkit
<saivann> I found the problem, thanks!
<sistpoty|work> np
<LucidFox> saivann> What is the package you're uploading to REVU?
<nenolod> crimsun, ping
<\sh> RainCT, looks like he is already root without and jumping into /root
<saivann> LucidFox : A new package, simdock, for hardy ( it's a dock which doesn't require Compiz )
<\sh> and can't find the .dsc
<tuxmaniac> has there been any issues with the latest gutsy upgrades. After a recent xserver-xorg upgrade all my videos are in monochrome
 * sistpoty|work heads home... cya
<\sh> RainCT, please check with something else then pbuilder-dist :)
<Adri2000> clear
<Adri2000> err
<Adri2000> sorry :)
 * Pici applies the paddles to Adri2000 
<Pici> *clear*
<Pici> Oh, this is -motu, not -offtopic.  /me scurries off
<\sh> RainCT, because when I use pbuilder manually it gives me the very same error message
<DaveMorris> saivann, you need to close the LP bug in your changelog, see my opensg package for an example at http://revu.tauware.de/details.py?package=opensg
<DaveMorris> Your debain copyright just needs the preamble of the licence and a link to where it is on the file system, see this for an example http://revu.tauware.de/revu1-incoming/opensg-0801101810/opensg-1.8.0/debian/copyright
<saivann> DaveMorris : I'll fix this in 2 minutes, thanks, you're right I forgot this
<DaveMorris> your control file needs to have a hompage and xsbc-orginal-maintainer fields, again see http://revu.tauware.de/revu1-incoming/opensg-0801101810/opensg-1.8.0/debian/control for an example
<DaveMorris> maintainer should be Ubuntu MOTU Team <ubuntu-motu@lists.ubuntu.com>
<jdong> anyone in a REVU mood? :D
<\sh> RainCT, got it
<DaveMorris> saivann: also fix the problems lintian and linda are moaning about
<saivann> DaveMorris : I though that it was due to the fact that this package use cdbs, isn't it?
<DaveMorris> no, your standards version is old
<saivann> Ok, noted!
<DaveMorris> saivann: something like this in your rule file will fix the other warning http://www.pastebin.ca/870022
<DaveMorris> remember that if needs to be tabbed in though
<\sh> RainCT, try to put a "--" between $SUDOREPLACE and pbuilder call, and remove the leading " before pbuilder call and after $@
<saivann> DaveMorris: I just added these lines to the rules file, thanks, I'll look if it will fix the warning
<DaveMorris> ls
<nixternal> jcastro: I like that playbook idea
<nixternal> DaveMorris: ls doesn't work in IRC :p
<nixternal> I have tried, at least a few thousand times
<jdong> Password:
<nixternal> heh
<\sh> could someone test pbuilder-dist from here? https://code.edge.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk
<RainCT> \sh: still doesn't work here.. :/
<\sh> RainCT, you need to invalid your sudo session
<\sh> hmpg
<\sh> if gksudo fails, sudo failes too...
<\sh> but sudo is doing correct now
<\sh> damn
<\sh> it worked and now not
<leonel> Just a question   :   asking in #postgresql   about  PostgreSQL 8.3 release  someone said that  before march will be released  ..  according to Hardy Release Schedule  Feb 14 is  Feature freeze   so  if PostgreSQL 8.3  gets released in  March   Is there any chance to include PostgreSQL 8.3 in Hardy ??
<rexbron> Got time for a review? Take a look at http://revu.ubuntuwire.com/details.py?package=openlibraries
<rzr> hi
<rzr> i worked on jaaa, it semms to be uploaded but RFS isnt closed how comes ? https://bugs.launchpad.net/ubuntu/+bug/160732
<ubotu> Launchpad bug 160732 in ubuntu "[needs-packaging] Jaaa (JACK & ALSA Audio Analyser)" [Wishlist,In progress]
<jdong> wait a sec, orig.tar.bz2s aren't valid, are they?
<zul> nope i dont think so
<zul> at least I dont recall seeing one
<jdong> *grumble* stupid uscan
<jdong> aha, uscan --repack
<ion_> uscan --repack seems to bunzip2 -c foo | gzip > bar. I wonder why not gzip -9.
<jdong> ion_: because it takes 10x as long for a very small gain, IMO
<jdong> if we want fast and small, we should work on orig.tar.lzma's ;-)
<DaveMorris> saivann: you didn't upload the orginal tarball so your update won't unpack on revu
<cbx33> hey hey
<cbx33> howz it going everyone
<saivann> DaveMorris : I just learned this, my package has been re-uploaded 40 seconds ago
<jdong> cbx33: good thanks for volunteering to revu my package :)
<cbx33> so, I got a tool to add to ubuntu-dev-tools
<cbx33> jdong, I did?
<jdong> cbx33: of course :) You spoke first
<cbx33> poop
<cbx33> Depends how soon you need it?
<cbx33> and if imbrandon gave me advocate powers on revu yet
<jdong> cbx33: I was just messing with you, if you really want to revu for me, that's cool but I don't expect you to ;-)
<cbx33> i'll take a look but can't say it'll be tonight
<cbx33> what's the pacakge?
<jdong> cbx33: clutch
<cbx33> so, what's the procedure for adding to that pacakge, dholbach said I should get the source from lp and commit my change
<cbx33> having not done that on someone elses branch before
<cbx33> would I checkout
<cbx33> as opposed to branching
<cbx33> and then would i commit or push or what?
<jdong> cbx33: nah, you'd branch like normal
<cbx33> oh
<cbx33> then push?
<jdong> cbx33: and then you'd push to your own ~user_name/ubuntu-dev-tools/your-branch-name
<cbx33> oh i see
<cbx33> right
<\sh> RainCT, ok...something is totally wrong with the script
<cbx33> ouch.....why does http://revu.tauware.de/revu1-incoming/clutch-0801231940/clutch-0.2/
<cbx33> take me to some weird place with torrent stuff?
<cbx33> oh RainCT was it you that improved my 404main script?
<cbx33> if so thanks....only saw the changes today ;)
<RainCT> cbx33: yes. no problem :)
<cbx33> adding a new one
<cbx33> it scans a python file and tells you the deps
<cbx33> recursive of course
<RainCT> cool
<cbx33> not 100% fool proof
<cbx33> but good for a start
<jdong> should manpages go into /usr/man?
<jdong> I thought they belong in /usr/share/man?
<cbx33> why can't I browse the files and more
<cbx33> any
<cbx33> just what is http://revu.tauware.de/revu1-incoming/clutch-0801231940/clutch-0.2
<cbx33> ??
<jdong> cbx33: that's revu interpreting the index.html in the package
<ion_> Just an index.html in the root :-)
<cbx33> oh
<cbx33> stupid
<jdong> cbx33: if you've got an idea how to turn that off in apache, we spent an hour on that this morning :D
<cbx33> hmm
<cbx33> well
<cbx33> not locally I don't think
<cbx33> that's an interesting one
<DaveMorris> jdong: move the index.hmtl our of the root dir upstream ;)
<cbx33> does an .htaccess apply to just the current dir or do child dirs inherit?
<jdong> cbx33: inherit , I think
<cbx33> so
<jdong> cbx33: we cannot found any option to turn off DirectoryIndex directives
<jdong> cbx33: without turning off auto-indexes
<cbx33> hmm
<cbx33> DirectoryIndex usually being index.html index.php etc
<jdong> right
<cbx33> what about setting it to be something exceedingly obscure?
<jdong> cbx33: well... that's quite a hack, isn't it? :)
<DaveMorris> saivann: Sorry, I was wrong before, you actually nned to remove config.cache and config.status rather than config.log
<cbx33> jdong, sure
<cbx33> but it would make it so idiots like me didn't get confused
<jdong> cbx33: well we wanted to find the "right" solution so as to also reduce the liklihood of security-related consequences of index interpretation
<saivann> DaveMorris : np, thanks for that solution, I'll fix it again, but before all, you talked about awn dock for Hardy, do you think that there's any interest to also add simdock?
<cbx33> jdong, true
<DaveMorris> saivann: you'll also wanna have debhelper (>= 5) instead of debhelper (>= 4.2.16) in your debian/control file
<DaveMorris> saivann: I would on my older hardware which can't run compiz/berly
<saivann> DaveMorris : Ok, I'm fixing this
<saivann> DaveMorris : For the clean rules, is that ok : 	if [ -e config.log ] ; then rm config.cache ; rm config.status ; fi ;
<DaveMorris> saivann: your copyright file is slightly wrong
<saivann> DaveMorris : In which way?
<saivann> DaveMorris : It is not GPL2 ?
<DaveMorris> no you want if [ -e config.cache  ] ; then rm config.cache ; fi ; and f [ -e config.status  ] ; then rm config.status ; fi ;
<saivann> DaveMorris : Oh you're right
<DaveMorris> You copy and pasted the bit from my package bby the look of things, my package was LGPL whereas your is GPL
<cbx33> jdong, hmm that's a tricky one
<DaveMorris> so lines 12, 18, 24 need changing
<saivann> DaveMorris : What is the right name to replace "GNU Library General Public License", "GNU General Public License" ?
<DaveMorris> saivann: yes, also looking at the source files they have "either version 2 of the License, or  (at your option) any later version." so you'll need to add that in
<saivann> DaveMorris : Is that OK? : http://upload.leservicetechnique.com/bugs/copyright
<rzr> le sevice technique hehe
<DaveMorris> line 24 has Library on it still
<saivann> DaveMorris : Ok updated
<DaveMorris> apart from that looks good to me
<saivann> DaveMorris : Ok I test building with the rules file and I upload to REVU again, thanks for your assistance
<saivann> rzr : leservicetechnique.com, it's because I give technical services to people with their computer :)
<rzr> saivann: see #ubuntu-fr you've got a customer waiting :)
<ScottK2> Any shell scripting experts handy (or even journeymen I suspect)?
<ScottK2> I'm trying to package a daemon written in Python.
<ScottK2> I've got a short shell script that is called by the init that fires it off.
<ScottK2> I need to have it also make the pid file.
<ScottK2> Any suggestions on an easy way to do that?
<jdong> ScottK2: start-stop-daemon should have a flag for making a pid file on behalf of the daemon
<saivann> DaveMorris : There's probably a syntax error in the rules file, maybe in the "and if" part because that doesn't build, do you see something? :if [ -e config.cache  ] ; then rm config.cache ; fi ; and if [ -e config.status  ] ; then rm config.status ; fi ;
<ScottK2> jdong: It does, but it also describes that as a last resort.  I'm going to give that a try now.
<DaveMorris> yeah the 2 if's should be on different lines without the and part
<DaveMorris> I should of used a pastebin, would of been clearer
<saivann> DaveMorris: Ok I'll test this
<saivann> DaveMorris : If you prefer :) I'm still very a beginner with this :)
<saivann> DaveMorris : It seems to work
<saivann> DaveMorris : re-uploaded, waiting to see it in REVU
<DaveMorris> yeah, it runs every 10 mins
<saivann> DaveMorris : It's here now
<asabil> hi all
<asabil> anyone to advocate this please : http://revu.tauware.de/details.py?package=libgee ?
<\sh> RainCT, I'm rewriting it from scratch...there is really something wrong with it
<pochu> what is the command to know the ip of a webpage?
<ion_> Itâs most likely v4. ;-)
<ion_> dig, host, getent hosts etc.
<jelmer> 'evening
<jelmer> is there documentation somewhere about how to merge changes from debian?
<jelmer> in particular, how the changelog file
<mok0> hey
<cbx33> \sh, you looking after ubuntu-dev-tools?
<mok0> cbx33: heh just having a problem with that
<cbx33> if so I just added a new tool called pydep to my branch https://code.edge.launchpad.net/~petesavage/ubuntu-dev-tools/trunk
<cbx33> mok0, with what?
<pochu> ion_: thanks
<\sh> cbx33, yepp
<cbx33> \sh feel free to see if you like it and add it
<cbx33> I'm sure RainCT will hack at it :p
<mok0> If I say: pbuilder-dist hardy create is echoes the command line and says: command not found
<\sh> mok0, yepp...working on it
<mok0> \sh: great.
<\sh> mok0, there are some strange problems...and I can't figure out why the sudo call doesn't work..
<\sh> without all the crap around and the shell vars set it works
<mok0> \sh: do you need sudo when it's building under your root?
<\sh> mok0, as user you need sudo ... as root not ;)
<cbx33> \sh it's not 100% reliable, but it's a good start if you need to package a python app and don't know its deps
<mok0> \sh: root can't write in my home dir, it's on an NFS share
<\sh> mok0, well, the problem of pbuilder
<\sh> mok0, using sbuild for myself now :)
<mok0> \sh: is that better?
<\sh> mok0, well it's more like the buildds of ubuntu...
<\sh> mok0, but it makes more sense when you have a local mirror...
<mok0> \me is ignorant of buildds
 * mok0 is ignorant of buildds
<mok0> \sh: but I'd like to have one :-)
<\sh> hmm...how do I check in a case loop against a value of a shell var ?
<\sh> $FOO ) doesn't help
<mok0> \sh: "$FOO")   ??
<\sh> nope
<RainCT> \sh: here $FOO) works
<\sh> RainCT, even in a fcuntion with the case?
<RainCT> \sh: moment, I'm testing..
<RainCT> \sh: yes
<RainCT> (tried with both bash and sh)
<\sh> RainCT, try this: http://pastebin.ubuntu.com/3817/
<RainCT> \sh: http://paste.ubuntu.com/3818/
<RainCT> ok, moment
<\sh> that's easy...this works ;)
<RainCT> looks nice with functions :)
<\sh> well, command line options will be dynamic ;)
<\sh> tricky a bit
<\sh> you see what I want to achieve?
<\sh> I'm getting the releases from /usr/share/debootstrap/scripts/ and create a $RELEASES with "dapper|bla|foo|etc" and now I need the value of $RELEASES as check for check_commandline ;)
<RainCT> I see :)
<\sh> $RELEASES is available in check_commandline...but it's not parsed as value
<RainCT> good idea
<RainCT> \sh: ./test: 17: Syntax error: "(" unexpected :P
<RainCT> \sh: in sh functions are just "blah()", not "function blah()"
<\sh> RainCT, yeah
<RainCT> ok.. now I don't get any output :P
<RainCT> ah ok
<\sh> let not defined
<\sh> what's the correct syntax in dash for let?
<RainCT> \sh: what does let do?
<jdong> /bin/bash -c "let .... just kidding
<\sh> RainCT, let is for arithmetic vars only
<\sh> so all numbers ;)
<RainCT> h
<RainCT> *ah
<RainCT> I'm checking https://wiki.ubuntu.com/DashAsBinSh/, I think there was something about let
<\sh> well, the dash bash problem is not important ;) the case is more important ;)(
<RainCT> right
<torkel> leonel: https://launchpad.net/ubuntu/+source/postgresql-8.3/
<leonel> torkel: Great !
<\sh> RainCT, 		x=$(($x+1)) is the dash replacement for let x=$x+1
<RainCT> \sh: I'm asking in #bash about it
<\sh> RainCT, thx :)
<RainCT> :(
<RainCT> >> greycat: You can't.  Don't put code in variables.  Put code in code.
<\sh> RainCT, the $RELEASES is dapper|asdasdkj
<RainCT> >> SiegeX6: i think you can ugly hack it with eval
<RainCT> breezy|dapper|edgy|etch|feisty|gutsy|hardy|hoary|hoary.buildd|lenny|potato|sarge|sarge.buildd|sarge.fakechroot|sid|warty|warty.buildd|woody|woody.buildd
<\sh> well..tomorrow more...need to go...wife is at home
<\sh> RainCT, or if you find a solution just mail me :) sh@sourcecode.de
<RainCT> \sh_away: okay... cya :)
<RainCT> cbx33: where have you put that pydep thing?
<RainCT> I don't see it in http://codebrowse.launchpad.net/~petesavage/ubuntu-dev-tools/trunk/files
<cbx33> it should be RainCT
<cbx33> hang on
<cbx33> RainCT, I was stoopid
<cbx33> it is there now
<cbx33> or will be in a few secs
<DaveMorris> saivann: I've built your package and looked at it.  http://www.pastebin.ca/870195
<mok0> DaveMorris: ... but you can comment, now
<DaveMorris> can I?
<mok0> Yes
<cbx33> RainCT, it is there now
<mok0> New feature on REVU
<mok0> DaveMorris: try it!
 * DaveMorris finds his password
<DaveMorris> so I can
<DaveMorris> when did the feature go live?
<RAOF> While we're on the shell scripting, how do you actually set IFS to split on lines and nothing else?
<blueyed> RAOF: IFS='<ENTER>'?
<blueyed> while pressing enter for ENTER of course.
<mok0> DaveMorris: a few days ago
<RAOF> blueyed: Thanks.  I hadn't tried that particular permutation :)
<mok0> DaveMorris: it was announced on ubuntu-motu ML
<jdong> can I revu-whore? http://revu.tauware.de/details.py?package=clutch
<DaveMorris> I'm not subscribe to that one, I best sign up on it
<saivann> DaveMorris : Thanks for these relevant comments, I'll fix this too
<DaveMorris> saivann: feel free to ask if your unsure as to how to fix those issues
<saivann> DaveMorris : Great! In fact yes I would have a question, in which section of the rules file I should cp the man templates to the build directory?
<saivann> s/man templates/man template/
<DaveMorris> do you mean how do you install manpage ?
<saivann> DaveMorris : I know that during the build process, compiled files go to a /tmp/buildd folder in the debian folder AND after this, these files are packaged as binary package. I need to know when, in the rules file, the manfile template should be copied..
<DaveMorris> if you look at http://revu.tauware.de/revu1-incoming/opensg-0801101810/opensg-1.8.0/debian/ you'll see opensg-tools.manpages
<DaveMorris> you'll need a file like that called simdock.manpages with the path to find the man page
<saivann> DaveMorris : CDBS will automatically install that manpage?
<DaveMorris> yes, you also need to create the manpage
<saivann> opensg-tools.manpages specify this file : "fcdedit.1" but where is this file?
<DaveMorris> it's created with a patch
<jdong> c!
 * DaveMorris wonders if anyone has 3/4 hrs to review his package. http://revu.tauware.de/details.py?package=opensg
<saivann> DaveMorris : Ok I found the patch, this patch creates the man file template at the root of the package?
<emgent> lol
<DaveMorris> yeah, I use cdbs patches,  to create it for me
<DaveMorris> but you can do it different ways
<saivann> DaveMorris : All I need to do to use that patch system is to respect names in the patches folder and add this to the rules file? : include /usr/share/cdbs/1/rules/simple-patchsys.mk
<DaveMorris> saivann: best way is to 1.) create your man file and make sure it works. 2.) incldue the line you mention in rules. 3.) in the root of your package do "cdbs-edit-patch 01-add-simdock-manpage.patch" This will give you a clean source package to create your patch in. 4.) copy your manpage in and exit the patch shell ( ^D I think)
<DaveMorris> this will give you your patch in debian/patches then
<saivann> DaveMorris : Wow.. I don't get how the man template finally get in the /usr/share/man folder
<DaveMorris> cdbs does it for you with the help of the .manpages file
<saivann> DaveMorris : Ok thanks, I copied your instructions and I'll explore this. If you're here in more than 1 hour, perhaps that I'll finished my work on this
<DaveMorris> I've got to go now, but I check it tomorrow at work.
<RAOF> saivann: More explicitly, cdbs always calls dh_installman, which looks at debian/manpages
<RAOF> saivann: CDBS is only magic in that it calls a whole bunch of debhelper (dh_foo) scripts for you automatically.
<saivann> RAOF : Thanks for that informations :) I need to learn more about these.
<saivann> DaveMorris : Thanks for all the help you gave to me today, I'll continue my work on this
<LaserJock> what would -dh_strip do?
<LaserJock> I've not seen putting a - before a dh_*
<LaserJock> is it just disabling it?
<persia> LaserJock: Makes rules not exit when stripping fails.  Shouldn't be there, or we don't see bugs in dh_strip.
<LaserJock> hmmpf
<LaserJock> well, wine had .debs about 3x larger than it used to
<LaserJock> it looks to me like the debugging symbols aren't being stripped
<LaserJock> I found that dh_strip was changed to -dh_strip
<LaserJock> with the following changelog entry:
<LaserJock> * debian/rules: ignore dh_strip errors to fix FTBFS in buildds
<LaserJock> so does that mean dh_strip was erroring out hence not stripping all the binaries?
<RAOF> Sounds like a plausible hypothesis.
<RainCT> good night
<mcisbackuk> Evening all! Quick question on packaging if there's anyone to answer?
<RainCT> Hi mcisbackuk
<RainCT> !ask > mcisbackuk
<mcisbackuk> RainCT: Hi
<RainCT> !ask | mcisbackuk
<ubotu> mcisbackuk: Please don't ask to ask a question, ask the question (all on ONE line, so others can read and follow it easily). If anyone knows the answer they will most likely answer. :-)
 * RainCT goes to bed.. good night :)
<mcisbackuk> OK...I was packaging scummvm from the latest upstream release, the sources are packaged and there didn't seem to be any problems, just wanted to know if I've done it right....I created the diff and interdiff, and I've uploaded them both to Launchpad, bug #183976. Is there anything else that needs to go on there?
<ubotu> Launchpad bug 183976 in scummvm "new upstream version 0.11" [Undecided,Confirmed] https://launchpad.net/bugs/183976
<persia> mcisbackuk: That's a well formed upgrade bug.
<mcisbackuk> persia: What's that mean?
<persia> mcisbackuk: You have done what you need.  You are now waiting for a sponsor to review.
<mcisbackuk> persia: Wow, I actually contributed! So there's no further steps for me until it's been reviewed? That's me happy :)
<mcisbackuk> Well its thanks to you guys that I've learnt a few things to do with packaging, so for that thank you to the guys who helped its much appreciated :) Hope to be working with you all more often :)
<rexbron> persia, I have been reading http://wiki.debian.org/RpathIssue and I believe that the current use of
<rexbron> rpath in openlibs is acceptable
<rexbron> as it is only between libraries in the same source package and they are installed to a non-standard directory
#ubuntu-motu 2008-01-24
<rexbron> where would be the appropreate place to document this sort of decision?
<rexbron> (that last question is open to all)
<LaserJock> rexbron: probably first ubuntu-motu/ubuntu-devel ML
<rexbron> LaserJock, this package is not in the repos yet, but I will do so
<persia> rexbron: I'm not really here, but my concern is that while openlibraries uses rpath entirely internally within itself, open libraries is intended to be used for building other applications, and I'm not convinced that there won't be odd follow-on behaviour once other packages dynamically load the libraries, possibly with RPATH set, nor am I sure those packages won't run against policy.  I may be completely mistaken, and expect your research to hav
<rexbron> ouch buffered
<rexbron> I would think that any libraries that use openlibs would not use rparth, hense preserving upgrade sanity
 * rexbron will definately take it to the ML
<RAOF> rexbron: But if the openlibraries itself uses rpath, then anything using it...
<rexbron> RAOF, if only internally?
<RAOF> rexbron: But the OL libraries are installed into a non-ld-config-known path, right?  Anything linking against them will need to do annoying stuff.
<rexbron> Basically, openlibraries is a collection (five main ones, with in each there is a C++ lib and a python binding) and a bunch of compiled plugins for those libs
<rexbron> RAOF, by nonstandard I mean /usr/lib/openlibraries-<foo>
<rexbron> which is how upstream is installing it
<RAOF> Ok.  So the libraries themselves are in /usr/lib, and the plugins are in /usr/lib/openlibraries type thing?
<rexbron> no,
<rexbron> currently everything is in /usr/lib/openlibraries-0.5.0
<RAOF> That sounds like a really annoying idea.
<rexbron> RAOF, I was striping the rpath out of the libs that had it (not all of them do)
<rexbron> but that completely broke the python bindings
<rexbron> due to the non-standard location
<rexbron> it is possible though that I mangle it in  the .install files
<RAOF> This non-standard location isn't build-time configurable?
<rexbron> afaict, no
<rexbron> beyond a prefix
<RAOF> rexbron: For details of why installing libraries in /usr/lib/foo is really annoying, see *anything* which embeds gecko.
<rexbron> :P
<RAOF> That's annoying.
<RAOF> Whine upstream :P
<crimsun> nenolod: pong
<crimsun> RAOF: pong
<rexbron> RAOF, upstream just revived itself
<rexbron> RAOF, it might have to do with the devs being Mac and Windows peps
<RAOF> crimsun: Hi.  Trying to hack in multiarch _sucks_ :(
<crimsun> heh, it's nice and comfy down here in hell, isn't it?
<rexbron> I wonder if I strip rpath and install everything to /usr/lib if the problems would allivate themselves
<RAOF> rexbron: Worth a try :)
<rexbron> I am unsure if ld.so.conf is getting updated by debhelper...
<RAOF> crimsun: My final problem is trying to make the bi-arch build not build plugins that it can't, but pkg-config thinks it can.
<rexbron> RAOF, the dir structure is like this: usr/lib/openlibraries-0.5.0/openeffectslib/plugins/
<rexbron> or usr/lib/openlibraries-0.5.0/openeffectslib/lib
<RAOF> rexbron: Hit upstream with a big "what the hell are you doing" stick.
<rexbron> "Bash upstream with the libtool handbook.."
<RAOF> It makes sense to have the plugins in /usr/lib/<my_plugin_dir>, but that looks mad.
<crimsun> RAOF: did you mean to follow up that last one?
<RAOF> crimsun: By "last one" did you mean the "stopping it building the plugins it can't, but pkg-config makes it think it can"?
<crimsun> RAOF: yes
<RAOF> Ah.
<RAOF> I can explain the problem: configure checks pkg-config for libpulse, jack, ald dbus-1, and sets "HAVE_foo".
<RAOF> However, pkg-config is returning results for the native bitness libraries.  So it tries to build all of these plugins.
<RAOF> I can partially work around this by telling pkg-config to look in /usr/lib$)bi)/pkgconfig (which is empty) and manually specifying the right libs & cflags.
<RAOF> That builds the basic plugins, with no external dependencies.  However, since they use a [if found] and a [if not found] custom action for their PKG_CHECK_MODULE configure calls, libpulse & dbus-1 (which exist in ia32-libs) don't get built.
<kdub> anyone have program that needs packaging that they've been saving for a newbie :-)?
<RAOF> crimsun: Given that what *I* want out of lib32asound2-plugins is a 32bit pulse plugin, this isn't very useful behaviour for me :(
<RAOF> crimsun: Any ideas?
<crimsun> RAOF: do your basic debian/rules modifications follow alsa-lib's?
<RAOF> crimsun: Yes, they do.  I can post them, if you like.
<crimsun> sure, though my attention is diverted to a PA security issue ATM, so I'll be slow in responding.
<RAOF> crimsun: That's fine.  It's at http://www.cooperteam.net/rules
<LaserJock> anybody know how to tell tracker what to index?
<_MMA_> LaserJock: Isnt there a place where to tell it what *not* to index?
<LaserJock> bah
<LaserJock> I killed it
<LaserJock> I want it to index my pdfs
<StevenK> That isn't hard
<LaserJock> and it doesn't seem to do it
<LaserJock> does it not index .pdf files?
 * _MMA_ only thought there was a blacklist.
<ScottK> LaserJock: It'll index your ISO images too.
<LaserJock> ScottK: hah, that's smart
<LaserJock> I saw it also indexes vmware images
<_MMA_> :)
<LaserJock> but they're gonna blacklist that
<LaserJock> so far the only thing I found it *can* do is index my email
<ScottK> Well I think Tracker is one of the best advertisements Kubuntu has has in a long time.
<LaserJock> which I can already do from evo
<LaserJock> ScottK: you use strigi?
<ScottK> LaserJock: Actually not, but I understand it's better behaved.
<ScottK> My main desktop (where it'd be useful) is still Dapper.
<LaserJock> I know there's been some cool work with strigi and chemistry indexing
<nenolod> crimsun, would ALSA plugin chains cause problems with DMA writes in libalsa?
<ScottK> LaserJock: BTW, so far so good the mass clamav backport.  Thanks again.
<LaserJock> ScottK: great
<crimsun> nenolod: quite probably, particularly if dmix and/or dsnoop are in the mix.
<LaserJock> bah, I give up >:(
<emgent> heya people
<bddebian> Heya gang
<bddebian> ScottK: I think you have been hanging around Debian too much already.. ;-P
<ScottK2> bddebian: Not yet.  I didn't curse at you.
<nenolod> crimsun, fantastic. thanks (:
<bddebian> ScottK2: Heh, touche :-)
 * emgent night.
<bddebian> ScottK2: Wanna help with a bug instead? :-)
<ScottK2> What bug?
<bddebian> testresources FTBFS
<ScottK2> And?
<bddebian> And I don't know how to fix it :-)
<ScottK2> Point me at a build log?
<LucidFox> I read that as "testosterone FTBFS" :/
<bddebian> ScottK2: http://paste.debian.net/47576
<bddebian> LucidFox: :)
<ScottK2> bddebian: Is the the Debian package or the Ubuntu one?
<bddebian> I just updated the debian one so they are pretty similar but same issue
<ScottK2> I'll have a look.
<bddebian> You ROCK :)
<bddebian> I need to improve my python.. :-(
<bddebian> Well, and everything else.. :)
<RAOF> Cue bddebian suckage rant?
<RAOF> :)
<bddebian> Yeah, he does suck doesn't he..
<ScottK2> Well the ubuntu package doesn't even get that far right now.
<bddebian> Ah, I used python support
<ScottK2> doko would kill me if I changed it in Ubuntu.
<bddebian> heh
<ScottK2> bddebian: I got it to build in Ubuntu.
<ScottK2> I made two changes.  I'm not sure which it was.  Testing.
<bddebian> What did you change... Oh :)
<ScottK2> The problem in Ubuntu was that python2.4 wasn't present
<ScottK2> So I changed python-dev to python-all-dev
<ScottK2> Also moved it from build-dep-indep to build-dep since it's needed in clean according to Lintian.
<ScottK2> So it'll build now and the current Ubuntu package that hasn't been built since python2.4 was default (I think) will now built.
<ScottK2> built/build
<bddebian> Hmm I have both of those.. weird
<bddebian> Do you have a sid pbuilder?
<ScottK2> I do.
<ScottK2> I just uploaded to Ubuntu so it'll at least build.
<ScottK2> I've got to run here in a minute.
<ScottK2> I kicked off my sid pbuilder and we'll see what happens
<bddebian> OK, thanks
<ScottK2> bddebian: Builds fine in my sid pbuilder.  Feel free to steal it for Debian.  ;-)
<ScottK2> It could use more work.  Lintian is happier, but not satisfied.
<bddebian> Grr, wtf
<tonyyarusso> Hey, would anyone be willing to throw together a _very_ simple package for me?  My personal life has taken a turn for the insane and I'm becoming unsure of whether I can get it done before freeze, although an experienced person could probably do it in a matter of minutes.
<ScottK> I just fixed bddebian's bug for him, so he's got free time.
<bddebian> I find it hard to believe that it's actually fixed with that :)
<bddebian> tonyyarusso: What/where is it?
<tonyyarusso> It has been proposed that a package with the name of 'nvu' be added to the Hardy repos in the same vein as the 'mozilla-thunderbird' package, just as a transitionary package depending on 'kompozer' (already in the archives), so that Dapper users have a clean LTS->LTS upgrade path.
<tonyyarusso> bddebian: ^
<ScottK2> tonyyarusso: Make it an additional binary package of your kompozer package.  Not a whole new package.
<bddebian> Aye, can't you even just make it Provides: ?
<tonyyarusso> ScottK2: That makes sense...
<tonyyarusso> bddebian: I'm not sure?  Probably?
<ScottK2> bddebian: We'll see.
<tonyyarusso> bddebian: So I just add a Provides: line much like Depends:, and if a user has nvu installed on Dapper, and upgrades to Hardy, they'll get the new kompozer package installed?
<StevenK> You could just ask mvo to add an hint to update-manager
<tonyyarusso> a hint?
 * tonyyarusso looks for documentation on Provides
<bddebian> tonyyarusso: Should.  You might also need a conflicts/replaces if you do that??
<RAOF> tonyyarusso, bddebian: Does provides: work properly accross package renames & upgrades?  I remember being asked to provide a proper package for Miro.
<bddebian> RAOF: It may not
<StevenK> tonyyarusso: I'd suggest asking pitti when he turns up
<bddebian> ScottK2: Can you throw a source package up somewhere or are you leaving?
<tonyyarusso> "For some types of packages where there are multiple alternatives virtual names have been defined. You can get the full list in the /usr/share/doc/debian-policy/virtual-package-names-list.txt.gz file. Use this if your program provides a function of an existing virtual package."
<StevenK> tonyyarusso: Ignore that
<tonyyarusso> StevenK: heh, all right.  Didn't know what it meant anyway!
 * Hobbsee would just use conflicts and replaces nvu
<StevenK> It has no reason to Conflict
<tonyyarusso> Hobbsee: I know that would properly replace nvu if they did it manually, but I'm confused about upgrade-specific behavior.
<StevenK> Replaces and Provides, sure.
<Hobbsee> StevenK: ah right, is that it.
<Hobbsee> StevenK: assuming none of the files wer ethe same
<StevenK> Wait, no reason to Replaces either
<tonyyarusso> It is possible to have both packages installed simultaneously.  It would just be a tad silly, and not what an upgrader would expect.
<tonyyarusso> AFAIK they have different paths for all files.
<StevenK> I think this should documented
<StevenK> Sigh
<tonyyarusso> I think I need a clone.
<tonyyarusso> (Full time student and managed to find myself doing three jobs too - stupid, but they're good jobs, so hey - just a wee bit busy between now and June)
<tonyyarusso> So pitti or mvo eh?  I forget; what times are they usually around?
<ScottK> tonyyarusso: European work day.
<tonyyarusso> ScottK: 'k
<bddebian> Damn Europeons
 * bddebian ducks
<ScottK> tonyyarusso: Any chance you could look into making the publish function work with SFTP and not just FTP.
<ScottK> That's be really handy.
<tonyyarusso> ScottK: Make it work, no.  Mention the desire to the guy who could, yes.  (I just put it in the archives; someone else wrote the code.)
<tonyyarusso> ScottK: Meanwhile, you wanna add scp as an option to sbackup?  :P
<tonyyarusso> (Just while we're talking about transfer methods in random packages on our wishlist)
<ScottK2> tonyyarusso: Mentioning would be great.
<tonyyarusso> ScottK2: on the todo list
<ScottK2> Great.
<ScottK> Good night all.
<bddebian> Gnight ScottK, thanks for looking at that
<bddebian> Even if it does fail on sid for me... ;-)
<crimsun> keescook: I've filed and attached the appropriate info to bug 185534.
<ubotu> Launchpad bug 185534 in pulseaudio "[SECURITY] Fix unchecked setuid() return values (feisty-security, gutsy)" [High,Fix released] https://launchpad.net/bugs/185534
<warp10> heya all
<Aloha> how do i build tarballs to create source packages from? like a source package to install wallpapers
<RAOF> Aloha: By taking a directory with all the stuff you want in it and going "tar czvf wallpapers_0.1.orig.tar.gz"
<Aloha> RAOF, i want to make a bonary package though
<Aloha> binary
<RAOF> Which will be built from a source package, which will start with a .orig.tar.gz?
<Aloha> RAOF, how do i get it to install the files?
<RAOF> Any way you like.  dh_install is probably a good way.
 * Aloha needs to grok dh_install
<RAOF> It's pretty easy; you have a 2 column list.  The first column is the file you want to work on, the second is where it should go.
<Aloha> RAOF, then i put dh_install in debian/rules?
<RAOF> Yup.  Probably in the install-indep target.
 * Aloha needs to grok install-indep
<Aloha> RAOF, thnx for the help
<RAOF> Heh.  debian/rules is just a makefile with a bunch of specified targets :)
<Aloha> gotcha
<RAOF> It helps to have a basic understanding of Makefile syntax.  Which is also pretty easy :).
 * Aloha needs to grok Makefile ;)
<Aloha> only Makefile work I usually do is typing make heh
<Aloha> what targets does the installer call in the Makefile when the package is installed?
<RAOF> Aloha: You'd want to check Debian policy; there's a list of all the targets there.
<Aloha> RAOF, thnx
<RAOF> In particular: http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
<Aloha> RAOF, whats the advantage of using dh_install over a simple cp?
<RAOF> It's more debianic, for a start.
<RAOF> If you weren't going to use dh_install you'd probably want to use install anyway, so you can control the permissions, for a start.
<RAOF> And if you're installing a bunch of wallpapers it can be more obvious to have them listed in debian/foo.install rather than having a bunch of cp lines.
<Aloha> RAOF, gotcha, how does dh_install how which .install file to look in?
<Aloha> or do i dh_install file.install?
<RAOF> It either looks for debian/install, or debian/<packagename>.install
<RAOF> This is common behaviour for debhelper programs
<Aloha> where dh_name looks for debian/name?
<RAOF> Or debian/<packagename>.name, yes.
<Aloha> RAOF, thnx you're a BIG help
<Aloha> dpkg-buildpackage --rfakeroot doesn't execute binary-arch?
<wallyweek> g'morning all!
<Aloha> wallyweek, morning
<\sh> hmm..how can I stop gnome/nautilus/whatever to show dynamically mounted lvm devices?
<huats> morning everyone
<norsetto> morning folks
<gaspa> norsetto: ue'.
<norsetto> uÃ© gaspa - ron
<gaspa> ue' == "tipical american greeting" :D
<norsetto> gaspa: gasparon = typical american nickname
<gaspa> :D
<gaspa> norsetto: how are you?
<norsetto> gaspa: surviving, and you?
<gaspa> norsetto: very <yaaAAwn> good!!
<Aloha> when i do dpkg -c packagename.deb it lists /usr/bin and /usr/sbin how do i get rid of that?
<gaspa> norsetto: i've a little monst... ehm... daughter that makes hard to sleep well. :D
<norsetto> gaspa: he, the pleasures of parenthood .... you going to Pisa this week-end btw?
<gaspa> siena, you mean...
<norsetto> Aloha: most probably you used dh_make and that automatically includes those in debian/dirs I guess
<norsetto> gaspa: yes, somewhere in Tuscany anyhow ;-)
<gaspa> lol
<Aloha> norsetto, oh gotcha. is there a better way to build non compile source packages?
<norsetto> aloha: to build not compile!? Sorry, don't follow you ... you mean to make a tarball and attach it a deb label?
<gaspa> norsetto: i don't know, there's not so much developers, and i don't like 'organization meetings'
<Aloha> norsetto, i just have dh_install in my package and not anything else. no software gets compiled
<norsetto> gaspa: yeah, I can undersatnd, its a good excuse to have fun together though
<norsetto> aloha: well, just make a very simple rules then, but you still need copyright, control and changelog
<gaspa> of course. and you? what will you do?
 * wallyweek welcomes norsetto in non-sleeping fathers club :p
<norsetto> aloha: also, some target needs to be there (don't remember the list by heart) even though they are used, you should check the debian policy for that
<norsetto> aloha: read that "even though they are not used"
<Aloha> norsetto, ok thnx alot :)
<norsetto> wallyweek: hey, its gaspa the lucky parent ;-)
<gaspa> wallyweek: yes, i'm the one
<TheMuso> Hey folks.
<mok0> Hey, TheMuso
<norsetto> aloha: you could also check some similar package to give you an idea, there are few which only ships bash scripts for instance
<wallyweek> oh I see... this online client is a nightmare :)
<norsetto> uÃ© TheMuso
<norsetto> ops, morning TheMuso
<gaspa> norsetto: so, will you go to siena?
<norsetto> gaspa: nope
<gaspa> i see.
<gaspa> norsetto: well, i think i'll go to fosdem, anyhow...
<wallyweek> gaspa: siena?! why?
<gaspa> wallyweek: there's the ubuntu-it meeting, this weekend.
<wallyweek> gaspa: I can't go either but it's nice to know, thanx! :)
<gaspa> wallyweek: uh. are you italian? or in italy?
<wallyweek> gaspa: yes to both
<gaspa> i see.
<amarillion> Hey there, would anybody like to review http://revu.tauware.de/details.py?package=speed-game ? It's a very simple package and I've addressed all previously reported issues. It's been 10 days since the last review.
<foolano> ScottK: r u around?
<slytherin> Can anyone please review this debdiff before I actually attach it to a bug. http://paste.ubuntu.com/3827/
<persia> slytherin: What level of review do you seek?
<man-di> slytherin: BTW: have you had time to look into that axis bug?
<slytherin> persia: I was not sure how to set a variable's value with command substitution in rules file and then use that variable. So I have used command substitution twice where needed.
<slytherin> man-di: Nope. Couldn't find what exactly the reason was. I will have to take a detailed look in the error.
<man-di> slytherin: from what I saw the bug was filed because GCJ ICEd on building
<persia> slytherin: At a base level, I think you want $(shell <command>) rather than `<command>` in a makefile, and I don't believe in minor standard version bumps when updating Debian packages: this is only worthwhile if you get the ancient-standards-version report, and feel like cleaning all the cruft.  3.7.2 -> 3.7.3 just adds noise to the patch and confuses MoM.
<man-di> slytherin: when you can build the package that is fixed already
<slytherin> man-di: I will try today
<persia> slytherin: For setting a variable, just use $(shell ...).  Whether to use = or := depends on whether the result changes during the interpretation.
<man-di> slytherin: thanks, I think that bug can just get closed
<slytherin> persia: Ok. Will remove version bump. And also use $(shell command). But then how to use that variable? $(var)?
<persia> slytherin: OK.  Assuming you want to set the variable once at parse time (to avoid multiple calls), you'd use MY_VAR := $(shell <shell command>).  You can also use curly braces if you find that less confusing.
<slytherin> persia: Done that. And then how to use that variable where the value needs to be substituted?
<persia> Then, you can use $(MY_VAR) later in the makefile to call it.  If you use :=, be sure to define before using.  If you use =, it is less strict (but produces multiple calls).
<persia> slytherin: Sorry.  I'm not the fastest typist :)
<slytherin> persia: oops, sorry. I thought you didn't understand my question
<\sh> soren, any clue why bochs ftbfs at configure stage with checking for default gui on this platform... x11
<\sh> ERROR: X windows gui was selected, but X windows libraries were not found.
<persia> slytherin: I just tend to be wordy, and there's this annoying 256 character limit imposed by freenode that often keeps me from using paragraphs properly.
<persia> (or maybe it's 255 characters: I never actually counted)
<slytherin> persia: By the way, I am not sure if the patch actually fixed the bug. It just installed extension at proper place. I have not actually tried the package to check if there are any ABI compatibility problems.
<persia> slytherin: Good to test things before uploading :)  Also, please shift to $(shell).  Using escape characters to convince make to run shell scripts is less than ideal.
<slytherin> persia: Do you have hardy running at this point of time? I am in office and can't test the package. :-(
<warp10> I was looking at http://packages.qa.debian.org/d/dialign-t-doc.html . This package is not in Ubuntu and I would like to request a sync. It is in non-free, but I don't understand why, since it is under LGPL. Any idea?
<persia> slytherin: Yes, but I've a larger queue that I am confident I can process before I next sleep.  You'll have better luck with another tester.
<slytherin> persia: Ok. If I don't find anyone I will test it tonight at home and then submit the fix tomorrow.
 * pochu wonders whether Hobbsee plans to write something regarding her application to the MC...
<slytherin> Is anyone willing to test a fix for nautilus-open-terminal? I don't have access to a hardy system at present.
 * DaveMorris asks persia nicely if he'd have time to review his OpenSG package again some time soon
<persia> DaveMorris: I'll start a build overnight, and try to take a look tomorrow.  Has nobody else reviewed it?
<DaveMorris> no
<DaveMorris> people tend to pick the smaller packages
 * persia encourages someone else to review opensg, as only one reviewer doesn't tend to make the best quality package
<norsetto> warp10: I didn't check it but it could [build-]depend on something in non-free
<persia> DaveMorris: You've not the biggest.  Take a look at the urbanterror candidate :)
<soren> \sh: Just a wild guess: Because you don't have x11 development packages installed?
<DaveMorris> persia: that looks like it has a sane build system though :)
<\sh> soren, libx11-dev is in b-d :)
<warp10> norsetto: I checked it before asking here: it just build-depends on debhelper, depends on ${misc:Depends} and suggests dialign-t (in main and universe).
<\sh> soren, well, it's the new debian upstream package...where your changes are applied :)
<soren> \sh: Ah, nice.
<\sh> soren, but the problem occured now..
 * soren is looking
<\sh> soren, cool thx
<persia> warp10: I'd guess it's considered non-free because there doesn't appear to be any source file for the PDF/ps/html docs.  Just a wild guess, though.
<soren> \sh: Builds fine in my sbuild.
<soren> \sh: Are you on amd64 or i386?
<warp10> persia: mmm... maybe that's the issue. I'll try to contact the maintainer, he should know about that
 * soren high-fives dholbach
<\sh> soren, amd64
<soren> \sh: Me too.
<persia> warp10: Check the changelog.  I suspect that it would make sense to drop the package, and restore the upstream tarball in dialign-t, rather than just moving to universe.  Of course, this is only worthwhile if you plan to maintain the fork.  If you just want to be a user, bests to leave in multiverse.
<\sh> soren, oh fun...what could that be
<dholbach> soren: what about? :)
<soren> dholbach: Because everything is *awesome*!
<soren> \sh: Are you building in pbuilder or sbuild?
<\sh> soren, sbuild
<dholbach> soren: OK, I think I can agree with you :))
<proppy> hi
<\sh> soren, I can check against pbuilder
<soren> To be fair, my sbuild is slightly out of date.
<soren> Well, my chroots are.
<soren> Dear TeX-maintainers. Please use triggers. kthxbye
<warp10> persia: well, I don't like to increase our delta with debian, but that could be a good idea, since I am greatly interested in having that package in good shape in Ubuntu.
<\sh> soren, update ;)
<soren> It's running, it's running, I've just got... erm... let's just say "a few" schroots.
<\sh> soren, are you using local archive mirrors, just as I do?
<soren> \sh: apt-cacher
<persia> warp10: Keeping close to Debian is largely a way to reduce the amount of work that MOTU needs to do.  If you want to commit coordination for that package, you might split it.  On the other hand, I don't think we allow non-built-from-source docs in universe either: check with an archive admin.
<soren> \sh: rebuilding with fresh chroot.
<\sh> ah
<\sh> well libx11-dev should be enough for with-x11
<warp10> persia: I'll surely do that, but I would like to ask to debian first, maybe there are additional reasons for putting that package in non-free.
<soren> \sh: It still builds fine here.
<\sh> hmmm
<\sh> I just recreated the chroot this morning
<\sh> soren, can you send me your build log please?
<\sh> I wonder what's wrong here
<norsetto> hey proppy!
<norsetto> heya dholbach ...
<dholbach> hey norsetto
 * proppy hugs norsetto
 * proppy hugs dholbach
<norsetto> whats up dholbach? You seem unusually depressed!?
<norsetto> proppy: any new spec in preparation? Any linux-unfriendly software being packed? :-)
<dholbach> norsetto: errrrr? :)
<dholbach> norsetto: not really :-)
 * dholbach hugs norsetto and proppy
<norsetto> dholbach: good ... you had me worried
<proppy> norsetto: was in a big hole that poped up just today :)
<dholbach> norsetto: why? what happened?
<norsetto> dholbach: I mean, that you seemeed not ok
<proppy> norsetto: I'm happy our spec got implemented :)
<proppy> norsetto: and juce packaging still waiting for upstream feedback
<norsetto> proppy: a hole? ok, your company discovered you and got rid of you even before it disapperead?
 * Kmos hugs norsetto & dholbach
<proppy> norsetto: kinda like that, we've setup specifications and meetings for a no budget response in the end :)
<soren> \sh: I kind of killed it before it finished. You said it died during configure..
<dholbach> hey Kmos
<\sh> soren, yepp
<norsetto> hi kmos
<Kmos> norsetto: won't you candidate to motu council member?
<norsetto> kmos: nope
<\sh> soren, trying with an i386 chroot now
<Kmos> norsetto: i think you have a good place there :)
<norsetto> kmos: there are much better people than me for that, believe me ;-)
<Kmos> norsetto: and one is you :) hehe
<\sh> soren, the same...checking for X ... no and then failing at checking for default gui on this platform... x11
<\sh> ERROR: X windows gui was selected, but X windows libraries were not found.
<persia> \sh: Have you tried using debuild under schroot -c foo?  You may find that you can more easily understand the issue when you are exploring the existing build.  There's also the --purge=never argument to sbuild if you like.
<\sh> persia, I'm checking against pbuilder now, and push a testpackage to my ppa...
<persia> \sh: You can get a pretty close simulation of the PPA if you download the buildd chroot tarball from launchpad, and use that to prep your schroot.
<soren> \sh: What version of bochs are you building?
<soren> 2.3.6-2 ?
<\sh> persia, -1
<\sh> soren, the last one which is in sids Sources.gz
<persia> \sh: ?
<soren> 2.3.6-2 ?
<soren> (!)
<\sh> nope 2.3.6-2
<\sh> aehm
<\sh> nope 2.3.6-1
<soren> That's not the last on in sids Sources.gz.
<\sh> it's sids Sources.gz from this morning actually
<soren> quit living in the past already! :)
<\sh> getsid.sh --update ;()
<\sh>   * Try to use pkg-config before AC_PATH_XTRA (fixes a FTBFS). Add pkg-config
<\sh>     to Build-Depends.
<\sh>     - debian/patches/patches/20_use_pkg-config.patch: New file.
<\sh> soren, YAY
<zul> morning
<\sh> those buggers
<\sh> moins zul
<\sh> ifneq ($(DEB_HOST_ARCH_CPU),i386)
<\sh>         $(error "build-indep will only succeed on any-i386")
<\sh> endif
<\sh>  
<\sh> WAAA?
<soren> That's not really unexpected.
<\sh> soren, sure...
<\sh> soren, I wonder what's the magic in our buildds to build at least the main bochs package
 * persia points at bug #183495 for one way to deal with building bios packages sanely
<ubotu> Launchpad bug 183495 in openbios-sparc "[FTBFS] openbios-sparc (1.0~alpha2+20070816-1) fails to build in hardy" [Medium,New] https://launchpad.net/bugs/183495
<\sh> persia, I like infinities idea...
<persia> \sh: You might want to also hit openbios then, as the person who was chasing that issue is no longer encouraged to follow up...
 * norsetto --> lunch
<\sh> persia, it means to introduce more packages
<persia> \sh: Only has to be a binary package: you can leverage the existing source package.  As they are mostly dummy packages, not so much pain, no?
<persia> Of course, how one gets an arch-all package to build-dep on a package only built on an architecture different than that of the buildd is a more interesting question...
<\sh> persia, actually right now I'm trying to understand what it involves to get this hack ready ;)
<\sh> persia, infinity mentions to use another (new)  source package which build-dep on the resulted binary arch dep package
<persia> \sh: Worst case you can do something like ia32-libs, but that's non-ideal.
<persia> \sh: Oh right.  I managed to ignore the fact that packages build-depending on themselves was bad :)
<\sh> persia, na...what adam means is this: Package: -sparcbios Arch: sparc ... build the package on the needed archs...and introduce a new source package which generates an arch:all package . the Arch:all can actually only be generated on the sparc arch because of the build-dep on the arch dep bianry package
<\sh> now I need some crack
<persia> \sh: That doesn't solve the problem.  The arch:all package needs to be able to be generated on an arbitraty arch, or else it still needs handholding.
<persia> I suspect that's the same sort of issue you're encountering with bochsbios, that you're not using the same architecture for building the arch:all package as Soyuz, but that shouldn't break the build.
<\sh> persia, so how can a i386 buildd include a _sparc.deb
<persia> \sh: Without internet access?  That's the hackish bit...
<persia> ia32-libs chose to do this with internet access at packaging time, but I'm not convinced that's really a source package.  I don't know the right solution.
<\sh> persia, I mean more, that the i386 arch needs to overwrite the behaviour apt of pulling in .deb packages for the build arch
<persia> \sh: That's not so hard.  The hard part is getting the sparc apt-cache on i386.
<\sh> persia, that's what I mean...or you switch for this special occasion the -A switch of sbuild on ;)
<persia> You might check in #launchpad to see what "no internet access" really means.  There might be a way to access an archive via the network, even if not the normal archive.  You could try archive.ubuntu.com, and if that failed, fall back to the internal archive.
<\sh> persia, and let the sparc buildd create the Arch: all package at all...it means just cp the binary of _sparc.deb build-dep to the Arch: all package
<persia> \sh: That's significantly less trivial within wanna-build, and I suspect even more so within Soyuz.
<pochu> Hobbsee: will you write something regarding your MC application?
<Hobbsee> pochu: probably, when i get inspired.  if getting inspired doesn't become before the end of the voting, then no :P
 * persia suspects Hobbsee of having a secret alien agenda, which is hard to describe in mere human languages
<\sh> persia, I think I'll talk to adam because he knows a lot about his buildd ... well I could also ask lamont...
<Hobbsee> persia: or involving a lot of beeping
<persia> \sh: That works too.  I suggest #launchpad, as I believe in teams, and someone else might know too.
<persia> Hobbsee: heh
<psicus78> hello!
<\sh> persia, see #launchpad ;)
<psicus78> I'v tried to compile glib2.0 2.15.3 for gutsy in using PPA, everything worked fine and I was able to install but now I have this weird situation:
<psicus78> gabriele@nicholas:/var/cache/apt$ apt-cache policy libglib2.0-0
<psicus78> libglib2.0-0:
<psicus78>   Installato: 2.15.3-0ubuntu1~psicus2
<psicus78>   Candidato: 2.15.3-0ubuntu1~psicus2
<psicus78>   Tabella versione:
<psicus78>      2.15.3-0ubuntu1~psicus2 0
<psicus78>         500 http://ppa.launchpad.net gutsy/main Packages
<psicus78>  *** 2.15.3-0ubuntu1~psicus2 0
<psicus78>         100 /var/lib/dpkg/status
<persia> !pastebin
<ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<psicus78>      2.14.1-1ubuntu1 0
<psicus78>         500 http://it.archive.ubuntu.com gutsy/main Packages
<psicus78> and the update manager keeps asking me to update it!
<psicus78> ops, sorry about that
<psicus78> http://paste.ubuntu-nl.org/53299/
<persia> psicus78: Usually indicates an issue with keys or repos.  Since you signed it, check to make sure you trust your PPA.  If not, ask in #launchpad (we don't really handle either glib or PPAs here)
<psicus78> ok, thanks
<zul> Hobbsee: if your write-up has a lot of click sounds like the bushmen do then I would vote for you
<slytherin> persia: Just FYI ... I tested the package with the help of another user and attached the debdiff to bug 185435
<persia> \sh: Maybe lunchtime?
<ubotu> Launchpad bug 185435 in nautilus-open-terminal "nautilus-open-terminal no longer works in Hardy" [Low,Confirmed] https://launchpad.net/bugs/185435
<persia> slytherin: Excellent.
<persia> zul: Do you think there are sufficient devs who read !Kung?
<\sh> persia, well, irc backlogs are nice :) need to re-enable them in my dircproxy
<zul> persia: probably :)
 * persia tends to wait for the turn of the hour, and rely on irclogs.ubuntu.com
<Hobbsee> persia: that's a launchpad bug.
<Hobbsee> psicus78: you'll have to wait for launchpad to fix their bug - it's known
<persia> Hobbsee: poor support for !Kung, or the key issue?
<Hobbsee> persia: glibc probably has a predepend
<Hobbsee> persia: which makes it forever try to reinstall
<StevenK> libc6 itself doesn't
<psicus78> Hobbsee: do you know the bug #?
<Hobbsee> psicus78: https://bugs.edge.launchpad.net/soyuz/+bug/165230
<ubotu> Launchpad bug 165230 in mythbuntu "PPA generates an endlessly upgrading package" [Low,Confirmed]
<psicus78> Hobbsee: thanks
<Hobbsee> ...apparently that's a low bug now.
<Hobbsee> oh, in myth.  right
<\sh> moins ivoks
<StevenK> The fix is commited. Maybe it was rolled out with 1.2.1?
<Hobbsee> hm, yeah, should be now
<Hobbsee> but i'd imagine it only works for packages that have been built and published and all that after the rollout
<StevenK> So they probably just need to be re-uploaded?
<Hobbsee> yeah
<psicus78> I built my package yesterday
<psicus78> when was 1.2.1 released?
<StevenK> Today
<StevenK> About six hours ago
<psicus78> great! :)
<effie_jayx> I get this 404 when I try to do a uscan for a watchfile uscan warning: In watchfile debian/watch, reading webpage
<effie_jayx>   http://qa.debian.org/watch/sf.php/medit/ failed: 404 Not Found
 * effie_jayx is doing the recipe
<Kmos> effie_jayx: try just http://sf.net/projects/medit/
<effie_jayx> ok
<effie_jayx> uscan warning: Filename pattern missing version delimiters ()
<Kmos> effie_jayx: man uscan
<persia> effie_jayx: You need to specify a perl-style regex to search for the version.  While the sf.net shorycut is handy, it is not alone sufficient.
 * persia feeds Soyuz
<effie_jayx> well at first I did try http://sf.net/medit/mooedit-(.*).tar.bz2, like the recipe said... and it just gave me an error
<persia> What error?
<effie_jayx> persia,  the first one I pasted
<persia> effie_jayx: Maybe the debian mirror doesn't handle that package :(  You might need to try something else.  I'm not sure.
<effie_jayx> persia,  shall try
<psicus78> it was probably due to Binary::Breaks field in control file
<psicus78> I'll check
<ScottK> foolano: Here now.
<\sh> soren, what do you think of changing bochs src package to something like this: Package: bochsbios-i386 Arch: i386 so it builds on a i386 and generates a deb, and creating a new source package named bochbios, which creates a Package: bochsbios Arch: all?
<\sh> soren, which means we are using a similiar way like ia32-libs
<emgent> heya
<mruiz> hi all
<soren> \sh: Why?
<effie_jayx> I am trying to find a real case for me to work on http://qa.ubuntuwire.com/uehs/no_watch.php.  I take it for granted I must use apt-get source package... https://wiki.ubuntu.com/PackagingGuide/Howtos/DebianWatch only mentions downloading by hand
<\sh> soren, because right now, the package will FTBFS on all other archs then i386
<soren> \sh: I've been thinking about doing something along those lines for openhackware, but why for bochs? We build arch-all packages on i386 anyway
<soren> \sh: No.
<soren> \sh: binary-indep will fail. That's fine.
<soren> \sh: Well, it would be better if it didn't, but make your proposed change doesn't fix anything for anyone
<\sh> soren, so the buildds are ignoring this and creating the other packages for Arch: any?
<soren> \sh: Er.. Yes. That's how it works.
<soren> \sh: We only pass -A to sbuild on i386.
<soren> \sh: ..so on non-i386 binary-indep never gets invoked.
<\sh> soren, ok...so only openbios-sparc is special in this case
<soren> \sh: How so?
<\sh> https://bugs.edge.launchpad.net/ubuntu/+source/openbios-sparc/+bug/183495
<ubotu> Launchpad bug 183495 in openbios-sparc "[FTBFS] openbios-sparc (1.0~alpha2+20070816-1) fails to build in hardy" [Medium,New]
 * persia thinks it's a bug if an arch:all package only builds on one architecture, even if it happens to be the one Soyuz uses to build arch-all today.
<soren> It has never built.
<soren> persia: Suggestions?
<soren> \sh: And it's the same for openhackware.
<\sh> soren, right
<soren> \sh: So not "only openbios-sparc".
<persia> soren: There's the hackish source-in-binary used by e.g. palo or ia32-libs.  I hoped there was an internal archive that the build might be able to access via a specially coded failover for a wget call.  Maybe Soyuz could grow a special arch-hint file for packages that need be built on specific architectures.  Nothing clean.
<slangasek> soren: because it's an arch: all package that can only be built with the sparc toolchain
<soren> slangasek: What question are you answering?
<persia> s/source-in-binary/binary-in-source/
<slangasek> soren: the "how is openbios-sparc special", sorry if I'm late to the party :)
<soren> slangasek: I was just curious why -- since I had only moments before mentioned openhackware -- this problem was an "only openbios-sparc" thing.
<slangasek> right
<soren> Which it wasn't.
 * slangasek nods
<\sh> now, slangasek joined our party, we can work on a solution for these packages in general ;)
<slangasek> none of the solutions are very good
<soren> An ia32-libs sort of approach is the best bet without changing stuff in the policy and on the buildd's.
<slangasek> you can cheat and build an arch: all package in the binary-arch target of a package that has other arch: any packages
<slangasek> you can shove binaries in your source <bleurgh>
<slangasek> you can build-depend on a cross-compiler
<slangasek> you can get someone to hotwire launchpad to allow weird affinities for particular arch: all packages
<\sh> I like the cross-compiler approach ;)
<slangasek> we don't currently package those
<soren> The correctest solution involves adding a hint to debian/control about where to build it and make the soyuz "get it".
<\sh> slangasek, yeah..that's the fun part ...
<\sh> soren, you mean to give soyuz a hint where to switch to -A mode
<soren> Something like that, yes.
<soren> Maybe a hint in PAS?
<persia> I really like the cheating solution: building the arch:all package in the binary-arch target, and relying on P-a-s to keep it off the FTBFS page (along with a bug against Soyuz to do something more intelligent).
 * \sh wonders what the new-to-me abbreviation of PAS/P-a-s  means?
 * persia notes that one could cheat further, and call it arch: sparc in debian/control, yet nonetheless produce an _all.deb (although this breaks the policy about debian/control actually describing the package).
 * soren shudders
<StevenK> \sh: Packages-arch-specific
<StevenK> \sh: Don't build packages on arch x
<persia> \sh: It's the hints file to explain to the buildds which packages shouldn't be built on which architectures
<slangasek> soren: not currently supported as part of the P-a-s file format; I don't see the value of extending that, vs. making it a soyuz-specific thing or putting it in the source package
<slangasek> soren: in particular, since this problem affects Ubuntu && !Debian, and Debian shares P-a-s with Ubuntu
<soren> slangasek: P-a-s is not covered by Debian Policy, is it?
<slangasek> no, but you lose the benefit of being able to share the file between the two dists if only the tools in one dist are upgraded to cope with your format changes
<soren> slangasek: Er... We'd have to make changes to *other* tools to do it the other way.
<soren> slangasek: Same difference, AFAICs.
<ScottK2> slangasek: Which would be a lot easier to deal with if one distro didn't use a proprietary tool set.
<persia> slangasek: We currently can't share the source, due to it working fine in Debian (the equivalant Debian bug was rejected)
<slangasek> persia: note that cheating requires that there *be* some other arch: any package built from the same source, otherwise it'll never get seen on the (e.g.) sparc buildd
<persia> slangasek: Depends on how much one cheats, and whether one lies in debian/control.
<slangasek> soren: eh, no; it *is* different, because one involves making changes to core Debian infrastructure as a precondition of continuing to be able to share data
<slangasek> soren: and the other involves either a soyuz-local override file, or Ubuntu-local changes for the small set of affected source packages
<soren> slangasek: Would maintaining a tiny delta to that file really be so completely awful that we're willing to do massively nasty things basically everywhere else than there?
<soren> slangasek: Well, yes, it could be in a separate file, I guess.
<slangasek> soren: yes - it doubles the work required for every update, because every update would become a merge
<soren> slangasek: ...which wouldn't require changes to the source packages.
 * Hobbsee celebrates the deletion in ppas
<soren> slangasek: Yes.. That would be the case for dpkg updates, too, if this were to become a field in debian/control.
<soren> dpkg is already a merge every time, though.
<soren> ...but that's a bit beside the point
<slangasek> it's not beside the point
<slangasek> that *is* the point
<StevenK> Hobbsee: You'll celebrate by deleting a package?
<Hobbsee> yeah
<persia> Hobbsee: Can we delete other people's packages yet?
<Hobbsee> persia: doubt it
<TheMuso> I thought that PPA UI for deleting packages was only on staging... Or has that now changed?
<soren> slangasek: Maybe I'm underestimating the amount of changes to P-a-s.
<ScottK2> Can any team member delete team PPA packages?
<soren> slangasek: How often does it change?
<StevenK> ScottK2: Yup
<StevenK> ScottK2: I was able to select ubuntu-mobile packages to delete. I didn't actually try, though
<ScottK2> Excellent.
<slangasek> soren: I'd estimate an average of 4-5 changes per month
 * ScottK2 goes to look for teams to join he doesn't like.
<TheMuso> lol
<slangasek> soren: and it's maintained in CVS, so merges == death :)
<soren> slangasek: The complexity of the delta in question is also quite relevant.
<soren> Oh.
<soren> I didn't realise.
 * slytherin is happy to be finally able to clean up his PPA. :-)
 * persia is glad to finally be able to use a PPA without significant fear
<TheMuso> yaaay! Its on edge.
<StevenK> TheMuso: I said that about five minutes ago
<persia> StevenK: You didn't say "yaaay!".  Without the magic words, meaning is less clear :)
<StevenK> Haha
<\sh> somehow my gnome is now scking more then ever
<persia> \sh: scary nautilus change maybe?
<\sh> for every sbuild start it shows me the dynamically created lvm device on my screen
<\sh> the same for everything else what involves lvm appearing
<persia> \sh: Open more windows in the forground, and maybe you won't notice :)
<\sh> persia, lol
<slytherin> Can anyone tell me if anyone is working on bug 184278. There are at least 3 packages in depwait state in multiverse due to this.
<ubotu> Launchpad bug 184278 in ubuntu "[Sync request] Please sync aspectwerkz2 2.0.dfsg.1-2 (universe) from Debian unstable (contrib)" [Wishlist,Confirmed] https://launchpad.net/bugs/184278
<\sh> what are lvm devices? hotplug or change media?
<persia> slytherin: It's in all the right queues.  Just waiting for an archive admin to get to it.
<slytherin> persia: Ok. Thanks for info. :-)
<\sh> damn...gnome's broken
<\sh> I can't work like that ;)
<TheMuso> Although I seem to be getting the something went wrong message/.
<\sh> bddebian <--- Da God is in da house
<StevenK> \sh: Must you?
<StevenK> :-P
<vorian> ScottK: just 2.3- ?   :)
<bddebian> Heya gang
<bddebian> Heh, heya \sh
<ScottK> vorian: Yes.
<vorian> thanks
<\sh> StevenK, why not for gods sake ;)
<ScottK> vorian: FYI for the future, pysupport and pycentral have different pyversions syntax.
<ScottK> bddebian: Heya.
<bddebian> Hi ScottK
<vorian> ah, that's something i'll keep an eye on.
<ScottK> bddebian: Please note that my fix built just fine for Ubuntu.  How's Debian going?
<bddebian> ScottK: Well your's failed for me in Debian too but I have gotten it to work.  Though I'm not totally sure why
<\sh> StevenK, anything against pushing octave3.0 into ubuntu? :)
<StevenK> \sh: ENOCLUE
<ScottK> bddebian: You built my package or made some of the same changes?
 * persia remembers something about a missing "octave" package due to un-epoch'ing that may require special handling
<ScottK> bddebian: Some of the stuff we were dealing with is processed differently pysupport/pycentral.
<Hobbsee> imbrandon: ping
<bddebian> ScottK: I built yours first and it still failed for me. :-(  I went back to mine and change the post-install call in rules to use $(MAKE) check instead of the PYTHONPATH=lib ./test_all.py
<ScottK> Weird.
<ScottK> Since mine built just find in my Sid pbuilder.
<bddebian> Totally
<ScottK> I'll just drop all your changes when the merge hits ;-)
<bddebian> :-)
<TheMuso> 99/c
<\sh> StevenK, I thought asking the last uploader of plplot ;)
<StevenK> Yeah, not gonna help
<Hobbsee> siretart: ping
<\sh> oh mk-sbuild-lv needs also more love
<\sh> itdoesn't work by default for debian
 * siretart goes and fetches table tennis equipment
 * siretart gives Hobbsee a racket and plays a service
<Hobbsee> hehe :)
 * Hobbsee hits the ball back
<foolano> ScottK: regarding the libtree-perl package. I can't manage to build the package and get the /usr/lib/perl5/auto/Tree  directory that you told me shouldn't be there
<siretart> \sh: oh yes, it would be great if someone could fix that. until then I'm using that: http://wiki.tauware.de/misc:create-chroot
<ScottK> foolano: I'll look at it again.
<foolano> my build is clean and doesn't have that
<\sh> siretart, why not replacing it with mk-sbuild-lv?
<ScottK2> foolano: How are you building it?
<ScottK2> foolano: It's definitely there in the .deb that I built.
<foolano> ScottK: dpkg-buildpackage
<\sh> siretart, adding some more love to /etc/schroot/schroot.conf and all is fine ;)
<ScottK2> foolano: I'm building it in a hardy pbuilder.
<foolano> ok
<foolano> gonna try that
<siretart> \sh: a) it still needs work, b) it does not preserve the same semantics as mk-sbuild-lv. I don't want to break other ppls systems
<\sh> siretart, do you know if this what I'm trying in http://pastebin.ubuntu.com/3831/ is possible?
<DaveMorris> hmm, PPA now has a delete package but you can't remove whats in the published archive :/
<\sh> argl..old version
<\sh> siretart, anyways...forget it...I'm trying to exaplain...I'm generating a string RELEASE with all releases of debootstrap/scripts/ ... and add a "|" in between the release names..to have something I can feed to case $foo in
<\sh> siretart, now case $foo in ; $RELEASE ) echo "match" ;; *) ;; esac should work...but it doesn't
<siretart> \sh: use python? ;)
<\sh> siretart, hehe...
<Adri2000> Hobbsee: where is your MC application wiki page?
<\sh> siretart, pbuilder-dist replacement, because our version is totally borked
<Hobbsee> Adri2000: on mars.
 * siretart is an sbuild fanboy. so any pbuilder rants are welcome here :)
<Adri2000> Hobbsee: is there a planned return to Earth?
 * Hobbsee resides on jupiter, so
<zul> isnt it a bit hot there?
 * Hobbsee is a green alien, and doesn't feel heat.
<Adri2000> Hobbsee: more seriously, are you going to write one?
<Hobbsee> Adri2000: unsure yet.
<pochu> It would help us to decide who to vote :)
<Hobbsee> don't vote for me :P
<ScottK2> Hobbsee has a strong base in the grumpy motu faction.
<\sh> how many MC members do we need? 2 or 3?
<pochu> \sh: 2
<pochu> \sh: If they were 3, a poll would be a bit useless ;)
<DaveMorris> pochu: would you appoint someone with no votes?
<StevenK> ScottK2: Which is you, and who else?
<foolano> ScottK2: regarding the license. Upstream just says that it can be distributed under the same terms as perl itself. So do you really think that I should include the GPLv1 license in the copyright file?
<StevenK> bddebian doesn't count, he's only grumpy at himself
<\sh> pochu, well it doesn't make sense if you can vote for all three, then...and this is possible by now ;)
<pochu> DaveMorris: or with a negative count? ;)
<ScottK2> foolano: Yes, because Perl is GPL v1 and later.
<foolano> ScottK2: alright then :)
<ScottK2> foolano: I suspect your empty dir problem is Perl tool chain related.  I built your package in my Dapper pbuilder and didn't get the empty dir.
<bddebian> I can be grumpy :-)
<ScottK2> Excellent
<gaspa> StevenK: who's supposed to create vboxusers group?
<StevenK> The virtualbox-ose package itself
<foolano> ScottK2: i'm creating the a Hardy pbuilder
<gaspa> mmm
<gaspa> StevenK: ah, ok. it just don't work in the installing shell.
<ScottK2> foolano: The problem is that your new rule to remove .packlist removes the file, but leaves the directory it was in.
<foolano> yeah. I see. I'll remove the dir too
<vorian> ScottK2: http://paste.ubuntu-nl.org/53321/
<vorian> \o/
<ScottK> vorian: How about linitian -I ?
<pkern> doko: Whatever you changed in Gobby without telling me: you screwed up.
<\sh> moins pkern
<pkern> Hey \sh.
<hellboy195> \sh: would you mind that I do the merge of crystalcursors? Though I think its a sync ...
<vorian> ScottK: same result
<vorian> :)
<\sh> hellboy195, do it :)
<ScottK> vorian: OK.  Now how about man page that's actually useful (as in tells how to use the program).
<hellboy195> \sh: k, thx :)
<ScottK> pkern: Good afternoon.
<ScottK> vorian: Why did you change the build-dep version on Python?
<\sh> hellboy195, just pin a "building or working" next to it, so I don't catch it...after you finished and determine what it is, just pin the bug number or uploaded behind it on DaD please :)
<vorian> ScottK: all-dev?
<ScottK> vorian: Yes.  It was 2.3 something and you changed it to 2.5?
<vorian> ah, mistake
<vorian> sorry about that
<hellboy195> \sh: yes. np
<\sh> pkern, would you like to merge new network-manager-openvpn ? :)
 * pkern hates n-m.  Especially because the Ubuntean n-m maintainers refused some changes to improve the openvpn experience.
<\sh> pkern, just asking because you were the last uploader :)
<doko> pkern: ?
<pkern> doko: You reused the version already in the archive, but you already got notified.  Any reason why you did not file a bug about it?  I could have merged it upstream and fixed in Debian, too.  Like this I only got to know that there might be an issue (I still don't know the patch) because your upload got rejected.
<doko> pkern: sure, you can fix it
<pkern> I don't even know the problem.  I would have responded promptly to a bug report or a Trac entry.  Like this the Ubuntu delta got increased.  (Although I don't know where you based your changes on.)
<doko> pkern: more g++-4.3 related changes
<hellboy195> \sh: A very stupid question. I write the bug number with the "bug #xxxxx" syntax in the comment field but if I leave the site and return the comment field is cleared
<\sh> hellboy195, press enter after you wrote it ;)
<hellboy195> \sh: omg. thx. As I said. stupid question -.- ^^
<\sh> hellboy195, :))
<ScottK> vorian: I don't think you need to depend on python-all-dev.  A build-dep on python appears to be sufficient.
<vorian> alrighty ScottK :)
 * vorian is typing away on the manpage
<pkern> doko: Your gobby package, not your patch itself.
<jdong> anyone heard any news if there's people packaging "tovid"?
<LucidFox> jdong> well, I just learned about its existence
<LucidFox> but searching Launchpad, Debian and debian-multimedia.org turns nothing
<LucidFox> the official site has debs, but no source package
<jdong> LucidFox: 2 years ago, I  once pseudo debianized the package for upstream. I wonder if they're using that, or checkinstall...
<jdong> LucidFox: I mean it certainly wasn't up to the quality standards of us, but it at least wouldn't break APT :D
<\sh> I wonder how packages are getting build in debian, which such enormous FTBFS rate because of not using newer API of special libs
<LucidFox> I could package tovid myself
<jdong> LucidFox: the only thing I'm not sure of right now are its dependencies
<jdong> LucidFox: it has flags for using both mjpegtools and ffmpeg as encoding backends...
<jdong> might be a package for medibuntu at this rate :)
<jdong> but yeah, if you're willing to take a look at packaging it, that'd be sweet and I'm sure upstream would appreciate it
<LucidFox> The GUI needs python-wxgtk2.6
<LucidFox> And mjpegtools is in the archive, it's ffmpeg that could pose problem because the Ubuntu version is castrated :)
<jdong> LucidFox: fortunately the ffmpeg backend isn't default, and we could nudge people in README.Debian to go towards the right repos ;-)
<RainCT> Hi :)
<RainCT> \sh: About the problem you had yesterday, the #bash guys told me to either use [[ =~ ]] or use a real programming language...
<jdong> ha
<\sh> RainCT, [[ =~ ]] in the case loop?
<RainCT> \sh: yes
 * jdong tries his luck advertising http://revu.tauware.de/details.py?package=clutch one last time before leaving for house shopping :)
<emgent> argh! Angela Merkel e Bill Gats, for microsoft in Germany (PA)
<emgent> s/e/and/
<\sh> RainCT, something like $RELEASES =~ <what>?  ;)
<\sh> RainCT, I don't know the syntax...never saw it
<RainCT> \sh: [[ $1 =~ $REL ]]
<RainCT> (2008-01-23 22:36:38) greybot: Binary operator, uses the expression on the right hand side as an extended regular expression and returns true if the expression on the left hand side matches the pattern. USE A VARIABLE to hold your regexes. eg: [[ $var =~ $r ]] && echo Match || echo 'No match'
<\sh> RainCT, ah so it's outside the case
<\sh> RainCT, well let's see if I have the energy to work on it today :)
<RainCT> \sh: yes.. either put it before it or inside the *) block
<RainCT> heh
<\sh> RainCT, yeah, that was my other idea to use * ) for that
<foolano> ScottK2: I've uploaded a new libtree-perl. GPL added. And it builds cleanly in my hardy pbuild
<ScottK2> foolano: Great.  I'll have a look at it in a bit.
<lifeless> where is the vote ?
<foolano> ScottK2: thanks
<LucidFox> Okay, if anyone seriously mentions Tk as the future of the Linux desktop again, I'll buy them a time machine so they can join us in 2008.
<zul> but but but
<Hobbsee> lifeless: for the MC?
<\sh> lifeless, https://edge.launchpad.net/~ubuntu-dev/+polls
<zul> are the "platforms" up for the MC election (other than Hobbsee)
<Hobbsee> zul: platforms?
<zul> basically what they are going to do if they are elected
<Hobbsee> the toher 2 have
<\sh> For me the vote system doesn't make sense...we need to elect 2 people...but a person can make 3 votes...now think about everyone is doing that...
<ScottK> \sh: It's the first time we've had some competition, so the vote system may not really support it well.
<Hobbsee> \sh: yeah...presumably it'll have to come out close
<\sh> ScottK, yeah...it's more a technical problem :)
<pkern> It's just LP...
<ScottK> So the suckage should be a given
<\sh> I don't file a bug for now...I want that the launchpadders are working on an xmlrpc interface ;)
<ScottK2> Competitive elections probably need a spec to get the design right.  Ideally it's be some kind of concordance system.
<pkern> Condorcet, yay yay.
<Spec> competitive elections? ie: i'm a dictator?
<ScottK> pkern: Yes.  It that other guy using my nick could spell ;-)
<\sh> Spec,  not possible...we have sabdfl :)
<Spec> oh, right. job filled. ;)
<\sh> ok enough for today
<\sh> doko, gcc toolchain 4.3 will it be for hardy+1 ?
<LucidFox> Hmm... I seem to magnetically attract weird upstream build systems :/
<LucidFox> now it's a Python package using automake to build and install
<DaveMorris> LucidFox: prog created by a C/C++ programmer
<DaveMorris> s/prog/prob
<LucidFox> the question is what to with it... do I need python-support/python-central at all?
<LucidFox> it installs a library into /usr/lib/python2.5/site-packages and some scripts into /usr/bin
<ScottK2> LucidFox: Is the library in C or Python?
<LucidFox> in Python
<ScottK2> Then it doesn't go in site packages and you need python-support or python-central.
<ScottK2> Version specific site-packages are only for C extensions under the new python policy.
<LucidFox> I see.
<LucidFox> But how do I use python-support with automake?
<ScottK2> Dunno.  I haven't had to do it.
<ScottK2> It may be easier to point automake at installing in the right places.
<ScottK2> It might also be easier to write your own setup.py, slap it in the debian/dir and use that instead.
<LucidFox> ScottK2> Using automake.mk and manually inserting a dh_pysupport call seems to have done the jub
<ScottK2> LucidFox: Excellent.
<LucidFox> it moved the library to /usr/share/python-support
<ScottK2> Which is where you want it.
<ScottK2> Does the binary package have egg-info in it?
<LucidFox> What is egg-info, and how can I check if it does?
<ScottK> LucidFox: Egg info is something used outside Debian to track depenencies.  Look in the .deb and see if there's an egg info file in /usr/share/pyhthon-support/packagename.
<ScottK> foolano: libtree-perl is advocated by me.
<ScottK> soren: libtree-perl is looking for a second advocate (ebox depends).
<foolano>  ScottK: thx
 * soren looks
<LucidFox> ScottK> No, there's only .version and files installed by upstream. Grepping for egg returns nothing either.
<ScottK> LucidFox: OK.  That's fine then.  If you have it you need a versioned depend on python-support, so that's not a concern for your package.
<soren> ScottK: GPL1? Seriously?
<ScottK> soren: Yes.  Perl is GPL v1 and later.
<ScottK> soren: I got a package rejected for the lack of that.
<soren> ScottK: "the full text of the license is in the code,"? Where?
 * ScottK2 looks
<foolano> I had intially looked at perl, perl-base and other perl modules...
<soren> foolano: Where did you find it? The copyright file doesn't say (which it should :) )?
<foolano> soren: cpan
<ScottK2> soren: lib/Tree.pm for example.
<foolano> i'm gonna add it then
<ScottK2> lib/Tree/Binary.pm and lib/Tree/Fast.pm too
<soren> ScottK2: Oh, it's got the perl snippet.
<soren> ScottK2: Not quite "full text of the license" :)
<ScottK2> I think it is
<ScottK2> If Perl suddenly relicensed GPLv3 only, then that's the only terms you could distribute this with that Perl with.
<ScottK2> Maybe I'm wrong.
<ScottK2> soren: I'm off looking for the specific package I got burned on to see how I resolved it and got it uploaded.
<soren> ScottK2: Grab libperl6-junction-perl.
<soren> ScottK2: That's my preferred way to do it.
<ScottK2> soren: You're right and I'm wrong.  I had to repack the tarball
<ScottK2> https://launchpad.net/ubuntu/feisty/+source/libnet-dns-resolver-programmable-perl/0.002.2-0ubuntu1
<soren> ScottK2: Let me guess: pitti was the one who reviewed it? :)
<ScottK2> Yes.
<soren> ScottK2: Heh..
<ScottK2> It was my first package uploaded to Ubuntu too.
<soren> ScottK2: Well, repacking it is ok. I wouldn't require it, but it's ok.
<soren> foolano: You can take a peek at libperl6-junction-perl's debian/changelog.
<foolano> alright
<soren> foolano: I'd have accepted something like that. Well, of course I would. I made it :)
<foolano> :P
<foolano> should i change the copyright file and add what libperl6-junction-perl has?
<ion_> The map <http://heh.fi/tmp/lightmap> gnomeâs clock thing displays nowadays is depressing. It reminds how scarcely we get sunlight. :-)
<soren> foolano: I would, yes.
<pochu> Am I the only one receiving a lot of copies of the same message from motu-reviewers@ ?
<hellboy195> mr_pouit: ping
<ScottK2> vorian: Your upstream says pdftk is no longer required.
<foolano> soren, ScottK2: i've just uploaded a new package. copyright is based on libperl6-junction-perl
<\sh> oh wow...
<\sh> we have so much to fix ;)
<vorian> thanks ScottK :)
<geser> \sh: what did you break? :)
<\sh> geser, nothing...I'm fixing stuff finally ;) gcc4.3 bugs and some build system bugs like setup.py with shebang against 2.4 ,-)
<LucidFox> jdong> I've uploaded a preliminary tovid package, it's still a WIP because there are lintian warnings; will continue tomorrow
<jdong> LucidFox: wow
<jdong> LucidFox: nice :)
<LucidFox> in the meantime, while I'm asleep, could you look at the avidemux upgrade bug? :)
<jdong> LucidFox: if I get a chance sure, I've got a doctor appointment and I don't know how long that'll take
<LucidFox> ah
<mr_pouit> hellboy195: pong ?
<hellboy195> mr_pouit: do you mind 'm going the qmail merge? *asking like the guidelines tell*
<hellboy195> *doing
<\sh> hellboy195, I think at this time of the release cycle you don't have to ask anymore...but this is just me ;)
<mr_pouit> hellboy195: it'll ftbfs in the buildds, but go ahead if you want ;)
<mr_pouit> hellboy195: thanks for asking ;p
<ScottK2> I'd say asking is stil nice, but waiting a long time isn't needed.
<hellboy195> ok ^^, it's written on DaD and also my mentor told me to do but i'll keep that in mind
<hellboy195> mr_pouit: ftbfs? because?
<ScottK2> hellboy195: It's a source only package due to qmail licensing.  Up until very recently binary distribution wasn't allowed.
<hellboy195> ah, k
<\sh> ScottK2, should this not be worth a change?
<ScottK2> \sh: You mean qmail?
<\sh> ScottK, yepp
<ScottK2> Personally, I think it's not worth the effort to mess with, but if someone want to fix up 9 year old code and make it work like a modern mail system (e.g. reject, don't bounce), it's now free software, so they should have at it.
<\sh> ScottK2, well qmail was known because it was fast...in the 90ties I crashed a sparc sendmail system with it :) (that was the sendmail running on sun os at DENIC (the german domain registrar))
<\sh> hey this is so annoying...sbuild start and woops..there is a new window
<hellboy195> ScottK \sh : so. no merge/sync. What to do? leave a comment?
<pochu> vorian: lol, I've got your comment on revu six times :)
<vorian> pochu: yes, lesson learned *don't refresh revu*
<vorian> :P
<vorian> I am sorry about that
<pochu> heh, that sounds like something to change in revu :)
<vorian> It wont happen any more
<somerville32> Yea, that is a bug.
<somerville32> Does anyone know if it is already reported?
<pochu> vorian: you aren't the first, and won't be the last one...
<ScottK2> vorian: REVU code in on launchpad.  Patches gratefully accepted.
<vorian> ScottK: I'll take a look see :)
<vorian> ScottK2: the package is finished too
<ScottK2> I'm just running out for a bit.  I'll try and have a look later.
<vorian> ok, thanks for your guidance
<\sh> hellboy195, even if it FTBFS .. it's a merge because the new package didn't have the fakeroot call which was added in ubuntu
<hellboy195> \sh: so I should do the merge/LP thouch it FTBFS?
<\sh> hellboy195, yepp..just add the debdiff to the LP bug then :)
<\sh> hellboy195, and subscribe ubuntu-universe-sponsors
<hellboy195> \sh: yeah I know ^^, I'll do that later. thx
<\sh> siretart, ping
 * siretart damaged
<\sh> siretart, you are running gnome (on hardy) and sbuild with snapshot chroots eventually?
<siretart> \sh: s/hardy/gutsy/, but yes
<\sh> siretart, well...I need you running hardy and latest gnome...and snapshot chroots ... right now, I#m getting annoyed by popup windows of newly mounted LVMs (session stuff)
<\sh> siretart, and it looks like i'm the  only one...(amd64 ;))
<\sh> siretart, but I think it's not me alone ;)
<siretart> \sh: oh, hardy's hal (finally) knows about LVM? neat
<\sh> siretart, well...annoyingly yes ;)
<siretart> \sh: in that case, gnome-volume-manager should be told to ignore lvm snapshots detected by hal
<\sh> siretart, how?
<\sh> siretart, I see dbus sending out messages to gvfs about it
<\sh> siretart, and I switched off all automounting/autoshowing up of removable and hotplug media
<siretart> \sh: please tell pitti. I think he knows enough about hal for that. maybe there is already a bugreport here?
<\sh> let's see
<\sh> siretart, I don't see any bugreport against hal, but the "lvm missing in hal" one...
<\sh> but lshal gives me this:
<\sh> shermann@home-emt64:~/packages/gcc4.3/acpitool$ lshal |grep LVM
<\sh>   info.product = 'Volume (LVM2_member)'  (string)
<\sh>   volume.fstype = 'LVM2_member'  (string)
<\sh>   volume.fsversion = 'LVM2 001'  (string)
<\sh> and points directly to my LVM enabled harddrive
<siretart> no snapshot listed here?
<\sh> nope
<\sh> siretart, but I see dbus sending out messages about the snapshots...I wonder where that comes from
<\sh> siretart, http://pastebin.ubuntu.com/3838/
<jdong> who do I talk to in order to make my account on REVU a MOTU account?
<ScottK> jdong: REVU admin of some kind
<siretart> who is sender=:1.17?
<\sh> siretart, -EDUNNO
<\sh> siretart, but I think that's the point why hte windows are popping up like mad...
<tuxmaniac> will pdebuild -sa include original source (it doesnt seem to)
<siretart> jdong: done
<jdong> siretart: thanks
<hellboy195> Can I change a sentence in debian/changelog so that it looks better (meaning is the same) ?
<siretart> that question is confusing
<RainCT> \sh: btw, better use [ -z "$VAR" ] instead of [ -z $VAR ] :)
<tuxmaniac> hellboy195, if you have used dch -i then your changelog should look beautiul by default :-)
<hellboy195> siretart: ^^, For Example: remaining ubuntu change in ubuntu : + Adhere to DebianMaintainerField.  <-- in my mind - Modify Maintainer value to match Debian-Maintainer-Field Spec looks better ^^ Am I allowed to change it?
<\sh> RainCT, k
 * ScottK always just writes change maintainer to MOTU.
<hellboy195> ScottK: ^^, yeah but do I have the RIGHT to change it if you want?
<hellboy195> *if I want
<\sh> siretart, any possibility to find sender 1.17?
<ScottK> hellboy195: If it's your changelog entry, yes.  If it's a previous one, no.
<siretart> \sh: /me no dbus guru. sorry
<hellboy195> ScottK: that's what I wanted to know :) thx
<ScottK> siretart: But you answered him. so by the FOSS laws of tech support, you have to solve his problem now. ;-)
<siretart> dammit :)
<\sh> *eg*
<\sh> nope
<\sh> I want to know what's happening at all.../me is no dbus/hal/whathaveyouforcorbainfrastructurehandy expert
<siretart> hellboy195: technically, you are allowed. However, I doubt that this is a good idea and worth bothering
<hellboy195> siretart: k ^^
<\sh> lol googling for sender 1.17 gives me the maemo irc log snippet
<RainCT> Can new versions of programs still get into universe after FeatureFreeze (without an exception)?
 * RainCT thought that's an easy question :P
<geser> RainCT: sort of, native packages with only small changes (bug fixes) doesn't necessarily need an exception
<RainCT> geser: and non-native packages?
<jdong> RainCT: and there's often blanketed exceptions for a bunch of core system stuff :)
<jdong> i.e. the entire GNOME stack
<jpatrick> and KDE stuff
<jdong> RainCT: everything else needs a UVFe bug
<jdong> or whatever tehy're called now
<geser> RainCT: for non-native packages you need an exception but I don't know how the new motu-ff team will handle minor (bugfix) releases
<superm1> jdong, and the mythbuntu stuff has a blanket too :0
<Kano> hi, could somebody add to openscenegraph Build-Depends: libxine-dev
<Kano> then osgmovie builds
<Kano> with is very cool...
<jdong> superm1: ok ok fine a lot of desktop stuff
<jdong> superm1: now all that's missing is somerville32 telling me that xubuntu has a blanket too
<superm1> has motu-ff been completely assigned?
<jdong> :D
<Kano> osgmovie dvd://1.xine --interactive
<RainCT> okay, thanks all :)
<jdong> lps openscengraph
<Kano> would play first dvd movie in 3d mode and you can move, rotate, zoom it..
<jdong> whoa why does it have like 6 control files?
<Kano> sample files for other distros
<Kano> you only need to change the the standard control
<jdong> yeah, I see
<Kano> if you like i give you a mod to compile it much faster
<Kano> optimized rules..
<jdong> Kano: what is the nature of the mod?
<Kano> wait, will make a diff
<Kano> it will fully use all cores
<\sh> ??
<\sh> make -m<howmany> is set in the buildd definition..DEB_MAKE_options or so
<\sh> -m+j
<\sh> make -j<howmany>
<Kano> http://paste.debian.net/47617
<zul> *sigh*
<Kano> that counts for cores
<jdong> I'm personally uninterested in applying that patch
<\sh> lol
<Kano> single core user ;)
<\sh> wow
<jdong> Kano: nah, dual with HT on this machine :)
<jdong> Kano: I don't believe you counted logical processors ;-)
<Kano> well osg really compiles very long
<Kano> because of introspection
<\sh> Kano, na
<Kano> on i386 introspection is active
<\sh> Kano, well, for the buildds is time not a problem
<Kano> when you optimizie it fully you could compile it in 10 min with dual core..
<\sh> Kano, just for the tester
<jdong> the last i386 buildd took 3h40m to build it
<Kano> if you want to test it faster disable introspection
<jdong> nah I'm paranoid, I'll test build it as-is with libxine-dev added
<Kano> RelWithDebInfo -> Release will give the rest of speed
<\sh> I wonder why debian didn't add xine then
<Kano> i dont know, i mailed the maintainer
<Kano> maybe they dislike osgmovie *g*
<\sh> Kano, xine was at some time already enabled
<jdong>   * Restrict compilation of introspection and xine
<jdong>     plugin to i386 because Introspection breaks the compiler (gcc-3.3)
<jdong>     and xine contains i386 assembly that cannot be rewrote right
<jdong>     away.
<jdong> long time ago, 0.9.9 or so
<Kano> \sh: right, the old 1.2.0 package had it
<jdong> ooh cool, cmake  shows percentages
<Kano> yes one of the cool things ;)
<Kano> so the 4h will not be that boring *g*
<jdong> I'm already up to 10%... how many stages are there?
<Kano> introspection takes long...
<jdong> perfect time to do laundry then :)
<Kano> as i said, you can tune it down to 10 min compile time on dual core
<jdong> meanwhile, someone please REVU clutch for me ;-)
<hellboy195> \sh: qmail merged :)
<somerville32> jdong: Since when has Xubuntu adhered to a number of policies? :P
<Elly> wait, ubuntu has policies?
<pochu> a lot
<pochu> PolicyKit
<pochu> ;)
<Elly> :O
<Elly> does it have selinux policies?
<jdong> Elly: uh oh don't start Apparmor vs SELinux again ;-)
<Elly> I thought apparmor relied on selinux
<Elly> o_O
<Elly> I didn't know they were opposed
<jdong> no
<jdong> they are "competing" technologies
<\sh> siretart, it looks like that I'm trapped in a behaviour of gnome-volume-manager to start always a filemanager when something is mounted with an <insert fs here> system ;)
<ion_> Ditto
<\sh> oh damn
<\sh> it's nautilus
<\sh> ion_, gconf-editor search for nautilus -> preferences -> media_automount <- checked -> media_automount_open <- also checked...uncheck this media_automount_open
<ion_> Thanks
<\sh> ion_, well...no...this is wrong
<yamal> reviewers wanted for http://revu.tauware.de/details.py?package=sabnzbdplus - thanks
<\sh> ok...going off...cu tomorrow
<schierbeck> what would be the reason that my newly built package only contains /usr/share/doc/<pkg>/<stuff>?
<schierbeck> when i extract the source package, everything is there
<schierbeck> and i can install just fine with ./configure, make and sudo make install
<persia> schierbeck: The install files aren't going in to one of debian/tmp/... or debian/<package>/... at build time.
<persia> jdong: Can you review yet, or are you still waiting for promotion?
<ScottK> persia: He's taken care of.
<persia> ScottK: great.  I missed it in backscroll.  Thanks for the update.
<schierbeck> persia: but i use $(MAKE) prefix=$(CURDIR)/debian/$(package)/usr install in the rules file
<schierbeck> and the package var is set correctly
<persia> schierbeck: Does the upsteam Makefile parse prefix when passed like that?  Try using debuild in a chroot and check the contents of debian/$(package)/ after the build.
 * persia notes that packaging tends to expose subtle bugs in upstream build systems
<schierbeck> persia: i've tried running make install manually, with prefix=./debian/<pkg>/usr, but it doesn't create the directories
<schierbeck> should i add a flag to /usr/bin/install?
<schierbeck> -D seems to be the right one
<mok0> schierbeck: install -D only copies one file at a time
<persia> schierbeck: You could try putting them in debian/package.dirs and calling dh_installdirs.  If that doesn't work, patching the upstream Makefile could do it.  The first is easier to handle for updates, as you won't have to merge a patch (although you will need to check to make sure they are still correct).
<persia> schierbeck: Whichever path you choose, best to tell upstream that it doesn't work, and they might appreciate a patch to make sure their software can be installed on systems that are missing the install directories.
<schierbeck> persia: it's my own project, so i can easily change the Makefile
<persia> schierbeck: It's handy when working with upstream only means talking to oneself, although it can be confusing sometimes :)
<schierbeck> indeed :)
<schierbeck> i use autotools -- is there something simple i can just put in?
<mok0> schierbeck: make DESTDIR=debian/tmp install
<schierbeck> mok0: i'll try that, thanks
 * persia notes that for autotools make DESTDIR=debian/$(package)/ ought work as well
<schierbeck> should i remove the prefix, mandir and infodir declarations from the make install line?
<mok0> schierbeck: Actualle there are 2 strategies: either have the buildsystem install things directly into the relevant debian/<package> directories, or
<mok0> schierbeck: let the build system make a complete installation into the debian/tmp tree, and then let <package>.install files put them into their right place for packaging
<schierbeck> i'll try with DESTDIR first :)
<mok0> schierbeck: I recommend that
<mok0> schierbeck: and then your rules only needs to be a 4 line cdbs script
<schierbeck> god damn it, all that work and i could've just put in 4 lines!!
<mok0> schierbeck: which means you don't need to quarrel with the MOTUs about debhelper details :-)
<persia> schierbeck: Think of it as a learning exercise.  If you learn the 4-line way, you'd get stuck for something more complex.  This way, you learn how it works, and then refactor the code.
<mok0> schierbeck: if your build is only a straight "configure; make; make install" idiom, cdbs is _much_ simpler
<schierbeck> hehe
<persia> mok0: see the sendmail rules file for a counterexample (although I tend to agree with you when no overrides are required)
<schierbeck> i'm still pissed
<mok0> schierbeck: learning is hard :-)
<mok0> schierbeck: check out https://wiki.ubuntu.com/PackagingGuide/Howtos/CDBS?highlight=%28CDBS%29
<schierbeck> tell me about it, i only started using autotools a few weeks ago, and now this whole packaging thing is nagging me
<mok0> schierbeck: spending time on autotools is *good*
<mok0> it saves you time later on
<schierbeck> yeah, i know
<schierbeck> crap, still not working
<schierbeck> i'll use that cdbs stuff instead
<mok0> schierbeck: save your old rules file :-)
<schierbeck> mok0: using bzr :)
<ion_> Naturally, itâs in the VCS history.
<mok0> schierbeck: cool
<schierbeck> i'm co-developing bzr-gtk on the side, so i kind of have to :)
<mok0> schierbeck: respect
<schierbeck> gracias
<schierbeck> hmm, i'm getting "E: mips_0.1.2-1_source.changes: bad-distribution-in-changes-file gutsy"
<schierbeck> when running debuild -S
<schierbeck> (still using the old rules file)
<schierbeck> perhaps that's the reason?
<mok0> schierbeck: ignore it
<schierbeck> okay
<mok0> schierbeck: lintian is a debian tool, it trips on Ubuntu releases
<schierbeck> k
<persia> schierbeck: You're getting that because of your version.  Pleaes use either 0.1.2-0ubuntu1 if you are targeting Ubuntu.
<persia> s/Pleaes use either/Please use/
<schierbeck> ohh
<schierbeck> on it
<persia> More generally, when you use a Debian revision number, lintian expects you plan to upload to Debian, and complains that Debian doesn't have hardy.
<mok0> persia: ok, didn't know that
<mok0> I only installed hardy yesterday on my new quadcore :-P
<persia> mok0: Please share.  I see that question a lot, and "ignore it" tends to result in REVU rejections, or difficulties upgrading from privately released early versions to the official version once it gets accepted.
<jdong> persia: I just got the powers earlier today
<jdong> oh nvm scott already answered that
<persia> jdong: Perfect.  Now, how many packages can you reject in 24 hours?
<jdong> persia: haha
<jdong> persia: I should ask you to rip apart the package I put up yesterday ;-)
 * persia has reached 33, but thinks 50 ought be possible, with a little concentration.
<schierbeck> if i use the autotools cdbs commands, do i still need to run autogen.sh before debuild?
<mok0> persia: I understand. But when struggling with getting the right files into the right packages, I think the problem can be dealt with at a later polishing stage
<persia> mok0: Agreed.
<persia> jdong: I REVU in mostly FIFO order, although I try to have reviewed every package that passes through REVU at least once.  Best way to get me to review your package is to review all the packages ahead in the queue.
<mok0> schierbeck: you should generate your tarball with a "make dist"
<schierbeck> ok
<mok0> schierbeck: then it will contain a correct configure etc.
<mok0> schierbeck: doing autogen.sh in packaging is frowned upon (.i.e. don't do it unless absolutely necessary)
<mok0> schierbeck: ... and since you are upstream it should be avoided
<schierbeck> okay
<jdong> persia: cool, that's awesome, I shall wait patiently then :)
<jdong> persia: is there anything that you don't do? :D
<mok0> jdong: back in line, dude :-)
<schierbeck> ... but i need to run my autogen.sh and configure before i even have a Makefile...
<schierbeck> but that's okay, right?
<persia> jdong: Lots.  Let me know if you're looking for something :)
<mok0> schierbeck: if you pack your tarball with "make dist" autotools make sure that everything needed is up to date. It will package a configure script + makefiles
<pochu> jdong: don't wait, review instead! :-)
<persia> jdong: And please don't wait patiently.  The more you can knock off as failing lintian or having something just plain wrong, the better hardy will be.
<jdong> persia: true
<mok0> schierbeck: then all you need to do is "configure; make; make install" which cdbs does automagically
<jdong> well I'll go eat and then try playing REVU night ;-)
<jdong> hopefully I won't get addicted :)
<schierbeck> okay
<pochu> jdong: you will end like persia if you do ;)
<mok0> schierbeck: when upstream does his/her work, packaging is sooooo much easier :-)
 * pochu hides from persia :)
<persia> pochu: Why does REVU show a bulb when I add a rejection to a package that someone else advocated?
<schierbeck> mok0: i shout at myself *all* the time :)
<pochu> persia: because it has > 0 advocates
<pochu> persia: what should I show instead?
<pochu> Would be trivial to fix
<persia> pochu: Hrm.  But it got rejected.  Can we add a test to make sure it wasn't rejected as well as having been advocated before granting a lightbulb?
<vorian> it knocked it from the top of the list
<mok0> schierbeck: I have to say: this forum has taught me humility
<emgent> hyea people
<pochu> persia: it's an if/elif/elif... block, so it's just moving the rejected thing before the "advocates > 0" :)
<pochu> persia: I'll do it in an hour, have to go right now.
<pochu> persia: let me know if you find something else!
<persia> pochu: No huge rush.  Thanks a lot for helping.
<mok0> Ah, a MOTU can skip queue none-the-less
<schierbeck> okay, switched to cdvs
<schierbeck> *cdbs
<schierbeck> crap, now i need autotools as a build-dep
<mok0> schierbeck: only if you use "autoconf" or "automake" which you should not
<schierbeck> okay
<schierbeck> i just copied from the packaging guide, but i guess i don't need them
<mok0> schierbeck: like I said above, package your distribution tarball with "make dist" , it will generate a configure file that cdbs will call
<schierbeck> okay
<mok0> schierbeck: then your only dependency is cdbs and debhelper
<mok0> schierbeck: in other words: you are upstream, make those changes in .orig.tar.gz
<schierbeck> okay
<schierbeck> building...
<RainCT> good nightÃ§
<mohammad> Is there any restriction on the size of a deb package?
<RAOF> Not that I know of.  There are extremely large debs (for game data, for example).
<RAOF> Smaller is generally better, though :)
<persia> mohammad: technically, making them larger than 2GB (compressed) might have issues on some architectures.  From a policy perspective, large packages need to justify their use of archive space (this tends to trigger around 50MB or so).
<mohammad> Thank you persia & RAOF
<schierbeck> persia, mok0: found a few bugs in my project's Makefile.am's, had to fix them before proceeding
<mok0> schierbeck: great!
<schierbeck> OMG! it's working!
<schierbeck> i thought i'd never see the day!!
<mok0> schierbeck: :-)
<schierbeck> :D
<schierbeck> thanks for all the help, guys!
<schierbeck> wouldn't have made it without you
<mok0> schierbeck: glad to help, I received a lot of help here myself...
<schierbeck> :)
<schierbeck> mok0: you're Danish?
<mok0> schierbeck: yes
<mok0> schierbeck: but don't hold it against me :-)
<schierbeck> :)
<schierbeck> i live in Ãsterbro -- what about you?
<mok0> schierbeck: I live in Aarhus
<mok0> schierbeck: if you like, there's often a nice crowd on ubuntu-dk
<schierbeck> cool
<mok0> we can speak danish there :-)
<jdong> whee! I revu'ed a package! I feel so happy :)
<mok0> jdong: way to go! (hope it was mine)
<ajmitch> jdong: congratulations, you get a gold star & a warm fuzzy feeling
<jdong> ajmitch: just like swimming camp!
<jdong> mok0: nah, with the todo list you hope it wasn't yours ;-)
<mok0> jdong: swimming camp? that would be more like, at cold shivering feeling...
<mok0> jdong: :)
<pochu> ENOENT means "No such file or directory", right? But is it an acronym? Or is there a reason for those letters?
<Seveas> E for error NO for no ENT for entry or entity oslt
<pochu> Seveas: ah, thanks :)
#ubuntu-motu 2008-01-25
<pochu> persia: so, if the package has one advocate, it gets a bulb. If then someone rejects it, it gets a hammer. When it's uploaded again, it gets a bulb again... until it gets another advocate and gets a heart. Is that right?
<pochu> persia: and what would you expect if the package has 2 advocates (and thus a heart) and someone rejects it? o.O
<jdong> pochu: hammertime!!
<pochu> :)
<jdong> couldn't resist
<mok0> pochu: if it has 2 advocates, it gets uploaded...
<Seveas> jdong, "can't upload this" dum-de-de-dum
<pochu> mok0: usually, yes.
<pochu> persia: new patch attached to bug 185133
<ubotu> Launchpad bug 185133 in revu "Improve package images so that there is just one image per package" [Undecided,In progress] https://launchpad.net/bugs/185133
<pochu> jdong: do you know transmission 1.02 is in debian unstable? I guess we could ask a sync, WDYT?
<pochu> jdong: as there are no changes other than a new upstream...
<Legendario> does anyone know what make error 1 is?
<Kmos> pochu: yes, it's in debian.. you should request a sync of it
<Kmos> it's installed now in hardy by default
<pochu> jdong: I'll request it. Let me know if you disagree :)
<Legendario> make erro 1. Any guess?
<LaserJock> Legendario: that is nowhere near enough info to say anything about
<LaserJock> Legendario: you need to pastebin the stuff that happened before the make error
<RAOF> Dear PyPy.  You sound cool, but please build on amd64.
<Legendario> LaserJock, here it is: http://paste.ubuntu-nl.org/53400/
<LaserJock> Legendario: well, look at what it's telling you :-)
<LaserJock> checking for PIDGIN... configure: error
<nxvl_work> i think is a Build-Depends error
<LaserJock> Legendario: does it make sense?
<jdong> pochu: wait a sec don't sync yet
<jdong> pochu: I want to review it, there was a tarball packing error with the initial 1.02 release; I feel more comfortable with the one I rolled
<jdong> the orig tarballs are not the same
<Legendario> LaserJock, yeah, it makes sence. it is building a pidgin plugin
<LaserJock> Legendario: so do you have a build dependency on pidgin-dev ?
<nxvl_work> does the Developer Sprint is taking place or this development circle there was no one?
<jdong> pochu: I closed the sync ticket you opened for transmission; reasoning can be found on the bug report. I'll also poke debian about the situation.
<vorian> how would a person go about tackling these issues? http://paste.ubuntu-nl.org/53402/
<vorian> :)
<RAOF> For the first two, you're using CDBS, yes?
<StevenK> vorian: You have ${shlibs:Depends} not ${python:Depends} and you're calling dh_shlibdeps instead of dh_pycentral or dh_pysupport
<vorian> RAOF: yes
<vorian> ah!
<vorian> thanks StevenK :)
<wallyweek> is there anyone willing to review http://revu.ubuntuwire.com/details.py?package=sdlmame
<wallyweek> please do it... it's been in revu since last february and I really like to see it in hardy :D
 * wallyweek is sad to leave, but he *strongly* needs some sleep
 * jdong fixes prevu's misuse of exceptions
<schierbeck> does anyone here know how to get rid of an installed package whose uninstall-hook messes up?
<pochu> jdong: hmm, if upstream rolled a new tarball, they should have done it with a version bump
<pochu> jdong: alright, let's wait for 1.03 then
<jdong> pochu: yeah, I agree that was bad judgement on their behalf
<jdong> pochu: but meh what can you do; it's good enough already that they didn't say "deal with it"
<pochu> jdong: yeah, but how would you know now whether someone has the good or the bad tarball offhand?
<pochu> jdong: anyway nice to hear it's fixed.
<jdong> pochu: well I compared md5sums first, then ./configure --help, look at mandir and infodir defaults. Correct ones say DATAROOTDIR/man and so on, incorrect ones say PREFIX/man. /usr/man is obviously not a good place for manpages ;-)
<imbrandon> yea but it wont work with Core Audio i dont think , not sure, I'll try a new compile here tonight and see
<imbrandon> err totaly wrong window
<browndruid> So can anybody here help me get on my path toward Ubuntu development?
<MarcC> what's the best way to get a GPL app put in the repos?
<LaserJock> browndruid: that kinda vague. What are you interested in?
<LaserJock> MarcC: well, packaging it. :-)
<LaserJock> MarcC: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<browndruid> I't not really totally sure. I have very little programming experience, so if there's somewhere you can point me to so I can start learning, I think that would be the best first step.
<LaserJock> browndruid: you might want to have a look at https://wiki.ubuntu.com/UbuntuDevelopment/
<LaserJock> well, you don't often need very much programming experience
<browndruid> I've been reading the Development site.
<browndruid> What kind of stuff would I do without programming experience?
<LaserJock> well, anything you want
<MarcC> thanks LaserJock
<browndruid> Yeah, but if I don't know how to do it, then I can't.
<LaserJock> browndruid: https://wiki.ubuntu.com/MOTU/TODO
<LaserJock> browndruid: well, we don't really program
<LaserJock> we package and take care of the archive
<LaserJock> programming experience can be helpful when bug fixing, but even then there's a lot you can do
 * jdong smiles...
<jdong> I'm going to hell for this one :)
<LaserJock> uh oh
<jdong> LaserJock: don't worry, it's ony on my personal computer :)
<imbrandon> you rick rolled someone ?
<jdong> I kinda reinvented module-assistant
<browndruid> Well, I guess I'll be on my way!
<LaserJock> devil!!!
<LaserJock> browndruid: why?
<LaserJock> browndruid: do you wanna help or ?
<browndruid> so i can start on the whole learning what i need to do thing.
<jdong> a deb package that in postinstall unpacks and recompiles madwifi-ng if it isn't probed in the running kernel...
<browndruid> Yeah, I want to help.
<LaserJock> browndruid: this is a great place to learn
<jdong> I was tired of recompiling madwifi on every kernel update.
<jdong> I'm sure I broke some holy rules of deb packaging :)
 * imbrandon waits for someone to package the wow installer + custom wine
<imbrandon> that would suck and rock , both
<jdong> imbrandon: I see dist-upgrader does --force-{some,all,etc} during release and partial upgrades now, so.... what's the harm in that ;-)
<imbrandon> heh, thus why i stick to apt-get
<imbrandon> if you cant apt-get dist-upgrade , something is broke imho
<jdong> imbrandon: personally, I wonder if a lot of dist-upgrader's jobs should be somehow worked into the metapackages
<imbrandon> jdong: they should imho
<jdong> bleh I just drank rubbing alcohol
<imbrandon> the time it takes to "fix" it in dist upgrader could easily be added to the packages
<jdong> don't keep open bottles of water and alcohol close by
<imbrandon> but thats just me personaly
<jdong> imbrandon: I agree, I don't see much of a technical reason why it couldn't be a part of a package's pre/post* scripts
<ScottK> imbrandon: Up for sponsoring a Kubuntu merge?  It's Bug #185754.
<ubotu> Launchpad bug 185754 in sip4-qt3 "Please merge sip4-qt3 4.7.3-1  (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/185754
<ScottK> I'm working on python-qt4 merge right now and that one needs to go first.
<imbrandon> ScottK: sure give me a few to dig out my usb key ( gpg ) and i'll have a look
<MarcC> can somebody tell me how this looks as a needs-packaging bug?
<MarcC> https://bugs.launchpad.net/ubuntu/+bug/185810
<ubotu> Launchpad bug 185810 in ubuntu "Art of Illusion - Easy to use 3D modeling studio" [Undecided,New]
<ScottK> imbrandon: Great.
<Legendario> LaserJock, sorry. i had to go away for a couple hours. Do you mind if we go back a little. I have the build dependencies for it. I have the pidgin-dev installed and when i run the configure script for the program i am trying to build a debian package, it says to me that everything is ok.
<LaserJock> k
<imbrandon> MarcC: looks fine as far as a request
<MarcC> ok, thanks imbrandon
<imbrandon> ScottK: is that a debdiff against the debian or ubuntu source, dosent look like the patch applies to the hardy ubuntu
<ScottK> imbrandon: debdiff against debian
<imbrandon> ScottK: got it
<jdong> debiandiff :)
<jdong> diffbuntu
<freakabcd> hi all
<jdong> I coin those two terms!
<freakabcd> can I bug someone to update the octave package on hardy? and subsequently gutsy?
<freakabcd> debian's got source packages for those in sid
<freakabcd> http://packages.debian.org/sid/octave3.0
<jdong> freakabcd: Hardy's easier to argue than gutsy currently
<jdong> freakabcd: see bug #185653
<ubotu> Launchpad bug 185653 in octave3.0 "[MoM SYNC] octave3.0 3.0.0-1" [Undecided,Confirmed] https://launchpad.net/bugs/185653
<jdong> it's already been put in the queue
<jdong> freakabcd: once it's in hardy we can talk gutsy-backports
<Legendario> gotta go
<freakabcd> ah, cool
<Legendario> will be back tomorow though
<ScottK> jdong: But those backports guys are crazy.
<jdong> ScottK: yeah I know ;-)
<freakabcd> well, it doesn't need to be a backport
<freakabcd> it could be a proper gutsy release
<jdong> ScottK: that's why people should make a website where anyone can upload and share the debs they create
<jdong> freakabcd: that is not in line with the update policy for released distributions
<freakabcd> because, the deb octave list have still not moved to gfortran based dependencies
<LaserJock> I didn't think we were doing Octave 3.0 yet
<freakabcd> LaserJock, deb has packages already. trivial to get them on hardy
<LaserJock> freakabcd: not exactly
<jdong> LaserJock: well \sh pulled the trigger ;-)
<LaserJock> we were thinking of leaving 3.0 out of Hardy perhaps
<freakabcd> no way
<LaserJock> as we weren't sure of the upgrade path
<freakabcd> you mean the octave modules issue?
<freakabcd> please follow debian's footsteps in this matter. they already have 3.0 released. providing binary modules isn;t too much of a priority anyway.
<freakabcd> the next step they are already working on is to move away from f77 and onto gfortran
<LaserJock> well, we can't just follow Debian in all cases
<LaserJock> we have to take care of our users as well
<LaserJock> Debian dropped the octave binary
<freakabcd> they dropped binary octave modules?
<LaserJock> no
<freakabcd> what did they drop then?
<LaserJock> the metapackage
<LaserJock> we were going to do some upgrade testing first
<freakabcd> obviously. their reasoning was that this time when someone installs 'octave' they get exactly that 'octave' nothing more like the binary octave modules, etc.
<ScottK> jdong: I did have a pleasant IRC conversation with someone I'm working on a project with.  He mentioned he was getting more spam.  I asked him if he'd upgraded to spamassassin 3.2.4 yet.  He said no, he guessed he'd have to build from source (he's got a feisty server).
<ScottK> I thoroughly enjoyed being able to say no, it's in feisty-backports.  Just install it.
<LaserJock> heh
<jdong> ScottK: :)
<LaserJock> well, perhaps we should have emailed -motu about Octave 3.0
<freakabcd> well, they need to include 3.0 atleast in hardy.
<LaserJock> we'll see
<freakabcd> how far away are we from freeze?
<LaserJock> hopefully
<LaserJock> Feb 14th
<freakabcd> wow, not too much time. hope the 'octave guy' here updates to 3.0
<LaserJock> well of course I want to
<freakabcd> i forgot his name; was kind enough to update the 2.9 package from the ancient .12
<LaserJock> well, nobody has filed a sync bug that I know of
<freakabcd> https://bugs.launchpad.net/ubuntu/+source/octave3.0/+bug/185653
<freakabcd> that one?
<ubotu> Launchpad bug 185653 in octave3.0 "[MoM SYNC] octave3.0 3.0.0-1" [Undecided,Confirmed]
<ScottK> freakabcd: You can look it up in the package info on Launchpad
<jdong> LaserJock: I just linked to one!
<LaserJock> bah
<freakabcd> lol
<LaserJock> stupid LP
<LaserJock> I did a search and nothing came up
<freakabcd> what is MoM sync ?
<jdong> LaserJock: it's filed under octave3.0 somehow
<imbrandon> Merge-o-Matic
<jdong> LaserJock: even though that package should be -ENOENT
<LaserJock> freakabcd: MoM is merge-o-matic
<jdong> I don't get Launchpad anymore
<freakabcd> ah, interesting acronym
<LaserJock> alright so maybe I should set it to Incomplete at the moment and leave a note
<freakabcd> damn, i don't have hdd space to mess around with hardy :(
<AnAnt> persia: ping
<freakabcd> whats with the tags on LP on the left?
<freakabcd> there is a tag '1680x1050' i clicked on it and there are no results
<jdong> Maybe we can use them like slashdot tags ;-)
<imbrandon> freakabcd: means what ever was using it is no longer
<freakabcd> lol, it was searching for 1680x1050 with the octave-3.0 domain
<imbrandon> LaserJock: UW search works much better than LP search in most cases :)
<freakabcd> thats funny
<LaserJock> hmm, well if minghua shows up we can discuss it
<imbrandon> ( LaserJock and even has a FF plugin hehe )
<LaserJock> freakabcd: it may be we just need to patch octave3.0 to build the octave metapackage
<freakabcd> cool. that would be great.
<freakabcd> LaserJock, i'm not on my ubuntu box at the moment. what packages does the octave metapackage install? the headers, emacsen, etc. ?
<LaserJock> well, octave3.0 itself too
<freakabcd> great. i hope to see 3.0 packages in gutsy too :D
<freakabcd> then i can start messing around with providing binary packages for the octave-forge modules
<LaserJock> no, they won't be in gutsy
<LaserJock> I don't think there would be a way to do that outside of maybe a PPA
<freakabcd> you mean the backport guys will refuse to backport it?
<LaserJock> I believe so, there's too much that depends on it
<LaserJock> you'd have to backport probably like 20-30 packages I'm guessing
<ScottK> LaserJock: Kind like with clamav, right?
<LaserJock> at least ;-)
<LaserJock> and without the justification
<freakabcd> wait a minute.. 2.9.19 from hardy hasn;t been backported to gutsy
<freakabcd> !! why?
<ubotu> Sorry, I don't know anything about why? - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<LaserJock> freakabcd: we don't just backport everything
<freakabcd> ok, i'm going to get the source package for 2.9.19 from hardy and backport it to gutsy.
<freakabcd> i will assume it is trivial. and let you guys laugh at me tomorrow at my failure :D
<freakabcd> LaserJock, what makes me believe it is trivial is that none(that i know) of the deps have updated releases
<LaserJock> well
<ScottK> freakabcd: If it build/installs/runs on Gutsy, you can ask for a backport.  File the bug in the gutsy-backports project.
<LaserJock> "what can be done by rebuild from source" is different than "building with the archive and making everything happy"
<freakabcd> ok, cool. i will mess with it tonight.
<freakabcd> i should setup a build environment, right?
<jdong> pbuilder
<jdong> slomo!!!! Just the developer I needed to speak to :)
<freakabcd> i finally managed to free some space. about 2G should be enough, right?
<jdong> (not really, just trying to scare you)
<jdong> freakabcd: octave's big, isn't it?
<jdong> when you add in the build-deps
<freakabcd> lol, no. i meant for the pbuilder environment thingy
<freakabcd> i hate building atlas. that thing compiles for years
<jdong> freakabcd: pbuilder's base.tgz for hardy takes like 50MB
<jdong> freakabcd: the problem is that the unpacked build environment is the size of apt-get build-dep octave plus a bit more
<jdong> and unless you have magical space (i.e. tmpfs) it won't be happy with 2GB most likely
<freakabcd> jdong, what if i have the _binary_ deps installed and the deps_dev packages installed too?
<freakabcd> i won;t need to rebuild the deps from src, right?
<LaserJock> no
<LaserJock> but you want a pbuilder for that
<jdong> freakabcd: pbuilder is a self-isolated environment
<jdong> freakabcd: what you have installed in your main system is irrelevant
<jdong> freakabcd: pbuilder will make a temporary chroot and bootstrap it, and install all build-deps via apt-get in that environment, then destory it once it's done building
<LaserJock> jdong: unless it's maybe Windows, I've not seen anybody run pbuilder off of Windows ;-)
<freakabcd> lol LaserJock
<LaserJock> I gotta run for a bit
<LaserJock> bbl
<jdong> LaserJock: haha cygwinbuntu? :D
<LaserJock> lol
<freakabcd> jdong, damn. so i need a lot more than 2G for a base-system + installing octave deps, then compiling octave-3.0
<freakabcd> thats what you are saying, right
<freakabcd> ?
<jdong> freakabcd: it would seem that way in my humble opinion
<jdong> freakabcd: do you have a large RAM+swap you're not using?
<freakabcd> ok, i'll try to free up more space tonight.
 * jdong puts on his hack hat
<freakabcd> i've got a 2G swap and 1.25G RAM. and 2G free space at the moment. if my simple calculations are correct i will be around 6G free hdd space
<jdong> :)
<jdong> it looks like unionfs hacking time ;-)
<jdong> stitch all your random free space together!
<jdong> frankenstein mountpoint
<StevenK> jdong: So unionfs doesn't work because it needs hundred year old bolts?
<freakabcd> lol, frankenspace
<jdong> StevenK: is that why frankenstein failed?
<StevenK> Hah
<jdong> :)
<gQuigs> can I confirm my own needs-packaging bug (185804) or does it need something else?
<gQuigs> https://bugs.launchpad.net/ubuntu/+bug/185804
<ubotu> Launchpad bug 185804 in ubuntu "[needs-packaging] BadRAM Linux Kernel Patch" [Undecided,New]
<LucidFox> gQuigs> triaged
<ScottK> imbrandon: How did the merge look?
<gQuigs> thanks LucidFox
<imbrandon> ScottK: looks fine, should have it uploaded here very shortly
<ScottK> imbrandon: Thanks.
<warp10> Heya all
<Aloha> warp10, hi
<warp10> Hi Aloha
<freakabcd> guys, can someone check libsuitesparse in hardy? I'm still on gutsy and had libsuitesparse installed before. now, i tried to install libumfpack and it conflicted with some files from libsuitesparse (amd)
<freakabcd> i don;t much care about this problem, but i thought it must be checked in hardy. why doesn;t just libsuitesparse install libumfpack?
<freakabcd> since it is supposed to be providing umfpack
<minghua> freakabcd: Why do you think it's a problem?  AFAIR libsuitesparse _should_ conflict with libumfpack.
<freakabcd> really? why would that be? also why would it tell me during the installation phase that it conflicts?
<freakabcd> it should have known that once i selected the package in synaptic
<LucidFox> How do I stop CDBS from turning debian/changelog files into symlinks in dependent packages?
<freakabcd> minghua, would you be able to tell me how much b/w will be consumed for me to setup a pbuilder env?
<minghua> freakabcd: I only have hardy here.  And it seems there is simply no libumfpack4 in hardy.  I'm checking the situation in gutsy.
<minghua> freakabcd: As for the bandwidth question, I don't really know.  For a minimal pbuilder it shouldn't be much, but you can't do much about the pbuilder either.
<minghua> freakabcd: Yes, there is a bug in gutsy's libsuitesparse package, it should Conflict and Replace libumfpack4 but doesn't.
<ScottK2> LucidFox: You don't
<minghua> freakabcd: Actually, there is bug 144171.
<ubotu> Launchpad bug 144171 in suitesparse "package libsuitesparse 3.0.0-3 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/144171
<ScottK2> LucidFox: This is a feature of Ubuntu's cdbs that Linitian isn't aware of.
<LucidFox> so I should add a Lintian override?
<LucidFox> or just leave it alone?
<minghua> What am I suppose to do with the bug?  It's fixed in hardy.  Just label it "Fix released"?
<LucidFox> minghua> yes
<ScottK2> LucidFox: I'd file a bug against lintian.
<Aloha> if i rename postinst.ex to postinst does it automatically use it in the package or do i need to add a line somewhere?
 * minghua reads the bug again and decides to mark it incomplete because the report didn't say why it failed to install...
<minghua> Aloha: It's automatic.
<Aloha> minghua, thnx
<minghua> Or perhaps, it's automatic if you use debhelper/CDBS/etc.
<Aloha> is there a way to interactively edit the changelog?
<minghua> dch/debchangelog
<minghua> debchange*
<ScottK2> minghua: It's automatic for cdbs.  For debhelper you need to call (I think it's) dh_installinit in debian/rules.
<minghua> ScottK2: Are you sure?  It's postinst, not init script.  I think either dh_control or dh_installdeb deals with postinst.  Both of which should be mandatory.
<ScottK> minghua: Sorry.
<ScottK> It's almost 3AM here.
<minghua> ScottK: :-)  It's dh_installdeb BTW.
<ScottK> I think it's automatic then.
<ScottK> Ah.
<minghua> Also, there is no dh_control, only dh_gencontrol.
<freakabcd> minghua, so on gutsy. i just installed pbuilder.
<freakabcd> to create the environment, i just go: pbuilder --create ?
<minghua> freakabcd: Pretty much.  There are some configurations you may want to set, though.  I am not really an expert on pbuilder creation.
<freakabcd> minghua, where will this env be stored on my computer?
<freakabcd> well, it will be persistent, right? i don;t want to do this every time i try to test out building new src packages
<minghua> freakabcd: ~/.pbuilderrc.  You should read pbuilder(8) man page first.
<slytherin> Hi all. Can anyone point me to nautilus extension library api docs?
<techno_freak> slytherin, i tested that package and it messed up things, i had to reinstall nautilus
<slytherin> techno_freak: There was no need to reinstall. You just had to remove the package. :-)
<techno_freak> i made a stupid mistake of saving the error message there itself, i deleted the image without noting it
<slytherin> techno_freak: I mean the open-terminal package
<techno_freak> slytherin, oh, i just did apt-get install --reinstall nautilus
<Aloha> does MOTU add packages to universe that are created by LoCo teams?
<superm1> persia, how verbose are you setting your lintian?  I set it to what you had mentioned to me some time back in my bashrc, but still seem to not be catching things you are catching
<wallyweek> hi folks! :)
<\sh> moins
<Kmos> superm1: are you using lintian -ivI ?
<vemon> is there and example for packaging .desktop files?
<Kmos> vemon: yes..
<Kmos> !packaging | vemon
<ubotu> vemon: The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
<wallyweek> I've added a watch file to sdlmame, I think it could receive advocation now, could anyone please have a look at it? http://revu.ubuntuwire.com/details.py?package=sdlmame
<\sh> minghua, ping
<vemon> Kmos, the packaging guide has a chapter of packaging desktop files for KDE apps but does that also apply for Gnome applications?
<\sh> minghua, bug #185653 what do you think about the idea in my comment?
<ubotu> Launchpad bug 185653 in octave3.0 "[MoM SYNC] octave3.0 3.0.0-1" [Undecided,Incomplete] https://launchpad.net/bugs/185653
<vemon> and is there a "cdbs way" to do it?
<\sh> moins raphink :)
<vemon> like just adding the file to say... debian/desktop.files
 * wallyweek feels downhearted as sdlmame is in revu since last february and still can't find his way to multiverse :(
<Kmos> vemon: cdbs do it automatically, catches for .desktop files
<raphink> hi \sh
<Kmos> vemon: https://wiki.ubuntu.com/PackagingGuide/SupplementaryFiles
<raphink> what's up \sh?
<vemon> Kmos, so if the .desktop files are in the root of the package they are installed? do i need a specific cdbs import/include for this?
<Kmos> vemon: no, you don't.. but try to learn cdbs manual..
<Kmos> !cdbs | vemon
<ubotu> Sorry, I don't know anything about cdbs - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<slytherin> is it ok to full fix fro a bug from upstream svn?
<vemon> Kmos, thanksfor the SuppFiles -link! haven't seen that page before
<raphink> slytherin: how do you mean?
<slytherin> raphink: I mean I check the SVN diff and create a patch for those fixes in Ubuntu package.
<raphink> yes it's ok slytherin, as long as  you include the patch properly
<\sh> raphink, waiting to start my new job :) what about you still happy at your place?
<raphink> using dpath, quilt or cdbs's simple-patchsys
<raphink> \sh sure :)
<raphink> I'm fine, still having fun
<raphink> there's tons of things to do here :)
<vemon> Kmos, the functionality i'm looking for seems to be in gnome.mk. thanks again!
<raphink> and I'm taking a week of vacation in the moutains in family next week :)
<slytherin> raphink: The fixes are just few lines. So it will be fine. There is a bug fixed in SVN, but the fix for that touches many files so I am not pulling that.
<raphink> slytherin: although it might sometimes be worth considering a full upgrade of the package if a good amount of fixes were added
<raphink> slytherin: ok
<raphink> slytherin: if you know exactly the few lines to patch, then create a patch just for that
<raphink> slytherin: just keep in mind that each patch that is added has to be maintained/merged in the future
<raphink> and that adding a patch system to a pacakge if it doesn't exist yet makes it harder to maintain
<slytherin> raphink: It is already using cdbs patch system. So that is not a problem. The bug for which I am pulling in the fix from SVN makes the package unusable in hardy. That's why this urgency. I will send email to maintainer asking when he plan to do new release.
<Kano> hi, did openscenegraph compile with libxine-dev?
<raphink> slytherin: in this case, go for it :)
<Kano> i dont see an updated package yet...
<raphink> \sh what is your new job?
<\sh> raphink, building a new datacenter infrastructure :)
<raphink> ah nice :)
<raphink> what tools are you using this time?
<minghua> \sh: Commented on bug #185653.
<ubotu> Launchpad bug 185653 in octave3.0 "[MoM SYNC] octave3.0 3.0.0-1" [Undecided,Incomplete] https://launchpad.net/bugs/185653
 * wallyweek is not away, it's only unable to tell this stupid online irc client not to disconnect him 
<raphink> wallyweek: make a cron to wake up your irc client every 5 minutes? ;)
<wallyweek> raphink: that would be good but I'm on mibbit web client as proxy doesn't allow irc protocol at work :(
<Kano> hmm, debian maintainers really skip always needed builddep for media players...
<Kano> even when i mail em
<raphink> wallyweek: how about using a transport agent with a jabber client or so?
<\sh> minghua, there is a mistake in your comment ... Package: octave3.0 \n Provides:  Provides: octave,octave2.9 \n Replaces: octave (<= 2.0.16-2),octave2.9 \n Conflicts: octave (<= 2.0.16-2),octave2.9
<wallyweek> raphink: I've no practice with such a thing, I'll have some googling about it, thanks! :)
<\sh> minghua, and I would like to recheck that octave3.0 will not break any other octave using sources...
<raphink> wallyweek: get a jabber client (Kopete, Pidgin, etc.)
<raphink> wallyweek: get a jabber account on a server with IRC agents (jabber.fr does that for example)
<slytherin> Kano: How come the packages compile then?
<minghua> \sh: Which part of my comment is mistaken?
<Kano> slytherin: they work but you dont have full features
<Kano> like missing output plugins for mplayer
<slytherin> Kano: Then upstream authors make the dependencies essential instead of optional
<Kano> you miss dxr3    DXR3/H+ video out when you forget em8300-headers
<\sh> minghua, that they are parallel installable..but I should read all comments...sry
<Kano> slytherin: but even in the description of the package is DXR3 support mentioned...
<minghua> \sh: Good that we agree, then. :-)
<\sh> minghua, well, as I said, I'm doing some tests now: 1. upgrade tests 2. rebuilding all sources which are directly build-depending on octave2.9/octave , against octave3.0 and 3. prepare a list of packages which are depending indirectly on octave2.9
<minghua> \sh: Sounds a good plan.  Also, according to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457675 all but one package have migrated to octave3.0 in Debian.
<ubotu> Debian bug 457675 in octave2.9 "RM: octave2.9 -- RoM; superseded by octave3.0" [Normal,Open]
<minghua> \sh: Altough there is probably a chicken an egg problem in hardy.  We can't start migration without octave3.0 in archive, but once we starts octave metapackage will be broken.
<\sh> minghua, this is not a problem...
<minghua> \sh: So it seems we need to get it done altogether.
<\sh> minghua, as I'm preparing the build-dep list and rdepends list I can prepare all packages to use octave3.0/octave and push a rebuild on our buildds
<\sh> minghua, just like libgif transition ;)
<minghua> \sh: Good, good, go ahead and good luck. :-)
<\sh> minghua, but now: just a bunch of packages at one time :)
<slytherin> I am getting this error when trying to build a package. - aclocal: configure.in: 18: macro `AM_PROG_LIBTOOL' not found in library. Can anyone help?
<TheMuso> slytherin: You need to install libtool
<DaveMorris> persia: Thanks for reviewing the package, couple of questions.  What am I patching in the bare diff.gz that should be moved to debian/patches?
<slytherin> TheMuso: Why was it not needed before?
<TheMuso> slytherin: What do you mean why was it not needed before?
<slytherin> TheMuso: I am modifying existing package
<TheMuso> slytherin: And? Sorry I wasn't reading prior IRC conversations, I just saw your error.
<slytherin> TheMuso: Yes that is the only information I have to give. I am getting this error when I am trying to fix a bug in nautilus-open-terminal
<TheMuso> slytherin: What did you run? Autogen?
<minghua> slytherin: What did you change?  Did you change configure.in or Makefile.ams?
<TheMuso> autogen.sh even
<slytherin> minghua: TheMuso: I changed configure.in
<TheMuso> slytherin: Right, in that case, you need to regenerate the configure script .Usually packages have a build.sh, or autogen.sh to do this.
<TheMuso> Thats when you need libtool and other bits like autoconf/automake.
<jonnymind_work> Hello
<slytherin> TheMuso: So should I simply add libtool to build dependency? or should I generate configure script locally (outside pbuilder)
<Kano> i would do all steps in the package itself
<Kano> do not patch added files as those are with wrong permissions
<Kano> that will not work inside pbuilder
<jonnymind_work> ScottK has recently declared http://revu.tauware.de/details.py?package=falconpl (Bug 174470) as clear from conflicts. I am searching for MOTUs willing to review it.
<ubotu> Launchpad bug 174470 in ubuntu "[needs-packaging] Falcon Programming Language" [Wishlist,In progress] https://launchpad.net/bugs/174470
<TheMuso> slytherin: The approach you take depends on how the package gets built, whether it uses a patch system, and whether extra patching is part of the package diff already.
<slytherin> TheMuso: it alread uses cdbs patch system. I had modified both configure.in and configure to change version of nautilus. I am wondering if I should drop this change since in hardy anyway I will get latest version.
<TheMuso> slytherin: Yeah cdbs does replace those files.
<emgent> moin
<pochu> hey there!
<effie_jayx> pochu,  congrats on your MOTU aceptance
<pochu> thanks effie_jayx :) you're a bit late, btw ;)
<effie_jayx> pochu,  I know, I just read it on the monthly report
<pochu> Ah
<persia> superm1: I use lintian -iIv and linda -v -f long -t E,I,W,X, but those are only a subset of my review checks.
<lifeless> so, I don't upload enough
<persia> DaveMorris: lsdiff -z file.diff.gz will give you a list
<lifeless> whats the current syntax for closing an lp bug in changelog? (closes: or lp: or ... ?)
<persia> lifeless: I like (LP: #nnnnnn)
<persia> lifeless: Further, I don't like "closes:" as even if someone does the magic to make it work with changes-closes-bug, it looks too similar to Debian.
<broonie> persia: There was some talk of an overarching, integrated closes: syntax that everyone could use.
<persia> broonie: That sounds really nice.  I just prefer to avoid confusion until then.  One of the frustrating bits about using LP is that there are frequently closed bugs that appear as open, although they were fixed in Debian, and since pulled into Ubuntu.  A unified syntax should also help reduce those.
<slytherin> persia: FYI ... Yesterday's fix to nautilus-open-terminal was not good enough. It was crashing nautilus. :-( I have ported fix from SVN in form of a patch. I will upload the debdiff with sufficient testing.
<persia> slytherin: Thanks for taking the extra steps to make it right :)
<amarillion> norsetto, thanks for your comments on speed-game. However, I think you're wrong regarding the use of /var/games
<amarillion> I think hiscore files are supposed to be in /var/games
 * persia confirms that hiscore files are supposed to be in /var/games, but notes that they should not be included in the package, as that resets them on each upgrade: better to touch the file if it doesn't previously exist in the postinst
<amarillion> yeah right, that is what my package does atm
<amarillion> This was the comment: "4) The use of /var/games/speed-game.rec to save hiscores doesnât seem appropriate. It would be better to save it in a local file owned by the user (ie. in a dotted file in $HOME). Note that this would not need to be removed by a postrm script."
<persia> amarillion: I disagree with that.  Especially so as it breaks competitive scoring for multiuser systems, defeats the entire point of setting score files as root.games 664, and differs from most other games in the distribution.
<amarillion> ok, that's what I thought
<persia> amarillion: Cite Debian Policy 11.11 in your rebuttal, if you like
<DaveMorris> persia: did you catch my question?
<persia> DaveMorris: Yep.  Did you see my answer?
<DaveMorris> no I had gone, let me see the logs
<DaveMorris> !logs
<ubotu> Channel logs can be found at http://irclogs.ubuntu.com/ - Logs for LoCo channels are at http://logs.ubuntu-eu.org/freenode/ - See also Â« /msg ubotu ircstats Â»
<persia> (lsdiff -z diff.gz lists all files adjusted)
<DaveMorris> persia: I can only see files in /debian adjusted, no others
 * persia looks again
<persia> DaveMorris: Sorry about that.  Obviously this is a case of me commenting before being fully awake.  I'm still not advocating because of 7, and would really like to see 4 & 5.  #6 was done while I was commenting.  #2 is upstream, and #3 is just a preference.
<DaveMorris> 3 will get better when upstream fix alot of the things I'm patching, for instance the make clean rules
<DaveMorris> done 4, 7 just about to do 5
<persia> DaveMorris: OK.  If you expect it to get nice and short again, doesn't make sense to change it.
<DaveMorris> yeah the big problem is you can't patch a make clean rule
<DaveMorris> as patch are removed before calling make clean
<persia> DaveMorris: There are ways around that, but most of them are even uglier :)
<DaveMorris> I assume you agree that a watch file won't work with the way they currently release the source?
<persia> DaveMorris: Yes.  You might be able to craft a working get-orig-source though, which would help for the hardy+1 merge cycle.
<DaveMorris> tbh for hardy +1 I will have hopefully got them to do a new release which can have a watch file etc
<persia> DaveMorris: That works too.  I'm mostly worried because about 60% of REVU packages don't get updated in the following release without some sort of automated mechanism.  If you're committing to getting it fixed, it's less of a worry.
<DaveMorris> persia I use it as part of the research we do at work.  So it's in my interest as well
<DaveMorris> persia: http://pastebin.ca/871916 that a correct copyright file now?
<persia> DaveMorris: No.  Still doesn't say who holds copyright.
<persia> To me, there are six interesting things that are kept in Debian copyright, as follows:
<persia> 1) The person who created the packaging, and the date they did that.  This isn't a legal requirement, but helps identify a person who may have a relation with upstream.
<persia> 2) The location from which the updated source can be downloaded (although I also like to see this in a watch file or get-orig-source rule)
<persia> 3) Any licensing for the packaging.  Typically this is the same as for the package, unless the packaging was copied from another package with a more restrictive license.
<persia> 4) The names of any upstream authors.  This is mostly to give credit where it is due.
<persia> Beyond that, we have two legal requirements, as follows:
<persia> 5) Identification of the copyright holder(s).  These are the people ultimately responsible for the licensing of the work, although they may have granted the right to sublicense to other parties.
<persia> 6) Description of the license under which the work is being distributed.  This is typically the full text of the license, but may be a shorter form for some common licenses (e.g. GPK, LGPL, etc.).
<wallyweek> persia: why not publish this on the packaging guide? it would be of great help
<persia> wallyweek: Good idea.  Would you might doing a copy & paste with appropriate spelling and grammar corrections?
<persia> s/might/mind/
<wallyweek> persia: I would if I was able to... I'm not english mother tongue and I think I can't update the web page
<DaveMorris> persia: something like this then http://pastebin.ca/871930
<persia> wallyweek: If you have an LP account, access to wiki.ubuntu.com is really easy, and shouldn't require any human assistance.  Don't worry about the spelling anf grammar too much: if you pull out the obvious typos, it would be great :)
<amarillion> According to http://doc.ubuntu.com/ubuntu/packagingguide/C/sect-contributing.html, you have to do a bug report first
<amarillion> sounds like a good way for your contribution to land in a black hole
<persia> DaveMorris: From a cursory look through the output of `grep -ri copyright *`, it looks about right.  Best to take a closer look to make sure that covers everything.
<wallyweek> amarillion: I see. I thought packaging guide was motu's responsibility :(
<amarillion> I've got a lot of notes that I could add too... but it seems the process is very complicated
<persia> wallyweek: Well, keeping it in shape is the responsibility of all developers, whether Contributors, MOTU, or core.  MOTU tend to be the ones who work on it most, but that's just coincidence.
<warp10> persia: May I suggest to add a link to http://wiki.debian.org/DFSGLicenses too? I found that page essential when tackling copyright and license issues.
<amarillion> Who is writing the packaging guide actually?
<persia> amarillion: That's a great resource!  Nice find.  Please do.
<wallyweek> sorry! there's been come connection error :(
<persia> amarillion: It's a collaborative work.  Most of the transition from the packaging-guide package to the wiki was done by Daniel, so his name appears in the history a lot, but there were many contributors to the content.
<amarillion> Yeah, but it's not really a wiki, is it? At least I can't edit it directly
<persia> amarillion: Erm.  Are you looking at the latest packaging guide?
<persia> !packaging
<ubotu> The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
<DigGo> hello
<DigGo> someone know how to deupgrade to gutsy ? now i'm in hardy.
<Hobbsee> DigGo: reinstall.
<DigGo> argh
<persia> DigGo: You likely will find a better response in #ubuntu+1.  Hobbsee is likely right though.
<DigGo> ok bye
 * Hobbsee sighs
<Hobbsee> don't these people ever learn?
<persia> Hobbsee: One-by-one.  How long does it take to count to 10 million?
<amarillion> persia, I see, I was looking at http://doc.ubuntu.com/ubuntu/packagingguide/C/
<Hobbsee> persia: one, two, skip a few, 9 999 999, 10 million
<persia> amarillion: That's the old one.  I'm not sure if whether it was being removed was ever resolved.
<persia> Hobbsee: it's the "skip a few" that is time consuming and repetitious :)
<Hobbsee> hehe
<amarillion> I think it should be removed, it can only lead to confusion. At least I was certainly confused by it.
<wallyweek> persia, amarillion: just tried, I can't edit wiki pages :(
<persia> wallyweek: Are you logged into the wiki?
<wallyweek> persia: yes
 * wallyweek is copying persia's suggestions on his desktop for later use ;)
<persia> wallyweek: You're logged into wiki.ubuntu.com, and the edit button doesn't work?
 * persia doesn't understand, and hopes someone with deeper wiki-fu will explain.
<DaveMorris> persia: Do I need the copyright of whats in the source package in the copyright file, or from the source files which make up the debs. (did that make sense?)
<persia> DaveMorris: Both, really.  You need to reference the copyright and licensing for everything that is distributed (source and binary).
<DaveMorris> ok, cos a lot of whats in the source package doesn't actually get built
<wallyweek> persia: ok, it was my fault... I logged in, press browser back button and forgot to refresh :(
<wallyweek> persia: now edit is enabled...
<persia> DaveMorris: Sure, but people can download it with apt-get source, so it is still distributed, even if not in the binary.
<wallyweek> persia: ...but connection error cleaned all previous messages... I lost them :(
<persia> wallyweek: http://irclogs.ubuntu.com/2008/01/25/%23ubuntu-motu.html or http://irclogs.ubuntu.com/2008/01/25/%23ubuntu-motu.txt might be helpful :)
<wallyweek> persia: good! thanks! :)
<amarillion> persia, I filed a bug for removal of the old packaging guide: https://bugs.edge.launchpad.net/ubuntu-doc/+bug/185899
<ubotu> Launchpad bug 185899 in ubuntu-doc "please remove old packaging guide" [Undecided,New]
<persia> amarillion: That's a great way to get the discussion going again.  Thanks.
<amarillion> If you look at that, there are actually a lot of bugs in the ubuntu-doc project filed for small changes to the ubuntu packaging guide. If those people had known that they could edit the wiki directly, there was no need to file a bug in the first place.
<amarillion> Like e.g. https://bugs.edge.launchpad.net/ubuntu-doc/+bug/158998
<ubotu> Launchpad bug 158998 in ubuntu-doc "Packaging guide: 822-date command deprecated, should use "date -R"" [Undecided,Confirmed]
<amarillion> I mean there really shouldn't be a need to go through the whole bug reporting & triaging process just for that tiny change
<persia> amarillion: It only moved to the wiki recently.  It used to be a source package.  If you want to improve things, integrating all those changes would be very helpful.
<amarillion> Yeah, sounds like a nice project. I'm going to work on that.
<persia> amarillion: Thanks.
<techno_freak> ok guys.. ciao..
<mruiz> hi all
<persia> slytherin: Re: lucene2.  I just had a report that it built with icedtea.  Did you have something that worked with gcj, or would this need extra care to be in universe (assuming the xhtml DTD issue gets resolved)?
<wallyweek> amarillion, persia: edit done, suggestion added to https://wiki.ubuntu.com/PackagingGuide/PackagingOverview#head-4032f87b77123c6c051910dbc3383cb6898506f6
<wallyweek> persia: are you aware when will next revu day start?
<persia> wallyweek: Nitpick: you've listed six interesting things, but the code section above only has five stanzas, which may lead to confusion.
<persia> wallyweek: 2008 28 January 0:00 UTC+14
<amarillion> wallyweek, do you understand the structure of the wiki?
<persia> wallyweek: Also, consider putting that in https://wiki.ubuntu.com/PackagingGuide/Basic#Copyright instead, so as to make the overview easier to read.
<amarillion> If you try to edit the main page, you just see a bunch of "Include" lines
<wallyweek> persia: thanks! is there a way to specially point out a package? sdlmame's been on revu for nearly one year, I would like to see in hardy
<amarillion> and then I can't find the actual page you need to edit
<wallyweek> amarillion, persia: unfortunately it's the first time I edit a wiki page :(
<amarillion> Not for me, but this is the most complicated one I've seen thus far
<persia> wallyweek: Just push advertisements, and hope someone is interested.  A year is a really long time: it's usually only a couple of months during REVU season.
<persia> amarillion: Try looking at the raw text (under more actions) to see what page is being included.  Then, manually enter that URL, and use Edit.
<wallyweek> persia: I saved your messages, I'll be back on edit the wiki asap
<wallyweek> persia: keep on advertising makes me feel like a channel pest... :o
<wallyweek> persia: or I should assume that noone will be annoyed by that?
<wallyweek> s/noone/no one
<persia> wallyweek: Understood.  I'm not sure what advice to give.  Eventually, your package should reach the top, and get reviewed.  If there are no more issues, it gets advocated.  I'm not sure how it kept getting rejected for an entire year unless there were gaps.
<persia> Also, I believe the only preference anyone ever expressed was to restrict advertisements to less than once every 24 hours.
<persia> wallyweek: amarillion: If either of you wants to update the maintainer scripts bit, http://women.debian.org/wiki/English/MaintainerScripts is an excellent reference.
<txwikinger> Is there motu Q&A today?
<persia> txwikinger: It's Friday, but feel free to beat the crowd and ask a question now :)
<wallyweek> persia: I must admit first uploads needed lot of work, but it should be ready for advocates now
<txwikinger> persia: :D
<txwikinger> I have some questions to interdiff
<persia> ...
<txwikinger> I am getting confused with the orig.tar
<txwikinger> basically what I am doing is having  a new orig.tar for the new release
<txwikinger> does the interdiff take account for that?
<wallyweek> persia: reference saved! :D
<persia> txwikinger: An interdiff is used to track the differences between the patches.  It completely ignores the orig.tar.gz (as we know it has changed).
<txwikinger> And if there aren't any patches?
<persia> txwikinger: So, it compares the two diff.gz files, and shows how they differ.  This allows the old diff.gz to be patched to generate the new diff.gz.
<persia> txwikinger: There is always at least debian/changelog, debian/copyright, debian/control, and debian/rules.
<txwikinger> well ok yes
<txwikinger> but if they would be the same in the old and the new release (changelog wouldn't)
<persia> Remember, diff.gz is just a patch to generate a debian-format source from the upstream source.
<txwikinger> yes I understand that
<persia> txwikinger: Exactly, so the interdiff tracks the differences between the patches.
 * persia builds a simple example
<txwikinger> So.. if would have to provide the orig.tar in addition anyway
<txwikinger> s/if/I/
<wallyweek> I'm leaving... thanks everyone! :
<wallyweek> :)
<\sh> wow...I think I'm through
 * txwikinger wonders what \sh is doing
<\sh> txwikinger, checking if octave3.0 is the right thing for hardy ;)
<txwikinger> )
<txwikinger> :)
<persia> txwikinger: You wouldn't provide the orig.tar.gz.  Upstream generally does that, and you use a watch file to reference it.  Where this doesn't work, you construct a get-orig-source in debian/rules
<txwikinger> persia: Well in that particular package there is a problem with that
<txwikinger> that was my next question anyway
<txwikinger> I need to take two tar files and merge them together that the package builds
<txwikinger> (two tar files from upstream)
<persia> txwikinger: Are you sure you don't want two source packages?
<txwikinger> well it doesn't build separately
<txwikinger> otherwise I wouldn't have a problem.... I think I create separate binaries anyway from it
<txwikinger> Yes the control file has two binaries
<txwikinger> which correspond to the two source tars
<persia> txwikinger: http://paste.ubuntu.com/3864/ has a small file, with an old diff, a new diff, and an interdiff.  Feel free to grab them and play with interdiff and combinediff to see how it works.
<txwikinger> cool thanks
<persia> txwikinger: Regarding your source issues, do both sources fail to build independently?  If one builds on it's own, and the other requires the first, then you just have a build-dependency.
<txwikinger> I think your explanation already helped me, but I will play with it.. it is always more illustrative
<txwikinger> well.. the main package fails to build if the directory of the themes is missing
<txwikinger> which is exactly the source tar of the second package
<persia> txwikinger: Can the themes build without the main package?
<txwikinger> I have not tried that.. it would have to be newly packaged then since there is no debian directory existing for it
<txwikinger> however, it still would not make the main package build
<persia> txwikinger: Best practice is to have one source package per upstream source package, unless there are really strong reasons not to do that.  Give it a shot :)
<persia> txwikinger: Why not?
<txwikinger> The build system expects the theme sources in that particular directory
<txwikinger> If it should work, the build system would have to be changed
<persia> txwikinger: That sounds like a build system in need of patching.
<txwikinger> and it might need to find the .h files somewhere too
<txwikinger> so that would probably require not only the binary theme file to be installed, but also a theme-dev file
<persia> txwikinger: If it needs .h files provided by another source, that other source should be packaged as a library, so the .h files would be in /usr/include/
<txwikinger> yes.. that's what I think
<txwikinger> I totally agree with you that it should be done that way
<txwikinger> unfortunately it is far more work
<persia> txwikinger: Yep.  That's why packages get maintainers.  If it were easy, people would just download the upstream releases, and it would work.  Of course, in cases where this is done, it tends to lead to completely reinstalling the system every six months or so, and wondering why it gets progressively slower in the meantime.
<txwikinger> :D
<txwikinger> well.. it needs to be rolled into debian too when I have done it
<txwikinger> Does this go through revu then?
<txwikinger> or just via the bug since it is a new release/package split
<persia> txwikinger: Which package?  If Debian is already doing it in an annoying manner, it may not be worth splitting the source.  On the other hand, if the new upstream breaks the old way of doing things, yes, the extra package would go through REVU.
<txwikinger> persia: No.. the source was split at the original source
<txwikinger> debian still has the old version
<txwikinger> and without the new package, the main package is broken.. because it depends on it
<persia> txwikinger: New upstream split for the new upstream version?  In that case, you do want a new source package, and you do want to upload to REVU.
<txwikinger> ok
<persia> (and you want to report in your bug not to upgrade until the REVU package is in, as otherwise it creates a FTBFS bug).
<txwikinger> well.. I think the old package has an FTBFS already since that's how I found the issue
<persia> txwikinger: The question you might want to ask is: is the package update important enough that it's worth trying to get all that done in the next three weeks?  (the answer may be yes, but it's worth asking).
<persia> txwikinger: Ah.  If it's already broken, then go for it :)
<txwikinger> well.. the new release is the first release candidate
<txwikinger> the old release is a very old alpha or beta release
<txwikinger> It is a game... so I don't know if it is worthy due to the time schedule
<txwikinger> maybe other causes are more important
<persia> txwikinger: Maybe you want to check with upstream then: if a release is coming soon, you might want to target that rather than the RC (although you would need to apply for an FFe in that case)
<txwikinger> FFe?
<persia> txwikinger: FeatureFreeze exception
<txwikinger> ah righh
<txwikinger> right
<slytherin> persia: there? I was away for meeting.
<persia> slytherin: Even when I'm not, I read all the backscroll
<DaveMorris> persia: I've fixed those issues, there were quite a lot of copyright holders actually.
<slytherin> persia: The issue with lucene2 has nothing to do with 'which JDK' The libraries build with even GCJ. I had disabled unit tests and tried building. If we get the DTD issue resolved then we can build with GCJ and promote it to universe.
<persia> DaveMorris: Are they all covered by the same license?  When there are lots of copyright holders, it sometimes means you need to do a deeper investigation into licensing.
<DaveMorris> I'll double check
<DaveMorris> they've included a copy of scons in the original source package, what do I do about that licence?
<persia> slytherin: Right.  I remembered the DTD issue, but had someone poke me that it worked with icedtea, and couldn't remember if you already had a GCJ patch.  If it's on the way to universe, them I've very excited :)
<slytherin> persia: One more trial is needed just to make sure that unit tests don't cause any trouble.
<persia> slytherin: Apologies.  I seem to be catching you too late.  Would you mind updating bug #185917?
<ubotu> Launchpad bug 185917 in lucene2 "lucene2 jdk dependence" [Undecided,New] https://launchpad.net/bugs/185917
<slytherin> persia: I will update that bug. Should I assign it to myself?
<persia> slytherin: If you've a solution prepared, sure.  Am I correct that you're planning to fix it in Debian and sync?
 * persia unsubscribes the sponsors, preferring gcj to icedtea, and the current patch not fixing the FTBFS
<slytherin> persia: No plan for Debian. In fact my explanation for w3c-dtd-xhtml bug seems not to be very useful to Debian developers. If nothing happens over weekend I will fix both bugs in Ubuntu only.
<persia> slytherin: Ah.  Right.  Arch-all not actually being built on the buildds and all.  Maybe the archive-rebuild scripts will catch it eventually, and they'll pull the patch.
<man-di> slytherin: I hope to find the time on sunday to write some mails about w3c-dtd-xhtml
<slytherin> persia: Looks like my last reply didn't reach Debain BTS. I will drop a reply tomorrow again, and see if it helps.
<slytherin> man-di: Thanks. :-)
 * slytherin wishes there was a 'Depends' field for bugs in launchpad
<persia> slytherin: It's been discussed, but there are too many different relationships.  If you write "bug #nnnnnn" in a comment, Malone replaces with a hyperlink to the bug to allow manual description of bug relationships.
<slytherin> persia: That will do for now.
<ScottK> persia: It's still a regression from bugzilla.
<persia> ScottK: I refuse to either defend Bugzilla's broken bug relationship system or Malone's lack of any relationship mapping.
<persia> s/either defend/defend either/
<ScottK2> OK.  It may or may not be true, but I find Malone's also affects substantially inferior to bugzilla's depency relationships.  Sure, it could be better, but at least it's there.
<persia> I consider "Also affects" completely different than bugzilla's dependency mappings.
<Hobbsee> [00:50] * Hobbsee notes that adding stuff in here is classed as contributing to ubuntu development, which is one of the things that kmos has been asked not to do.
<Hobbsee> [00:50] * Hobbsee therefore will prohibit him from doing so.
<amarillion> doko, are you around?
<amarillion> I've got some java packaging questions
<persia> amarillion: There are a number of people who can answer Java packaging questions.  Best to just ask.
<amarillion> sure
<amarillion> I would like to package cytoscape
<amarillion> http://www.cytoscape.org/, it's a scientific package for analyzing networks, mostly genetic networks
<amarillion> The trouble is, it includes a large number of jar files
<amarillion> most of which are not packaged yet either
<persia> amarillion: How does upstream bundle the release package?
<amarillion> As far as I can tell
<amarillion> The jar files are included in the tar.gz
<amarillion> you have to get the sources elsewhere if you want them
<joejaxx> grr i still cannot get pbuilder-dist to not clean the build environment :\
 * persia is not a Java expert and welcomes correction
<DaveMorris> would it be best to package the jars up so other packages could depend on them?  Or is that too much work?
<persia> amarillion: I've seen other packages that fiddle with the classpath to get ant to use the system libraries in preference to the local libraries.
<amarillion> DaveMorris, yeah, that is what I want to do although it would indeed be a  lot of work
<persia> Of course, this means first making sure there are system libraries in all these cases: many Java applications seem to require first importing two or three libraries.
<slytherin> amarillion: Are the jar's very uncommon? May be some of them are already present in Ubuntu.
<amarillion> Some of them are, some of them aren't
<amarillion> I'll list them
<amarillion> there is jdom, junit, jnlp, xerces, getopt, jaxb, batik, giny, colt, coltginy, freehep, piccolo, biojava, looks, glf and more
<LucidFox> Gah! Stupid dh_pysupport :S
<amarillion> jdom is very common but I couldn't find it in the repo
<LucidFox> When there was a single package, it saw and handled Python-Depends for every package.
<amarillion> same for batik
<LucidFox> Now that there are multiple packages, it ignores Python-Depends for all packages but the first one.
<slytherin> amarillion: It is there I am sure. Batik has build failure.
<slytherin> amarillion: I mean jdom is there
<amarillion> slytherin, ok, I thought it must be
<amarillion> what is the name of the package? There is no libjdom-java
<tuxmaniac> LucidFox, have again re-uploaded the package after your comments. Can you please re-review it? this is wrt alliance
<slytherin> amarillion: https://edge.launchpad.net/ubuntu/+source/libjdom-java
<amarillion> Somebody told me in the past that there is a ubuntu-java mailinglist
<persia> tuxmaniac: You'll get the best quality package by having different reviewers, as we all check slightly different things.  Try to find a new reviewer each time, if you can.  Best to just advertise your URL generally.
<tuxmaniac> persia, coolness. here goes my ad. http://revu.tauware.de/details.py?package=alliance
<amarillion> slytherin, oops, my mistake
<rexbron> siretart, I know I have asked about ffmpeg in the past, but what can I do to speed along an update?
<amarillion> synaptic doesn't show it if you search for jdom
<joejaxx> rexbron: :)
<rexbron> joejaxx, I thought I would make it a productive question :)
<joejaxx> rexbron: lol :P
<siretart> rexbron: get sam to revise the altivec patches. What would also help is to review the current patches, and comment them in a form that would be acceptable for upstream inclusion
<slytherin> amarillion: Perhaps you are searching for wrong field. :-)
<jdong> siretart: we plan to include a newer ffmpeg before freezing?
<rexbron> It would be ideal to get a svn pull that is more recent than october...
<DaveMorris> persia: you where right as usual, other licences in there.  I've upload the new version and addressed all the points.
<siretart> jdong: there is a newer ffmpeg in debian/experimental. we could most probably include that into hardy right now
<slytherin> If I attach updated debdiff should I delete old one form the bug?
<siretart> jdong: however I don't have the time to deal with the breakage :(
<rexbron> siretart, I can take a look at the patches, but would be afraid to submit them to the -devel list. I am subscribed to it and they are vicious :P
<persia> DaveMorris: Excellent.  I'm not likely to try that build again soon, but will take at least one more look before the last REVU day.
<siretart> rexbron: you bet
<DaveMorris> the changes won't affect the building :)
<jdong> siretart: sounds good
<siretart> rexbron: still, I don't feel comfortable with both dropping them nor having them around
<jdong> siretart: I'm guessing as always, rebuilding the revdep tree will be necessary?
<siretart> jdong: would you feel comfortable with having ffmpeg updated in hardy, dropping patches from the debian package?
<siretart> jdong: yeah
<jdong> siretart: yeah, if you are comfortable with it, I'm comfortable with the idea
<rexbron> siretart, would it be possible to "start fresh" ie, include a newer version of ffmpeg in paralle and transition packages that need the newer funtionality over to it?
<jdong> siretart: I'm not certain what patches are in the debian package, so I can't comment specifically on dropping those
<slytherin> Can anyone sponsor the latest debdiff attached to bug 185435
<jdong> rexbron: what kind of changes have been made to ffmpeg since the experimental snapshot that are important to you?
<amarillion> so how does a good java package set the classpath? Just hard-code it in a startup wrapper script?
<ubotu> Launchpad bug 185435 in nautilus-open-terminal "nautilus-open-terminal no longer works in Hardy" [Low,Confirmed] https://launchpad.net/bugs/185435
<rexbron> jdong, inclution of MXF container support
<rexbron> so one can playback files created by an HVX200
<jdong> rexbron: interesting....
<jdong> siretart: it doesn't completely sound unreasonable to do an up-to-date SVN checkout does it?
<tuxmaniac> Hope I am not kicked for the repeat post. Can someone please review the package http://revu.tauware.de/details.py?package=alliance
<jdong> (not having looked at the changelog yet...)
 * DaveMorris kicks tuxmaniac
<rexbron> jdong, there also have been patches submitted to the -devel list for the inclution of encoding DVCPRO HD
<rexbron> but those still need work
<ScottK> jdong: It depends on if svn is more or less broken that what's already in experimental.
<siretart> jdong: I'm not comfortable with the idea, since I doubt I have enough time and energy to deal with the breakage
<rexbron> siretart, what about what I suggested?
<siretart> rexbron: you want to maintain 2 different versions of ffmpeg? uuuh
<siretart> no
<jdong> siretart: the package in experimental seems to be around a month old. Are there a lot of people helping QA that?
<rexbron> siretart, that would be part of a migration strategy
<siretart> jdong: I did a rebuild of the revbuilddep tree, and found no regressions. I didn't test the packages, though
<jdong> siretart: ah, ok, looks like you did a lot of work into this already :)
<siretart> yes
<siretart> what would help me most would be people that look at the patches and review and document them
<persia> slytherin: Do you think http://paste.ubuntu.com/3871/ would break anything critical?
<rexbron> siretart, the ones off of debian experimental right?
<slytherin> persia: let me check
<jdong> siretart: was the orig.tar.gz repacked?
<siretart> http://svn.debian.org/viewsvn/pkg-multimedia/experimental/ffmpeg/debian/patches/
<siretart> jdong: yes, using this script: http://svn.debian.org/viewsvn/pkg-multimedia/experimental/ffmpeg/debian/strip.sh?rev=923&view=log
<siretart> http://svn.debian.org/viewsvn/pkg-multimedia/experimental/ffmpeg/debian/strip.sh?rev=923&view=markup
<jdong> siretart: so h.264/mpeg4 are entirely removed, or just their encoders?
<siretart> just the encoders
<jdong> siretart: ok
<slytherin> persia: Looks ok to me. What is this for?
<persia> slytherin: http://www.netbeans.org/issues/show_bug.cgi?id=112679 and http://www.netbeans.org/issues/show_bug.cgi?id=98212
<persia> Thanks for being a second pair of eyes.  I'll go chase rdepends a bit, and might push to 1.2.
<slytherin> persia: Is that fix really needed if netbeans 6.x is going to eventually land in Ubuntu
<persia> slytherin: Well, it's either apply that patch or bundle a special libresolver for netbeans, which would be painful from a support perspective.
<slytherin> persia: Ahh, then it is fine
<persia> Oh, and 6.0.1 :)
<slytherin> persia: can you review the nautilus-open-terminal fix and sponsor it?
<persia> slytherin: I'm going to bed in about 10 minutes.  I'll be reviewing the sponsors queue in 8-10 hours, and will be sure to take a look if it is still there.
<slytherin> persia: Ok. No problem
<persia> (unless this is blocking something else, and you really need it now)
<slytherin> persia: No. It is not blocking anything except the use of extension. :-) But I already have it in my PPA and those who want can use it.
<persia> slytherin: Good to hear.  Thanks.
<LucidFox> poor Kmos :(
<zul> hey ivoks
<ScottK2> LucidFox: I hope your kidding.
<rexbron> Would anyone be able to explain the difference between rpath and runpath?
<LucidFox> well, I don't know what he did...
<wallyweek> persia: just fyi, updates to packaging guide commited: https://wiki.ubuntu.com/PackagingGuide/Basic
<amarillion> Is the new packaging guide only on the wiki, or is it still possible to get it in other formats?
<wallyweek> amarillion: I don't know :( I guess is on the wiki only
<amarillion> It seems like there must be a better way to do that
<slytherin> amarillion: Use httrack to download all the pages
<amarillion> I was more thinking along the lines of docuwiki http://wiki.splitbrain.org/wiki:dokuwiki
<LucidFox> Hmm.
<mok0> What is the tool that syncs packages into a new development branch? What does it do the the changelog entry?
<LucidFox> Apparently, dh_pysupport reads the correct Python-Depends values for all packages, but only correctly substitutes ${python:Depends} for the binary package whose name is the same as the source package
<mok0> My problem is that I now need to update all our local packages to hardy, and I would rather not have to go in and edit debian/hangelog in all of them
<StevenK> mok0: That tool is called "Merge-o-Matic" or MoM
<mok0> StevenK: Is that something that I can run locally?
<james_w> StevenK, I don't think it is that one is it?
<StevenK> mok0: sed -e 's/gutsy/hardy/' < debian/changelog > debian/changelog.new ; mv debian/changelog.new debian/changelog ?
<james_w> mok0, you can do it with dch and a couple of lines of shell.
<mok0> james_w: ok, seems feasible
<LucidFox> StevenK> or sed -e -i 's/gutsy/hardy/' debian/changelog
<LucidFox> :)
<StevenK> Meh :-)
<POX_> LucidFox: no, pysupport is copying Python-Depends in arch all packages
<mok0> LucidFox: that's kinda the dirty solution
<POX_> and adds 2.X in arch any (python extensions)
<POX_> so if you have python-myextension package that needs pygtk module, pysupport will generate Depends with python2.4-pygtk, python2.5-pygtk
<mok0> So, how do people store the source packages? In one big whopping directory?
<POX_> python2.4-pygtk and python2.5-pygtk are virtual packages provided by python-pygtk package
<StevenK> mok0: For me, depends on what I'm doing
<mok0> I guess the easiest would be to have them all in bazaar
<LucidFox> POX> The problem is...
<LucidFox> I have the source package tovid and binary packages tovid, tovidgui, todiscgui and todraw
<amarillion> mok0, I have everything in ~/debs/packagename/packagename-version/
<LucidFox> I inserted debug print into dh_pysupport - it definitely parses Python-Depends for all of them
<LucidFox> but only generates the dependencies for tovid - for others, it's just "python" :.
<mok0> amarillion: I have something similar. I have recently started tracking my packing in git
<POX_> oh, file a bug against python-support then
<POX_> LucidFox: ^^
<amarillion> mok0, do you then just check in the debian directory?
<amarillion> or do you check in the entire source tree?
<mok0> amarillion: no, I am not allowed
<LucidFox> I should first identify why exactly it fails to paste the dependencies into substvars
<mok0> amarillion: I use git_import_dsc
<mok0> amarillion: it keeps the original source on a separate branch
<POX_> LucidFox: dh_pysupport line 104
<mok0> amarillion: which makes it easy to track what you have been doing
<mok0> amarillion: so, that's a separate git repo for every package
<amarillion> oh good idea. I'm going to try that
<mok0> amarillion: you then have to use git-buildpackage instead
<amarillion> is there a nice way to combine that with patches too?
<mok0> amarillion: you can make it as fancy as you want. A branch for each patch.... or whatever
<POX_> LucidFox: or rather line 202 (works only for packages with 'python-*' name)
<mok0> amarillion: then, at the end, merge the branches you want
<LucidFox> Neither of my packages are named python-*, but all Python-Depends are named so
<mok0> amarillion: there's quite a lot of docs on using git for packaging in debian
<mok0> Ah, friday afternoon... the boys are playing Wii next door :-)
<LucidFox> What about python-central, does it have a mechanism equivalent to Python-Depends?
<ion_> git-buildpackage is quite nice. And how git handles branching is awesome if you want to have the upstream stuff in one branch, the packaging added to it in another, and perhaps other packaging branches in addition to that (such as for maintaining the package in an older distro version).
<POX_> LucidFox: no
<LucidFox> so how does it handle dependencies?
<ion_> Not to mention that git is superfast compared to the alternatives. :-)
<mok0> ion_: It's truly awesome
<POX_> LucidFox: you have to enter them in all packages by hand
<mok0> ion_: would be a good topic for the MOTU School!
<POX_> LucidFox: Python-Depends is good only for python extensions anyway
<LucidFox> Ah
<amarillion> good idea. I'd like to hear more about it
<amarillion> Here is one manual: http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html
<mok0> amarillion: put it on the wiki
<mok0> amarillion: I mean, as a wish for a class
<LucidFox> so, if I have a package depending on python-tk, I can just put it in Depends instead of Python-Depends? Or do I have to depend on something like python2.5-tk | python-tk?
<POX_> use python-tk or python-tk (>= first_version_with_2.5_so_file)
<POX_> LucidFox: btw, if you need a script to detect python dependencies, we have one in DPMT
<POX_> really ugly one, but it work (most of the times)
<POX_> +s
<amarillion> mok0, done: https://wiki.ubuntu.com/MOTU/School/Requests
<LucidFox> well, this package installs lots of scripts in /usr/bin... some are Python, others are bash
<POX_> LucidFox: http://svn.debian.org/viewsvn/*checkout*/python-modules/tools/find_python_dependencies.sh
<james_w> mok0, yeah, I plan to do one. However I doubt that git will be used.
<james_w> perhaps I can cover it briefly, but hopefully the concepts will be transferable.
<LucidFox> POX_> Thanks, that was really helpful!
<LucidFox> it caught python-cairo
<POX_> LucidFox: check if it's really needed (cairo module could be in docstring and its not detected coreclty)
<goodhabit>  Hello. I have some trouble. I am linux newbie, also ubuntu newbie. I have found some software, and with helps of manuals, google, brain I have compiled some software. But, as I understood,"make install" is wrong-way. And I need making deb file. I am started googling forward and found some manuals for it (#ubuntu also). But there are some issues I cannot solve. But as I told allready I need that package. Maybe someone could help me with packaging?
<LucidFox> goodhabit> What is the software?
<\sh> hmmm...why I'm still a non-ubuntu-developer, regarding ubuntu-devel?
<pochu> \sh: same here :)
<LucidFox> POX_> http://paste.ubuntu.com/3874/ - that's weird... it points to a file that isn't even in the directory I pointed the script to
<goodhabit> LucidFox, wired. http://sourceforge.net/projects/wired/
 * persia briefly surfaces to point at #canonical-sysadmins for developers having issues posting to mailing lists
<POX_> LucidFox: grep -r cairo /usr/share/python-support/tovid
 * \sh has no time for this now..need to finish the bugfixes for the octave3.0 stuff
<LucidFox> goodhabit> there is a PPA with this package here: https://launchpad.net/~tsmithe/+archive
<goodhabit> LucidFox, yep, but there are outdated version...
<mok0> amarillion: great
<POX_> LucidFox: it shows a file from which the module comes from, not the one with import command
<LucidFox> POX_> yes, it is used after all
<POX_> LucidFox: uncomment '#echo "  $i" # DEBUG'
<POX_> and you will see module names
<LucidFox> thanks for the script again!
<\sh> persia, #canonical-sysadmins is empty ;)
<davies> \sh: #canonical-sysadmin?
<\sh> ah
<POX_> LucidFox: next time join #debian-python, there are more python guys there. If you need help, we have DPMT (for python modules) and PAPT (for applications) teams
<pochu> POX_ rocks :)
<yamal> reviewers/advocates wanted for http://revu.tauware.de/details.py?package=sabnzbdplus
<LucidFox> POX_> thanks :)
<LucidFox> on a tangentially-related note... why does CDBS not respect debian/docs? It automagically calls "dh_installdocs ./README ./AUTHORS" rather than just dh_installdocs
<ScottK> LucidFox: cdbs is about automagic, not respect.
<LucidFox> heh
<tuxmaniac> reviewers/advocates wanted for http://revu.tauware.de/details.py?package=alliance
<bddebian> Heya gang
<\sh> btw...bug for the octave3.0 transition: https://bugs.edge.launchpad.net/ubuntu//+bug/185959
<ubotu> Launchpad bug 185959 in xmds "octave3.0 transition" [Undecided,Confirmed]
 * \sh < -- bbl
<zakame> hi folks, long time..
<schierbeck> hi guys
<schierbeck> i'm having trouble installing a bash completion script to /etc/bash_completion.d/
<schierbeck> i can't seem to do it directly, because i don't have the permissions to write the /etc
<schierbeck> what the hell should I do then?
<james_w> schierbeck, in a package build?
<schierbeck> yup
<james_w> don't install to /etc, install to "$(CURDIR)"/debian/tmp/etc/
<james_w> or similar depending on whether you use tmp or the package name.
<schierbeck> i use the package name
<schierbeck> and then it'll be copied to /etc when installed?
<schierbeck> thanks!
<james_w> if this installed by the upstream Makefile then you need to patch it to accept $(PREFIX) and then use that.
<schierbeck> i'll try it out
<hellboy195> How long does it normally take until there is a new changelog entry for a new revision in Debian?
<james_w> hellboy195, I'm sorry, I don't understand the question, could you explain please?
<tuxmaniac> hellboy195, you mean once uploaded a new revision of a package?
<hellboy195> tuxmaniac: right ^^
<hellboy195> Because I want to do a merge but Debian site hasn't got a new changelog entry :(
<tuxmaniac> hellboy195, I suppose a few hours. Atleast one package that I knew took 10 hrs app
<hellboy195> tuxmaniac: k, thx. so I'll wait at least until tomorrow (uploaded yesterday)
<schierbeck> james_w: that works! now, how the hell do i remove it when uninstalling?
<james_w> schierbeck, you don't need to, it should now appear in the list of files in the package, and so apt will take care of that for you.
<schierbeck> okay
<schierbeck> thanks!
<james_w> schierbeck, though you should probably read http://wiki.debian.org/DpkgConffileHandling
<schierbeck> james_w: okay
<\sh> how strange is this...even with trackerd in the gnome-session management disabled, it comes from time to time up and running...and eats my resources...oh well
<geser> \sh: the workaround it to deinstall trackerd
<rexbron> this is fun... I hate non-standard directories
<rexbron> in /usr/lib that is
<slangasek> rexbron: given that the standard says you can have more or less arbitrary subdirs of /usr/lib, what constitutes a non-standard subdir of /usr/lib? :)
<rexbron> slangasek,  installing to /usr/lib/<foo>/<foo.bar>/lib so that libs need rpaths to find anything....
<rexbron> that or setting something like ld.so.conf, but I really don't know enough about that subject
<slangasek> oh
<rexbron> :P
<slangasek> so not the directory, but the non-standard placement of the files :)
<rexbron> sladen, ya
<rexbron> slangasek, I posted to the ML with my problems if you want to take a look. The subject is "Acceptable use of rpath"
<bddebian> I thought slangasek thought there was no acceptable use of rpath? ;-P
<pochu> I thought bddebian thought slangasek thought there was an acceptable use of it
<\sh> slangasek, you are my debian guru...what will happen to packages in non-free in debian, which are not existent anymore (upstream), or are not being maintained by the debian package maintainer? as an example in this case: octave-gpc
<slangasek> bddebian: yes, that's my position
<slangasek> \sh: nothing happens automatically to such packages
<slangasek> \sh: if they cease to be buildable or installable, they'll get removed from testing fairly routinely; if they should be dropped altogether as obsolete, bugs need to be filed
<\sh> slangasek, ok..so I'm asking the octave team what should be done with this package..I can't find any new upstream nor is it building with octave3.0
<\sh> ok..one package still left for octave3.0 transition...it's building right now...after this, we can start with the sync and upload orgy
<jonnymind> I got this problem; I have a dev package that contains a binary file (which is used only in dev things, i.e. useless to normal users).
<jonnymind> I have also a dev-dbg package that contains its debugging symbols.
<jonnymind> is that ok?
<geser> jonnymind: does the -dev package need really an extra -dev-dbg package?
 * LucidFox pings RainCT
<jonnymind> yes, as there is a binary file that is not in the normal non-dev package.
<jonnymind> If that is a problem, I may just put the developement binary helper in the main package.
<jonnymind> If it's not a problem, that would be logically cleaner.
<geser> aren't the automatic -dbgsym packages sufficient for debuging?
<davies> LucidFox: /whois RainCT
<jonnymind> I am generating them.
<LucidFox> davies> I know :)
<jonnymind> The point is that I have this dev package with a binary /usr/bin file, which has to be stripped/debug enabled.
<davies> LucidFox: so why ping? :)
<geser> jonnymind: the buildds create for every package a -dbgsym package containing the debugsymbols
<jonnymind> this requires a dbg package... I just asked if there is any problem in having a dev-dbg package for the dev package.
<jonnymind> So, It's ok if I have an extra dbg package for the dev package, right?
<geser> jonnymind: there is no problem
<jonnymind> Oh, thanks. :-)
<geser> jonnymind: btw how big is the binary?
<jonnymind> about 40 kb
<jonnymind> the dbg symbols are about 16kb.
<geser> because every extra package makes the Packages files bigger
<jonnymind> But they may grow a lot in the future.
<jonnymind> If this is a concern, I can just put that helper binary in the non-dev package.
<blueyed> jdong: have you solved "Can someone confirm/explain why sudo seems to forget environment variables?" (from #ubuntu-devel some hours ago)? It's likely because all/more env vars get dropped by sudo now. See "sudo -E" / env_reset.
<jdong> blueyed: no, I was still wondering about that
<jdong> blueyed: thanks re. -E
<jdong> I'll have to update prevu's documentation regarding it
<jdong> the tool uses environment variables to communicate some settings
<joejaxx> yay xorg is finished compiling :DD
<joejaxx> :D  *
<blueyed> jdong: I've read your question on irclogs.u.c - it affects e.g. pbuilder, too (there's a bug filed about it)
<jdong> blueyed: thanks :)
<bddebian> slangasek: You bored?
 * azeem chuckles
<bddebian> :)
<\sh> wine 0.9.54 ... oh I'm so lucky
<joejaxx> hmm
<ScottK> \sh: Thank you for becoming a MOTU again ... ;-)
<\sh> ScottK, hmm...
<\sh> ScottK, was your statement ironical? ;)
<ScottK> \sh: Not entirely as I was worrying about WINE uploads during your sebatical (thank you for reviewing the packages for me then).
 * ScottK is really glad you're doing it now.
<\sh> ScottK, well there is no package right now...I'm building myself..
<ScottK> Ah.  Scott Ritchie didn't do it?
<\sh> ScottK, there is nothing on winehq...I can't get him...
<ScottK> Hmmm.
<ScottK> He's here...
<ScottK> YokoZar: You around?
<\sh> ScottK, I want to start with wine PPA packages, so we can stop backporting and using the PPA because people are using normally the packages provided by winehq
<\sh> ScottK, #ubuntu-wine :) I asked him already :)
<ScottK> Ah.
<\sh> ah well..0.9.54 was released today ,)
<ScottK> You're doing the work, so whatever you want, but I think it's better to keep in the official archives if we can.
<ScottK> My clamav PPA is just for testing until we do get stuff backported (for example).
<\sh> ScottK, yeah...this we can do still...but I like to have a version which works on former releases even in backports...so if we need to make debian/control changes or other things inside debian/ dir it's better to test it via ppa
<ScottK> Agreed it's better to test via PPA.
<Kopfgeldjaeger> hi
<Kopfgeldjaeger> could someone please have a look at #178845 and sponsor it (if possible)?
<jdong> Kopfgeldjaeger: hi, it's on my TODO list
<Kopfgeldjaeger> ok, thank you
<\sh> ScottK, can you do me a favour?
<ScottK> \sh: Maybe?
<\sh> ScottK, and re-check bug #185959 if I catched all packages, build-dep / build-dep-indep / depend on octave (so including octave2.1 and octave2.9)
<ubotu> Launchpad bug 185959 in xmds "octave3.0 transition" [Undecided,Confirmed] https://launchpad.net/bugs/185959
<\sh> ScottK, I think I have all packages...but good to have a second pair of eyes ;)
<ScottK> Sure.
<\sh> ScottK, thanks a lot :)
<\sh> ah one I have still...
<\sh> oh this is only recommends
<\sh> and it will catch Recommends: octave
<ScottK> blueyed: reportbug has a lot of lintian complaints (I'm looking at your bug fix now).  Any chance you could work on fixing the rest up and sending it back to Debian?
<pwnguin> is it too late to request a package be resync'd from debian?
<geser> pwnguin: not until FF which is around Valentines Day
<pwnguin> neat
<geser> but check that it doesn't break other things
<\sh> wine 0.9.54 hits hardy
<ScottK2> Yum.  Does it backport?
<\sh> ScottK, nope...not now ;)
<\sh> libgif breaks it
<\sh> I do some backport stuff next week...after I worked with pitti the octave3.0 stuff...I'll go off now, I think for today I did enough motu work ;)
<\sh> ok good night folks :)
<saivann> DaveMorris : If you get time for it, I applied needed changes to simdock package, which you can review again here : http://revu.tauware.de/details.py?package=simdock
<saivann> DaveMorris : thanks for this
<DaveMorris> yeah, I'll do it once I've kicked my program off to build in a bit
<oly-> hi, i am building packages with dpkg-buildpackage, is there a way to output the resulting files to another location ?
<slangasek> bddebian: boredom is a disease of the mind
<slangasek> and with that, I'm off for the night :)
<Coper> Hi, I have followed the guide "Packaging with Debhelper" and have a new package for a new application console-freecell. I have added a new bug report id:186016 and assing it to me with status In progress.
<ScottK> Coper: Once you think it's ready, you can upload it to REVU.
<ScottK> !revu | Coper
<ubotu> Coper: REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
<Coper> ScottK: okey, I will look in to it and will be back with some more questions. :)
 * ScottK hugs sabdfl (even though he's not here right now) [see MC ML for details].
<Coper> REVU admin can you resync the REVU uploaders keyring?
<ajmitch> ScottK: someone buy that man a beer
<ScottK> Absolutely.
<crimsun> "And today, in 'As The Ubuntu Turns'..."
<DaveMorris> saivann: commented
<blueyed> ScottK: re reportbug.. do you mean fixing bug 163924 correctly, including the lintian fixes and then also submitting it to Debian?
<ubotu> Launchpad bug 163924 in reportbug "manpage should mention that the default in Ubuntu is not to send to Debian" [Low,Triaged] https://launchpad.net/bugs/163924
<rexbron> Looking for some review karma? Check out http://revu.ubuntuwire.com/details.py?package=libopenfx
<ScottK2> rexbron: Reviewing doesn't give karma.
<rexbron> Not LP karma, just the general kind
<ScottK2> leonel and sommer: New clamtk in edgy/feisty/guty clamav-ppa for your testing pleasure.
<ScottK2> Oh.
<rexbron> Snap.
<sommer> ScottK2: sweet, everything need restested, or just those apps with issues?
<saivann> DaveMorris : Greaet, thanks
<saivann> Great*
<ScottK> sommer: New clamtk, not clamav
<cbx33> hey guys
<cbx33> anyone use enlightenment?
<sommer> ScottK: ah, should have read closer
<sommer> I'll give it a spin this evening
<ScottK> No problem.
<ScottK> Great.  I expect it's fine.
<ScottK> Actually, I tested it on Guty before uploading, so I'll mark that down.
<leonel> ScottK  clamtk works  fine in Gutsy
<Coper> I have some problem to recive a password from revu, it says that no REVU account exists for my email.
<leonel> ScottK2:   clamtk works  fine in Gutsy
<leonel> scottK2 scottK testing in feisty
<blueyed> Coper: have you uploaded anything yet?
<Coper> blueyed: yes, I did "dput revu package_version_source.change" and go Succsessfully uploaded packages.
<blueyed> Coper: then the keyring might not be synced yet. There is probably someone around who could do this. siretart?
<blueyed> Can the keyring not get synced when someone unknown uploaded something? would me handsome.. ;)
<Coper> blueyed: okey, I got a warning "This key is not certified with a trusted signature!"
<blueyed> what key?
<Coper> my gpg key.
<blueyed> And where does the warning come from? Can you encrypt mails and text successfully?
<Coper> I have no problem with encrypting email or text I get the warnings when Checking Signature on .dsc It says that it's a good signature but get a warning that it's not certified.
<DaveMorris> what is the mythbuntu site running on?  CMS wise
 * DaveMorris opps, wrong channel
<_MMA_> DaveMorris: I see drupal mentioned in the page source. For whatever thats worth.
 * DaveMorris has an account on the server but can't remember his password for, otherwise I could check that way
<emgent> heya people
<ScottK> blueyed: Please make lintian happy while you're working on reportbug too.
<sommer> ScottK: new clamtk good to go on Edgy
<ScottK> Great.
<leonel> scottK clamtk  OK on feisty
<ScottK> great
<mgdm> Hi - I have a potentially dumb question. Is it bad form to package and upload something I've written myself...?
<DarkMageZ> mgdm, only if it's malware.
<mgdm> DarkMageZ: I assure you it isn't ;)
<StevenHarperUK> Hi everyone
<DarkMageZ> mgdm, then feel free to upload it ?
<mgdm> It's a little GNOME applet written in PyGTK for use with Asterisk. When it's in better shape, I'll package it.
<StevenHarperUK> I have a question : I have an Idea on how to improve the Resolution Gnome Applett, I cant find the launchpad project to put my suggestion into can anyone help me find it?
<DarkMageZ> StevenHarperUK, you mean gnome-display-properties?
<StevenHarperUK> is that | System | Prefrences | screen resolution
<DarkMageZ> yes
<StevenHarperUK> Can I bounce my suggestion off you>
<DarkMageZ> go ahead ?
<StevenHarperUK> Ok at the moment you can pick a resolution for a user - What im thinking is that the Xorg file - the first resolution in the list supported by the Screen you have is always the one you get on the Login screen : if you move a nice entry to the start of the list you get that : on my 22" monitors it picks stupid res like 2048x1024, I would move a nice one to the front on user selection
<Coper> If I have dsc file and succsessfully build it in pbuilder can I generate a deb file and try it on my system?
<StevenHarperUK> So you could have an option name : login screen Resolution (and all unset users) or simular
<StevenHarperUK> what  do you think
<DarkMageZ> StevenHarperUK, i've been wishing for that for awhile. you might want to see if there's a bug about it in the gnome bug tracker. if not then search launchpad for one. if not then file a bug or a specification about it ?
<DarkMageZ> StevenHarperUK, you'll want to file it against gnome-control-center ?
<StevenHarperUK> Ill go look 1 sec
<StevenHarperUK> OK that looks like it : should I raise a bug and a blueprint?
<DarkMageZ> i'm not sure which one is most appropriate
<StevenHarperUK> I haven't done this before
<StevenHarperUK> Id say blueprint
<StevenHarperUK> As it as a new feature - setting the login screen res
<DarkMageZ> true
<DarkMageZ> once you've created it, subscribe me ?
<DarkMageZ> tho don't force my involvement. just make it so i get the emails about it ?
<StevenHarperUK> OK - I may plan to help code - I am a developer and have packages myself
 * jdong verifies the avidemux package he promised Kopfgeldjaeger 
<DarkMageZ> ah, well. i think the best way to do this then would be to talk to the guys in (i think it's #ubuntu-devel). see what their thoughts are and how they think the best method of implementation would be (yay for idea gathering). then submit a patch ?
 * Kopfgeldjaeger jumps up, screams "YEAH!" and hugs jdong
<jdong> Kopfgeldjaeger: tested and uploaded :)
<Kopfgeldjaeger> yeah :)
<Kopfgeldjaeger> thank you
<Kopfgeldjaeger> jdong: btw, there's a little typo in the description (see http://packages.ubuntu.com/hardy/graphics/avidemux ): verison instead of version
<Kopfgeldjaeger> anyway,
<jdong> Kopfgeldjaeger: gack just after the upload completed... at any rate I wanted to give Matvey the credit for this upload without mangling; please file a quick bug report on it and we'll take it from there
<StevenHarperUK> DarkMageZ: your subscribed
<Kopfgeldjaeger> ok, maybe yesterday
<Kopfgeldjaeger> good night
<jdong> Kopfgeldjaeger: night :)
<goodhabit> Hello. Help me please. I have all binary files compiled. Can someone help me with *.deb file composing? I am newbie. :|
<Aloha> goodhabit, dpkg-buildpackage -rfakeroot will build deb
<StevenHarperUK> goodhabit: what are you developing in
<StevenHarperUK> Python?
<goodhabit> I am not developer. Actually I am newbia @ IT at all. All day gone for compiling it :)
<DarkMageZ> !ubuntupackagingguide
<goodhabit> Nonono.
<goodhabit> I have read it all.
<StevenHarperUK> goodhabit: so what you trying to do : make a package from source?
<goodhabit> Some parts are impossible fo me. The packaging wants some rules of tar.gz file, which I cannot do.
<goodhabit> Nope
<goodhabit> I have compiled allready.
<goodhabit> I have all files instaled with --prefix
<goodhabit> I need to have *deb file.
<DarkMageZ> goodhabit, it's difficult to turn a current installation into a .deb . maybe you should build the package from scratch.
<goodhabit> DarkMageZ, can you guide me?
<DarkMageZ> goodhabit, the ubuntu packaging guide contains all the guidance that one should need.
<StevenHarperUK> goodhabit: I have an example project that has build scripts
<goodhabit> Some parts of that guides are really impossible for me.
<DarkMageZ> goodhabit, how so?
<goodhabit> You know, I am not developer. I can send e-mails. Recieve e-mails. Play music, watch video :)
<jdong> goodhabit: at one point, none of us were. We'd be glad to help explain/clarify things if you're interested :)
<goodhabit> Can somebody help with packaging (small aplication)
<goodhabit> I see.
<Aloha> goodhabit, why are you creatinga deb package if you know nothing about developing?
<goodhabit> Aloha, I want to use that software, and cannot find the deb file.
<Aloha> goodhabit, if its compiled just run it
<StevenHarperUK> goodhabit: what is the software
<goodhabit> wired http://sourceforge.net/projects/wired/ there are packages @ ppa, but they are outdated.
<crimsun> goodhabit: have you checked with the Ubuntu Studio folks?
<crimsun> IIRC, someone was working on it.
<goodhabit> crimsun, why folks :) ?
#ubuntu-motu 2008-01-26
<crimsun> goodhabit: I don't understand your question.
<goodhabit> dpkg-source: warning: extracting unsigned source package (./wired-0.6.orig.tar.gz)
<goodhabit> dpkg-source: error: syntax error in source control file ./wired-0.6.orig.tar.gz at line 1: line with unknown format (not field-colon-value)
<goodhabit> What can I do with it?
<joejaxx> ah that stinks bryce is not in here :\
<joejaxx> i wanted to talk to him about including my Xorg patch :D
<joejaxx> and it needs to get in before freeze as it would create a new binary package off of the xorg-server source package
<RAOF> joejaxx: What does it do?
<joejaxx> it gives us KDrive :D
<RAOF> I've seen that scroll past in the configure output, but what does it do?
<joejaxx> it is tiny X
<joejaxx> xserver*
<joejaxx> a tiny*
<RAOF> Ok, that makes sense.  Eventually :)
<joejaxx> yeah
<joejaxx> i am probably going to use it for fluxbuntu :)
<joejaxx> i am using it now but i have not gotten xinerama to work correctly
<minghua> What does the ordinary Xorg xserver have that XDrive doesn't?
<rexbron> Anyone got time for a review? http://revu.ubuntuwire.com/details.py?package=libopenfx
<bddebian> Heya gang
<LaserJock> hi bddebian
<RAOF> Yo bddebian
<bddebian> Hi LaserJock, RAOF
 * pochu waves
<ion_> Hi all
 * ion_ is about to go to bed
<ion_> I just took my first shot at shooting and tonemapping an HDR photo. :-)
<ion_> (Thereâs a lot of room for improvement, of course)
<RAOF> Licensing sucks :(
<crimsun> eh?
<bddebian> Yep
<RAOF> As in: reviewing debian/copyright for packages on revu.
<ScottK> Depends on how much pleasure you take out of telling people, "Hey, you suck."
<bddebian> heh
<crimsun> ya gotta start somewhere, heh  :-)
<RAOF_> Wow.  Translating pypy is an excellent way to generate excessive system load.
<bddebian> heh
<crimsun> for me, apparently so is scrolling in a Web browser while using the "normal" compiz config.
<crimsun> yay, exa.
<bddebian> Gah, I don't know how to test this libapache2-mod-xmlrpc2 properly :-(
<emgent> crimsun, i talked now with kees about ubuntu-hackers team
<crimsun> emgent: ok
<emgent> he will talk with infra team monday
<emgent> and go to ufficializzation :)
<crimsun> emgent: excellent.
<emgent> ^^
<LaserJock> ubuntu-hackers?
<emgent> LaserJock, yep
<emgent> https://edge.launchpad.net/~ubuntu-hackers
<LaserJock> fascinating
<emgent> yep :)
<LaserJock> what kind of thing would the team even do?
<RAOF> Wow.  Enough system load to cause irssi to timeout, apparently.
<emgent> LaserJock, team for infra debug and ubuntu community (and not) system.
<emgent> penetrations test, auditing and builting patch
<LaserJock> hmm
<emgent> only about infra system (webapps etc..).
<emgent> "The team of hackers Ubuntu aims to take care of security problems in Ubuntu Services as Launchpad, REVU, Forums, website and other community systems.
<emgent> The team will also aims to organise the "Ubuntu Hack Day", a day dedicated to hacking tests on the structures of the community with auditing and penetrations tests."
<LaserJock> emgent: but is there enough need for a team?
<emgent> yep, because now ubuntu-security and motu-swat work only for packages.
<LaserJock> seems like encouraging a community infrastructure team that wrote/tested, etc.
<emgent> this is a indipendent group (motu-swat branch)
<emgent> kees thinks that.
<ScottK> Could we pick a different name though.  Us honest hackers would rather that stereotype wasn't furthered.
<LaserJock> yeah
<emgent> uhm ok np.
 * keescook really would like to avoid the "what does 'hacker'" mean situation.  :P
<LaserJock> I assumed it was a team *writing*, etc. for Ubuntu infra
<emgent> monday kees will talk with infra team and council.
<keescook> I would simply like to avoid confusion about the name, though..
<emgent> waiting him :P
<keescook> I don't have a solution for the name part exactly, but it does seem like people interesting in _finding_ security issues in ubuntu need a place to coordinate
<keescook> my initial suggestion is to just make it all motu-swat
<LaserJock> hmm
<crimsun> that sounds feasible
<keescook> since the audience of people interested in helping with security (either through fixes or through finding new issues) is somewhat small, I don't want to arbitrarily segment them up.  :)
<emgent> i think branch to motu-swat
<keescook> regardless, the entire idea of performing "organized pentesting of Ubuntu infrastructure" needs some level of validation from the IS staff.  :)
<crimsun> agreed.  I'm frankly far more interested in app fuzzing.
<keescook> solving the details of which team and what name is just a matter of making a judgement call everyone likes.
<keescook> crimsun: yeah, I'd love to see more of that too.
<LaserJock> crimsun: what is that again?
<crimsun> LaserJock: `apt-cache show fuzz` will give you some idea  :-)
<emgent> :)
 * keescook wants to fuzz the X.org video drivers -- at least one issue in the past has come up in the nvidia driver
<emgent> well keescook we will wait your news :P
<keescook> emgent: cool.  :)  what do people think of having a recurring meeting for ubuntu security topics too?
<keescook> we're starting to have enough different things going on that maybe we should try to coordinate a bit.
<emgent> keescook, for me ok
<emgent> keescook, date? :)
<keescook> emgent: heh, I'm not sure.  perhaps Wed?  I will send email to the ubuntu-devel and ubuntu-hardened mailing lists when I get home tomorrow
<emgent> send to me too.
<emgent> in 26 and 27 i'm to Siena (Ubuntu italia meeting)
<emgent> next week it's perfect
<emgent> Wednesday it's ok for me
 * keescook nods and crawls to bed for real now
<emgent> lol
<ScottK> Anyone know why we have octave2.1-forge, but octave2.9-forge was recently removed? - \sh_away?
<persia> ScottK: I seem to remember some issue around the etch release that required both packages.  I don't expect we still need octave2.1-forge at this point.
<LaserJock> we're gonna remove both 2.1 and 2.9 when 3.0 gets in
<ScottK> Cool
<ScottK> I'm double checking
<ScottK> on \sh_away's affected package list for the transition.
<LaserJock> hmm, it's too bad I know next to nothing about security :/
<LaserJock> in general I think QA and security to very interesting
<LaserJock> *to be
<persia> LaserJock: No better way to learn than to help out fixing things.  Reading CVEs can be very informative.
<StevenK> Reading CVEs tends to give a nice idea of what *not* to do.
<persia> StevenK: Depends on your goal :p
<StevenK> Heh
<LaserJock> I did read up a bit while working on moodle MIR
<LaserJock> it'd really be cool to have a resource for people writing our webapps, etc. to go to to make sure everything's tight
<ScottK> Rule 1: No PHP.
<emgent> lol
<emgent> :)
<LaserJock> ah, easier said then done I'm afraid
<LaserJock> there are so many goodies in PHP
<ScottK> All depends on your priorities.
<LaserJock> and what you've got to work with
<ScottK> \sh_away: My review is complete.  I found a couple of meta packages that need looking at, I think that was it.  All added to the bug anyway.
<ScottK> LaserJock: You've got a lot to work with.  It's FOSS.
<LaserJock> well, when it's not my server it's a bit limiting
<LaserJock> and when most of the good apps are PHP it's harder :/
<LaserJock> but I know what you mean
<minghua> ScottK, LaserJock: I suspect octave2.9-forge was removed because it was removed in Debian testing/unstable.
<ScottK> That'd make sense.
<LaserJock> I am trying to learn Ruby though so I have a bit more in my toolbox
<minghua> ScottK, LaserJock: There doesn't seem to be an octave3.0-forge in sight, though.
<ScottK> Maybe it's all perfect now that 3.0 is out and no more extra goodies are needed?
<minghua> LaserJock: BTW thanks for the mail reminder about \sh_away's work on octave3.0.  I talked with him on IRC.
<LaserJock> minghua: ok good, I was afraid maybe I was stepping on toes
<LaserJock> I just wanted to make sure everybody was on the same page
<persia> There's a semi-automatic removal of anything removed from Debian that doesn't have rdepends or Ubuntu variation.  I thought that was good, but it might also cause this type of issue: anyone have any ideas for noticing?
<LaserJock> hi tuxmaniac
<crimsun> bug 186095
<ubotu> Launchpad bug 186095 in ubuntu "hardware destroyed!" [Undecided,New] https://launchpad.net/bugs/186095
<crimsun> brilliant!
 * persia fondly remembers the IBM 5150
<ScottK> Kewl.
<minghua> LaserJock: Yeah, it was good, no toes stepped on.  I talked with \sh_away _after_ getting your commenting on his bug.
<tuxmaniac> LaserJock,
<tuxmaniac> LaserJock, can you please review http://revu.tauware.de/details.py?package=alliance . I have been advertising from yesterday :-(
<bddebian> tuxmaniac: I'm trying but I have a full disk :(
<tuxmaniac> bddebian, oh you are still around. :D
<tuxmaniac> bddebian, its morning in India already :-)
<bddebian> OK, I have this: in a rules file that works on the command line but gives missing '))' on build.  Any clues??
<bddebian>         echo Ion:ApiVersion=$$((cat /usr/include/ion3/version.h; echo ION_API_VE
<bddebian> RSION) \
<bddebian>                 | cpp -P | tail -1 | sed 's/"//g') >>debian/mod-xinerama-for-ion
<bddebian> .substvars
<bddebian> Gah, sorry, bad pase
<persia> bddebian: Didn't we drop ion3 for licensing reasons?
<bddebian> Seems to be back afaict
<bddebian> Debian has a 20080103 or so version
<tuxmaniac> aah looks like \sh_away  has been going bizzerk with octave3.0 sync. Great to see and hope it gets into hardy! A wonderful milestone it shall be.
<persia> bddebian: My understanding is that the license for io3 requires distribution of the latest snapshot, which we can't support.  Debian has it, but only because they have an RC bug preventing it reaching lenny.  Ubuntu has no such mechanism.
<persia> s/io3/ion3/
<bddebian> Ahhh
 * bddebian thinks persia knows everything
 * persia is certain that is a false statement, and is willing to provide mathematical proofs
<bddebian> Now go fix survex for me ;-P
 * persia cringes
 * persia wonders if there are any spelunkers about
<bddebian> Not me :)
<RAOF> Oooh, looks pypy has finished locking my box :)
<bddebian> Is there one of the texlive psuedo packages that installs the texlive-lang-* packages or do I need to build-dep on each texlive-lang-<language> ?
<bddebian> Ah, texlive-common?
<LaserJock> well, texlive-lang-all
<LucidFox> Is there any way I can see which package versions a particular Hardy alpha contained?
<persia> LucidFox: Your best chance is to download the CD, but many users call something "Alpha 2" when they have been doing daily updates.
<minghua> And the alpha-2 label means nothing for universe anyway.
<RAOF> Lack of copyright headers in source files isn't grounds for rejection from NEW, as long as there's a statement that the software is licensed under the GPL, right?
<jdong> RAOF: I believe in that case ~ubuntu-archive would *like* you to make sure of the terms of the license of the headers, but right, it's not deathly necessary
<jdong> and not, IMO, cause for rejection
<jdong> though of course I'd be the worst, most liberal archive admin in the world
<persia> RAOF: Depends on the archive admin.  There have been several rejections for that.  Ask upstream to follow the instructions in the GPL about how to apply the GPL to their source first, and only push to the archive admins if upstream won't fix it.
<RAOF> Right.
<desertc> If I wanted to get involved with the MOTU team, then would I need to set up a separate partition or make sweeping changes to my desktop system?  I have been reading the MOTU documents, but I am still unclear what would be the physical requirements.
<persia> desertc: There are no physical requirements.
<RAOF> No, not really.  There are a variety of tools for building packages in a clean system without actually having a clean system :)
<persia> It is strongly recommended that you set up either pbuilder or sbuild.  pbuilder seems to want a fairly large /tmp, and sbuild wants it's own partition area (I set aside 19.99 GB for sbuild).
<ScottK> RAOF: There also has to be a full copy of the license in the tarball.
<tuxmaniac> desertc, I personally feel pbuilder is better for a start. Since I am also in the beginning stages.
<desertc> I see.  Good to know.  Setting up a partition would not be a big deal.  I can always add another hard drive via USB.  I just was picturing having to have 09.04 configured or something.
<desertc> um 08.04  :)
<RAOF> ScottK: Yeah, it's got a copy of the GPLv2 in there, and it says that it's GPLv2 licensed.  It's just that none of the source files have any copyright attribution at all.
<persia> desertc: Nope.  There are MOTU who run Dapper or even Debian.
<tuxmaniac> desertc, though I have not tried sbuild, pbuilder is a breeze to get started.
<ScottK> RAOF: You're probably OK then
<desertc> I will take a look at pbuilder and idle here.  Hope to get a handle on how to help soon.
<persia> RAOF: copyright attribution is different than licensing.  It is acceptable for the collective work to be under a collective copyright (although discouraged), but doing that doesn't match the instructions in the GPL for licensing.
<ScottK> desertc: My main desktop is still dapper.  I've got servers on Gutsy and (until tomorrow - the last one dies - Feist), a Gutsy laptop and an Edgy install on my wife's laptop.
<persia> desertc: What interests you?  A common way to get started is to look at problems with software you use or like, and try to get them resolved.
<RAOF> ScottK: Wanna help me close the ITP, then? :)
<ScottK> RAOF: It's late and I'm going to bed.
<ScottK> Good night all.
<RAOF> Fair enough.  Sleep well!
<bddebian> Gnight ScottK
<tuxmaniac> desertc, most of the info you might need are there here https://wiki.ubuntu.com/PbuilderHowto with respect to pbuilder
<desertc> tuxmaniac: thanks for the link :)
 * persia notes that the official buildds run sbuild, and points at https://help.ubuntu.com/community/SbuildLVMHowto
<tuxmaniac> persia, thanks. I think I shall try that out on my home machine.
<desertc> How much space (est) does pbuilder require?
 * RAOF notes that sbuild-on-lvm can also be quite a lot faster than pbuilder. 
<desertc> or sbuild
<persia> desertc: Lots less.  Something like 50MB per chroot tarball.
<RAOF> And then a variable ammount of space while building.
<persia> Err.  pbuild requires lots less.  sbuild-on-lvm requires 4-5GB per chroot + 4-5GB per simultaneous build.
<desertc> Is sbuild is recreating the environment of the entire OS?  And pbuilder is just for the individual package?
<desertc> (taking a guess here)
<RAOF> They're both doing the same thing, but different technical means.
<persia> Similar things.  They are only about as close as apt-get and aptitude.  Each has a few unique features, and the codebases are different.
<RAOF> pbuilder creates a minimal ubuntu system then tars it up.  Each time it builds, it unpacks that tarball under /tmp and then chroots into it.
<RAOF> sbuild-on-lvm has a separate lvm logical volume containing the minimal system, then uses snapshots to build in.  The reason why each lv has to be big is so that you've got enough space to install the build-dependencies & build the package.
<desertc> hmm!  thanks for the explanation!
<persia> If you choose pbuilder, be sure to either have a fair amount of space available on /tmp, or if using tmpfs, a large swap partition.
<tuxmaniac> can I have two pbuilder chroot tar? since I am on a limited bandwidth, its not simple to clean up everytime I build a different package. I mean two pbuilder ch tar for the same dist?
<RAOF> You should be able to have a local apt cache, which will do what you want.
<RAOF> I forget if pbuilder is set up to do that out of the box.
<persia> tuxmaniac: Both pbuilder and sbuild clean up after each build.  You want a local mirror (or cache) to not download everything with each build.
<minghua> That would be --aptcache option, or APTCACHE variable in pbuilderrc.
<desertc> I have a CS background, but I've not put any of it to use since college.  I was thinking I might like to start working toward programming linux code, and I thought this might be a good way to get started on that path.  I also have work training in QA, so I think I can be pretty handy.
<desertc> Most importantly, I have a lot of control over my time these days, which is awesome.  :)
<RAOF> There's really not that much programming involved in MOTU work.
<persia> desertc: MOTU only very rarely actually touches the linux package :)
<RAOF> At least, the actual *packaging* part.
<desertc> It will help me work toward it, by giving me a better understanding of the Ubuntu system.
<persia> RAOF: Depends.  There can be for bugfixing, or library porting (and we can always use more library porters)
<RAOF> The bug finding/fixing, yes.
<desertc> You don't want me programming anything right now anyway.  I probably would have trouble with helloworld() at this point.
<RAOF> In that case, bugfixing may well be a nice gentle reintroduction :)
<tuxmaniac> desertc, I get memory leaks with my hello world sometimes
<tuxmaniac> :D
<desertc> :)  I was leading QA efforts for a popular open source project a short while ago, and I am burnt out from dealing with developers.  ;)
<desertc> All features and no bug fixes.  Made me understand the importance of groups that hold the projects together at a high level, like the Ubuntu Project.  :)
<desertc> Or did you mean actually making the programmatic changes myself, RAOF?  Hmm!  Interesting idea.
<desertc> Okay, sorry to take over the conversation, I'll keep looking at pbuilder and sbuild.
<RAOF> desertc: Oh, yes.  Making the changes yourself.
<RAOF> It's quite a different skill to be able to dive into some totally unfamiliar code and find the bug :)
<RAOF> Anyone want to close an ITP? http://tinyurl.com/2249zg for the DDs among us.
<persia> RAOF: What does it break?  Should it really be priority "extra"?
 * persia is not a DD, but picky about priority extra
 * RAOF *always* forgets priority :(
<RAOF> Thanks.
<desertc> Okay - this will sound a bit noobish, but what does an Ubuntu programmer program?  Aren't Ubuntu packages derived from Debian, for the most part?
<desertc> I suppose there is the installation and the upgrade software..
<persia> desertc: It's mostly maintenance coding.  Looking through code from upstream or from Debian and fixing bugs or improving integration.
<desertc> Ah, gotcha.  Thanks
<persia> Most fixes end up being patches that go to Debian or to Upstream, and are dropped in the next release.
<desertc> In MOTU work, you do a bit of compiling with the package source, right?
<desertc> sorry - I should read and not keep asking questions that I can find myself  :-)
 * RAOF hit's miro again, in the hope that it'll work if you give it a kick.
 * RAOF is taken away by the society against cruelty to apostrophes.
 * persia hands RAOF a white coat and a clipboard as defence against arbitrary societies
 * Hobbsee hides in the white padded room, to avoid wor
<Hobbsee> k
 * persia hands Hobbsee a white jacket with long sleeves and extra straps
 * Hobbsee gets out her whip
<Hobbsee> woe betide anyone who decides to do *anything* stuipd tonight.
<persia> !channels
<ubotu> A list of official Ubuntu IRC channels, as well as IRC clients for Ubuntu, can be found at https://help.ubuntu.com/community/InternetRelayChat - For a general list of !freenode channels, see http://freenode.net/faq.shtml#channellist - See also !Guidelines
<persia> tjaalton: Re: the java X bug.  Is it confirmed fixed for gcj & icedtea?
<StevenK> Hmph.
<StevenK> cln jumped from using cln-config to using pkg-config.
 * persia wonders if anyone ever grabbed the first 38 libldap rdepends
<StevenK> persia: I thought you had 19 of them?
<persia> StevenK: I did 19, and you did 19, but I thought there were 78 or so in total.  Do I misremember?
<StevenK> persia: For universe it was only 58 or so
<StevenK> I have 2 left, I think
<persia> I have 3 that didn't work smoothly.  I was just considering pushing the simple cases in "" - haskel if nobody else had yet.
<jonnymind> Hello all
<RAOF> Miro taunts me with new boost dependencies.  I shall set it on fire!
<RAOF> How many libtorrents are there?
<persia> RAOF: I think there should only be three
<RAOF> Ah.  Which one is Miro embedding now...
<tjaalton> persia: I'm not sure, haven't tried myself
<persia> tjaalton: I'm just wondering if it's only a hypothetical closure.  I haven't encountered the issue, but it would be unfortunate if it still existed for new hardy installs using icedtea.
<persia> (or openJDK, but I don't expect that to be ready for hardy)
<RAOF> Right. It's not the libtorrent that we have in our archives, anyway.
<tjaalton> persia: the upstream bug says that it's fixed, but doesn't mention the version
<persia> tjaalton: Hmmm.  I don't expect our X to need any further modification, but just wondered if our Java did.  Maybe all is good (and maybe soon we can drop the sun java blobs)
<tjaalton> we can't touch them, so it just needs to be mentioned on the release notes..
<persia> tjaalton: We can't touch the sun-* blobs, but we can touch icedtea, which is why I mention it at all.
<tjaalton> oh right
<persia> Most things that work with sun-* should work with icedtea, and we should be patching icedtea like anything else in universe to demonstrate good practice, and encourage more open java.
<tjaalton> I believe it's fixed there already, someone just needs to test it :)
<RAOF> Accursed script kiddies!  Stop hitting my password-disabled ssh server, damn you!
<persia> tjaalton: Do you have any good test case?  Testing first against gcj, I don't seem to have a jconsole binary, and don't understand fcitx well enough to be comfortable breaking my scim.
<tjaalton> try eclipse
<tjaalton> first check that /etc/eclipse/java_home has gcj/icedtea on top
<persia> tjaalton: I don't have any Sun-* installed.  Shouldn't it do the right thing without any conffile mangling?
 * minghua is awaken by the mentioning of scim.
<tjaalton> persia: yep
<persia> minghua: We're discussing bug #87947.  Not really a scim thing.
<ubotu> Launchpad bug 87947 in libx11 "xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed." [Medium,Fix released] https://launchpad.net/bugs/87947
<persia> it's just that one of the test cases uses fcitx
<minghua> Heh, xcb issues.
<persia> tjaalton: If the bug exists, eclipse should crash on first run?
 * persia tries installing Sun Java to see if it breaks eclipse
<minghua> persia, tjaalton: I don't think 87947 is in any way related to input methods.
<tjaalton> persia: I think so..
<persia> minghua: I agree.  It's just that I didn't want to mess with my scim configuration, so wanted another test case
<minghua> persia, tjaalton: Sun Java is known to be (or have been) broken with xcb.  Old Xorg used to have problem with xcb for input methods, but as the bug states, it has been fixed.
<tjaalton> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373
<tjaalton> that's the upstream bug
<tjaalton> gone ->
<minghua> Actually, scim used to break with xcb as well.
<persia> tjaalton: eclipse doesn't seem to show it either with or without sun-java.
 * minghua once got a bug about this, but Xorg maintainers took it back after a few days and eventually fixed it.
<persia> minghua: Does icedtea fix the problem with sun java?  I've never encountered the bug, and so have a hard time testing to see if it is fixed.
 * persia doesn't like telling users "it's a problem with non-free software" when there is a free software replacement available.
<minghua> persia: I've never encountered it either.
<persia> tjaalton: Could you please find a test case, and verify whether it was fixed or not?  I'm happy to help test.
<minghua> So hardy has xcb enabled now?  I didn't notice any difference.
<persia> Does anyone know why python-profiler is in multiverse?
<RAOF> There's a licensing issue in linking gpl code with openssl, isn't there?  Do I remember that correctly?
 * minghua hopes not.
<minghua> GPL code linked with openSSL is downright non-distributable.
<persia> RAOF: The GPL code needs to offer a specific exception to allow linking against OpenSSL, if I remember correctly.
<RAOF> Yes, that was what I was afraid of.
<RAOF> Well, it seems miro is now undistributable.
<persia> RAOF: You could patch it to not link against SSL for now.  It's not a problem to distribute source.
<minghua> persia: Non-DFSG-free restrictions for the python-profiler case, it seems: http://mail.python.org/pipermail/python-dev/2005-February/051450.html
<persia> minghua: OK.  That makes sense.  Thanks.
 * persia is trying to reduce multiverse usage
<persia> Anyone have any hints for injecting a local package into an sbuild session?
<azeem> persia: sbuild takes .dsc files
<azeem> persia: or what do you mean with injecting?  Installing it in the chroot rather than building it?
<persia> azeem: Right.  I have two packages.  One build-depends on the other.  I could use a local archive of a PPA, but would like to just be able to tell sbuild I want this specific local package also installed in the chroot.
<azeem> ah
<persia> s/of a PPA/or a PPA/
<azeem> that's not so trivial I think, yeah
<azeem> I usually install it manually in the chroot
<persia> azeem: In the base chroot?  Doesn't that affect your future builds?
<azeem> well, and try to remember to remove it again afterwards ;)
<azeem> deborphan is good for that
<azeem> hrm
<persia> azeem: install/purge cycles are supposed to be clean, but aren't always :(  Be careful with that.
<azeem> persia: well ok, but it's no different to installing any other build-depens, that can potentionally happen all the time
<persia> azeem: Depends on how you use sbuild.  I always use it in a snapshot LVM volume, which I discard after each build.
<minghua> persia: Can't you login into your LVM snapshot chroot then?
<persia> minghua: That's my workaround for now, but as I'm setup to discard chroots after use, I end up using debuild, which doesn't keep the logs in the same place.  I was hoping for something simple (and should probably be using a local archive)
<azeem> yeah, I guess a local archive is the easiest then
<persia> Well, a PPA is easier, but the latency from here to there makes downloading annoying.
<minghua> persia: Make a PPA mirror! :-)
<persia> minghua: Now there's an idea I never imagined promoted.
<superm1> folks i've got a small app up for revu if someone else would like to take a glance: http://revu.tauware.de/details.py?package=project-x
<jonnymind> Hello ppl; I have cleared the last stoppers from pochu on http://revu.tauware.de/details.py?package=falconpl
<jonnymind> I think it should be clean now. Is there someone willing to have a look?
<Coper> Hi can a REVU admin resync REVU uploaders keyring?
<persia> Coper: starting now.  Takes about 20 minutes.
<Coper> persia: okej, thanks
<habit_> Hello. I am newbie. Can somebody teach me how to make packages (allready done with google, with ubuntu links). Just advice me how to solve some troubles.
<habit_> ?
<azeem> habit_: describe your troubles, and maybe somebody will be able to help you
<habit_> I have done with dependencies, with dev packages needed for compilation, so, 'make' works fine and create binaries. 2nd step I have opened ubuntu packaging manual. At the begining as I understood I need to do 'dpgk -x source_tarball.tar.gz
<habit_> Oups, mistake, dpkg-source -x
<persia> habit_: That's not quite how I'd start.
<persia> If you have a working upstream that compiles from source, the first step is usually tar xzf upstream-tarball
<habit_> But dpkg-source returns an error.
<azeem> dpkg-source acts on Debian source archives, not random upstream tarballs
<persia> Then, move the upstream tarball to $(package)_$(version).orig.tar.gz and change the directory name to $(package)-$(version).  Create a "debian" directory in the new working directory, and add your control, copyright, and rules file.  Step down one directory, and create your copyright file with dch.
<persia> At this point, `debuild -S -sa` should generate you a source package, which you could later use with dpkg-source -x
<habit_> One question - i didn't understood what actually I must do with 'tar xzf'
<persia> habit_: Unpack the upstream tarball
<habit_> Guys, I'm sorry for maybe very stupid questions, but I'm totally newbie with computers :) So 1. I must unpack sources, create there 'debian' directory with needed description files and then I must run @ that directory (root unpacked sources directory I mean) 'debuild -S -sa'
<habit_> Right?
<persia> habit_: Yes.  You also have to make sure to rename the upstream tarball and unpack directory.
<habit_> persia, the renaming is for later making "right-way tarball"? So I can just delete original tarball?
<habit_> Now I have wired-0.6  wired_0.6.orig.tar.gz  wired_0.6.tar.gz directory and files.
<persia> habit_: No.  debuild expects you to be in a directory named $(package)-$(version), and may behave oddly if you are not.  It also expects the upstream tarball to be in the parent directory and named $(package)_$(version).orig.tar.gz, and will likely be unable to build a source package if it is missing (or may build a native package, but that isn't what you want).
<persia> Ah.  Yes.  You want wired-0.6 and wired_0.6.orig.tar.gz.  You don't need wired_0.6.tar.gz
<habit_> What files I must put into DEBIAN folder?
<persia> That is part of the binary package, and will be generated from the contents of the debian/ directory in the source package.
<habit_> Now I have wired_0.6  wired_0.6.orig.tar.gz . Wired_0.6 - is unpacked wired_0.6.orig.tar.gz, but with debian folder into them.
<habit_> Right?
<persia> habit_: Right.  When you make the source, you will also get wired_0.6-0ubuntu1.diff.gz and wired_0.6-0ubuntu1.dsc.
<habit_> Make the source mean 'cd wired_0.6 && debuild -S -sa'
<habit_> ?
<persia> habit_: You might want to run `dget http://launchpadlibrarian.net/10123377/wired_0.5.1%2Bdfsg2-0tsmithe3.dsc` to see previous packaging work on wired, and contact Toby to collaborate.
<persia> habit_: Yes.  That would be making the source.
<habit_> One more question. What files must contain DEBIAN directory?
<habit_> AH, sorry )
<habit_> Just saw your link.
<persia> habit_: Note that wired is a fairly complex package, as it incorporates all of a library, an application, and some plugins.  You might want to try packaging something simpler to become familiar with the process first.
<habit_> Actually I think I will not familiar never with it :)
<habit_> As I think that it for "power users" and developers.
<habit_> I am only normal user..
<habit_> Whatewer )
<habit_> persia, cannot find toby's contact. dget doesn't work also.
<habit_> How I can search it?
<vorian> habit_: check the changelog
<persia> Grr.  I thought dget was supposed to work with launchpad now :(
<vorian> woops
<persia> habit_: dget http://ppa.launchpad.net/tsmithe/ubuntu/pool/universe/w/wired/wired_0.5.1+dfsg2-0tsmithe3.dsc
<habit_> Now I must make debian folder like @ that file and do 'cd wired_0.6 && debuild -S -sa' yep?
<habit_> I think I'm really annoing :(
<habit_> But if I will take it once, I'll help next newbie :)
<persia> habit_: https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate may be helpful
<rzr> persia: BTW, debian policy suggests now to use '~' in version names
<persia> rzr: In what context?  ~ has been supported for a while.  Is there a new update to policy including that?  Are they now supposd to be used more often?
<rzr> I saw that days ago in /usr/share/doc/debian-policy/changelog.gz
<rzr> * Bug fix: "[PROPOSAL] Document ~ behavior in version numbers", thanks
<rzr>     to Nicolas FranÃÂ§ois and Marc Brockschmidt                (Closes: #382612).
<broonie> It's just an update to policy to reflect existing usage of ~.
<persia> rzr: Right.  '~' has been there for a while.  3.7.3.0 finally included documentation of this behaviour.  Next question: did I tell you something this contradicts?
<Coper> persia: I have still problems with getting a email with my password in REVU.
<persia> Coper: REVU doesn't send emails with passwords.  Have you uploaded anything?
<rzr> persia: i dont think so  this makes me think we you pasted the wired dsc
<Coper> Yes I think everything is uploaded.
<persia> rzr: Ah.  Yes.  That package wasn't ready for the archives.  I just thought it would be a good reference for habit when trying to start out, as it at least included the package split correctly, and handled a lot of the DFSG removals.
<persia> (and was the same upstream)
<Coper> When I try to recover password for my email, REVU says that there is no account. And my fil is not listed on the site.
<persia> Coper: Which package did you upload?
<Coper> console-freecell
<persia> smater: dcut doesn't work on REVU.  Just wait 10 minutes and upload again.
<persia> Coper: Get your password from http://revu.ubuntuwire.com/lostpw.py?email=lars@dunemark.se and look at your package from http://revu.ubuntuwire.com/details.py?package=console-freecell
<StevenK> dcut is a Debian-ism
<StevenK> It doesn't work for Ubuntu either
<persia> StevenK: Maybe someone could patch dput to not tell the user to use it?
<StevenK> persia: Maybe one could use it to sharpen their Python skills? :-)
 * persia goes to look at dput...
 * StevenK chuckles
<StevenK> persia: I've got patches in dput, so if you want to run stuff past me, sure
<Coper> persia: okej, the problem was that I was looking at http://revu.tauware.de/
<persia> Coper: Same site.  Same code.  Different name.
<persia> (same data too)
<Coper> okej..
<persia> Coper: The run only happens 5 times an hour or so.  You likely cheked just before the run, and I just after.
<persia> Does dcut work on mentors.debian.org?
<StevenK> Good question. I have no idea.
 * persia decides to only block on "ubuntu", "revu", "local", and "ppa" for now.
 * persia decides understanding python is a morning activity
<smarter> hi there
<smarter> could someone please review my packages? http://revu.ubuntuwire.com/details.py?package=extremetuxracer and http://revu.ubuntuwire.com/details.py?package=kde4-style-bespin
<Coper> How do I create a binary package from my dsc file if I want to add it to my ppa repos?
<effie_jayx> Coper, you must build it
<rulus> Coper: just upload the source package, it gets build by Launchpad's build daemons (PPA support in #launchpad btw)
<effie_jayx> rulus,  wow :O
<rulus> If I'm wrong, please tell :p
<Coper> so it's just to wait then. :)
<rzr> man dget
<rzr> man dput
<civija> DktrKranz: could you please review this and let me know do you need any more info about this https://bugs.launchpad.net/bugs/184261? TIA
<ubotu> Launchpad bug 184261 in slrnface "slrnface doesn't display X-Face header" [Undecided,In progress]
<DktrKranz> civija, thanks for the pointer, I forget to check, I'll look at it now :)
<civija> ok :)
<DktrKranz> probably, I'll need your help to setup something, though
<civija> just let me know
<DktrKranz> civija, ok. I've got slrn up and running (or at least I think so), could you point me to a newsgroup with some discussion with X-Face headers in?
<civija> DktrKranz: subscribe to group news.software.readers
<DktrKranz> civija, mh, I've got news.software.misc, no .readers... I think I need to switch server
<civija> DktrKranz: do you have alt.test?
<DktrKranz> No
<civija> jeez :)
<DktrKranz> :)
<mok0> What do you do if upstreams package comes in two archives, and you want to make one source package? Is there a smart way of dealing with this, without repackaging and merging?
<DktrKranz> civija, which NNTP server are you using? If it is free, I can connect to it
<civija> DktrKranz: i'm using my isp news server which allows access only for ip's from my country
<civija> DktrKranz: wait, i'll find something
<civija> server or newsgroup or ...
<DktrKranz> civija, do they provide some exceptions from their neighbours? I'm not far away from you :)
<civija> DktrKranz: only if you are their user :)
<civija> DktrKranz: btw: where are you from? :)
<DktrKranz> Italy
<civija> hehe, cool :)
<jdong> ha this is so sweet....
<jdong> using a 37" LCD HDTV as a terminal :)
 * jdong runs a matrix screensaver and pretends to do work
<geser> jdong: which resolution?
<civija> DktrKranz: do you have any test group on your server? i.e. it.test or something else ...
<jdong> geser: it's a cheapie, 1024x768 currently, it's only 1080i
<jdong> geser: was only recently able to obtain an HDMI cable at a price I felt was fair; before this TV was used as... um.... furniture? visual decoraton?
<DktrKranz> civija, is there a quick way to sort or find them? They don't seem to be sorted
<civija> DktrKranz: try shift-l
<DktrKranz> civija, nervermind, I found use of backslash, and I found news.software.readers too
<civija> DktrKranz: ok :)
<civija> DktrKranz: wait i'll found some article on news.software.readers that has x-face in it
<DktrKranz> good
<DktrKranz> in the meantime, I'll test build slrnface with your patch in
<mok0> Is there a policy on how to repackage if you fetch stuff from CVS?
<civija> DktrKranz: open news.software.readers, you see thread with subject: [Leafnode] & [slrn] page: Comments?
<civija> do you*
<DktrKranz> civija, I see only 67 threads, and yours is not between them. Is there a way to expand buffer?
<rexbron> Hey everyone! I am looking for a review of a small C library called openFX. http://revu.ubuntuwire.com/details.py?package=libopenfx
<civija> DktrKranz: ok, nevermind
<DktrKranz> civija, found!
<civija> hehe :)
<civija> DktrKranz: dou you see author named mike yetto in that thread?
<DktrKranz> Yes
<civija> ok, he has x-face
<civija> when you open that article if slrnface works it should display a little picture on your screen
<civija> top left corned by default
<civija> corner*
<civija> top right, sorry :)
<civija> DktrKranz: does it display anything?
<DktrKranz> No picture at all, just a black square
<civija> ok, wait i'll just check something
<civija> DktrKranz: black square size about 48x48 px?
<DktrKranz> so it seems
<civija> can you move that square around the screen? left click and hold
<DktrKranz> I got a face now
<civija> how?
<civija> what did you do?
<DktrKranz> Nothing relevant, just followed your instructions
<civija> DktrKranz: ok
<civija> DktrKranz: it seems that it works for you without a patch
<civija> are you using hardy?
<DktrKranz> yes
<civija> ok
<DktrKranz> I'll post a screenshot
<DktrKranz> civija, http://img104.imageshack.us/img104/1025/slrnsj2.png
<civija> DktrKranz: yep, that's it
<DktrKranz> do you want me to test on gutsy too?
<civija> DktrKranz: i would be most gracefull :)
<civija> if it isn't too much trouble for you
<DktrKranz> absolutely not
<DktrKranz> civija, for your reference, I found thread you showed in your bug report, and I'm able to see shark in my first try
<DktrKranz> now, let's try guysy
<DktrKranz> *gutsy
<civija> DktrKranz: ok, tnx
<DktrKranz> civija, gutsy works well too... I keep compiz off.
<civija> DktrKranz: thank you very much for you help
<DktrKranz> you're welcome :)
<civija> it seems that problem is somewhere else then
<DktrKranz> I guess so
<civija> i'll look into it more :)
<DktrKranz> Is it ok for you to unsubscribe u-u-s?
<civija> DktrKranz: yes, but i can't unscribe them only myself
<civija> unsubscribe*
<DktrKranz> I'll do it now.
<civija> ok, tnx
<DktrKranz> Try to look into .slrnfaces directory in your home if there's some pipe in when displaying faces
<DktrKranz> as suggested by README
<civija> will do
<Coper> I have some problem with my package that I don't get any binary inluded in my package.
<Coper> I get all README files and that shoudl be added to /usr/share/doc/... but no files are copyed to /usr/bin.
<DktrKranz> Coper, do you use debhelper or cdbs?
<Coper> debhelper
<ion_> cdbs uses debhelper
<DktrKranz> Coper, do you use dh_install (and associated files) or invoke install in your rules?
<Coper> in binary-arch: build install  there is a # before dh_install
<Coper> and no dh_install in the install: section.
<StevenK> ion_: CDBS doesn't have to use debhelper.
<DktrKranz> Coper, it seems your rules lacks some install routine, could you please show us in pastebin?
<DktrKranz> !paste
<ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<ion_> stevenk: True indeed. Iâve just never seen anyone using CDBS without using debhelper. :-)
<Coper> http://paste.ubuntu-nl.org/53562/ <- There is my rules file.
<bddebian> Heya gang
<DktrKranz> Coper, it seems "$(MAKE) DESTDIR=$(CURDIR)/debian/freecell install" does not work properly
<Coper> DktrKranz: should it point to the binary that should be installed?
<Coper> example $CURDIR/src/freecell
<tjaalton> persia: ok I'll try to find a test case
<DktrKranz> Coper, DESTDIR is fine
<shibata> Hi, all.
<shibata> I would like to create package of poppler-data.
<shibata> This package include adobe cmap files which need to display CJK fonts in PDF.
<shibata> License of cmap files is Redistribution is OK, "altered" is NG. Probably, "altered" mean "modify".
<shibata> Should I upload it into multiverse?
<shibata> If so, can I upload revu in the same way as universe package?
<civija> DktrKranz: can I close LP #184261 or you have to do that?
<ubotu> Launchpad bug 184261 in slrnface "slrnface doesn't display X-Face header" [Low,In progress] https://launchpad.net/bugs/184261
<DktrKranz> civija, you can close it, if you think everything is fine now.
<DktrKranz> thanks for investigating :)
<civija> DktrKranz: ok, is there anywhere close link or something? :)
<DktrKranz> just set status to Invalid
<civija> ok, tnx
<DktrKranz> you're welcome
<hellboy195> Also Debian folks are lazy at documenting changes -.-
<hellboy195> hoi DarkSun88 :)
<DarkSun88> Hi hellboy195
<hellboy195> ahoi jono :)
<Hobbsee> oh noes, it's jono!
 * jdong pings jono too because it seems to be a fad :)
<jono> hey folks
<jono> :)
 * ion_ performs a man-in-the-middle attack when jdong pings jono
<jono> hehe
<DktrKranz> hellboy195, in bug 186035, it seems Debian fixed something which Ubuntu managed in edgy with 1.99.16-8.1ubuntu3, is is worth merge it?
<ubotu> Launchpad bug 186035 in oleo "Merge oleo  1.99.16-10 from Debian(Unstable)" [Wishlist,In progress] https://launchpad.net/bugs/186035
<hellboy195> DktrKranz: I was very unsecure with that merge. I'll check it later again
<DktrKranz> hellboy195, thanks. Also, since you dropped some changes, could you explain why?
<hellboy195> DktrKranz: if you have time would you mind telling me what's exactly false? Maybe I only forgot some ... :/
<DktrKranz> hellboy195, I'll be back in about an hour, will you be there, so we can look at it?
<hellboy195> DktrKranz: sure :) thx
<DktrKranz> c u later then :(
<DktrKranz> erm.. wrong smiley
<DktrKranz> :)
<hellboy195> ah
<hellboy195> ^^
<hellboy195> k, cya
<hellboy195> I'm doing a merge some things changes I wanted to test it with pbuilder. But I get an error debhelper (>=6) is not installable and I should remove pbuilder-satisfydepends-dummy
<hellboy195>  to solve the problem. so how to remove that?
<geser> hellboy195: debhelper 6 isn't in hardy yet
<geser> hellboy195: either downgrade the build-depends to debhelper 5 (and also debian/compat) or wait till debhelper 6 is merged
<hellboy195> geser: ah. good to know :) any idea how long it will take until v. 6 is in hardy?
<geser> hellboy195: depends on my sponsor
<geser> I hope in the next week
<hellboy195> geser: so what do you advice me for my merge? downgrade or waiting?
<RainCT> Adri2000: Hi. Anything new? :)
<geser> hellboy195: it's up to you, but if you can wait (and the merge isn't important) I'd wait to not introduce extra changes compared to Debian which can be dropped again soon
<hellboy195> geser: Yeah I also think so. And it's not that important I think so I'll wait. Thx :D
<the_belgain> hi, is there any way to package a program which requires a version of ffmpeg supporting non-free codecs (aac, mp3, xvid, ...) at the moment?
<the_belgain> because the version of ffmpeg in universe is compiled without support for these
<the_belgain> the comments in the bug suggest the answer is no, but i just wanted to double-check: https://bugs.launchpad.net/ubuntu/+source/ffmpeg/+bug/6366
<ubotu> Launchpad bug 6366 in ffmpeg "Please enable AAC Support in ffmpeg" [Wishlist,Confirmed]
<the_belgain> snap.  shame
<the_belgain> looks like this isn't something which is being actively worked on?
<the_belgain> is there a compelling reason why two separate (free and non-free) ffmpeg packages couldn't be provided?
<proppy> hi
<bddebian> Hello proppy
<crimsun> the_belgain: there are arguments both ways, but in addition to the source bloat (having to maintain separate versions), there is the compelling factor that no one with commit access wants to touch it.
<crimsun> the_belgain: if you'd like to volunteer to ensure that the non-free version remains synced at all times with the free one, then please submit a source package to REVU.
<crimsun> the_belgain: if you're unfamiliar with Debian or Ubuntu packaging, the links in the topic of this channel are a good place to start, particularly under Contributing.
<the_belgain> i'm in the process of becoming familiar with deb packaging (i'm currently packaging a program which uses ffmpeg, hence my question)
<Seveas> the_belgain, heh, you've picked an awful starting point :)
<Seveas> ffmpeg is insane
<jonnymind> Good evening.
<the_belgain> well it looks from the debian/rules in ffmpeg that enabling / disabling the non-free codecs is just a case of setting/unsetting a single debian build flag ("risky") - ffmpeg has been packaged in such a way that it should be straightforwardish to recompile from souce
<DktrKranz> hellboy195, back here.
<hellboy195> DktrKranz: wb :)
<the_belgain> so an ffmpeg-nonfree package would be identical to ffmpeg-free but with that debian build flag set?
<the_belgain> that still leaves the issue of keeping them in sync though - is there any mechanism to keep similar debian packages in sync with each other (a simple diff-based mechanism, in the same way that a package itself has the program source plus a diff against it)?
<crimsun> you'd also need to modify debian/control* so that the appropriate new binary package(s) and build-dependencies are set.
<hellboy195> DktrKranz: query?
<DktrKranz> hellboy195, probably here is better, unless someone complains
<hellboy195> DktrKranz: np
<the_belgain> debian/rules already adds the required dependencies to the weak-build-deps variable - at the moment it then just prints it out to screen, but presumably these can just be added to debian/control, yes
<the_belgain> is the "risky" build string a standard string which gets set or unset, or just something someone's added here?
<DktrKranz> hellboy195, in 1.99.16-8.1ubuntu3, we put "chmod -R 644 debian/tmp/usr/share/doc/$(package)/examples/*", which is basically what 1.99.16-10 does.
<hellboy195> DktrKranz: ah, right
<DktrKranz> hellboy195, in that revision, it seems translog files have been removed
<DktrKranz> I really don't know what they are, though. Probably some junk stuff inserted by mistake
<hellboy195> DktrKranz: hmm
<hellboy195> DktrKranz: postrm for example?
<DktrKranz> I'm referring to http://dad.dunnewind.net/oleo/oleo_1.99.16-10.patch, translog.20010520153852.log and translog.20010602042022.log
<jeromeg> can anyone review my SRU proposal ? bug 184112
<ubotu> Launchpad bug 184112 in klavaro "[SRU] klavaro crash" [Wishlist,Incomplete] https://launchpad.net/bugs/184112
<hellboy195> DktrKranz: ah, I don't suppose we need them?
<DktrKranz> hellboy195, me too.
<DktrKranz> They shouldn't be published anywhere but in .diff.gz, though
<hellboy195> DktrKranz: well I didn't remove them, the Debian folks did it so hopefully they know what they do
<DktrKranz> I think they can be safely removed, but let's see if they are referenced somewhere
<hellboy195> DktrKranz: I don't think that they are used. Or have you found something?
<jeromeg> jdong: hello !
<jeromeg> would you mind ack'ing some backports please ?
<DrKranz> jeromeg, hi. Does bug 184112 triggered only with french locale?
<ubotu> Launchpad bug 184112 in klavaro "[SRU] klavaro crash" [Wishlist,New] https://launchpad.net/bugs/184112
<jeromeg> DktrKranz: seems so, some say it also happens with the Spanish locale
<DktrKranz> jeromeg, I'll try with italian one too
<jeromeg> ok thank you
<DktrKranz> Only Gutsy seems affected?
<hellboy195> DktrKranz: so. any others things to change beside the "chmod -R 644 debian/tmp/usr/share/doc/$(package)/examples/*" ?
<jeromeg> DktrKranz: yep fixed it got fixed in hardy thanks to our forwarding of bugs :)
 * DktrKranz hugs bugsquad
<DktrKranz> hellboy195, since there are some changes, we'll need to look at them more carefully
<hellboy195> DktrKranz: I'm ready ;)
<DktrKranz> since a couple of them sounds weird to me
<DRebellion> When the rules file is executed, what is its current directory?
<DktrKranz> DRebellion, the one which contains debian directory
<hellboy195> DktrKranz: I'm going to have dinner now. Ping me if you have time :)
<Coper> I have a problem with that my last 2 dput of a package to REVU didn't get the orig.tar.gz file uploaded. Anybody know why?
<DktrKranz> Coper, when uploading to REVU, remember to use -sa flag when launching debuild or dpkg-buildpackage
<Coper> DktrKranz: okej, will try agian.
<DRebellion> DktrKranz: so the directory above debian/? eg. i have monkeystudio/debian/rules . when rules is executed its current directory will be monkeystudio/ ?
<jeromeg> got to go, bye
<DktrKranz> DRebellion, yes
<DRebellion> DktrKranz: thanks
<jonnymind> people, a question on dh_makeshlibs
<jonnymind> the man says it "adds" ldconfig calls to postinst/postrm
<jonnymind> if those scripts are unneeded except than for that, they should be present in the source package or not?
<luckyone> when could I expect to see Tomcat 6 in the repos?
<Seveas> luckyone, when someone packages it :)
<luckyone> Seveas: could any old idiot be a packager (me for instance)?
<Seveas> any idiot willing to spend some time on learning packaging
<Seveas> !packagingguide
<ubotu> packagingguide is The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
<luckyone> Seveas: is it pretty tough?
<Seveas> it takes some time to get the hang of it
<luckyone> Seveas: thank you for the info - and thanks for all your work - I have your repos in my source.list :D
<jonnymind> An OT question: Why, when I put myself in away, and my nick stays the same, i am being pinged by MOTUS saying I should not changing my nick and using /away instead?
<mgdm> jonnymind: does your client send a message to the channel when you go away?
<jonnymind> yes
<jonnymind> Well, to the server.
<mgdm> That's why
<pochu> jonnymind: because of that
<jonnymind> Oh, ok, I will part from the channel before going away
<pochu> jonnymind: emilio@venus:~/.irclogs/Freenode$ grep jonnymind \#ubuntu-motu.log | grep 'jonnymind is away' | wc -l
<pochu> 14
<mgdm> if you're just setting /away then you're fine, but if you spam the channel with "jonnymind is away [BX MsgLog: on]" or some nonsense you will be frowned upon
<pochu> jonnymind: just deactivate that script!
<jonnymind> It's not a script; it's xchat.
<jonnymind> let me see...
<blueyed> I'm at the grep package, which uses autotools.mk and tarball.mk in debian/rules. How can I rebuild the grep-2.5.3.tar.gz?
<jonnymind> Ok, fixed. Sorry for the distress.
<jonnymind> people, I have made dh_makeshlibs -p libfalcon-engine1 -V in the package and removed postrm and shlibs, and now...
<jonnymind> gian@hplin:~/tmp/falbuild_ubuntu/falconpl-0.8.8$ lintian /var/cache/pbuilder/result/*.deb
<jonnymind> Elly: libfalcon-engine1: no-shlibs-control-file usr/lib/libfalcon_engine.so.1.9.0
<jonnymind> Elly: libfalcon-engine1: postinst-must-call-ldconfig usr/lib/libfalcon_engine.so.1.9.0
<jonnymind> (sorry Elly, that was just E:)
<ion_> :-D
<ion_> Iâve never understood why that âfeatureâ was implemented and why people use it. :-)
<pochu> jonnymind: your last upload to REVU doesn't have a dh_makeshlibs call
<jonnymind> Yes, that was a test, sorry.
<jonnymind> I am testing with dh_makeshlibs
<pochu> jonnymind: ok. -V needs an argument (the version)
<jonnymind> No, it doesn't need it, but I get it:
<jonnymind> dh_makeshlibs creates the files in /debian
<jonnymind> they must then be installed with something as
<jonnymind> dh_installdeb
<pochu> Call dh_installdeb then :)
<pochu> +too
<jonnymind> yes; I was going to try it :-)
<jonnymind> same
<jonnymind> dh_installdeb
<jonnymind> dh_shlibdeps
<jonnymind> dh_install -plibfalcon-engine1 --sourcedir=debian/tmp
<jonnymind> after dh_makeshlibs -p libfalcon-engine1 -V
<luckyone> I am working on setting up fax-to-email on my asterisk server, but I am getting an error using SetVar()
<luckyone> hah wrong channel
<joejaxx> luckyone: lol
<joejaxx> Good Afternoon All :D
<jonnymind> pochu: I got it.
<jonnymind> I was calling the utils before installing the package in the local dir, and there was no warning about the missing files.
<jonnymind> Uploading
<stgraber> pochu: Yeah, virtualbox on 2.6.24 !!! :)
<pochu> stgraber: let me know what I broke when the buildds do their work ;-)
<pochu> (NB: I tested it) :)
<LaserJock> hmm, we really should get the "Maintained by: MOTU Media" thing fixed
<LaserJock> anybody know what "modified" on merges.ubuntu.com means?
<Flare183> LaserJock: means someone has messed with it
<LaserJock> hmm, "local" and "repackaged" are I guess the ones I'm wondering about
<LaserJock> I was trying to find an easy way to find the number of Ubuntu-changed packages
<LaserJock> grepping through _Sources is faster :-)
<vemon> what are the files in /usr/share/menu used for?
<geser> vemon: for the Debian menu which is disabled by default on Ubuntu
<vemon> is it ok for an ubuntu package to be lacking that kind of menu file?
<vemon> providing that the package already has a .desktop -file
<geser> LaserJock: you could also use the mdt summary to get those numbers
<geser> LaserJock: Same version, but Hardy has local changes : 1218 packages + Outdated in Hardy (Sid version > Hardy version), and Hardy has local changes : 269 packages + Outdated in Sid (Hardy version > Sid version) : 121 packages
<geser> 1608 total
<Taggard> Hi.
<Taggard> I'd like to help with Ubuntu somehow and I'm looking at MOTU but I'm not exactly sure what you do. I think you package packages into .debs, but there also seems to be things about you coding bugfixes and such.
<geser> Taggard: yes, packaging new software is one aspect but fixing existing packages is also important
<pochu> Taggard: https://wiki.ubuntu.com/MOTU/GettingStarted
<LaserJock> geser: yeah, but the mdt summary is wrong
<LaserJock> geser: there are 10869 packages in universe and 1770 with Ubuntu versions, that doesn't even come close to what the mdt page has
<Taggard> geser, pochu: I think I am competent enough to package software (probably), but I don't have coding experience other than Ruby or a little Python. Is coding experience required here, or are languaged like c++ or c required?
<jpatrick> Taggard: (ruby rocks), languages aren't needed but recommended
<Taggard> jpatrick: (Yeah it does), Okay.
<geser> LaserJock: we modified of 16% of the source packages? wow
<LaserJock> yes
<LaserJock> the mdt page is a bit messed up, I think something must've gone wrong in Fujitsu's script
<LaserJock> it works fine for Science bugs, but Universe has 0 for packages where Sid == Hardy and that's not right :-)
<blueyed> mdt?
<LaserJock> multidistrotools
<geser> Taggard: coding experience isn't required. Often patches/fixes exist already, you just need to find them and seldom write them on your own. You just need to apply them on the package and test if it fixes it.
<LaserJock> blueyed: http://qa.ubuntuwire.com/multidistrotools/universe.htm for instance
<blueyed> +l
<LaserJock> warp10: ;-)
<warp10> hey LaserJock :)
<Coper> Can someone revu my package? http://revu.ubuntuwire.com/details.py?upid=1517
<luckyone> when trying to build a package, why is it saying that I am missing glibconfig.h?
<luckyone> I have the -dev package installed
<blueyed> luckyone: which package? Try apt-get build-dep <package>
<luckyone> trying to build source for agx-ast-addons
<luckyone> I think the build script I am using is puking on cmake "." -DCMAKE_INSTALL_PREFIX=/usr
<jpatrick> luckyone: maybe the makefiles have the header paths incorrectly set
<geser> luckyone: does it happen during configure or during the build?
<luckyone> geser: there isn't a .configure script, just a build.sh
<geser> luckyone: does it use the correct include path for glibconfig.h?
<luckyone> geser: I can't tell which cmake file it is using for the path
<luckyone> geser: /usr/include/glib-2.0 /usr/lib/gl
<luckyone> ib-2.0/include
<luckyone> good to go now, thanks
<LaserJock> yikes, Planet Gnome has some not-so-friendly remarks on our SRU policy
<jpatrick> LaserJock: ouch..
<amarillion> "who will eventually contribute to the Yodeling Yak version of Ubuntu?"
<amarillion> That is going to be Ubuntu 16.10...
<pochu> Taggard: I didn't know any programming when I started (and I don't know much nowadays...)
<LaserJock> me neither
<Taggard> pochu: :)
<geser> LaserJock: there will always be people unhappy with the SRU policy. Either people complain that it's to restrictive or people complain that stable changes to much
<LaserJock> yeah, but it's a bit trickier when it's upstreams that are unhappy
<geser> LaserJock: we wonders what those people think of Debian stable where gnome is much older
<geser> LaserJock: doesn't upstream always want the last, best version in stable?
<LaserJock> the kind of thing that guy is talking about doing, putting a warning in Gnome software about Ubuntu, is a bit troubling
<geser> sound like the ion3 issue where upstream was unhappy about Debian stable shipping old devel versions and changed the license which lead to moving ion3 to non-free
<LaserJock> yeah, but unlike ion3, people actually use Gnome ;-)
<zoke> what is this converstaion about ?
<zoke> is Gnome warning it's users about Ubuntu or what ?
<LaserJock> zoke: http://blogs.gnome.org/phomes/2008/01/26/ubuntu-update-policy-suckage/
<zoke> LaserJock, can't this be fixed by putting fixes via backports ?
<zoke> and then encouraging the user to use backports ?
<LaserJock> zoke: well, but the same problem exists
<LaserJock> -backports isn't for bug fixes primarily, but for new upstream versions
<LaserJock> it's not meant to have the stability
<LaserJock> what the Gnome guy wants is a stable distro with the latest version of his software
<zoke> LaserJock, isn't that what we all want ?
<Seveas> Pumperni1kle, Pumperni2kle Pumperni4kle Pumperni5kle Pumperni6kle Pumpernickle: dude fix your connection :)
<persia> LaserJock: The list of packages unchanged between hardy & sid is intentionally removed from the ubuntuwire multidistrotools report: it's about 13,000 packages and would otherwise hide interesting information.
<pochu> lol
<LaserJock> persia: that's what I figured
<LaserJock> persia: I'm a little suspicious of the Not in sid: 784 packages
<persia> LaserJock: Why?  The new semi-automated removals script is doing a good job of keeping that down, and several people have been pushing packages to Debian.
 * Taggard is working his wya through the packaging guide.
<persia> Taggard: At this point in the development cycle, you'd likely do better to start working on bugs, rather than packaging new software.
<Taggard> persia: That generally involves coding though, doesn't it?
<persia> Taggard: About 30% of the time.
<pochu> persia: he can do package updates too
<LaserJock> persia: I can't imagine there being more than 100 "not in sid:" packages
<persia> There are lots of bugs that just need some adjustment to the packaging, some patch pulled from upstream, etc.
<Taggard> persia: Surely I do need to do the packaging tutorial to do that though?
<persia> pochu: Deadline for that is also ~2 weeks away.  Better to do bugfixes.
<persia> LaserJock: REVU is a powerful force
<LaserJock> persia: ummm, I guess that's one way of putting it
<persia> Taggard: Depends how you learn.  The packaging tutorial won't hurt.
<LaserJock> a horrendous drag was what came to mind
<Taggard> persia: (:
<persia> LaserJock: Why?  I think that now that we have UEHS, it's significantly less painful.  About half the packages report as up-to-date (I think).
<persia> LaserJock: Err.  Nevermind.  Seems there was less progress than I thought.  About 100 of the packages seem to be in good shape.
<LaserJock> persia: because most of that software should be maintained in Debian
<persia> LaserJock: Why?  A lot of our multiverse media stack is maintained in Debian-multimedia, which inflates the numbers some.  Also, I don't think it is a bad thing to add new software, as long as it is maintained.  As our tools improve, we should be better about this.
<LaserJock> if that page is correct, we roughly 1/3 of the software we maintain is *not* in Debian
<LaserJock> bah, kill the first "we"
<persia> Right.  1/3 of the stuff we touch is not in Debian.  I believe this to be a result of our documentation: we encourage new packaging.  We need to encourage bugfixing more.
<Taggard> Hmm
<Taggard> dpkg-buildpackage sure is picky about the changelog file
<persia> Also, we need to encourage chasing UEHS during merge season: it should be clear by DIF.
<persia> Taggard: The dch tool is your best means of getting it formatted correctly.
<Taggard> persia: Probably, I don't knpw, but I'm just doing the manual section of the tutorial right now
<Taggard> If I continued doing this and made bugfixes would they actually go into the next release?
<LaserJock> persia: well, Multiverse isn't even included in the 784
<LaserJock> Multiverse adds another 84
<persia> LaserJock: Still, from a policy viewpoint, which is better: killing off REVU and saying everything must go through Debian and DMO, or advocating UEHS review at the beginning of each cycle?
<persia> Personally, I suspect the first would annoy Debian.
<geser> Taggard: you mean hardy? yes
<Taggard> geser: That'd be a pretty rewarding feeling
<LaserJock> persia: well, I actually think a bit of both
<LaserJock> I don't think we should totally shut down REVU, but 800+ packages is a lot for us if we have no packaging upstream
<geser> Taggard: for the programming language part: I know C but since I started to contribute to Ubuntu I didn't do much C, more Makefiles or shell scripting and of course the packaging of the fixes
<persia> LaserJock: Utnubu complained that they wanted someone as a point of contact with whom to coordinate.  DCT keeps flailing due to differences in individual preferences of DDs.  Perhaps reinvigorating one or both of these might help?
<LaserJock> well, I think the new DM stuff may make it easier for people to maintain stuff in Debian
<LaserJock> I mean, if people are *actually* going to maintain packages in Ubuntu and have no interest in Debian I think that's fine
<geser> Taggard: it depends on with part you concentrate, there are enough parts where help is needed, e.g. catching unmet deps, fixing package which fail to build (FTBFS), looking out for important fixes in Debian unstable which need to be included in hardy, etc.
<LaserJock> but 1/3 of our package load just seems way too much
#ubuntu-motu 2008-01-27
<geser> are the package introduced through revu currently maintained?
<persia> LaserJock: Maybe.  I think the lack of UEHS was the biggest issue.  Lots of that never got updated as it was working fine.
<persia> geser: Only weakly.  UEHS was intended to assist with that.
<geser> I mean do the packagers update to their packages?
<geser> :(
<LaserJock> but the issue is that it's contributing to our maintenance load, regardless
<LaserJock> if we need to maintain it, it's still a bigger load than syncing from Debian
<Taggard> geser: Defien catching unmet deps
<persia> I just don't think we should reduce features to reduce workload.  Down that road lies an embedded distro.
<LaserJock> no
<LaserJock> I agree to an extent
<LaserJock> but there seems to be this constant push to package new stuff
<LaserJock> regardless of whether it's useful or not
<LaserJock> and that has created quite a lot of packages we have to maintain
<persia> LaserJock: That's just a matter of fixing the documentation, and guidance we give newcomers.  Personally, I really don't like the GettingStarted page, and encourage the use of https://wiki.ubuntu.com/MOTU/Contributing as a better place to start.
<geser> if you run "apt-cache unmet -i" (preferably in a hardy environment) you get a list of packages which can't be installed as there dependencies can't be satisfied. The task it fix them (we never got the list to be empty).
<geser> Taggard: ^^
<persia> Taggard: http://qa.ubuntuwire.com/debcheck/ also has a nice web report that shows some of that.
<LaserJock> persia: agreed. I was just a little shocked. I expected to see something around 100-200
<Taggard> geser: So just packaging new things
<Taggard> Hmm
<Taggard> There are a LOT of problem depends
<persia> Taggard: Yes.  There's a lot of work remaining for hardy.  Anything you could do to help resolve them would be greatly appreciated :)
<geser> Taggard: first you need to find out, why the are unmet deps, e.g. library transitions, removed packages but packages depending on them are still there, FTBFS, etc.
<Taggard> Soundsl ike a good way to get involved with ubuntu
<geser> Taggard: e.g. apache 1.3 got removed from the archive, but there are still some package left which depend on it
<Taggard> geser: What do you do in that case?
<geser> Taggard: check what Debian did, check if it also builds a variant for apache2 and disable then the apache1 package or remove it entirely
<Taggard> Ahh
<awen_> Taggard: it's a good starting point... i got started with packaging in ubuntu solving some 15 of those depending on the old apache
<geser> Taggard: for library transitions it's often to check if it builds with the new version and do a rebuild then
<Taggard> geser: That makes sense
<geser> Taggard: then there is also NBS (Not Build by Source (anymore)): http://people.ubuntu.com/~ubuntu-archive/NBS/
<geser> Taggard: these packages are currently still there but will be removed soon leading to more unmet deps, so should also be fixed
<geser> the files list the packages still depending on them
<mok0> I am fixing a piece of code that's giving me a bunch of warnings:  "deprecated conversion from string constant to âchar*â" . The code becomes really ugly when you have to cast every string constant. What is the rationale behind this change of the C language?
<geser> Taggard: so you see there is enough work where you don't need to do much programming
<persia> There's also the conflict checker: http://conflictchecker.ubuntu.com/possible-conflicts/hardy/, when more than one package provides a file, and the packages may nee to either conflict, or one be changed.
<persia> mok0: unicode
<mok0> persia: I was guessing that. It still looks ugly
<geser> mok0: is it C? I believe I've seen it on C++
<mok0> geser: I think it's in both
<mok0> geser: If it's unicode, C needs the change as well as C++
<persia> mok0: Did you ever get satisfactory answers for your package merge or VCS questions?
<mok0> Yeah
<mcisbackuk> Hi guys, what do I do after packaging a new upstream release? What needs to be uploaded to the Launchpad bug, is it the new diff.gz and dsc, or all of the files, i.e. orig.tar.gz, diff.gz, dsc, dsc.asc, source.build, source.changes??
<mok0> geser: I am using git now to keep track of my packaging, it works great
<persia> mcisbackuk: An interdiff.  Thanks for the reminder: I meant to add changing that to the meeting agenda.
<awen_> mcisbackuk: https://wiki.ubuntu.com/MOTU/Contributing ... look for interdiff
<Taggard> geser: Yeha
<Taggard> geser: Sorry
<mcisbackuk> I couldn't find it on there..
 * persia thinks https://wiki.ubuntu.com/UbuntuDevelopment/Interdiff is a better URL
<mcisbackuk> persia: You're welcome lol
<mcisbackuk> OK so once I've created the interdiff, what needs uploaded?
<persia> mcisbackuk: The interdiff.
<awen_> persia: didn't know that one :)
<mcisbackuk> persia: Just that?
<persia> mcisbackuk: Well, it's good to make sure your watch file will grab the latest upstream, but yes.
<Taggard> http://pastie.caboo.se/143928 > I get this when I am trying to do the Building a package tutorial
<mcisbackuk> persia: Coolio, thanks for your help....again :)
<persia> Taggard: Try debuild.  It wraps dpkg-buildpackage and makes sure you are using fakeroot
<persia> Alternately, install the fakeroot package
<Taggard> persia: debuild where?
<persia> andy@andy-desktop:~/hello/hello-2.3$ debuild -S
<Taggard> Okay (:
<Taggard> persia: Errors
<bddebian> Heya gnag
<bddebian> Err gang
<Taggard> persia: http://pastie.caboo.se/143929
<Taggard> hI bddebian
<bddebian> Hello Taggard
<bddebian> persia: Heya.  How are you with perl/glade? :)
<persia> Taggard: cd ..
<Taggard> Oh, yeah right
<Taggard> I am dumb
<persia> bddebian: Never touched it :)  How can I help?
<bddebian> hehe
<mcisbackuk> persia: One last question sorry lol IF the build of the new source packages fail with debuild will it tell me, I mean if I've done the dependencies wrong will it tell me?
<persia> mcisbackuk: Yes.  Also, best to ask questions generally, even if you know I'll likely answer.  Means I can step away for a bit :)
<Taggard> persia: I get the exact same erorr
<Taggard> error
<mcisbackuk> persia: lol sorry, but thanks alot anyway :) appreciated :)
<bddebian> I'm trying to move dfontmgr to libgtk2-perl and libgtk2-gladexml-perl but it's kicking my arse.  I'm not sure how to get rid of RunPerl
<awen_> Taggard: does debian/rules exists, and does it have executable rights?
<Taggard> awen_: Yep
<dcordero> hi
<dcordero> i have learn how to create my own packages from source codes, and i have practice with various programs. What i could do for start helping on ubuntu?
<awen_> Taggard: sounds strange... seems like it complains for a missing makefile (some error in the rules file maybe)
<Taggard> awen_: Hmm
<persia> bddebian: Do you have a WIP I can hack at?
<Taggard> persia: Are you a team leader or somesuch?
<persia> Taggard: Nope.  I hope to be a member of Council, but won't find out for a few more days.
<Taggard> persia: Ooh :)
<bddebian> persia: I haven't gotten far.  I just changed the build deps and see what breaks.  I'm hoping most of the stuff is just gtk -> gtk2 calls but this Glade::RunPerl::pixmaps_directory I don't see a direct replacement for
<geser> Taggard: persia is a very active motu
<Taggard> What makes someone an official MOTU?
<geser> Taggard: when you hang around here some time, you will often read the same nicks
<persia> Taggard: The process of helping (and eventually joining) MOTU is described in http://wiki.ubuntu.com/MOTU/Contributing
<pochu> Taggard: And you will end asking questions directly to persia (as everybody does), and persia will be annoyed by that :-)
 * awen_ is confused... why would someone package version 0.6 of a package in 2001 when version 0.9 had been avaible since 1999
<persia> bddebian: Hrm.  `grep -ri RunPerl *` in the defoma directory gets me nothing :(
<bddebian> Or you just whine and complain enough like me and they let you in.. ;-P
<bddebian> persia: Sorry, it's PerlRun, I'm dyslexic :(
<Taggard> pochu: Hehe
<Taggard> Debhelper is fancy!
<Taggard> cd de
<Taggard> Oops
<Taggard> :X
<LaserJock> awen_: maybe that's the latest version they found?
<bddebian> persia: Actually I'm thinking about just replacing "$Glade::PerlRun::pixmaps_directory/glade2perl_logo.xpm" with "" anyway :)
<persia> bddebian: That somehow seems excessive.  Does it work?
<awen_> LaserJock: found the reason... the copyright just pointed at cpan.org so had some trouble finding the right package :)
<bddebian> persia: Currently, or you mean if I use "" ?
<persia> ""
<bddebian> That glade2perl_logo.xpm file I can only find in a package called taxbird
<bddebian> I don't think it would change anything since I think that file is really missing anyway
<persia> Sounds safe...Does it work?
<bddebian> Haven't tried it yet :)
<Taggard> http://pastie.caboo.se/143935 : Is this bad?
<Taggard> Should I be replacing that nice?
<persia> Taggard: It can be (and is very common).  If your make clean breaks in a way you didn't expect, it won't tell you.  Better to figure out why it is failing, and trap those conditions.
<Taggard> line*
<Taggard> persia: I changed the line and it stopped moaning
<bddebian> Ugh, DfontmgrUI.pm is going to be much worse :(
<awen_> seems to have lost the link for how to get a sponsor for package removal... anyone has a link to the page describing it?
<persia> bddebian: PerlRun pixmaps handling is now deprecated in favor of the improved icon cache stuff (as far as I can tell).  Safe to kill all that.
<persia> awen_: Just subscribe the sponsors team to your bug as usual.
<awen_> persia: any special status required?
<persia> Generally New is preferred.  The sponsors will set Confirmed when forwarding to the archive admins.
<bddebian> persia: Yeah, I killed that but DfontmgrUI.pm uses "use Glade::PerlRun; "  :-(
<dmaster> where can I find .iso file help?
<Taggard> .. YAY!
<Taggard> I just made my first ubuntu package!
<LaserJock> Taggard: rockin!
<persia> bddebian: `grep -ri PerlRun * | grep -v pixmaps` tells me that you shouldn't care.
<Taggard> I don't acutally know where it went though.
<Taggard> dpkg-buildpackage said it is in .. but it isn't
 * persia encourages someone to hijack bug #152348 so we have it fixed for hardy
<ubotu> Launchpad bug 152348 in mmm-mode "on feisty, the mmm-mode package forces installing emacs21 instead of emacs22" [Undecided,In progress] https://launchpad.net/bugs/152348
<Taggard> persia: Is this an easy bug?
<Taggard> persia: Doesn't this just involve fixing some dependancies in debian/*
<persia> Taggard: Yep.  And there's a patch.  It just needs a little massage to be included.
<Taggard> persia: Do you think .. I could do it *gasp*
<persia> Taggard: Sure.  Give it a shot.
<Taggard> persia: Okay
<Taggard> persia: Can I be annoying and ask you if I am doing it right?
<persia> Taggard: No, but you can ask for help in this channel, and I may well answer :)
<Taggard> Hehe
<pochu> Taggard: do you see it? I told you you would end asking him directly ;-)
<Taggard> Hmm, I don't actually know how to apply the patch
<Taggard> And hwat to apply it to
<persia> Taggard: Look in the testing debdiffs section of https://wiki.ubuntu.com/MOTU/Contributing
<Taggard> Okay
<Taggard> I updated the dependancies and added this to the changelog but I remember seeing somewhere I included the bugid in the changelog but I forgot where and how
<Taggard> Can anyone tell me?
<persia> Taggard: https://wiki.ubuntu.com/ClosingBugsFromChangelog
<Taggard> (:
<Taggard> I get this now: http://pastie.caboo.se/143941
<Taggard> (Sorry for all this newishness)
<bddebian> persia: The way I read the Gtk2::GladXML stuff, I shouldn't have to use the generated perl files at all I don't think
<persia> bddebian: cruft removal for the win!
<LaserJock> Taggard: that looks ok
<Taggard> LaserJock: oh.. I'm silly
<Taggard> Ugh
<Taggard> I thought that was meant to compile
<Taggard> That is pbuilder isn't it
<Taggard> Okay, well, I've compiled it
<Taggard> It says it put it in .. but it didn't
<Taggard> So I don't know where it is
<pochu> Taggard: /var/cache/pbuilder/result/ possibly
<Taggard> Okay
<emgent> heya *
<Taggard> Yup, it is there.
<Taggard> Okay, so what now?
<Taggard> I have fixed the bug.
<persia> Taggard: Review the contributing page again.  Make sure you are only incrementing the Ubuntu revision, attach the debdiff, and subscribe the sponsors.
<Taggard> Okay :)
<Taggard> xemacs22-basesupport (>= 2003.11.13-1): This is a requirement in the control file I noticed after I built the .deb. I Now think I should be changing the date to something but I don't know what. Any ideas?
<persia> Taggard: If you haven't already, you might want to look at the other patches attached to the bug.  My memory is that it was a good solution, and the only missing part was with the changelog (although circumstances may have changed in the meantime)
<Taggard> Ahhh, yes.
<awen_> libapache-* packages with broken depends for hardy slowly approaching zero :)
<persia> awen_: Excellent work.  Thanks.
<awen_> persia: i've sent three more removal requests at the sponsor list now... so only one left; awaiting some sort of reply from the debian maintainer for a little longer
<persia> awen_: Do you have your next project already planned?
<vorian> evening :)
<awen_> persia: next project = going to bed.... but i could be needing a project for tomorrow, if you have one lying around? ;)
<persia> awen_: I generally recommend people find projects that interest them, but if you're stuck for what to do after you finish the apache1 rdepends, I can probably find you something.
<Taggard> This is annoying me :(
<awen_> persia: i'm trying to get the imapsync package to work for hardy atm.; but hope to get it through debian as it needs a new package to be included
<persia> awen_: Feature Freeze is 14th February.  With the deadline looming, REVU may be faster (although there are only two more REVU days, so it may not be)
<RAOF> Hooray for cooperative upstreams!  gtk-nodoka-engine now has license headers.
<awen_> persia: it needs an old version of a package; so need to include it with a new package-name and patch it so it can co-exist alongside the new version... and that package should really be called the same in both debian and ubuntu i suppose
<persia> awen_: Would it not be better to port the app to work with the new version?
<dcordero> hi, i have a problem solving a bug, i am updating a package tacking as source a debian package, have i write on changelog something?
<awen_> persia: i've talked to the maintainer... he has started the project slowly, but has given up porting to the new version; so this seems the best solution to me for now
<awen_> but as always; i might be wrong, good proposals is welcome :)
<vorian> ping pochu :)
<persia> vorian: Better to ask your question (and I agree with pochu)
<vorian> persia: on the upstream site, it says this package requires chmlib and htmldoc
<vorian> http://code.google.com/p/chm2pdf/
 * persia looks harder
<vorian> The package builds fine with no lintian warnings
<bkudria> i'm new to fixing ubuntu packages, and i'm previewing my debdiff, and it looks like it's added and deleted identical lines (in the description in debian/control).  i only chnaged the maintainer to MOTU from the debian address, and i didn't change the description at all.  why is the extra change appearing?
<vorian> well, with the suggested changes
<persia> bkudria: Likely whitespace issues.  Pastebin your debdiff?
<vorian> I made the changes, I just wanted to make sure this was the right decision
<bkudria> persia: certainly
<bkudria> persia: http://pastebin.ca/874072 , referring to lines 18 and 19
<pochu> vorian: pong
<vorian> hey pochu, thanks for your feedback
<persia> vorian: You're entirely correct about htmlkdoc.  I had been looking at libchm1 and the licensing.
<Taggard> I've updated all of the emacs21 instances in the Depends field apart from xemacs21-basesupport because there isn't an xmacs22
<Taggard> Ugh
<vorian> pochu: I was just trying to clarify what you recommended vs what the upstream site recommended
<persia> Taggard: You likely don't want to update: rather support all the different emacs.  The problem was the comma
<vorian> persia: ok, thanks for checking :)
<Taggard> persia: I am pretty bad at this
<persia> Taggard: No, just new :)
<pochu> vorian: well, the package doesn't import those (specially since they aren't python modules ;) and doesn't call them with os.popen...
<Taggard> Okay
<persia> pochu: os.system
<Taggard> How do I support all of them?
<bkudria> persia: so, can I just remove the lines from the debdiff?  which ones, exactly?
<Taggard> I was doing exactly the same as the patch and it still required emacs21
<vorian> should I set these two packages to recommends/suggests then?
<persia> bkudria: I don't see a difference, but be careful editing diffs (edtidiff can help).
<persia> Taggard: | in dependencies means OR
<bkudria> persia: i'll try that, thanks
<persia> s/edtidiff/editdiff/
<Taggard> persia: Okay
<Taggard> Thanks
<Taggard> Ooooooooooooh
<Taggard> I understand now
<vorian> :)
<persia> vorian: At least for htmldoc, Depends: is correct.  I haven't looked into the others.
<pochu> persia: crap. You're right
 * persia advocates grep -ri *
<pochu> vorian: ignore my comment.
<vorian> Taggard: isn't that a great feeling :)
<dcordero> ok, i have a new package that fix a bug, This package is the new version of a "aplication". How can i send it now? where? someone can help me?
<pochu> persia: well grepping for os.popen didn't show them ;)
<vorian> pochu: I did fix the copyright
<Taggard> vorian: Yep!
<Taggard> vorian: :D
<persia> pochu: grep -ri htmldoc * does :p
<persia> dcordero: Sounds like an upstream update.  Check the Contributing page, hit the othe bugs in the package, and submit an interdiff
<awen_> 14. of february is in general last change of getting new packages in? ... any dates earlier than this one i should be aware of?
<pochu> vorian: great. I'll upload it then.
<persia> awen_: 4th February is the last scheduled REVU day
<eddyMul> Hi. I'm (very) new to Ubuntu packaging. I'm trying to package "WWW SQL Designer" from http://ondras.zarovi.cz/sql/ . Upstream makes releases in ZIP instead of tarballs. Should I unzip and re-tar?
<persia> pochu: Who is second advocate?  Also, I don't see the update on REVU
<dcordero> persia, thanks
<pochu> persia: I'm the second one. And I'm waiting for the update :)
<persia> pochu: Advocates are counted by upload, no>
<persia> s/>/?/
<pochu> persia: do you mean ScottK's vote doesn't count anymore?
<vorian> pochu: just uploaded the change
<vorian> thanks for being patient with me :)
<persia> eddyMul: Two schools of thought about that.  Most would recommend unzipping and building a tar.
<bkudria> persia: i get: "diff -u ruby-prof-0.5.2/debian/control ruby-prof-0.5.2/debian/control, rediff: Not supported: +" when trying to use rediff.  any idea?
<pochu> persia: this was just linking to GPL-2 in debian/copyright
<Taggard> Is there anyway to "fake" installing a package
<persia> pochu: According to current practice, it doesn't.
<Taggard> Like just to test what it requires and such
<pochu> persia: okie
<vorian> yeah, the copyright was a bit rough
<awen_> i would need an introduction to revu before that then :) ... i suppose a request to sync from debian should be posted around the 4/2 also?
<persia> bkudria: Not really.  I usually just repatch and regenerate the debdiff.  editing diffs has caused me pain in the past.
<eddyMul> persia: I'll try that for a start. Thanks.
<bkudria> persia: oh, ok.  i'll try that
<persia> awen_: That makes for the best chance that it would get done before the freeze.
<awen_> persia: but if the package in hardy is currently unusable and debian has a working one, it should still have a chance past freeze, or?
<persia> awen_: Requires a freeze exception.  If it fixes a nasty bug, and doesn't break anything else, it may well get approved.  On the other hand, this will require more effort on your part to weave through the processes.
<pochu> vorian: linking to GPL-2 instead of GPL would have been better, since GPL is now a symlink to GPL-3. Although at the license is GPL2+ and not GPL2-only, I guess it's not a blocker. Advocating.
<vorian> thanks pochu
<pochu> vorian: no, wait.
<pochu> vorian: extract_chmLib and enum_chmLib are in libchm-bin, so you need to change libchm1 with libchm-bin in Depends:
<vorian> yes
<pochu> vorian: so change that and link to GPL-2 :)
<vorian> sure thing
<eddyMul> persia: just curious: what's the "other" way of handling zips, other than re-tar-ing?
<awen_> persia: i'll work on getting this done before freeze then! ... i suppose "won't do anything apart from casting exceptions" could be called nasty bug :)
<persia> eddyMul: Wrapping the zip in a tarball and unzipping during the build.  Don't do that unless you have a really good reason.
<persia> awen_: Yep :)
<eddyMul> persia: ouch. I see. Thanks. I'll stick with re-tar-ing.
<Taggard> Ugh, I have absoloutely no idea why this isn't working.
<awen_> must be time now... night everyone
<persia> eddyMul: Don't forget to document the process by automating with a get-orig-source rule in debian/rules
<Taggard> The dependancy list is "emacs22 | emacs21 | emacsen | emacs-snapshot | xemacs21-basesupport (>= 2003.11.13-1)" and I have emacs22 installed but it still makes me install emacs21.
<bkudria> i want to submit a debdiff for sponsorship and review, but the wiki links to a breokn script: https://wiki.ubuntu.com/SponsorshipProcess .  can anyone tell me how to send the request email myself?  alternativly, i already have an LP bug open(#184946), should i just attach the debdiff to that?
<persia> bkudria: Just attach the debdiff to the bug.  Feel free to update that wiki page to be less confusing.
<persia> bkudria: Also, remember to subscribe the relevant sponsors team for the package you are updating.
<bkudria> persia: ok, i'll do that.  the orginal replier (dholbach) to my bug did request going through the sponsorship process.  is subscribing all i need to do?
<persia> bkudria: Subscribe, unassign, and set "Confirmed" or "Triaged".
<bkudria> persia: ok, thanks
<eddyMul> persia: debian/rules: get-orig-source: where can I read more about this? (my gut tells me to add this target (get-orig-source) inside debian/rules. Am I right?)
<persia> eddyMul: You have it correct.  http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules documents it.
<bkudria> persia: hmm, dholbach requests that it be set back to new.  what's the usual way of doing this?  or does it not matter?
<eddyMul> persia: Thanks. What's an example source package with get-orig-source that I can look at?
<persia> bkudria: https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue is authoritative
<persia> (some bugs get "New", and some get "Confirmed" or Triaged", depending on the nature of the sponsorship request)
<persia> eddyMul: I don't know of any off-hand that do zip -> tar.gz.  Maybe someone else can help?
<eddyMul> persia: how does get-orig-source perform the "get"? Does it use `wget`? or `uscan`? or something else?
<persia> eddyMul: I prefer seeing packages that use uscan, but when that doesn't work, wget usually does.  There's no requirement to document the packages required to make get-orig-source work in debian/control.
<eddyMul> persia: so I don't need to document that "build depends" includes, among others, zip and uscan?
 * Hobbsee waves
<persia> eddyMul: Not if those are only used in get-orig-source
 * Hobbsee waves
<eddyMul> persia: I see. Thanks!
<LaserJock> hi Hobbsee
 * persia wonders if Hobbsee's wave frequency is 20 seconds, and expects a null result
<Hobbsee> hm, lagging
<ion_> The noise-to-signal ratio of the comments in the bug report about flashplugin-nonfree is steadily approaching infinity. :-)
<bkudria> persia: ok, looks like i did everything correctly.  thanks for patiently answering my questions
<LaserJock> persia: I was wondering if it was gonna be a 20^i
<persia> ion_: That's expected.  Any ideas on how to fix it cleanly?
<pochu> How many packages does universe/multiverse have?
<ion_> Iâm not familiar enough with the problem with Konqueror.
<persia> LaserJock: That's likely more accurate given the nature of Hobbsee
<persia> pochu: About 13,000
<pochu> ty
<persia> pochu: For accuracy, check Packages.gz
<Hobbsee> persia: heh
<ion_> Perhaps Launchpad should make it possible to vote comments as signal or noise, and with enough noise votes, a comment would be hidden by default. :-)
<persia> ion_: Do you believe there are enough triagers to make that a useful extra part of their work?
<ion_> Just a random braindumplet, with a smiley to indicate that itâs not a very serious idea.
<LaserJock> pochu: Hardy source Universe+Main is 13693
<LaserJock> man oh man there are a lot of people subscribed to that bug
<persia> Now that gaphor works again, I think that gets the prize for most duplicated bug.
<eddyMul> persia: can you point me to a package which has a get-orig-source target using uscan? I want to learn how to handle uscan's non-zero exit code
<persia> eddyMul: http://revu.ubuntuwire.com/revu1-incoming/mscore-0801022000/mscore-0.8.0+dfsg/debian/rules (and please ask questions generally: I don't always have the best or fastest answer)
<pochu> vorian: there you have :)
<persia> Note that I don't really like the duplicated get-orig-source: rule definition for mscore, but it does work.  https://wiki.ubuntu.com/PackagingGuide/Basic#head-4bb01b3c07548aaf98e85ac7eb7983e632f8eb38 may also be useful.
<dcordero> how many time have i wait since i sent a package to revu, until i can see the package? i sent it but i cant see it con revu website
<eddyMul> persia: thanks
<LaserJock> persia: I haven't read all of the flash bugs, but it seemed to me like a package with new md5sums would at least get a lot of people going
<persia> dcordero: Usually not more than 10-15 minutes.  If you still don't see it, ask here, and include the package name.
<bkudria> persia: hmm, you think updating https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue is ok, even with the warning at the top of the page?
<dcordero> persia, ok thanks
<persia> LaserJock: Yes, but it makes konqueror segfault :(
<dcordero> i'll wait for a long time
<LaserJock> segfault? I thought it was just flash not working
<LaserJock> hmm
<persia> bkudria: I know that is the official current policy.  The URL will change, but has not yet done so.
<persia> LaserJock: Well, it only segfaults when visiting a page with flash.  Personally, gnash works well enough for me.
<vorian> thanks again pochu :)
<pochu> vorian: you and ScottK did most of the work, no need to thanks me ;)
<vorian> lol
<pochu> dcordero: your package is there now
<pochu> erlang-doc-html I guess
<dcordero> pochu, thank, yep, that is it ;)
<persia> dcordero: That doesn't really want to be on REVU though :(
<dcordero> i read that all new package have to do revu system
<persia> dcordero: new packages.  Updated packages (including upstream updates) don't go through REVU.  Check "Preparing New Revisions" in https://wiki.ubuntu.com/MOTU/Contributing
<dcordero> ups
<persia> Just for extra clarity, a "NEW" package is one not currently available in the Ubuntu repositories.
<persia> We use REVU to make sure that at least two MOTUs have reviewed it and can't find any issues to reduce the number of bugs found in these packages.  For updates, it only takes a sponsor confirming the update is good.
<dcordero> and whre is sent updates?
<persia> dcordero: In a bug.  See the wiki page referenced above
<dcordero> i think that i have to read all the contributing again
<mcisbackuk> Evening all.
<jscinoz> persia
<jscinoz> im stumped for what to do now on the urbanterror package
<mcisbackuk> Can someone give me a little bit of guidance with bug #186183. I'm trying to package it, the debuild -S -sa went find, changelog is chaged to reflect new version, but I'm getting build-stamp errors in debian/rules, and I'm not sure what to do
<ubotu> Launchpad bug 186183 in drqueue "Update drqueue to version 0.64.3" [Undecided,In progress] https://launchpad.net/bugs/186183
<persia> mcisbackuk: What sort of errors?
<mcisbackuk> sorry......i ran pbuilder on the dsc file
<mcisbackuk> ermmm wheres that paste bin thing?
<mcisbackuk> ill paste output
<dcordero> i dont understand, my mind is crazy, for send a bug to Ubuntu Sponsors for universe i have to belong to Ubuntu Sponsors for universe group. And for belong Ubuntu Sponsors for universe i have to send a bug, I dont understand
<pochu> !paste | mcisbackuk
<ubotu> mcisbackuk: pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<Hobbsee> dcordero: you can subscribe ubuntu-universe-sponsors to a bug
<mcisbackuk> add the bug, and subscribe them
<persia> dcordero: Why do you need to belong to that group?  Just subscribe the team.  If you can't, that's an unacceptable regression in LP, and it will be fixed.
<mcisbackuk> thanks pochu
<Hobbsee> persia: it's probably just the official new way to use LP :P
<mcisbackuk> http://paste.ubuntu-nl.org/53623/ thats what I'm getting during pbuilder
<persia> Hobbsee: I am prepared to be very angry if bug #58410 gets closed before there is a sane solution in place for bug #179857
<ubotu> Launchpad bug 58410 in malone ""Subscribe Someone Else" should be restricted to drivers of relevant software" [Low,Confirmed] https://launchpad.net/bugs/58410
<ubotu> Launchpad bug 179857 in malone "Package sponsorships involve awkward bugtracker machinations" [Undecided,New] https://launchpad.net/bugs/179857
<mcisbackuk> lol
<mcisbackuk> Can someone have a quick look for me please at http://paste.ubuntu-nl.org/53623/ - it's what I'm getting when using pbuilder, is this safe, or is there a problem with the rules file, and if so, how do I go about it?
<Hobbsee> persia: it looks lost
<persia> Hobbsee: What?  Non-members really can't subscribe?
<persia> mcisbackuk: Looks to me like ./configure isn't being called
<Hobbsee> persia: as in, it looks like no one's talking on it, so it won't get done for ages
<tuxmaniac> h0la all! Good morning
<persia> Hobbsee: Ah.  Yes.  I'd be perfectly happy for 58410 to be forgotten forever :)
<mcisbackuk> persia: There is no configure file, just a makefile
<mcisbackuk> correction : not even a make file
<persia> mcisbackuk: OK.  pbuilder can't find it in /tmp/buildd/drqueue-0.64.3
<persia> mcisbackuk: If there is no makefile, perhaps you don't want to call make?
<mcisbackuk> persia: ok.....but then will the source still get built, cuz I sure as hell dont know that much about coding lol
<dcordero> ok, it's that ok? -> https://bugs.launchpad.net/ubuntu/+source/erlang-doc-html/+bug/70745
<ubotu> Launchpad bug 70745 in erlang-doc-html "erlang-doc-html conflicts with other erlang packages" [Low,Confirmed]
<dcordero> ubotu, what
<ubotu> Sorry, I don't know anything about what - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<dcordero> haha bot
<persia> mcisbackuk: I have no idea.  Most upstreams provide instructions on how to build the package with the package.
<mcisbackuk> persia: and then I assume its just a case of copying the instructions into a new makefile and then calling it in the rules file?? Is that right?
<persia> dcordero: Looks well formed and subscribed to the right team.
<dcordero> persia, ok, so, enought for today. Thanks, i'm going to bed
<persia> mcisbackuk: debian/rules build should include whatever steps are required to build the package according to the upstream directions.  While this is often as simple as `make`, it may differ for different upstreams.
<mcisbackuk> persia: I see...OK I'll try fiddling with that then
<tuxmaniac> Hi. please can anyone throw more light on this lintian warning I get. "W: alliance: script-with-language-extension usr/bin/dreal.sh"
<LaserJock> I think that's talking about the .sh
<LaserJock> that means the user would have to type "dreal.sh" to run it rather than "dreal"
<tuxmaniac> LaserJock, yeah. But what is the recommeneded extension?
<tuxmaniac> aah ok
<LaserJock> none at all
<tuxmaniac> how do I resolve this? I have 5 such warnings
<LaserJock> the script should have a shebang and no extention is needed
<tuxmaniac> ok
<LaserJock> I'm guessing mv'ing the files in debian/rules would suffice
<tuxmaniac> LaserJock, can I pm for some OT stuff?
<LaserJock> sure
<mcisbackuk> Every time I run debuild -S -sa, I get gpg skipped and gpg: [stdin]: clearsign failed: secret key not available, yet i have edited the .bashrc and put export GPGKEY=XXX and exported DEBFULLNAME and DEBEMAIL, how come?
<persia> mcisbackuk: The identity on your GPG key doesn't match your changelog entry
<mcisbackuk> persia: But I put EXACTLY the same info in...
<persia> mcisbackuk: What's your LP page?
<mcisbackuk> I'm mcisbackuk on LP but i havent got a page
<persia> mcisbackuk: Yes you do :)  https://launchpad.net/~mcisbackuk.
<mcisbackuk> oops lol
<persia> Anyway, you're GPG key isn't registered, so I can't check that against your changelog :(
<persia> s/you're/your/
<mcisbackuk> How do i register it? update OpenPGP keys?
<persia> mcisbackuk: Exactly.
<mcisbackuk> I can't register, I can't decrypt the email as i use hotmail
<persia> mcisbackuk: Does hotmail not let you download the raw message?
<mcisbackuk> Nope, although I could copy the -----begin pgp----- to end and save in a file
<mcisbackuk> But if I do that, how do I decrypt it with my key?
<tuxmaniac> grrr. alliance folks have miserable manpages ;-) I am beginning to hate them
<tuxmaniac> too many lintian warnings.
<persia> mcisbackuk: man gpg should tell you the right option (I forget offhand).
<mcisbackuk> persia: Got it! :)
<mcisbackuk> persia: Damn I think I just seen the problem....if I happened to have stupidly put a comment when I was creating the key like "GPG Key" would that have to go in the changelog too so it could sign it??
<persia> jscinoz: After looking in a bit more detail, I don't have any good suggestions.  It looks like there is an incompatible fork of libjpeg62.  Please hit upstream with a stick, and ask sistpoty to unreject (as it is "absolutely needed").
<persia> mcisbackuk: Yes.  Exactly.
<mcisbackuk> persia: Damn I'm stupid sometimes, sorry about that lol
<jscinoz> i like the stick comment :) i'll do that :P
<jscinoz> ugh revu is being screwy
<jscinoz> logged in on mainpage, but if i go to package pages im not logged in >_<
<persia> jscinoz: The cookie timeout is based on when you logged in, not when you last visited a page.  Reload the main page to log in again.
<jscinoz> tried that >_<
<jscinoz> prob just need a restart of firefox or somethign along thoes lines, i'll do it in a bit
 * persia requests someone familiar with python exception handling to critique http://paste.ubuntu.com/3930/
<persia> Hobbsee: If you're around, could you please delete /srv/uploads/dcut.Emmet_Hikory__persia_ubuntu_com_.1201407915.25411.commands
<Hobbsee> persia: please reping
<persia> Hobbsee: Please delete /srv/uploads/dcut.Emmet_Hikory__persia_ubuntu_com_.1201407915.25411.commands
<persia> I was testing a fix to make those not happen anymore :)
<Hobbsee> persia: done
<persia> Hobbsee: Thank you.
<Hobbsee> no problem
<Hobbsee> persia: revu looks broken
 * persia looks, and wants more context
<Hobbsee> persia: http://pastebin.ca/874271
<Hobbsee> persia: oh wait.  there never was an orig tarball.  nevermind.
<persia> Hobbsee: And console-freecell was due to the key not being in the keyring the first time (now fixed).
<Hobbsee> right
 * joejaxx wishes DeXtop GUI still existed :(
<persia> joejaxx: Doesn't CDE work now?
<joejaxx> cde is not available for linux anymore
<joejaxx> i cannot even buy it
<joejaxx> which fails
<LucidFox> ewww, stop poking that corpse, it smells!
<joejaxx> CDE is nice
<joejaxx> i am so tempted to email the open group and request a special license for myself
<joejaxx> since they {cannot,will\ not} open source it
<LaserJock> oh for goodness sakes joejaxx, get with the 21st century ;-)
<joejaxx> lol :P
<LaserJock> it's like me using a sliderule ;-)
<LaserJock> which I do on occasion just for fun
<persia> joejaxx: Why do you want it?  Can't you get most of that with KDE or GNOME and a one of the less-popular app-launching tools?
<joejaxx> i do not like them
<joejaxx> kde started out as a cde clone
<joejaxx> i have not used kde since 1.x
<Nafallo> hmm
<Nafallo> I don't think I would like CDE ;-)
<joejaxx> xfce started out as a Cde clone as well
<joejaxx> i do not like any of the "modern" de/wm's
<persia> Hobbsee: For your reduced deletion pain, bug #186275 is now Fix Released.
<ubotu> Launchpad bug 186275 in dput "dcut shouldn't pretend to work for Ubuntu" [Undecided,Fix released] https://launchpad.net/bugs/186275
<joejaxx> they are bearable though
<Hobbsee> persia: yay!  thansk!
<ToyKeeper> I don't like gnome/kde either, but there are countless other options.  :)
<joejaxx> like CDE :)
<ToyKeeper> ... not too familiar with CDE's features.  I only used it briefly, a decade ago.
<joejaxx> it is great :)
<ToyKeeper> Sawfish is nice.  I mean, if none of the simpler WMs work.  It's nice being able to add features without recompiling or logging out.
<LaserJock> I kinda go back and forth, I like gnome and kde quite a bit, but sometimes I just use openbox for simplicity
 * persia cheers the power and simplicity of twm
<ToyKeeper> ;P
 * Hobbsee cheers at kde and gnome
<LaserJock> persia: twm always looked kinda ugly to me
<LaserJock> I like that openbox looks nice while being minimalistic
<LaserJock> and is being actively developed
<persia> LaserJock: You just need a high-enough DPI screen that it becomes a nice even gray.
<LaserJock> haha
<persia> (and yes, even when I use that interface, I tend to use fluxbox these days)
<joejaxx> well that does it i am calling them up tomorrow :)
<joejaxx> tomorrow being monday
<ToyKeeper> fluxbox is nice.  I like its tabs so much I had to kludge something similar into sawfish.  :)
<persia> But seriously, on the DPI point.  When I was a big twm user, I had 1280x1024 on a 15" screen (still have that screen around).  Now I'm lucky if I can find anything even 100 DPI.
<joejaxx> ToyKeeper: lol
<ToyKeeper> Heh, it's not too hard to find high-dpi screens.  I'm on a 1280x800 12" screen right now.
<ToyKeeper> ~124dpi, I think
<persia> ToyKeeper: That's surely integrated in a larger chunk of electronics, and won't be useful in 10 years.
<ToyKeeper> Perhaps.  I've got some pretty old notebooks which are still useful.
<ToyKeeper> Once they get old, it seems size is all that matters.  :)
<LaserJock> my ClassmatePC is 7" 800x480
<joejaxx> LaserJock: :D
 * persia has a 3.7" 640x480, but that's beside the point.  None of these are desktop monitors.
<LaserJock> my classmate is not a desktop, but it is a laptop which sort of counts, no?
<ToyKeeper> Hmm, lessee...  94dpi on my desktop monitor.  I fail.
<joejaxx> ToyKeeper: lol
<ToyKeeper> I wonder what the chances are of seeing openvz kernel packages in hardy.
<joejaxx> :)
<joejaxx> i believe we are past the point for any kernel flavour inclusions
<joejaxx> any new*
<ToyKeeper> I'm not really expecting any virtualization stuff until at least 8.10.
<ToyKeeper> Even a third party package source would help, though.  :)
<joejaxx> :)
<RAOF> What's different with openvz over, say, Xen or kvm?
<joejaxx> openvz is shared kernel
<ToyKeeper> Basically.  Openvz and linux-vserver implement containers instead of virtual machines.
<joejaxx> yeap
<ToyKeeper> A lot of container stuff is getting mainlined, though.  Expect to see a lot more of it in 2.6.25 and 2.6.26.
<ToyKeeper> It's helpful for splitting a large, multi-purpose server into smaller, easy-to-maintain chunks.
<joejaxx> :)
<ToyKeeper> So, less flexible than xen/kvm, but a lot faster.  There is a 4X-6X speed difference.
<RAOF> Does anyone from .au want to guess how much Harvey Norman sells 1.5 metre DVI->HDMI cables for?
<persia> RAOF: I'm not in AU, but can I play?  ($135)
<joejaxx> persia: :P
<Hobbsee> RAOF: shared kernel, and shared ram
<joejaxx> Hobbsee: Hi :D
<Hobbsee> heya joejaxx!
<joejaxx> :D
<ToyKeeper> Oh yeah, shared RAM is kind of important too.  :0
<ToyKeeper> :) even
<Hobbsee> RAOF: why?
<ToyKeeper> HDMI cables are horrible and expensive ...  designed at least 10 miles from the nearest RF signal engineer.  :)
<persia> ToyKeeper: Make a better one
<tritium> Why should RF engineers design them?
<ToyKeeper> Heh, I'm not even remotely qualified.  :)
<persia> tritium: They are designed to carry RF, no?
<LaserJock> tritium!
<tritium> persia: no
<tritium> LaserJock: Hey :)
 * persia reads the HDMI spec
<ToyKeeper> There's a reason why HDMI cables don't come in lengths of, say, 25m...  yet coax works fine over much longer distances.
 * persia gets annoyed at the HDMI website, and reads open sources instead
<joejaxx> persia: wikipedia :D
<ToyKeeper> persia: It's really not that interesting...  probably not worth the effort.
<persia> tritium: HDMI carries an electrical signal path.  Difference between this and RF is semantics.
<tritium> persia: important semantics, however.  Not all electrical signals are radio frequency.
<persia> tritium: That's not what I learned at uni.
<tritium> In fact, most circuits are _not_ designed for RF.  RF layout is quite a unique art.
<tritium> persia: the simplest counter-example would be DC.
<ToyKeeper> HDMI cables are not circuits.  They're just designed as if the circuit approach works over long distances.  :)
<persia> Unless you mean a specific limited section of spectrum by "radio frequency".  The lack of attention paid the the frequency domain was the topic of one of the lectures in a circuits class, and we were told to pay special attention for digital signals.
<tritium> persia: I do mean that, but that's because I'm an E.E., and I pay attention to those kind of things.
<persia> tritium: OK.  Yes.  Continuous current DC, with all capacitors and inductors balanced, and not in a EM field of any other sort doesn't generate anything.  I've never seen such a circuit in real life.
<persia> tritium: Ah.  OK.  My misdefinition of "radio frequency" then (and misuse of RF previously).
<LaserJock> my laser creates a silly RF that's rather annoying. I have to isolate my oscilloscope or put it on another table
<tritium> persia: eh, no worries :)
<tritium> ToyKeeper: they form circuits with other electrical components.
<persia> ToyKeeper: Also, circuits do work over long distances.  How close is your computer to a generator?
<tritium> LaserJock: how's the dissertation?
<tuxmaniac> is it absolutely necessary that _all_ lintian wrnigns have to get resolved? <- I know its a stupid question. But I feel some changes that I make to resolve this might/could break some other stuff.
<ToyKeeper> persia: True, I was thinking of a different meaning for circuit.
<persia> tuxmaniac: For NEW packages, almost always yes.  What warning is giving you trouble?
<tritium> I think we all agree, it's just semantic differences :)
<persia> tritium: Just out of curiosity, if RF is 3Hz-300GHz, and HDML is pumping at 10.2Gbit/s, what frequency does it use?
<tuxmaniac> persia, most of the lintian warnings that I have are manpages related. and upstream has a few manpages only in french.
<persia> tuxmaniac: OK.  Can they not be translated?
<tuxmaniac> persia, I am writing a mail now. But I am afraid whether it shall be done before FF :-|
<tuxmaniac> persia, I will try to get it translated myself in collaboration with French translator at office
<persia> tuxmaniac: Understood.  Are these the one that your changes to resolve might break other things?
<tuxmaniac> persia, some have invalid extensions it seems. instead of filename.gz some have filename.something.gz
<tuxmaniac> persia, and I never know where they have included what. they use a lot of manpage includes
<persia> tuxmaniac: I need a little more context.  Could you please pastebin your lintian output?
<tuxmaniac> persia, http://paste.ubuntu-nl.org/53632/
<tritium> persia: I'd have to look into the physical layer, to find out
<tuxmaniac> i have removed 19,20,21 already
<persia> tritium: Oh well.  I was hoping you knew offhand.  I'm not willing to pay enough to read the spec and find out :)
<tuxmaniac> persia, also removed 1, 4, 6
<tritium> persia: sorry, I don't.  If I can find out, I'll let you know.
<tuxmaniac> build in progress
<persia> tuxmaniac: check the manpage for 2&3.  I suspect it's not required for linux installations.  5&7 are likely typos.  8-11 need inspection of the source: something is odd there: maybe an encoding issue?  12-17 are violations of policy: the .sh must be stripped from the name (and you might have to adjust the files to expect that).
<persia> For 18, check how the script is used.  It should be sourced by other executables, rather than run, and likely should have the initial !# line removed.
<tuxmaniac> ok persia thanks for the quick comments. I shall look into them
<persia> tuxmaniac: Good luck.  You've 3 hours and 15 minutes before REVU day :)
<tuxmaniac> REVU Day!? After that no new packages are accepted?
<persia> tuxmaniac: No, but getting it in before REVU Day increases the chances it will get reviewed this week.
<tuxmaniac> persia, OMG.
 * tuxmaniac switches to top gear
<LaserJock> dang, I should get squeak fixed up soon
<LaserJock> some of it's gonna have to go through NEW
<persia> LaserJock: Best try to get it in soon then.  There's a lot of candidates on REVU, and people are busy.
<LaserJock> I wasn't even thinking of putting them on REVU ...
 * LaserJock has to get his brain into "policies" again
<RAOF> Wow, I really managed to start that up :)
<RAOF> persia: Higher.
<persia> RAOF: Wow!  I was guessing about 10,000 yen + markup to ship to the bottom of the world.  I'm suddenly glad I'm not in the HDMI cable market :)
<RAOF> In fact, you're off by a factor of >2
<RAOF> Although this is not a reflection of the total market, just the Harvey Norman market.  Which is apparently populated entirely by audiophiles with huge disposable income.
<persia> That's a lot of money.  18,000 yen for 1m here :(
 * LaserJock pats the roll of coax sitting behind his TV
<persia> No, that was just a bad brand.  Panasonic has a 1.5m for 5,000 (which, even with markup, shouldn't be more than $60)
<LucidFox> persia> You're in Japan?
<persia> LucidFox: That's what LP says
<LaserJock> persia: you're so integrated in LP that it tells you where you live? :-)
<persia> LaserJock: How else is one to keep track in this modern international society?
<LucidFox> I'm interested in Japan. I'm currently studying Japanese.
<Aloha> LucidFox, domo arrigato
<persia> LucidFox: So you'll be coming to visit soon?
<LaserJock> persia: facebook of course!
<persia> LaserJock: The advantage of LP over facebook is that one doesn't have to manage freinds lists :p
<LucidFox> persia> No
<persia> Oh well.  Maybe later then...
<LucidFox> I'm not in a sufficiently solid material position to :)
<persia> LucidFox: Depends how you go.  Trans-Siberian isn't that expensive, and there's a ferry, but that turns a week vacation into a month-long journey.
<LaserJock> persia: hmm, maybe I should file a bug for LP to get friend lists and status boards and ...
<persia> LaserJock: Please no.  I've already retreated from several places infected by the social meme
<minghua> LaserJock: Although I also think it's a horrible idea, I am curious what do you think adding a friend list to LP can do?
<minghua> I can watch the bugs my friends report?
<LaserJock> and see who's online and leave messages
<LaserJock> "yo, fix this bug you nut"
<LaserJock> "you seriously didn't just merge that? ;p"
<LaserJock> "OMG OMG isn't this the coolest package eva!?!?!"
 * persia thought that was why we used IRC
<LaserJock> alright, maybe it wasn't the best idea
<LaserJock> ;-)
<LaserJock> I'm heading to bed
<minghua> Good night LaserJock.
<warp10> Heya all
<tuxmaniac> persia, those encoding issues you pointed out are those in lines where there are stuff like \351 \352 etc. How do I find out which character is that and what is missing?
<tuxmaniac> persia, http://paste.ubuntu-nl.org/53632/ again for reference.
<persia> tuxmaniac: I suggest looking for a latin1 encoding reference, as that seems to be the most common non-unicode encoding used in europe.
<persia> Extra points for asking questions generally or waiting for the person you pinged to get back to you.
<persia> shibata: re: termlauncher-applet: It is acceptable for upstream to have those extra files in their tarball.  You probably want to delete them in debian/rules clean:
<shibata> persia: Should write in clean rule "rm -rf src/*.pyc autom4te*" ?
<persia> shibata: To me, that seems the right method to use.
<shibata> persia: thank you. I will do from now.
<persia> shibata: Thank you.  I will review it again thereafter.
<Gunirus> afk
<persia> shibata: Also, I wonder if bbs2chreader or ãããã¾ç® would be good to include, or if only JD is enough.  I don't think many here would be prepared to package them, but maybe not having a dependency on GTK would be nice.
<shibata> persia: sorry, I failed to understand what you meant. Is it which you should use?
<persia> shibata: I use jd, but I thought that another one might be good for KDE users, as JD depends on GTK.
<shibata> persia: if KDE users generally use Firefox, then bbs2chreader+saitama skin is good.
<shibata> persia: If you want standalone 2ch reader for KDE users, how about kita?
<persia> shibata: Standalone is even better.  I didn't know about kita.  Maybe that is a better choice?
<minghua> Hmm, 2ch reader.
<persia> minghua: Much better than the web interface (which is painful)
<minghua> persia: I agree web-interface BBS is painful.
<shibata> persia: I have not use Kita, but it is seemed to use Qt libraly.
<persia> shibata: Looking at http://kita.sourceforge.jp/, it looks to me like it uses more KDE than just QT, but the license looks free enough.
<jeromeg> hello
<jeromeg> i wonder what is the difference between "dh_scrollkeeper -i" and "dh_scrollkeeper" in debian/rules
<jeromeg> can anyone explain this to me ?
<shibata> persia: There are kita package in Japanese local repository. If it is necessary, do I hear to packager whether upload to official repository?
<persia> shibata: If you don't mind.  I think it would be better to get things into the official repository, rather than the local repository.  While I'm not sure about the licensing on the fonts, and UTF-8 is still unpopular here, most of the other applications seem like good candidates.
<persia> jeromeg: -i acts only on arch:all (similarly, -a acts only on arch:something)
<jeromeg> persia: ok thanks
<persia> jeromeg: man debhelper :)
<jeromeg> persia: ok i'll have a look
<shibata> persia: I found one more alternative. It is "V2C", Java base browser. http://v2c.s50.xrea.com/
<persia> shibata: That upstream seems much more active as well.  I wonder if it works with icedtea
<shibata> persia: V2C seems to work somehow on icedtea, but it is not yet tested enough, there are some problems.
 * RAOF is subdued by his rampaging mythtv non-setup.
<persia> shibata: Beyond those related to the trouble I'm having getting icedtea installed locally? :)
 * persia is now annoyed.  command-not-found encourages installation of icedtea-java7-bin to get `java`, but installing this package doesn't actually succeed in providing `java`.
<persia> Right.  $JAVA_HOME.  Anyway, v2c coredumps for me :(
<shibata> persia: According to V2C thread in 2ch, there are report to good for Fedora 8+Icedtea+V2C(non JRE).
 * persia looks
<shibata> persia: Sorry, my reply is too late. I'm not so good to use English.
<persia> æ´ç°ï¼ããªãã®è±èªãåã®æ¥æ¬èªããè¯ãã§ãã
<shibata> persia: No. 580 in "Java+Swingã«ãã2chãã©ã¦ã¶ V2C_T8" thread.
<shibata> persia: thank you. and I uploaded termlauncher-applet into revu.
* persia changed the topic of #ubuntu-motu to: Masters of the Universe: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Unmet Deps time! http://qa.ubuntuwire.com/debcheck/ | QA resources from http://qa.ubuntuwire.com | It's REVU Day.  Packagers: 2nd to last chance: make sure they are perfect.  Reviewers: let's get as many in as possible
 * persia is happy to see reports of v2c working on gutsy, and wonders if anyone feels like packaging it
<rulus> Since it's REVU day, I'll ask again to review my package please :) It's at http://revu.ubuntuwire.com/details.py?package=gtkvd Thanks!
 * persia syncs the keyring
<persia> rulus: commented
<shibata> persia: If there is time, I hope I will challenge it. But I'm not confident to make it until last REVU Day.
<persia> shibata: Understood.  Good luck.
<rulus> persia: thanks, I'll fix it asap :)
<shibata> persia: Thank you.
<shibata> By the way, I have a question. I'm creating package which should include in multiverse. Can I upload it to revu?
<geser> shibata: yes
<geser> if it's redistributable
<shibata> geser: According to license, "redistribution" is OK, "altered" is NG. Probably, "altered" mean "modify".
<persia> shibata: termlauncher commented
<persia> shibata: Which package?  (which upstream?)
<shibata> persia: Thank you for comment, and package is poppler-data
<shibata> http://poppler.freedesktop.org/
<minghua> I think we have poppler-data?
<persia> shibata: https://launchpad.net/ubuntu/+source/poppler.  You probably want to ask on #ubuntu-desktop about poppler-data
<minghua> Hmm, apparently not.
<shibata> minghua: Really? I can not find in repository.
<minghua> There is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453172 though.
<ubotu> Debian bug 453172 in wnpp "RFP: poppler-data -- Encoding data for the poppler PDF rendering library" [Wishlist,Open]
<persia> Urgh.  Right.  So CJK+Cyrillic is broken :(  Still best to ask in #ubuntu-desktop
<pochu> shibata: RFP means request for package. You might want to own it
<persia> shibata: Based on my reading of poppler-data COPYING, it should be safe for multiverse.
<hellboy195> Hey folks, Debian Changelog site down?
<persia> hellboy195: Which site?
<hellboy195> persia: packages.debian.org/changelogs  <-- I can't connect
<persia> hellboy195: Doesn't work for me either.  Might want to look around on OFTC to see if there is any news.
<wallyweek> g'morning all
<hellboy195> persia: sry, whats OFTC?
<geser> hellboy195: another IRC network
<hellboy195> geser: ah. haven't heard about it yet ^^
<persia> hellboy195: The IRC network used by Debian.  Try irc.debian.org if you need a name and don't want to track one down.
<geser> hellboy195: http://www.oftc.net
<hellboy195> thx thx
<wallyweek> with latest fixes sdlmame should only need advocation... can anyone review it, please? It's now nearly 1 year it waits uploading! :( http://revu.ubuntuwire.com/details.py?package=sdlmame
<wallyweek> thanks
<minghua> It would be nice to have poppler-data, I sometimes need it as well.
<theseinfeld> Hi ll
<theseinfeld> A very strange thing happen to my upload
<theseinfeld> I uploaded last package on 23rd of January and it was 1ubuntu7 version
<theseinfeld> to see today that somebody uploaded on revu the 1ubuntu3
<theseinfeld> how the hell was that possible to superseed the 7 version?
<persia> theseinfeld: REVU doesn't care about versions
<theseinfeld> ok
<theseinfeld> but how did it get uploaded then?
<theseinfeld> I was not even connected
<theseinfeld> ?
<persia> theseinfeld: Someone used dput.  Which package?
<theseinfeld> libdc1394-22
<theseinfeld> when you use dput don't you need the gpg key?
<theseinfeld> http://revu.tauware.de/details.py?package=libdc1394-22&upid=1530
<wallyweek> theseinfeld: no, you don't, AFAIK you only need to sign source package
<theseinfeld> is it a rogue upload then?
<theseinfeld> how should I fix it?
<persia> theseinfeld: You just need a GPG key on the keyring.  Doesn't have to match the uploader name, if someone uses the sponsor flag for debuild/dpkg-buildpackage
<wallyweek> theseinfeld: upload it again
<theseinfeld> ok
<persia> theseinfeld: Upload a new one.  Also, please collapse your changelog.  It should be -0ubuntu1 when it enters the archive.
<theseinfeld> persia: roger that
<theseinfeld> incoming package :)
<wallyweek> persia: have you got some time to look at sdlmame, please? :D
<persia> wallyweek: Not tonight.  Maybe tomorrow.
<rulus> persia and others: I updated gtkvd: http://revu.ubuntuwire.com/details.py?package=gtkvd :)
<wallyweek> persia: ok
<shibata> minghua and persia: Well, poppler-data package is going to be made in Debian anyone. And I should wait to upload and to sync Ubuntu. Is it OK?
<persia> shibata: Depends on timing.  FeatureFreeze is 14th February.  If it goes to Debian fast enough, that works.  If there may be delays, maybe it would be good to bring to Ubuntu sooner.
<minghua> shibata: That's usually the preferred way.  You can always get involved in the Debian packaging effort.
<minghua> "Lotus Notes 8.5 Will Support Ubuntu 7.0"  http://www.computerworlduk.com/technology/applications/enterprise/news/index.cfm?newsid=7193&print
 * minghua wonders what version they meant.
 * wallyweek wanders what they mean with "will support"
<persia> Probably 7.04, as 7.10 is usually incorrectly written as "7.1".  Anyway, based on Mr. Murphy's quotes, I expect it should work fine for 8.04 as well.
<wallyweek> I never heard about an app supporting an os... ;)
<persia> wallyweek: Really?  I remember Escape Velocity finally supporting Windows being huge news.
<hellboy195> persia: working again. nobody knows why ^^
<wallyweek> persia: maybe it's simply a matter of terms, but I would expect to hear ubuntu will support lotus notes protocols/data formats
<smarter> hi all
<persia> wallyweek: Really?  That's not traditionally an OS vendor's job.  Typically, the application firm writes something to be cross-platform, and has to readjust for each new revision from the OS vendor.  This team (MOTU) tries to help with that some, but...
<smarter> I've some packages ready for review: http://revu.ubuntuwire.com/details.py?package=kde4-style-bespin and http://revu.ubuntuwire.com/details.py?package=extremetuxracer
<persia> smarter: Don't use dcut.  It just doesn't work for Ubuntu.
<smarter> persia: I don't use dcut
<Ng> wallyweek: loads of "enterprise" apps support (ie certify to be compatible with) OSes
<persia> Commercial games also tend to be public about which OS they support, as there are often lots of quirks that break in other environments.
<wallyweek> persia, ng: ok, so "will support" should be read "will be available for" ;)
<persia> wallyweek: Actually, they probably support it as well, meaning you can pay IBM to help you if you have problems with Notes on Ubuntu.
<persia> (whereas, I doubt IBM would take your money if you had problems with Notes on QNX)
<wallyweek> persia: do you mean lotus notes is already available for linux? :o
<persia> wallyweek: Google can answer your question better than I
<theseinfeld> persia: done. http://revu.tauware.de/details.py?package=libdc1394-22
<persia> theseinfeld: Great.  Now it's ready for review :)
<LucidFox> Oh, so REVU day has begun?
<wallyweek> persia: right... googling... done! yes, it is since rel. 7 :o
<theseinfeld> persia: yeah... find a reviewer if you can :)
<LucidFox> I would like to pimp http://revu.ubuntuwire.com/details.py?package=libgee - it's not my package, but I'm interested in it
 * wallyweek is surprised to know lotus notes was already available for linux
<persia> LucidFox: Are you still happy with the latest upload?
<theseinfeld> wallyweek i think it was for quite some time. since IBM decided to go OSS
<theseinfeld> DaveMorris hi!
<DaveMorris> hi
<LucidFox> persia> holy... I didn't notice how huge the diff was, I thought he just corrected the debian/docs issue
<LucidFox> although wait, it's a new upstream release... that explains why it's huge
<persia> LucidFox: This is why we ignore previous advocations for the same package when we get a new revision.  Please review again, and add your support if it is good.
<persia> For a new upstream, if may be worth downloading both versions and playing with interdiff -p1
 * LucidFox downloads
<persia> jdong: clutch commented
<LucidFox> persia> he migrated to CDBS, that changes things and I've posted a new objection
<persia> LucidFox: OK.  I'll ack.
<vemon> persia, hi. it seems that the .desktop file is not installed automatically even if the gnome.mk is included in rules
<vemon> i tried to put it to debian/ also
<LucidFox> vemon> desktop files in debian/ are not automatically installed
<vemon> then i dl'd source of vkeybd which seems to have a debian/install -file that lists the vkeybd.desktop to be installed in /usr/share/applications/
<vemon> so is this the right way to do it?
<vemon> or does an "automatic" way exist?
<LucidFox> not at the moment
<vemon> ok. thanks!
<LucidFox> you will need to explicitly install desktop files in debian/ with dh_install or cp
<persia> s/cp/install/
<LucidFox> well, I've never seen plain install used in debian/rules, although I have seen dh_install with arguments
<persia> If you look in some of the older packages, you'll see it.  install is preferred over cp as it allows one to set the permissions properly.
<LucidFox> Ah.
<persia> (or the updated packages by those who dislike debhelper)
<LucidFox> I don't like maintainers who prefer to do things their own way
<persia> LucidFox: I actually use install whenever I need to change a filename, as dh_install doesn't support that.
<man-di> install has another nice feature, it can create the target directory for you if needed
<LucidFox> true
<persia> I generally use dh_installdirs for that, but it can be handy
<persia> vemon: lashwrap commented
<LucidFox> for example, the lsb_release patch for psi - it was a dpatch in Ubuntu, but when I advocated it to the Debian maintainer, he said he "didn't like dpatch" and lumped it into the diff.gz with some other changes already there
<vemon> persia, thx! i have a new upstream version though :)
<man-di> persia: I normally use dh_installdirs too, but I dont like to introduce it when I only need one small dir
<persia> LucidFox: In that case I agree with the Debian maintainer.  He probably tracks changes in a VCS, and dpatch just makes merging harder.  Mind you, dpatch is useful for packages not maintained in VCS (or with only debian/ maintained in VCS)
<persia> man-di: Makes sense.
<persia> man-di: On another note, how did libxml-commons-resover1.1-java come to be 1.2?  Is that just an annoying historical naming issue?
<LucidFox> probably the same way how libmono-addins0.2-cil is version 0.3 in Hardy :)
<man-di> the package was libxml-commons-resover-java 1.0... originally, then 1.1 came out and it was API incompatbile, 1.2 was API compatibale to 1.1...
<persia> Right.  Why do we put versions in package names again?
<man-di> persia: for some time we had libxml-commons-resolver-java AND libxml-commons-resolver1.1-java
<persia> man-di: That makes sense.  Thanks.  I'll be pulling it soon, possibly with a patch.  Do you happen to be familiar with the internals?
<man-di> persia: partly
<persia> man-di: I've been asked to apply http://paste.ubuntu.com/3934/.  I'm waiting on some explanation about the last chunk from the author, but wondered if you had any reservations.
<man-di> persia: I have seen your discussion with slytherin about this, I would be interested in the explanation for the last chunk too.
<persia> man-di: You agree then that the first two seem reasonable?
<man-di> I wonder where getPublicIDs() gets used
<man-di> the rest seems fine
<persia> man-di: Additional introspection to support NetBeans.  I'm not at all sure why they felt it belonged in this library.
<man-di> no objections, it should not hurt at least
<persia> On the other hand, I'm not sure how adding a function would break anything, and I have complained about them not pushing changes back to upstream properly.
<tuxmaniac> persia, for that "script-has-language-extension" lintian warning, the line     mv $(DESTDIR)/usr/bin/dreal.sh $(DESTDIR)/usr/bin/dreal in debian/rules enough?
<man-di> persia: unfortunately its common for java developers to take some 3rd party library, change it and ship it
<persia> man-di: Thanks for the confirmation.  I'll pass the explanation for the third chunk and the patch to the BTS if they can defend it sensibly.
<persia> tuxmaniac: Yes,
<tuxmaniac> its saying no such file found! Any clues why.
<man-di> persia: Thanks for your work, its really appreciated
<persia> man-di: Unfortunately true.  All we can do is try to educate them as to the advantages of non-duplication of code.
<persia> man-di: No.  Thank YOU.  This wouldn't even be possible without your efforts to get Java in shape, and all your previous work with the same people to get the rest of the libraries in.
<man-di> persia: thank you too *g*
<tuxmaniac> persia, do I remove the $(destdir) directive and check?
<persia> tuxmaniac: Is DESTDIR defined?  You might need $(CURDIR)/debian/...
<DaveMorris> persia: any small packages which I could revu for you guys?
<persia> DaveMorris: Feel free to comment on anything waiting for review on REVU.  Those that have not yet had any reviews are the ones needing the most attention.
<jonnymind> Hello;
<pochu> hey jonnymind
<jonnymind> yo
<jonnymind> I don't understand the last point of the comments at http://revu.tauware.de/details.py?package=falconpl
<pochu> I think it means whether the clean target removes debian/tmp
<jonnymind> Can someone explain that to me? -- I copied that clean: section from the book
<jonnymind> And it shouldnt?
<pochu> jonnymind: basically, if "dpkg-buildpackage && fakeroot debian/rules clean && dpkg-buildpackage" works, you are done.
<DarkSun88> Hi all
<jonnymind> pochu: I use pbuilder, and everything builds fine...
<pochu> jonnymind: it should AFAIK. But perhaps geser means that you don't need to say it, it will be done automagically
<pochu> hey hey DarkSun88
<jonnymind> Ok. So I just remove it.
<pochu> and try the command above (build a package twice in a row)
<jonnymind> Ok
<smarter> IIRC dpkg-buildpackage already does debian/rules clean
<geser> jonnymind: does your clean target also clean the package dirs below debian/?
<jonnymind> No, only /tmp.
<jonnymind> Is that the problem?
<jonnymind> clean:
<jonnymind> 	dh_testdir
<jonnymind> 	rm -f build
<jonnymind> 	rm -rf *~ debian/tmp debian/*~ debian/files* debian/substvar
<man-di> jonnymind: you should really use dh_clean
<jonnymind> man-di: thanks
<jonnymind> clean:
<jonnymind> 	dh_testdir
<jonnymind> 	rm -f build
<jonnymind> 	dh_clean
<geser> jonnymind: after a build and calling the clean target your dir should like before (like the fresh unpacked source package)
<jonnymind> man-di: like the above?
<jonnymind> IC
<jonnymind> In other words, making packages should be idempotent... I get the picture.
<jonnymind> diff -r falbuild_ubuntu/falconpl-0.8.8/ falbuild_ubuntu_cp/falconpl-0.8.8/
<jonnymind> this after a build and fakeroot debian/rules clean on the second dir.
<jonnymind> So, yes, I would say that now they are idempotent. -- reuploading.
<rexbron> Hey everyone! Would I be able to get a review of libopenfx? http://revu.ubuntuwire.com/details.py?package=libopenfx
<dcordero> hi
<dcordero> what is the difference between use pbuilder or debootstrap?
<dcordero> This are 2 tools with exactly the same target, arent this?
<smarter> pbuilder is used to automaticaly build a package in a clean environment
<smarter> debootstrap is used to create a debian or ubuntu system where you can chroot in to test things for example
<smarter> IIRC, pbuilder use debootstrap
<tuxmaniac> hello. to avoid script-with-language-extension lintian warning. I added a line  mv $(CURDIR)/debian/alliance/usr/bin/dreal.sh $(CURDIR)/debian/alliance/usr/bin/dreal
<tuxmaniac> but it keeps saying file not found.
<dcordero> i see, so, pbuilder is a tool that keep a clean system using dbootstrap for build packages. And with debootstrap you can do all that you want in you new system
<tuxmaniac> and I added them in install section of debian/rules
<tuxmaniac> anything wrong?
<tuxmaniac> i have been breaking my head with this thing for quite some time now
<Lamego> dcordero, debootstrap is the tool to build a new debian system, it has nothing to do with what you plan to use that system for
<dcordero> Lamego, ok, i understand now. Thanks
<Lamego> dcordero, also I would recommend to talke a look at schroot/sbuild
<tbutter> tuxmaniac: why not "mv $(DESTDIR)/usr/bin/dreal.sh $(DESTDIR)/usr/bin/dreal"?
<dcordero> ok, i'll read about it, thanks again
<tuxmaniac> tbutter, that doesnt work
<tuxmaniac> tbutter, it also givees the same file not found error
<tbutter> where did you put it in the install section? at the end?
<tuxmaniac> tbutter, the last line of the install section is this
<brinley> Hi, I've just uploaded a patch to fix a bug, is there anyone here who can review it?
<tuxmaniac> tbutter, I have 5 such warnings and is really important that I get this fixed for my package to get reviewed soon
<tuxmaniac> the debian.install file installs it in usr/bin/filename.sh only
<tuxmaniac> tbutter, but the mv commands fails for some reason.
<tbutter> tuxmaniac: wait a min, i am trying to build it
<tuxmaniac> tbutter, its alliance on revu. just in case you build a wrong one. :-)
<rexbron> Sorry to review spam again, but I made a large booboo that needed to be fixed :P http://revu.ubuntuwire.com/details.py?package=openfx
<rulus> Can anyone review gtkvd? I think I fixed the comments raised earlier today, I'd really like it to be in Hardy :) http://revu.ubuntuwire.com/details.py?package=gtkvd Thanks!
<Hobbsee> erk. something's broken ruby
<Hobbsee> an autosync.
<rexbron> Thats no fun
<Hobbsee> so, we have ruby source, and ruby-defaults, apparently
<tuxmaniac> tbutter, any clues yet?
<Hobbsee> 8 packages to fix
<tbutter> tuxmaniac: its still building...
<tuxmaniac> hello Hobbsee
<Hobbsee> hi tuxmaniac
<\sh> Hobbsee, which version of ruby?
<Hobbsee> \sh: (< 1.9.0)
<\sh> Hobbsee, ah so not my fault with ruby1.9 ,-)
<Hobbsee> \sh: they've decided to change the version #, and now have nothing in common with the actual version of ruby.
<\sh> Hobbsee, you mean the version of the ruby package..grmpf..why that?
 * \sh tries to find out why some libs for wine amd64 are not found by configure...
<Hobbsee> \sh: yes.  see their changelog
<Hobbsee> oh, twitch
<\sh> Hobbsee, you mean 1.8.6.111 is wrong?
<Hobbsee> \sh: i mean 4.1 is wrong.
<tbutter> tuxmaniac: it is because you install the /usr/bin/*.sh files with alliance.install
<shibata> persia: uploaded and commented: http://revu.tauware.de/details.py?package=termlauncher-applet
<\sh> Hobbsee, where do you see 4.1? /me is not really awake today :(
<Hobbsee> \sh: version of ruby-defaults, of which the ruby binary is now built from
<tbutter> tuxmaniac: those files are copied after your mv command. just do it manually.
<tuxmaniac> tbutter, manually as in change the filename itself?
<tbutter> tuxmaniac: i think renaming the initial files in debian/desktop would be the best. otherwise you could cp/install them in the rules file instead of using alliance.install
<tbutter> anyone would like to review my package at http://revu.tauware.de/details.py?package=jodviewer ?
<tuxmaniac> tbutter, thanks a million for those valuable inputs. Hope I get someone to review my package before REVu day gets to a close
<tuxmaniac> affter fixing those warnings ofcourse
<\sh> Hobbsee, now I get it...
<Hobbsee> \sh: i'm guessing the breakage of 8 packages are those that use the old ruby
 * Hobbsee would have expected higher
<\sh> Hobbsee, yepp
<Godofgods> hello
<Godofgods> can anyone help me with regards to developing software for linux?
<jonnymind> Suggests fields in control should refer (= ${source:Version}) or (= ${binary:Version}) ?
<jonnymind> (if they refer other binary pacakges in the same source control file?)
<\sh> bah we need more libs in ia32-libs :(
<geser> jonnymind: it depends mostly on the Architecture type (all or any) of the affected packages
<peter1209>  hello
<jonnymind> I think I got it;
<jonnymind> geser: with architecture any?
<geser> jonnymind: see "How to make packages binNMU safe?" on http://wiki.debian.org/binNMU
<jonnymind> grazie
<jonnymind> *thanks
<jonnymind> gezer: If I get it right, in short any-to-any dependency and suggestion should be on binary version.
<geser> tbutter: re jodviewer: it looks like you can build jodviewer with a java compiler from universe, but depend on a runtime from multiverse. This means the jodviewer must go to multiverse. Doesn't it run with a free jre?
<geser> jonnymind: yes, if you need them to be strict
<jonnymind> geser: k, thanks.
<tbutter> geser: it runs with icedtea which is in universie
<tbutter> geser: icedtea provides java6-runtime
<geser> tbutter: but you list the sun-java6-jre as first in Depends
<dcordero> i am fixing a bug, and must be to hardy because dont pass the stable conditions for changes in gutsy. Ok, i write on debian/changelog "hardy" but then lintian tell me:
<dcordero> N:   Your version string suggests this package is for Ubuntu, so your
<dcordero> N:   distribution should be one of gutsy, feisty, edgy, dapper, breezy,
<dcordero> N:   hoary or warty.
<geser> dcordero: lintian in gutsy doesn't know hardy.
<Nafallo> outdated lintian
<geser> dcordero: gutsy-backport has a newer lintian
<dcordero> mmm ok ok ;/
<dcordero> thanks
<tbutter> geser: so the order matters?
<tuxmaniac> how do I put in manpage the value "(*(*foobar". Is this right? \(*\\(*foobar
<rexbron> Hey everyone! looking for a review. http://revu.ubuntuwire.com/details.py?package=openfx
<geser> tbutter: sort of, apt tries sun-java6-jre first before it looks for other packages providing java6-runtime
<tbutter> geser, ok i'll change the order
<tbutter> thx
<geser> tbutter: if you change the order, you should list a real package as the first alternative
<geser> rexbron: re openfx: what are the headers good for? doesn't it need to be linked to some library?
<rexbron> geser, openfx is a c api only
<rexbron> it only defines how to handle a plugin type in a program
<rexbron> openfx does not do anything by itself
<geser> do libraries exist which implement this API?
<rexbron> geser, yes, OpenLibs but that is a seperate source package. The other implimentations are propritary
<rexbron> Note that this is an optional dep for OpenLibs
<geser> rexbron: the "Recommends: libopenfx" in libopenfx-doc is correct? shouldn't it recommend the -headers package?
<rexbron> hmm, let me look
<geser> rexbron: you use the wrong automatic bug closure syntax. it's "(LP: #xxx)" (the () are optional)
<rexbron> ok, fixing both
<rexbron> geser, Pushed a new source package.
<awen_> when making copyright / changelog files what is the max number of columns in a line that i should use?
<\sh> awen_, vim does know it ;)
<rexbron> awen_, iirc 80
<geser> awen_: it should fit into a normal terminal
<awen_> \sh: needs to be trained for vim at some point :P
<awen_> rexbron: thx
<man-di> awen_: 76 is better
<ion_> 72 is even better: you can indent it by an entire tabulator and it still fits. ;-)
<awen_> i'll stick with 80 as some of it is already at 78 ;)
<ion_> (By the way, you can reformat text in vim with the gq command.)
<pochu> Is it a good idea to suggest -dev packages in the normal ones?
<dcordero> i have subscribe to ubuntu sponsor to 2 bugs that i have fix. What i have to do now? only wait?
<pochu> yes
<dcordero> oki
<mok0> I thought needs-packaging bugs were automatically closed when the package was uploaded...
<rexbron> geser, Fixed another issue, new upload available
<rexbron> mok0, iirc, the uploader sets it to "Fix Commited" and the build daemon/archive uploader will set it to "Fix Released" when the updated pacakge is in the archives
<rzr> mok0: I had to close it myself too
<mok0> rexbron: ok, so being in packages.ubuntu.com is not enough?
<mok0> Is it ok to close it yourself?
<rexbron> mok0, I could be wrong but that is the way I believe it should work. Check to see if binary packages are in archive.ubuntu.com
<mok0> I want them off my list
<mok0> rexbron: yeah, they're there.
<rexbron> should be fine then
<mok0> rexbron: fine to close, you mean?
<rexbron> mok0, yes
<mok0> rexbron: great, thx
 * mok0 goes off to close some bugs
<rexbron> mok0, That this did not happen automatically could be releated to the bugs not being set as "Fix Commited" when it was uploaded
<mok0> rexbron: yeah that didn't happen
<mok0> rexbron: uhm, it did happen on one of them
<rexbron> Then perhaps I am incorrect as to how it works
<mok0> rexbron: perhaps it doesn't :-)
 * mok0 waits to get his karma updated :-)
<warp10> Heya gang!
<wallyweek> hi folks!
<Legendario> i am having "make error 1" when trying to build a package. Does anyone know what it is?
<Legendario> the error: http://paste.ubuntu-nl.org/53400/
<Legendario> i have already tried to download all the build dependencies i could guess...
<mok0> Legendario: it tells you: you need pidgin installed
<geser> Legendario: as configure complains about pidgin try pidgin-dev
<Legendario> mok0: i have pidgin installed
<Legendario> geser: and have installed the pidgin-dev
<mok0> Like geser said, it is -dev
<Legendario> thats the problem
<mok0> Legendario: perhaps you need a switch to configure, to tell it where to find it. The macros are not always very smart
<LucidFox> Gah!
<mok0> Legendario: configure --help should tell you
 * LucidFox goes to #ubuntu to rant about how his keyboard suddenly stopped working with a normal GNOME login
<mok0> LucidFox: did you check the cable?
<LucidFox> it works right now, in a safe mode xterm session
<Legendario> mok0: what exactly should i do?
<mok0> Legendario: does configure --help tell you something?
<Legendario> mok0: tells me lots of things... i will paste bin. One second
<Legendario> mok0: here it is: http://paste.ubuntu-nl.org/53712/
 * mok0 looks
<mok0> Legendario: please pastebin configure.in (or configure.ac)
<Legendario> ok
<Legendario> mok0: here: http://paste.ubuntu-nl.org/53714/
<mok0> Legendario: can you do a dpkg -l pidgin for me?
<wallyweek> after nearly 1 year of work, sdlmame should be ready for advocation: can anyone have a look at it, please? :D http://revu.ubuntuwire.com/details.py?package=sdlmame
<mok0> wallyweek: the slowest packager in the Universe :-P
<wallyweek> so it seems :(
<mok0> wallyweek: j/k
<mok0> Legendario: can you do a dpkg -l pidgin for me?
<wallyweek> mok0: of course! :)
<Legendario> ok
<mok0> wallyweek: seems like it's gone through a few cycles of reviewing
<Legendario> mok0: http://paste.ubuntu-nl.org/53717/
<mok0> Legendario: after that do: pkg-config --variable=libdir pidgin
<mok0> ... and pkg-config --variable=datadir pidgin
<Legendario> mok0, should i type /usr/bin in the place of libdir pidgin?
<mok0> Legendario: no, just cut-n-paste this:
<mok0> pkg-config --variable=datadir pidgin
<mok0> into your terminal
<mok0> Legendario: it should say: /usr/share
<wallyweek> mok0: yes, with some gaps between each other
<Legendario> mok0, that's it
<mok0> Legendario:  pkg-config --variable=libdir pidgin
<mok0> Legendario: that should say: /usr/lib
<Legendario> mok0, /usr/share
<mok0> Legendario: /usr/share, for libdir?
<Legendario> mok0, no. /usr/lib
<mok0> Legendario: that's fine
<Legendario> mok0: sorry
 * mok0 thinks for a while
<Legendario> mok0, both have default values... what could it be?
<mok0> Legendario: Something is wrong in the macro PKG_CHECK_MODULES. Try to comment it out, like this: http://paste.ubuntu-nl.org/53722/
<albert23> Legendario: you are building in a pbuilder. That does not see pidgin on your local system.
<Legendario> albert23, do u have any other solution?
<LucidFox> I've determined that the keyboard lockup is caused by gnome-settings-daemob
<LucidFox> *daemon
<mok0> Legendario: you need pidgin-dev in Build-Requires
<geser> Build-Depends
<albert23> Legendario: what mok0 says. That will install pidgin in the pbuilder
<Legendario> mok0, i have download the package already. What else should i do? i have updated pbuilder also
<mok0> Legendario: errhh, like geser says: Build-Depends:
<mok0> Legendario: The line build-depends tells pbuilder what packages to install before attempting to compile
<mok0> Legendario: Pbuilder has a very basal system, it knows nothing about the system you are working on
<Legendario> mok0, could you please guide me step by step?
<mok0> Legendario: edit debian/control
<mok0> Insert "pidgin-dev" in the line that appears near the top, that says "Build-Depends:"
<mok0> remember a comma
<mok0> Legendario: have you done that?
<Legendario> mok0, do i have to build the source again with debuid -S -sa after it?
<mok0> Legendario: yes
<mok0> Legendario: to get your new changes in the diff.gz file
<Legendario> ok
<mok0> Legendario: then run your pbuilder
<Legendario> mok0, i will try it
<mok0> albert23: thanks for noticing the pbuilder
<mok0> albert23: I was going out on a limb
<albert23> mok0: no problem
<Legendario> does pbuilder install "another system" tree on it's folder?
<mok0> Legendario: yes
<mok0> Legendario: it keeps it around in "base.tgz"
<Legendario> mok0, so building packages is very space consuming... ;-)
<mok0> Legendario: that's the nice thing: you don't need to pollute your workstation with all kinds of weird development packages
<mok0> Legendario: not so much, that base.tgz is < 100 Mb
<mok0> Legendario: expands to ~250Mb
<Legendario> mok0, so i wasn't supposed to install the pidgin-dev on my system, only on the pbuilder?
<mok0> Legendario: you are supposed to put it in Build-Depends, then it is automatically installed by the build system in pbuilder
<mok0> Legendario: you should not install anything manually in your pbuilder system. Only update it now and then
<Legendario> mok0, i haven't installed it manually on the pbuilder, but on my system through apt-get...
<mok0> Legendario: I understand. If you want to build your system without using pbuilder, you need it of course
<Legendario> mok0, i can probably uninstall it with no problens right?
<mok0> Legendario: yes
<mok0> Legendario: in general, you don't need -dev packages
<Legendario> mok0, well it's downloading 123 packages... i guess it is going to take a while. I have to go now. I come back here later to tell you guys if it has worked
<mok0> Legendario: cool
<Legendario> mok0, thanks a lot
<mok0> Legendario: don't thank me yet :-)
<Legendario> you too albert123
<Legendario> i gotta go now
<mok0> So, my package gpp4 reached the archives, but the _all subpackage is not found for my amd64 system?
<mok0>  libgpp4-dev: Depends: libgpp4-0 (= 1.0.4-0ubuntu1) but it is not going to be installed
<mok0> :(
<mok0>   libgpp4-0: Depends: libgpp4-data but it is not installable
<crimsun> mok0: what is libgpp4-data's source package?
<mok0> crimsun: gpp4
<mok0> crimsun: everything is in that
<crimsun> mok0: there is no binary package named libgpp4-data in gpp4's debian/control.
<mok0> crimsun: what??
<crimsun> crimsun@Box:~/pulse.migration/gpp4-1.0.4$ grep -nH libgpp4-data debian/control
<crimsun> debian/control:14:Depends: libgpp4-data, ${shlibs:Depends}
<crimsun> looks like a packaging error.
<mok0> crimsun: that is _strange_
 * mok0 checks
<mok0> crimsun: thank you. I merged that package into the shared library one in the very last minute. I don't know how I could have missed that dependency error
<bddebian> Heya gang
<geser> Hi bddebian
<bddebian> Heya geser
<wallyweek> hi bddebian!
<wallyweek> bddebian: could you please have a look at http://revu.ubuntuwire.com/details.py?package=sdlmame :D
<bddebian> Hello wallyweek.  I'll try
<wallyweek> bddebian: thanks!
<jdong> persia: thanks!
<mok0> If someone could take a look at Bug #186393 before revu day, I would be grateful
<ubotu> Launchpad bug 186393 in gpp4 "Bogus dependency in libgpp4-0 shared library package" [Undecided,In progress] https://launchpad.net/bugs/186393
<geser> mok0: looks ok, I'll try to remember to upload it later
<\sh> what is the syntax for adding more bugnos to (LP: #<bugno>), is it comma separated?
<tbutter> i uploaded a new version at http://revu.tauware.de/details.py?package=jodviewer . anybody want to give it a review?
<\sh> Nightrose, done :)
<Nightrose> \sh: done what?
<\sh> Nightrose, xing
<Nightrose> ohhh ;-) hehe thx
<\sh> ok...pushed wine with some bugfixes...
<jdong> persia: when you commented upstream changelog would be nice, you mean try to find the SVN changelog up to the 0.2 release and ship it as a debian/docs?
<Taggard> persia: That dependancy thing you gave me: I have no idea how to do it because I have n oidea why it won't work.
<Taggard> persia: Ive added emacs22 as an optional dependacy but it still doesnt work
<juliank> persia: I've done what you requested @ http://revu.ubuntuwire.com/details.py?package=industrial-icon-theme
<jdong> O_O did I just start a ping persia flood? :D
 * Taggard laughs at everyone taqlking to persia 
<mok0> i would be grateful if someone could take a quick look at bug #186393 -- before revu day would be great because it is a dependency of the clipper package that I will upload later
<ubotu> Launchpad bug 186393 in gpp4 "Bogus dependency in libgpp4-0 shared library package" [Undecided,In progress] https://launchpad.net/bugs/186393
<Taggard> mok0: I can't find the package in question
<mok0> Taggard: hang on...
<mok0> Taggard: http://archive.ubuntu.com/ubuntu/pool/universe/g/gpp4/gpp4_1.0.4-0ubuntu1.dsc
<Taggard> mok0: Okay
<persia> jdong: I think upstream changelogs are user-useful.  Others disagree.  IF you pull a changelog from somewhere and install it, you make me happy.
<persia> Taggard: What happens if you just change "gutsy" to "hardy" in the last proposed patch?
<civija> guys, where can i find some info why there are no freenx packages for gutsy?
<persia> juliank: Excellent.  Now you just need another reviewer :)
<Taggard> persia: I did that
<persia> civija: There's never been any freenx package.  Maybe search for a needs-packaging bug?
<persia> Taggard: And it still didn't work?
<Taggard> persia: It makes me install emacs21, yeah
<persia> Hmm....  which bug was it again?
<Taggard> persia: Let me see
<Taggard> bug #152348
<ubotu> Launchpad bug 152348 in mmm-mode "on feisty, the mmm-mode package forces installing emacs21 instead of emacs22" [Undecided,In progress] https://launchpad.net/bugs/152348
<persia> Taggard: Did you already have emacs22 installed before installing mmm-mode?
<Coper> Hi can someone revu http://revu.ubuntuwire.com/details.py?package=console-freecell thanks.
<civija> persia: you are right, there is needs-packaging bug
<civija> persia: if i decide to package it how can i get it included in universe?
<Seveas> civija, good luck with that -- upstream for NX has an insane buildsystem from hell
<civija> Seveas: that is why you quit packaging it?
<Seveas> civija, and archive admins told me in the past that NX won't be accepted because it's basically an unpatched old version of X
<civija> aha, tnx
<Seveas> It's just not worth the trouble
<steveire> jdong: ping?
<LaserJock> hmmpf, I don't understand how people can subscribe themselves to a list and not figure out how to unsubscribe
<jdong> LaserJock: it onl says on the bottom of every e-mail...
<jdong> :D
<LaserJock> exactly
<LaserJock> and I'm staring at an email that says "please unsubscribe me from this list"
<jdong> persia: thanks for the opinion, indeed half-decent upstream changelogs are good to have, but my upstream provides none. I've uploaded another candidate with an upstream svn listing, but that isn't nearly as interesting as an upstream changelog, I am considering at this point to not include that in the final candidate :)
<LaserJock> Fujitsu: pingaloo, can you make me an admin for ~motuscience?
<persia> jdong: Seems reasonable.  My basic position is that upstream changelogs are good, as debian/changelog is often populated with "New Upstream Version (LP: #nnnnnn)", but this only makes sense when the upstream changelog is actually readable and contains useful information.
<jpatrick> jdong: you're wanted in #kubuntu-devel
<jdong> jpatrick: ooh, for what?
<jpatrick> backports
<jdong> persia: right. Well I'm not all that familiar with this project's history, but definitely for the next version I'd know enough about the release to populate at least a bit more than "new upstream release" and summarize changes
<persia> jdong: As long as someone is hand-parsing and populating debian/changelog reasonably, the upstream changelog is less important.
<jdong> persia: agreed
<Taggard> persia: I did, yes.
<Taggard> persia: Sorry for the longg delay
<persia> Taggard: Strange.  I'm about to run off, but I suggest reviewing the dependencies of your binary package.  You might need a | emacs22 |
<Taggard> persia: Okay
<Fujitsu> LaserJock: Sure.
<mok0> Taggard: so, what's the verdict on the bug? Can you re-upload?
<Taggard> mok0: Eh, I haven't been able to get the source. I am sorry if you got your hopes up, I'm just new around here. If you can tell me the name of the source package I can try though.
<mok0> Taggard: couldn't you get the source from that link I posted?
<Taggard> mok0: No, I tried all the packages in there.
<Taggard> mok0: apt-get source failed on all of them, and I also tried some regexp's.
<mok0> Taggard: dget -x http://archive.ubuntu.com/ubuntu/pool/universe/g/gpp4/gpp4_1.0.4-0ubuntu1.dsc
<mok0> Taggard: use dget
<Taggard> mok0: Ah :)_
<Taggard> mok0: I'll have a hack at it then, what is the bug number?
<Taggard> mok0: I don't promise anything though
<mok0> Taggard: bug 186393
<ubotu> Launchpad bug 186393 in gpp4 "Bogus dependency in libgpp4-0 shared library package" [Undecided,In progress] https://launchpad.net/bugs/186393
<Taggard> mok0: Building it
<mok0> Taggard: could you apply the debdiff?
<Taggard> mok0: I fixed the bug
<mok0> Taggard: When did you become motu?
<Taggard> mok0: I'm not an motu, but I'm trying to help
<Taggard> a mptu*
<Taggard> motu**
<mok0> Taggard: Ah, ok, but then you can't upload
<Taggard> mok0: No :(
<steveire> siretart: ping?
<Taggard> mok0: Do ou want libgpp4-0_1.0.4-0ubuntu2_i386.deb
<mok0> Taggard: I've got it
<Taggard> mok0: ubuntu2?, that is the version I just built
<mok0> Taggard: My problem is getting someone to re-upload the fixed package at ubuntu's server
<crimsun> mok0: I've uploaded it.  In the future, you just need to ask for a correction.
<Taggard> mok0: Oh :/
 * Taggard sighs.
<mok0> crimsun: in what way do you mean, correction?
<crimsun> mok0: just ask for it to be uploaded.
<mok0> Thanks for your effort, Taggard
<Taggard> mok0: Hehe.
<mok0> crimsun: here on the channel?
<Taggard> mok0: It is good practice even if I did the wrong thing
<mok0> Taggard: exactly!
<crimsun> yes, because ~u-u-s has a higher latency.
<mok0> crimsun: got it, thanks!
<crimsun> subscribing u-u-s and asking are sufficient.
<mok0> crimsun: I think I subscribed u-u-s, didn't I?
<crimsun> mok0: yes.
<crimsun> (i.e., there's usually someone around who can upload)
<mok0> crimsun: It's was a stupid little error to get stuck on
<crimsun> at least it was innocuous.
<mok0> crimsun: the library is a dependency of a package I will upload shortly
<Taggard> Anyway, is there a tool or way to check the dependancies of a binary .deb package?
<mok0> Taggard: a pbuilder is good
<Taggard> mok0: ?
<mok0> Taggard: install the package in a pbuilder
<Taggard> Oh
<Taggard> :/ I unfortunately have no idea what you mean.
<Taggard> I'm really kinda new at this.
<mok0> ubotu, !pbuilder > Taggard
<Taggard> mok0: Oh, I've done that. But I don't know how to install them in the chroot.
<Taggard> I've only used pbuilder to build
<mok0> pbuilder --login
<Taggard> Okay!
<Taggard> So then I'd jsut install a package like normal?
<crimsun> pbuilder has a couple hooks that can be used to automate testing package installation/upgrade/removal
<mok0> Taggard: you can use apt-get like always
<crimsun> these exist in /usr/share/doc/pbuilder/examples/
<crimsun> namely, B91dpkg-i and execute_installtest.sh
<Taggard> mok0: Heh, you are better qualified than me at this
<mok0> Taggard: nah, crimsuns the man :-)
 * mok0 should play with pbuilder hooks
<Taggard> crimsun: This is what I wanted
<mok0> crimsun: Is B91dpkg-i executed from within the chroot?
<mok0> crimsun: I don't see how the packages get into /tmp/buildd
<Taggard> mok0: You move then
<Taggard> them
<crimsun> mok0: specify a directory containing the hooks you want.  See pbuilder(8).
<Taggard> crimsun: This is gunna help a lot :)
<crimsun> e.g., sudo pbuilder build --hookdir "~/blah" junk.dsc
<crimsun> you could also use --execute [...].
<mok0> crimsun: Ah, I understand, it will execute all the scripts at different points in the process
<mok0> I guess you can also use --bindmounts if you don't have your .debs in an apt-get'able archive
<crimsun> with the usual caveat of such mounts, e.g., don't blow away files willy-nilly.  Bad Things can happen.
<crimsun> not that that has ever happened to me.  *cough*
<mok0> crimsun: /tmp is a good candidate
 * mok0 uses /tmp for all his development work ;-)
<jdong> is this a good place to cry about revu UI annoyances or is there a more appropriate venue?
<jdong> crimsun: haha recursive deletes and mountpoints... dont' we all have those nightmares to relive :D
<jdong> nvm, grievance already filed
<crimsun> hmph.  I guess it would be a good idea to backport alsa-driver 1.0.16rc1.
<mcisbackuk> How do I help out with the unmet-deps? I know how to change the control files and make sure that the builds are fine, and create interdiff patches for the changes, does this get done through LP or??
<crimsun> mcisbackuk: yes, bugs should be filed using LP against the appropriate source packages, and debdiffs, attached.
<mcisbackuk> crimsun: http://qa.ubuntuwire.com/debcheck/ so just check on there, file bug for one of them unless one is there, fix and upload debdiff?
<crimsun> mcisbackuk: and subscribe the appropriate ubuntu-foo-sponsors LP team as appropritae
<crimsun> appropriate*
<mcisbackuk> yup got that kewl thanks for help :)
<mcisbackuk> oh one other thing, does the version number get changed, like from 1ubuntu1 to 1ubuntu2?
<crimsun> generally, dch -i will get it correct.
<mcisbackuk> ok kewl thanks crimsun :)
<vemon> ok. the first version of phasex is in revu: http://revu.tauware.de/details.py?package=phasex
<vemon> please revu if you got some time & are interested in getting bleeding edge sound synths to ubuntu :)
<mok0> vemon, not a motu but a couple of comments
<mok0> vemon: debian/docs, no need to include COPYING
 * ion_ purchased a hardware synth recently. :-)
<mok0> vemon: phasex.man must be phasex.1
<vemon> damn.. i first named it phasex.1 but saw .man postfix in some other packages
<mok0> vemon: I'm not sure, dh_installman may rename it
<vemon> it probably does since it works after installing the package
<vemon> i thought it would be more clear to have .man postfix in the package source
<mok0> vemon: I'll try and see
<ion_> As long as itâs installed correctly, i donât think thereâs a problem. But i donât have authoritative knowledge about the issue.
<vemon> yes, it seems to rename it. at least the .deb has usr/share/man/man1/phasex.1.gz
<mok0> vemon: yep
<mok0> vemon: that's dh_installman magick
<vemon> lord, i thank thy for the magic :)
<jdong> thee.
<vemon> i don't have to upload a new version.. at least not yet :D
<mok0> vemon: You need a priority field in debian/control
<mok0> vemon: Priority: optional
<vemon> ok. i just removed "Prioriry: extra" :D
<vemon> Priority
<mok0> vemon: put it back
<jdong> and I beleive thy magic is correct too
<mok0> vemon: remove COPYING from debian/docs
<jdong> I thankest thou?
<vemon> mok0, done. anything else you noticed?
<mok0> vemon: In manpage, you need a correct .SH NAME line
<joejaxx> woohoo
 * joejaxx is about to do something crazy
<joejaxx> :)
<joejaxx> like upgrade the gutsy livecd to hardy live
<mok0> phasex \- program to do something
<LaserJock> DktrKranz: ping
<mok0> vemon: that's a fixed format
<vemon> mok0, in the manfile?
<DktrKranz> LaserJock, pong
<mok0> vemon: yes, the line after .SH NAME
<vemon> mok0, should it be the binary name?
<vemon> or the program name
<mok0> vemon: i.e. phasex
<vemon> phasex vs. PHASEX
<mok0> vemon: binary name
<LaserJock> DktrKranz: you didn't think a crash for klavaro warranted an SRU?
<LaserJock> seems like that would fall under the "regression" category
<mok0> vemon: phasex \- advanced software synthesizer
<mok0> vemon: I also think your manpage is b.o.r.i.n.g. This is where you want to advertise your program and say how good and fantastic it is
<DktrKranz> LaserJock, I had some doubt about it because it is reproducible with some locales only and it is quite hard to reproduce, but I agree it may fall under "regression"
<mok0> vemon: explain what you can do with the program, why it is better than others, what it can do that others can't etc.
<mok0> vemon: it is also good with some examples (if relevant) in the manpage. So the casual user can try it out and get it to work right away
<DktrKranz> LaserJock, my main concern is about what we mean with "severe regression", though
<TheMuso> Mousetweaks on revu is seeking a second advocate.
<TheMuso> I just advocated it.
<jdong> TheMuso: I don't get any love?
<TheMuso> jdong: ??
<jdong> TheMuso: never mind ;-)
<TheMuso> jdong: Ok.
<mcisbackuk> Can someone have a look at bug #186457, I'm not sure if I done it right, it's literally a 2 second look lol :) Thanks
<ubotu> Launchpad bug 186457 in a2mp3 "[unmet-deps] a2mp3" [Undecided,Confirmed] https://launchpad.net/bugs/186457
<TheMuso> jdong: If you want a package looked over, let me know. I doubt I can do a thorough job now, but I can have a lgood look later, when  I have more time, and am a bit less tired.
<steveire> siretart: ping?
<jdong> TheMuso: yeah, clutch, already on revu. It should be at the 90%-ish ready state
<LaserJock> DktrKranz: hmm, I see. Although it doesn't look like it takes too much to fix it, the debdiff is small. They went to all the trouble
<TheMuso> jdong: Ok, will take a look when I get a chance, probably when I get home.
<LaserJock> steveire: he's on German time and not likely around at the moment and you've already pinged him so perhaps email or waiting until he gets up is a good idea
<jdong> DktrKranz / LaserJock: I took a quick look at that, and if they are willing to follow through I don't see why it shouldn't be approved. "I don't have a configuration that triggers the bug so it must not be important" doesn't sound all that right :)
<steveire> LaserJock: OK. I'll try tomorrow. Cheers
<jdong> TheMuso: thanks in advance
<TheMuso> jdong: np
<steveire> What's the deal with that anyway? Do people leave their computers on and logged into IRC?
<jdong> steveire: I do
<RAOF> I do, but more so.
<mcisbackuk> Did I do wrong fixing a debian policy change bug #186457, I don't wanna get flamed for it, just trying to help out, but is this right, and OK?
<ubotu> Launchpad bug 186457 in a2mp3 "[unmet-deps] a2mp3" [Undecided,Confirmed] https://launchpad.net/bugs/186457
<mok0> vemon: I put comments on revu for your reference
<jdong> steveire: it's been 4 or so months since I've logged out
<steveire> What's the benefir?
<LaserJock> steveire: yes, many do so that they can read what's been going on
<steveire> t*
<jdong> steveire: I do read all mentions of my name while away and also like to know what's been going on since
<steveire> oh right.
<DktrKranz> jdong, well, my configuration triggered the crash (with some locales only). My main doubt is about severity of that bug.
<steveire> It must take a while to catch up.
<jdong> DktrKranz: well if one person was irritated enough to go all the way to the point of a debdiff, I think it's fair to assume a fair number of people were irritated by the bug
<DktrKranz> jdong, good point. Can we assume "severe regression" includes such cases? No doubt is a regression, but I think we should analyze what we mean with "severe"
<DktrKranz> jdong, anyway, it's reproducible (at least I was able to) and should be easy to test the fix as well.
<jdong> DktrKranz: severe to me means that the defect significantly impairs the operation of the program. A crash would definitely suffice, while a spelling mistake in the preferences window is not.
<jdong> DktrKranz: Of course this is much looser than what I'd say if we were ~ubuntu-sru
<emgent> heya
<DktrKranz> jdong, I was looking at some bugs approved by ~ubuntu-sru, and in some circumstances sigsegv-fix SRUs passed without many discussions, so I agree with you.
<crimsun> I can't help but think that perhaps we're misthinking the entire SRU testing infrastructure.
<crimsun> why aren't we using vm images?
<crimsun> (granted, it's not feasible for some portion of the testing range, like some packages affecting hardware)
<LaserJock> crimsun: yep
<DktrKranz> crimsun, IIRC use of vm images is fine: https://wiki.ubuntu.com/QATeam/PerformingSRUVerification
<crimsun> DktrKranz: more complicated than that, but I don't have it fleshed out yet.
<crimsun> there's no SRU/security policy that can satisfy every possible requirement.  They're just starting points.  We have a release manager.  Shouldn't our release manager have authority to say, "look, this is a serious bugfix and needs to get in now"?
<emgent> heya crimsun DktrKranz
<crimsun> hi
<DktrKranz> hi emgent
<LaserJock> crimsun: well, um that'd be nice
#ubuntu-motu 2009-01-19
<dholbach> good morning
<nhandler> Hey dholbach
<dholbach> hey nhandler
<hyperair> it's afternoon here
<hyperair> anyway hi
<hyperair> anyone got time for a revu?
<hyperair> (or a few)
 * nhandler can't REVU until he gets a working Jaunty pbuilder
<ScottK> nhandler: I made a new one yesterday on Intrepid, so I think your problem is system specific.
<nhandler> ScottK: It might be. I just have no idea what might be causing it. And I would prefer not to do a fresh install unless absolutely needed
<nhandler> Well, I'm heading off to bed. I need to get up early tomorrow
<hyperair> nhandler: i've got a jaunty pbuilder script if you like
<didrocks> morning
<Koon> didrocks: I'll be available to help in the French "Getting Started" session tonight, at least the first hour
<didrocks> Koon: great! thanks :)
<directhex> i won't be home until after the whole getting started session is well underway
<directhex> so if someone could tell people to have a jaunty chroot which can run x apps, for the mono session, that'd be grand
<hyperair> chroot which can run X apps? how would you pull something like that off?
<directhex> hyperair, there are guides out & about. depends how you run your chroot, really
<directhex> e.g. a pbuilder login
<directhex> then there are options like Xnest
<hyperair> hmm
<directhex> lots of guides on t'internets
<directhex> pick one & poke it until xlogo works
<hyperair> having a pbuilder chroot run X apps is awesome!
<hyperair> then i don't have to start a jaunty live session to test out packages
<hyperair> right, it never occurred to me to use Xvnc
<ScriptRipper> hi!
<ScriptRipper> i got ubuntu 9.04 on my beagleboard (ARM arch) running.
<ScriptRipper> i connected a USB ethernet adapter to it, lsusb lists it also
<ScriptRipper> how do i setup networking with that now?
<ScriptRipper> network adapter as listed with "$ lsusb":
<ScriptRipper> Bus 001 Device 007: ID 9710:7830 MosChip Semiconductor MCS7830 Ethernet
<ScriptRipper> please help!
<al-maisan> Hello there! I am trying to create a package for Apache's ActiveMQ message broker which requires a JDK to build.
<al-maisan> There's number of JDKs .. which one should I specify in the 'Depends:' section?
<hyperair> ScriptRipper: wrong channel.
<ScriptRipper> hyperair: where should i go?
<hyperair> #ubuntu+1
<hyperair> also, post your entire question in one line, not multiple
<Koon> al-maisan: you should build-depend on default-jdk
<al-maisan> Koon: ah, OK, thanks for the advice!
<Koon> al-maisan: my pleasure :)
<Koon> al-maisan: in the same vein, you should (runtime) Depend on default-jre[-headless]
<StevenK> al-maisan: If it requires a JDK to *build*, it should be in Build-Depends
<al-maisan> Ah, OK, I see.
<al-maisan> Thanks!
<pochu> Koon: congrats for your MOTU-ship :)
<Koon> pochu: thx ! I'm just back from my paternity leave, so I haven't had much time to try my new powers :)
<pochu> :)
<hyperair> =O
<hyperair> what does it take to become a MOTU?
<hyperair> Koon: to celebrate your MOTU-ship would you like to revu some packages? =p
<Koon> hyperair: i'm trying to clear out my bugmail right now, so not immediately, but tell me which and I'll see what I have the time to do :)
<hyperair> http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin, http://revu.ubuntuwire.com/details.py?package=vazaar, http://revu.ubuntuwire.com/details.py?package=sigx
<hyperair> Koon: ^ thanks =p
 * directhex summons a java team person
<Koon> directhex: I may correspond to that description.
<directhex> what's "antlr" and why does it build-depend on nant?
<al-maisan> antlr is a parser generator
<al-maisan> "ANTLR: ANother Tool for Language Recognition"
<Koon> directhex: I guess it uses ant to build in its rules file ?
<directhex> nant.
<Koon> ah, not a typo then ;)
 * Koon fetches the source package
<directhex> it's one i seem to have missed from the whole mono 2.0 transition thing
<directhex> hm, it's full of c#, it really IS a mix
<directhex> how bizarre
<Koon> ew.
<Koon> it's apparently used to build csharp libs.
<directhex> it needs transitioning
<directhex> i have no idea how i missed its existence
<proppy> oy
<stefanlsd> dholbach: Is it possible that the guys doing the dev week sessions upload files they use somewhere. im going thru some stuff and there's alot of pastebin stuff...
<dholbach> warp10: let me know when and where the interview will be posted :)
<warp10> dholbach: of course! hopefully even today, both in english and in italian :)
<dholbach> warp10: fantastico! :)
<warp10> dholbach: and thank you so much!
 * warp10 hugs dholbach
 * dholbach hugs warp10 back
<dholbach> no worries :)
<foolano> if i file a bug to request sponsorship for a new upstream version, when i attach a diff.gz, should i change its status to confirmed?
<james_w> foolano: it doesn't really matter, but yeah, go ahead and do that
<james_w> foolano: then important thing is that the sponsors are subscribed.
<foolano> james_w: after attaching the diff.gz, i subscribed the sponsors team. I was reading that I had to use the status to indicate if it's a sync, new upstream version...
<james_w> where did you read that?
<foolano> james_w: https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue Notes for contributors
<james_w> ok
<james_w> I for one never really pay attention to the status
<foolano> ok :)
<Laney> I wouldn't be surprised if some people have some fairly specific search listings set up that do check the status though
<savvas> do motus prefer diff.gz or debdiff ?
<Laney> Also, I didn't know about using incomplete for exceptions, interesting
<Laney> savvas: Depends what for
<savvas> for a patch, not a new upstream release
<savvas> just asking to know which one makes life easier :P
<james_w> savvas: debdiff please
<Laney> debdiff then
<savvas> ok :)
<Laney> Makes it easier to review just what you changed
<slytherin> james_w: just FYI ... I have verified that the changes to azureus launcher done in Debian work properly. So I will probably complete the merge today.
<james_w> slytherin: great, thanks
<slytherin> james_w: ï»¿I have one question though. Azureus has auto update enabled by default, when I launch azureus first time it starts downloading latest version. This in my opinion not only security issue but also wastage of bandwidth.
<james_w> yeah, I think it's not a good idea to have that
<james_w> I though it was disabled
<james_w> or maybe there was just an open bug about it
<Laney> Don't we generally disable automatic updates?
<broonie> Certainly anything that should be provided by the package manager ought to have it disabled.
<slytherin> james_w: IIRC, there is a open bug for it in Debian.
<slytherin> james_w: so I think I will have to patch the source to disable it.
<slytherin> savvas: it depends on the type of sponsorship. if it is upstream version change then .diff.gz, if it is ubuntu revision change then debdiff
<savvas> ok
<mok0> azeem: I've committed a new version of gamgi to the svn repo
<mok0> azeem: the license problems have been solved now I think
<james_w> "printf '%%s/^hardcode_libdir_flag_spec=.*$/hardcode_libdir_flag_spec=" -D__LIBTOOL_AINT_NO_FOOL__ "/\nw\nq\n' | ed libtool"
<ia> hello, maybe it's not right place for this question, but at #ubuntu-devel i can't find out answers. i use alpha-3 with latest updates. http://www.markshuttleworth.com/wp-content/uploads/2008/12/jaunty904_notifications_example1_web_092.swf - this notification system looks very useful, but how can view it in action? i mean, which apps and what kind of events supports such notifications? how this system names? and technical question - it's just some impove of n
<ia> otification-daemon, or something else? and where i can find out, which api's in which languages allow to initiate such notifications? i will be very appreciate for any useful information :-)
<slytherin> ia: I don't think that notification system is yet implemented.
<azeem> mok0: awesome!
<_ruben> is it just me or is it just not that clear which dependencies are problematic when using pbuilder :p
<_ruben> (trying to backport bind 9.5 to hardy)
<mok0> azeem: perhaps we should try another upload?
<azeem> yeah, looking into it currently
<mok0> azeem: cool
<_ruben> ah .. got it .. i think
<_ruben> The following packages have unmet dependencies: pbuilder-satisfydepends-dummy: Depends: libcap2-dev which is a virtual package.
<slytherin> _ruben: what is exact problem? And why are you blaming pbuilder for that?
<_ruben> slytherin: its an interoperability problem with pbuilder and my eyes really ;)
<_ruben> pbuilder outputs a lot, kinda hiding the actual problem
<azeem> mok0: was it gamgi-all or gamgi-src that we need?
<mok0> azeem: errr, the watch file got the right one for me
<azeem> k
<slytherin> _ruben: the bind in jaunty needs libcap2-dev >= 2.11 as build depends, but intrepid has only 2.10-1. That mighte be the problem.
<_ruben> slytherin: hardy doesnt have libcap2-dev .. that's the prob :)
<slytherin> _ruben: oh, I thought you were backporting to intrepid
<_ruben> ah
<hyperair> mok0: got time for revu? =p
<mok0> hyperair: errm, not now
<hyperair> alright
<AdamDH> is there any easy way to find out what dependancies a package requires?
<AdamDH> hey
<mok0> AdamDH: what package, one you've the source package for?
<slytherin> AdamDH: apt-cache show packagename, check the Depends: field
<hyperair> AdamDH: apt-cache depends packagename
<AdamDH> a package from source one I am packaging at present
<hyperair> for build-deps, apt-cache showsrc
<hyperair> oh
<slytherin> AdamDH: look into debian/control
<mok0> dpkg-checkbuilddeps
<hyperair> as in one that hasn't been packaged you mean?
<AdamDH> yes as in one that has not been packaged before
<mok0> AdamDH: is is a depends missing in debian/control?
<hyperair> mok0: he's packaging one from source. he's making the debian/control
<AdamDH> i am packaging from source so I am making the debian/control file
<hyperair> AdamDH: ask the upstream author, or alternatively, look at the build system it's using. if it's autotools, look in configure.ac or configure.in
<slytherin> ok, then probably look into any README file or configure.ac, configure.in
<hyperair> AdamDH: look for the stuff that says PKG_CHECK_MODULE(
<hyperair> and poke around some more if it's not complete
<AdamDH> thanks for the help I will take a look
<mok0> AdamDH: ... or if you can find out what file it's looking for, find the file at http://packages.ubuntu.com/ where you can search the content of packages
<AdamDH> thanks mok0 never considered doing that, thats a faster way of finding the dependancy
<azeem> mok0: uploaded
<bddebian> Heya gang
<ripps> Since launchpad is in the process of generating everybodies archives keys as we speak, how can one go about making a *-keyring package?
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek to start in #ubuntu-classroom in 17 minutes
<james_w> ripps: there's not a great deal of point
<hyperair> ripps: launchpad will have signed ppas then?
<ripps> james_w: I don't care, I'm bored and need a project to do.
<ripps> hyperair: I couple archives already have them released. (Ex. https://edge.launchpad.net/~fta/+archive/ppa )
<hyperair> i see. that's cool
<hyperair> but does that mean that the private keys are held on the lp server?
<lfaraone> Hi, a sync request I filed two weeks ago that has been ack'd by MOTU has yet to be acted upon, how much longer should it take? (bug 313773)
<ubottu> Launchpad bug 313773 in ubuntu "Please sync python-gasp 0.2.1~bzr65-1 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/313773
<mok0> lfaraone: there are no specifications on the duration of sync requests
<lfaraone> mok0: Ok, I'm just trying to make sure that I don't miss the freeze on this one.
<lfaraone> (yes, I know that's months away :)
<james_w> it may be delayed as it is a new package, I'm not sure
<mok0> lfaraone: The archive admins will get to it in time
<mok0> lfaraone: it's not so long ago it was ACKed
<lfaraone> mok0: it was acked the same day I filed it, 15 days ago.
<lfaraone> james_w: understood.
<mok0> lfaraone: it's pretty high up the wishlist, so shouldn't take too long now
<maxb> hyperair: Yes, it does.
<lfaraone> mok0: kk.
<hyperair> maxb: so they finally decided to go ahead with it despite the fact that the keys are on the server? i thought they didn't want to store private keys on the server
<maxb> They're not storing _people's_ private keys - they're storing locally generated PPA-only private keys
<ScottK> Right, it's the PPA archive that's signed by LP.
<Ng> so who's going to kban hormesis? :)
<laga> why?
<jpds> Ng: What laga said.
<Ng> [17:36] DCC SEND from hormesis [0.0.0.0 port 0]: startkeylogger [0B bytes] requested in channel #ubuntu-motu
<ScottK> !ops
<ubottu> Help! Hobbsee, Riddell, sladen, fbond, mneptok, gnomefreak, Seveas, dholbach, elkbuntu, PriceChild, or jpatrick!
<jpds> Too late.
<ScottK> OK
<hggdh> gone
<Ng> (startkeylogger being a string which causes some terminally braindead windows firewalls to cut network connections to protect against botnets ;)
<Ng> or maybe half of you *are* spambots :)
<SherokiX> hi
<lfaraone> Ng: oh, yeah, I'm currently a bot DDoSing http://whitehouse.gov :)
 * hyperair hates xulrunner
<mneptok> there is no data, only xul.
<hyperair> whatever
<hyperair> it's hell trying to get this damn package to LINK with xul
<hyperair> something about libxul.so having unresolved symbols
<hyperair> and cannot find libmozjs.so
<hyperair> but for the love of god it's right there
<hyperair> why can't it find
<hyperair> @_@
<hyperair> short of hardcoding the path into -R i don't know what to do
<pochu> RainCT: feel free to join #ubuntu-es-dev, we have quite a few new interested contributors :)
<pochu> dholbach: the Spanish session was great :)
 * pochu hugs nxvl and dholbach 
<dholbach> pochu: ROCK ON guys!
<dholbach> :-)
<dholbach> thanks a bunch
<tigreton> hi
<pochu> hello tigreton
<hyperair> hey how do i path -rpath-link <somedir> to ld from autotools?
<hyperair> bla_LDFLAGS doesn't seem to work T_T
<quadrispro> RainCT: followed DktrKranz suggestions, now uck seems ready -> http://revu.ubuntuwire.com/details.py?package=uck
<Chris`> http://revu.ubuntuwire.com/details.py?package=partitionmanager Can someone free please review my package? :)
<ivoks> zul: i don't understand pitti's comment :)
<ivoks> wrong channel :)
<dholbach> didrocks, pochu: still have the session logs?
<dholbach> can you post them to https://wiki.ubuntu.com/UbuntuDeveloperWeek ?
<dholbach> bddebian: #ubuntu-classroom needs you :)
<dholbach> if bddebian can't attend can somebody please assist nxvl in #ubuntu-classroom with "Working Well With Debian"? please?
<stefanlsd> im around and can try help, not sure how i can help tho
<ia> does exist some automate tools, which helps to search "Copyright" strings in source code tree of project for "copyright" file? if yes, how it names, and which of them ubuntu maintainers use?
<pochu> ia: there's "licensecheck" in devscripts
<pochu> and there's also "grep -R -i copyright *" :-)
<didrocks> I try to use start-stop-daemon in an init script, with -m option (to create the pidfile), but it does not write the right pid (cf http://paste.ubuntu.com/107052/). So, my init script fails
<fabrice_sp> Hi. I'd like to request the sync to upgrade of a lib from debian (bug #318658), but it breaks openmovieeditor. Should I request first the sync, and open another bug for openmovieeditor? Or my sync will be denied?
<ubottu> Launchpad bug 318658 in gavl "Please sync gavl 1.1.0-2 from Debian unstable" [Undecided,In progress] https://launchpad.net/bugs/318658
<fabrice_sp> hmm, building openmovieeditor with the old lib also fails, so it's not because of the sync. I'll request the sync, and open the bug report for the FTBFS
<james_w> fabrice_sp: do you plan to work on the openmovieeditor FTBFS? It's also holding up the NBSing of the old gavl soname?
<Chris`> http://revu.ubuntuwire.com/details.py?package=partitionmanager Can someone free please review my package? :)
<jsmidt> If I patched a bug that affects a package both in intrepid and jaunty, for which distro do I make the debdiff? Both intrepid and Jaunty?
<james_w> jaunty
<laga> jsmidt: for intrepid, it'll have to be an SRU. in general, you get your fix into jaunty first and then SRU it
<jsmidt> james_w, laga thanks.
<fabrice_sp> james_w, yes: I'll fix the wrong header
<fabrice_sp> in openmovieeditor to take into account hte new lib
<fabrice_sp> s/hte/the/
<Chris`> Just outta curiosity, how many days does it normally take to get a full revu? :)
<RainCT> Chris`: Interesting question. I can't really say (it depends on the package, how insistent you are and a lot of stuff :P).  If I'm bored some day I may write a script to calculate some average values.. :P
<jpds> RainCT: What do you think of my splitting of the common.py script into little bits in Bazaar?
<Chris`> How persistent should one be? :)
<ia> if use pbuilder for building package, then all packages, which were installed as deps for building, will be removed after building. but if i login in tgz archive via "pbuilder --login" and install some packages, will they be removed after logout either?
<Laney> ia: yes
<Laney> (unless you use --save-after-login if you want it to save)
<RainCT> jpds: dunno.. would we win anything with that?
<RainCT> jpds: btw, the recursive dir creating function in common.py can probably be replaced by a os.makedirs inside a try-except
<jpds> RainCT: No need to load a massive file for small scripts? Just the specific thing you want?
<jpds> RainCT: Got point, I'll try that.
<RainCT> jpds: Right now I'm not even sure what it contains, so feel free to do what yo think is the best. At the moment you're the u-d-t master ;)
<jpds> \o/ POOWER!
<RainCT> lol
 * Chris` pokes RainCT 
 * RainCT is poked by Chris` 
<Chris`> Fancy doing a review? :D
<RainCT> doing homework :(
<RainCT> but I've almost finished so drop an URL and I may look at it
<Chris`> I'll only give you the one if you're busy; http://revu.ubuntuwire.com/details.py?package=partitionmanager
<Laney> Chris`: It's LP: #xxx, no need for Closes
<Chris`> Laney: But for now is Closes acceptable? :)
<Laney> not
<RainCT> nope
<Laney> no*
 * Chris` quickly edits
<RainCT> Closes means bugs.debian.org
<Laney> Chris`: Do you need compat to be 7?
<RainCT> (unless what you've written "Closes LP:", which would be correct but is ugly :P)
<Chris`> Laney: It's ok as it is but I could change it if you wanted?
<RainCT> lower versions are preferred if possible, as they allow for easy backporting
<Laney> ^
 * Chris` changes to 3 then ;o
<RainCT> o_O
<Chris`> Bad idea?
<RainCT> 3 is obsolete :P
<RainCT> not recommended anymore.. minimum is 4 iirc
<Chris`> 5? Ã²_Ã
<Chris`> Ah 4 then
<Laney> Chris`: check man debhelper for what the levels do
<Chris`> I have updated twice now, wait for the updates to appear I guess
<Laney> I hope you checked everything was still OK with the new compat level :O
 * Chris` is running pbuilder but wishes for the best anyway
<RainCT> (REVU processes the uploads every 3 minutes)
<Laney> Bah
 * Laney bahs at debian-multimedia changelogs
<jpds> Gotta love cron.
<Chris`> Ok it;s up
<RainCT> (except for PPA imports, which run every 5 minutes as nobody is using them right now anyway)
<Laney> "New upstream version". Except lots more than that was changed >:(
<Chris`> http://revu.ubuntuwire.com/details.py?package=partitionmanager
<Chris`> How long does it take for me to get my packages to be auto uploaded? Do I need like a month's perfect track-record first of no errors or something?
<fabrice_sp> Hi. Some MOTU to review a dvd authoring tool? It's dvdstyler (http://revu.ubuntuwire.com/details.py?package=dvdstyler) and already has an advocated from mok0
 * RainCT tries to hug mook0 but doesn't find him online :P
<Chris`> <Chris`> Just outta curiosity, how many days does it normally take to get a full revu? :)
<Chris`> * mok0 (n=mok@563413c5.rev.stofanet.dk) has left #ubuntu-motu
 * fabrice_sp too :-)
<Chris`> :)
<laga> Chris`: it needs two reviews.
<RainCT> Ah, right. I don't read quit messages :P
<Chris`> I was refering to mok0 leaving :)
<jpds> from ubuntutools import lp.cookie -> SyntaxError: invalid syntax. WHY?!
<RainCT> jpds: the dot
<RainCT> jono: lp.cookie is file cookie from module lp
<RainCT> which of course is not valid as you're saying it also that the module is ubuntutools
<pochu> RainCT: jono doesn't care :P
<RainCT> uops
<RainCT> well, I'm sure jono also likes Python! :P
<jpds> RainCT: OK... good point.
<Arc> would anyone here want to advise on an XMPP client library to use for a new app intended for universe?
<Arc> (an XMPP x.509 cert manager via gnome-keyring)
<xnox> hello today at the classroom session about working with debian it has been referenced to use tags in the patches with a link to past ubuntu-devel discussion. Is there any more documentation about this? Is it ubuntu specific? Am I safe to include those in packages aimed to enter debia? I have a link mentioned in the session if you want it it's from 2007 though.
<xnox> s/debia/debian
<raof> xnox: You mean the tags from the list which was basically: (a) this should go upstream, (b) this should go to Debian, (c) this is Ubuntu specific?
<raof> That tagging scheme is Ubuntu specific, but there'd be no harm in including it in packages for Debian (with the obvious exception that there should be no patches with the (c) tag in Debian ;))
<raof> There's no tool (that I know of) that uses or reads those tags; they're just for the benefit of the human reader, and Debian can benefit just the same.
<james_w> xnox: what was the link?
<james_w> was it about http://wiki.ubuntu.com/Debian/Bugs/Usertagging ?
<james_w> https://wiki.ubuntu.com/Debian/Usertagging I mean
<xnox> james_w: https://lists.ubuntu.com/archives/ubuntu-devel/2007-November/024743.html
 * xnox sorry was reading debian-legal and forgot everything
<james_w> ah, yeah, that's the scheme raof was talking about
<xnox> raof: Yeah I don't quite understand how to and where to put them
<james_w> they go inside the patch, or the changelog, so it's not really something we can annotate externally
<james_w> and perhaps shouldn't be
<xnox> james_w: so how do I put inside the patch? A comment in the begging, debian/control style tag: value?
<xnox> cause I have patch to add to the package
<james_w> xnox: ah, if you're creating a patch that is perfect
<james_w> xnox: if it's a dpatch then it can go in the dpatch comments
<james_w> if it isn't then in the changelog
<james_w> (if it's another patch system then it can go at the top of the file, but that's a preference thing really)
<xnox> james_w: cool
<xnox> james_w: Has been reading about Usertags, cool stuff
<xnox> So..... If I contribute to debian using ubuntu-hat, can I reference that to become Ubuntu Member? =DDDDD
<james_w> xnox: it will count towards your application
 * xnox exciting
<xnox> s/exciting/excited
<Rudd-O> hey guys
<Rudd-O> I'm looking for a packaging ninja to package an app for ubuntu
<Rudd-O> anyone up to the task?
<Rudd-O> (it should be really simple because the install is basically python distutils and that's it)
<Rudd-O> the reason I ask is because I run fedora and I am looking for a volunteer to package this for me on ubuntu
<pochu> https://wiki.ubuntu.com/PackagingGuide/Python
<pochu> in case you or somebody else find it useful :)
<Rudd-O> I will likely do that but the problem is that I don't run ubuntu myself, so I have no access to the packaging system
<Rudd-O> this is what I want to get packages for:
<Rudd-O> http://rudd-o.com/new-projects/portablelinux
<pochu> you can file a needs-packaging bug
<Rudd-O> ah that's the procedure?
<Rudd-O> will do so right away
<pochu> Rudd-O: basically report a bug here, and tag it "needs-packaging" https://edge.launchpad.net/ubuntu/+filebug
<pochu> Rudd-O: of course add a link to the project, a description, and mention what license it has
<pochu> that should do enough
<pochu> but there are no warranties anybody will package it :) it's just a request
<Rudd-O> I just did that
<Rudd-O> done
<Rudd-O> https://bugs.launchpad.net/ubuntu/+bug/319005
<ubottu> Launchpad bug 319005 in ubuntu "Portable Linux Needs packaging" [Undecided,New]
<pochu> Rudd-O: you might want to talk to evand in #ubuntu-installer; I think he develops a similar tool for Ubuntu
<Rudd-O> pochu: thanks for the HUP, I'm gonna talk to him now
<porthose> Could I get a REVU of http://revu.ubuntuwire.com/details.py?package=quickplay please :)
<maxb> porthose: You have a quickplay.py in your .orig.tar.gz, and then a near-identical quickplay with no extension in you .diff.gz
#ubuntu-motu 2009-01-20
 * Hobbsee blecks at that 'diff' containing the entire source code and debian/ of the project.
<jsmidt> I've been reading https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate to learn how to update a package.  After I update the package do I make a bug on launchpad?  The howto doesn't say.  Should I subsribe the universe sponsors?
<shenron> hello, I am currently trying to get some software I wrote into ubuntu. Is it important to use make for compiling? Currently it compiles using a script which runs a few g++ commands (its a fairly simple compile), but if I want it packaged for ubuntu should I switch to make?
<shenron> I was directed to ask that question here by someone in #ubuntu, btw.
<raof> shenron: It's not important to use make at all; all that's required is that it builds from source, and this build can be automated.
<shenron> oh ok, so since there is a script that builds it that should be fine?
<raof> jsmidt: Yes, you make a bug on launchpad, attaching the new diff.gz
<raof> shenron: Right.
<shenron> w00t, awesome. should I include an installer which will put something in /usr/bin as well?
<jsmidt> raof, thanks.
<jsmidt> raof, do I need to kink to the new orig tarball?
<jsmidt> link
<raof> shenron: That's generally nice for other distros, but is not absolutely necessary.
<raof> jsmidt: No; have a watch file that works ;)
<shenron> alright, thanks raof
<porthose> maxb: thx. shot myself in the foot with that one hehe
 * porthose goes and fixes
<maxb> porthose: see comments on REVU, sorry, I've given you a lot to think about :-)
<jsmidt> I have a debian rules file with a slice command.  What is that?  Pbuilder is complaining slice: Command not found.
<maxb> jsmidt: Try 'dpkg -p slice'
<maxb> Though clearly the package is wrong if it uses a command and doesn't Build-Depend on it
<jsmidt> maxb, it does build depend on slice.  Yet, right off the bat I get this error
<maxb> hrm, peculiar
<maxb> that doesn't make any sense :-/
<jsmidt> ya
<maxb> do you want to pastebin a buildlog?
<jsmidt> maxb, http://pastebin.com/d3b659090
<maxb> Ohhhh
<maxb> See line 14
<jsmidt> ya
<jsmidt> What warning is that?
<maxb> unmet build-deps
<jsmidt> I thought pbuilder took care of adding build-depends
<maxb> pbuilder has two modes, in the mode you're running it in, it builds a source package *outside* the chroot, copies(?) the source into the chroot environment and builds it
<jsmidt> How do I run the other mode? I typed "pdebuild " which has seemed to work with everything else.
<maxb> --use-pdebuild-internal. The man page warns "This option will not protect the working directory and its parent directories from the build scripts." I get why it doesn't protect the working dir, since it's being bindmounted into the chroot. I don't understand how the parent dirs would be visible, though
<maxb> unless you can actuall ../../ up out of a bindmount!?
<jsmidt> weird
<raof> jsmidt: The problem is that slice is required for the clean target; IE: you need slice to build the _source_ package.
<jsmidt> okay
<hyperair> does anyone here have experience making a program link with xulrunner?
<raof> hyperair:  asac does.
<hyperair> asac: ping
<hyperair> raof: thanks
<jsmidt> Is there any documentation for interacting with Lanuchpad over the command line?  Open/closing bugs, adding attachments, etc... Do I have to use the web interface?
<raof> You can use gpg-signed mail.
<jsmidt> Okay, is there documantaion for how to open a bug using mail for example?
<raof> Yes.  There's a page on launchpad, or you can email help@bugs.launchpad.net, I think, to get an automated thingy.
<jsmidt> raof, thanks, I think I have found it.
<xnox> Do I need to write patch description anywhere? Changelog?
<raof> You do need to write a patch description _somewhere_.  If you're using dpatch, I'd stick it in the dpatch header.
<raof> You also need to describe what the patch _does_ in changelog.
<xnox> raof: simple-patch-sys?
<xnox> raof: patch comments on top + changelog?
<raof> That should be OK, yeah.
<hyperair> raof: is it required for initial releases?
<raof> Is what required for initial releases?
<hyperair> entries in changelog regarding patches
<ScottK> hyperair: Yes.  All patches should be documented.
<hyperair> ScottK: even if there's a header?
<ScottK> hyperair: Yes.
<hyperair> i see
<hyperair> on a side note, if i've got a package which requires *-gtkmozembed, which package should i b-d on?
<hyperair> i tried using libxul-dev, but it seems that it's an older version of xulrunner
<hyperair> xulrunner-1.9-dev refuses to be compiled without -R in LDFLAGS
<raof> xulrunner-1.9-dev is, I believe, the right header.
<raof> s/header/package.
<toresbe> OT: Are there any doxygen-literate people here? I'm faced with a problem and I don't know where to ask it.
<toresbe> I've been asked to fix up some PHP files (ugh) and I'm doxygenizing them now. For *one* of the files, a completely unremarkable file, it is refusing to document the functions (but not the @file).
<toresbe> (The line endings are the same, BTW.)
<hyperair> raof: but the libraries are all in /usr/lib/xulrunner-1.9.0.5/, and ld can't find them to link without -R. if i chrpath -d the executable after compiling, ld can't find the library to link with
<raof> hyperair: That's right.  You either need a wrapper that sets LD_LIBRARY_PATH, or you need a RPATH.
<hyperair> raof: i'd leave the RPATH intact, but it seems that debian policy doesn't allow it
<toresbe> If anyone feels like taking a look, the file is here: http://gunkies.org/stuff/problematic_php.txt
<raof> hyperair: There's a _reason_ the world + their dog is moving to embedding webkit rather than gecko.  Gecko is a pain in the arse.
<toresbe> It sees the function, but not my comments.
<hyperair> raof: you don't really have a choice if the package only has support for embedding gecko
<hyperair> well there's the choice of not embedding it at all
<hyperair> i mean not packaging it at all
<raof> Right.
 * hyperair grumbles
<hyperair> i thought patching the thing to use gtksourceview2 instead of 1 was the end of my problems
<hyperair> at least it compiles with libxul-dev
<hyperair> and runs. just that you get the old chiselblock interface that reminds you of firefox 2
<fabrice_sp> Hi. When fixing a FTBFS, should I also fix warnings in lintian? Or I should just patch the FTBFS? It's for openmovieeditor in jaunty
<fabrice_sp> (I'm getting warning/errors on watch file, out-of-date standard 3.7.2 and  build-depends-on-obsolete-package
<fabrice_sp> )
<ScottK> fabrice_sp: Standards version you should not change at all.
<ScottK> There is Ubuntu Policy on that.
<ScottK> Fixing the watch file and build-dep-on-obsolete package (make sure it works with the new one) are both good.
<ScottK> Those are also changes that should go back to Debian.
<fabrice_sp> ok (I didn't remember is Policy apply to development version). As soon as I've got a working package, I'll report the FTBFS to debian
<fabrice_sp> thanks
<diwic1> Hello, I would like a MOTU to perform a merge for Jaunty
<stochastic> How should I format a copyright file if none of the headers have copyright attributions?
<raof> stochastic: If its obvious that they're all under the same license as found in COPYING or whatever, then just as if they all had the same copyright header.
<raof> stochastic: If it's not obvious what license they're under, then you get to play "poke upstream until Ubuntu can redistribute".
<stochastic> raof, it's clear it's GPL, but no years are mentioned
<fabrice_sp> diwic1, is there a bug in launchpad?
<diwic1> fabrice_sp: #317254 and duplicates
<fabrice_sp> bug #317254
<ubottu> Launchpad bug 317254 in audacity "Please sync audacity 1.3.6-2 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/317254
<raof> stochastic: Then, I guess, you don't have copyright years in debian/copyright.  But I'm not entirely sure.
<_16aR_> Hello, any admin of revu there ?
<dtchen> diwic1: it's enqueued for archive admin processing; please be patient.
<stochastic> raof, I'm updating libphat0 (and it's dev counterpart) to the upstream version, and neither have anything in the copyright field of the debian/copyright file but lintian gives me warnings about this, should I just leave it without (it came from upstream that way)
<diwic1> dtchen: Okay, thanks. Is there a way I can find status or know more about this "archive admin processing"?
<raof> stochastic: If you don't have date information, I don't see what else you can do; you might want to get other opinions, though.  Also, libraries are a bit more complex; have you read the library packaging guide and done all the necessary ABI checks etc?
<dtchen> diwic1: one of the archive admins will look at the bug in due time. i'm not an archive admin, so i don't have an ETA.
<stochastic> raof, I'll take a look, I'm new to packaging, so I'm learning as I go...
<raof> stochastic: You'll want to read at least the library packaging guide http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
<stochastic> raof, thanks
<persia> Any REVU people about?  I'm troubleshooting the upload of hexdiff for _16aR_ (lp:dolanor).  The GPG key in use changed recently, and the package is repeatedly rejected, although the signature matches the key in LP.
<persia> Anyone know how to force key resync?
<coppro> wait 24 hours?
<coppro> wait for a REVU admin to come along?
<persia> coppro, I am a REVU admin.  I just haven't tried a resync since the LP integration.  Do you know that 24 hours fixes it?  I thought that might have changed with the LP integration.
<coppro> oh.
<coppro> in that case, no clue, since I do not have resync access. But IIRC, REVU resyncs automatically every 24 hours
<persia> It certainly used to be that way, then it was stopped, and we did it manually roughly once a day.  I don't know the current state.
<persia> nhandler, ?
<dtchen> jpds: ^
<hyperair> speaking of revus could someone review my package http://revu.ubuntuwire.com/details.py?package=sigx?
<coppro> no, MOTUs don't review your packages; they just let them simmer and hope they get better :P
<hyperair> T_T
<hyperair> well i can't think of anything else i need to do, so i'd either like guidance or an advocate
<jsmidt> Is there a website that keeps track of packages in debian and not Ubuntu?
<jsmidt> And outdated packages in Ubuntu versus upstream?
<dholbach> good morning
<raof> jsmidt: We've got an Ubuntu external health thingy.
<jsmidt> raof, found it, thanks
<dholbach> was there anybody in the Italian "Getting Started" session yesterday and could post the log at https://wiki.ubuntu.com/MeetingLogs/devweek0901/GettingStartedIT ?
<persia> jsmidt, You've found UEHS, or mdt, or both?
<jsmidt> I found http://qa.ubuntuwire.com/ which seems to have everything
<dholbach> hey warp10
<dholbach> warp10: do you have the log of the Italian Getting Started session? :)
<warp10> morning dholbach!
<dholbach> warp10: could you add it to https://wiki.ubuntu.com/MeetingLogs/devweek0901/GettingStartedIT if you have it? :)
<warp10> dholbach: I have about one hour and half of the whole log, my network had troubles in the remaining half hour
<dholbach> warp10: no worries, I can ask quadrispro or gaspa once they turn up :)
<dholbach> warp10: how did the session go on the Italian end?
<warp10> dholbach: anyway, one of the attendant logged the whole sessione, he should be online soon
<dholbach> warp10: super, thanks! :)
<warp10> dholbach: very well, IMO. We had 4 or 5 people attending the session, and we covered the whole program: LP, GPG, setting up the tools, some basic information and a lot of questions! :)
<dholbach> so we have a bunch of new Italian MOTUs soon? ;-)
<warp10> dholbach: I really hope so! :D
<dholbach> woohoo :)
 * dholbach hugs warp10
 * dholbach is really happy with how UDW is kicking off this time
 * warp10 hugs back dholbach 
<toresbe> OT: Are there any doxygen-literate people here? I'm faced with a problem that looks a lot like a bug and I don't know where to ask it.
<warp10> dholbach: what about the other LoCo sessions? Lot of people attending everywhere?
<jsmidt> Well everyone, thanks for the help.  I learned a lot today.
<jsmidt> I was able to work on 10 bugs.  I've never been able to do that many.
<dholbach> warp10: I think we had like 25 people in the German channel - what I liked very much was that they were all asking lots of questions in the sessions afterwards, so I'd say they found their way in (during the getting started session) quite easily
<jsmidt> But I've tried a lot of new stuff so sorry in advance. :)
<dholbach> jsmidt: Keep up the good work! :-)
<jsmidt> Try not to  send to many angry emails.
<jsmidt> Again, thanks for the help.
<dholbach> toresbe: I used doxygen many years ago - I'm not sure I can help, but can take a look
<toresbe> dholbach: thanks.
<toresbe> I've been asked to fix up some PHP files (ugh) and I'm doxygenizing them now. For *one* of the files, a  completely unremarkable file, it is refusing to document the functions (but not the @file).
<warp10> dholbach: oh, a *lot* of people! well, great! I hope we will keep on with these MOTU-Loco activities. The italian development team will be happy to partecipate
<dholbach> toresbe: do you have that file, your Doxyfile and the log somewhere?
<dholbach> warp10: that's exactly what I wanted to hear! :)
<toresbe> dholbach: The log is uneventful; it parses the file no problem.
<warp10> :D
<toresbe> http://gunkies.org/stuff/problematic_php.txt
<toresbe> that's the PHP file.
<dholbach> warp10: let's try to plan a developer-loco-something day in a few weeks
<toresbe> dholbach: http://gunkies.org/stuff/problematic_php_doxy.txt
<toresbe> dholbach: Oops, ignore the colourful comment at the top of the code, please. :)
<warp10> dholbach: cool! Feel free to ping me if you need help on the italian side :)
<dholbach> warp10: super! :)
<_ruben> ok .. this is weird .. im trying to backport bind 9.5 to hardy .. the ./configure command fails when run by pbuilder, but the same ./configure command runs just fine when run in the shell that i got via a pbuilder hook .. guess next step would be to see how debian/rules would go about things
<dholbach> toresbe: does it document other files in the directory? does it stop somewhere? is there NO output at all about that file?
<toresbe> dholbach: It documents other files no problem. It runs through the entire thing. The file is documented, but the *functions* are not.
<toresbe> dholbach: subsequent @warnings in the same file *are* included; so it doesn't stop parsing. It just doesn't see @fns for *that* file.
<dholbach> toresbe: very weird... I'm sorry I'm not of much help - it's been ages since I used it.
<dholbach> toresbe: no idea
<toresbe> dholbach: It's driving me crazy, documenting this code is something that I was supposed to be done with yesterday.
<dholbach> toresbe: do the doxygen folks have an IRC channel?
<toresbe> dholbach: Nope. :(
<toresbe> That's why I'm asking in random channels wherein I expect to find clever people :)
<dholbach> toresbe: I'd try there mailing list then
<toresbe> dholbach: Sigh, I haven't got many good experiences with those.
<_ruben> hmm .. even debian/rules build seems to work just fine .. must be some odd $ENV thingie messing stuff around .. oh well .. lets wait for the results first
<persia> toresbe, Check your autotools configuration.
<toresbe> persia: How could that change the behavior of an already-compiled program?
<persia> toresbe, It oughtn't: it's just one of the places I tend to look when ./configure doesn't do what I'm expecting.
<persia> Since ./configure is often run at package-time or build-time, I'm probably confused.
<didrocks> Hi everyone
<didrocks> I try to use start-stop-daemon in an init script, with -m option (to create the pidfile), but it does not write the right pid. I think the process is forking as soon as it starts (cf http://paste.ubuntu.com/107252/)
<didrocks> consequently, my init script fails :/
<savvas> where can I find documentation about .update-notifier files, the ones that go in /var/lib/update-notifier/user.d/ ?
<didrocks> I can pgrep to erase the wrong pid, but well... I would prefer another solution
<stefanlsd> didrocks: does the program not create its own PID?
<didrocks> stefanlsd: unfortunately not. That's why I use the -m option
<savvas> didrocks: is this about an init script/daemon?
<stefanlsd> didrocks: yeah, it prob forks after starting. have u tried the -b option
<didrocks> savvas: yes
<didrocks> stefanlsd: not sure, let me check the manpage
<didrocks> stefanlsd: yes, I used the long form. And same pid retrieved
<stefanlsd> didrocks: mm. yeah. -m -b should hopefully do it. i can see its not thou.  -v help u anything
<didrocks> stefanlsd: unfortunatly yeah, it seems that there is no solution with start-stop-daemon option. That's why I supposed to use pgrep to create it in the init script. Does this make sense?
<stefanlsd> didrocks: yeah. not sure why start-stop-daemon isnt doing it properly, maybe we could investigate that more, but pgrepping and writing the PID and telling start-stop-daemon the PID file should be ok
<didrocks> stefanlsd: ok, I will try to add more options (and to be in contact with upstream to see if he can implement it). If not possible, I will pgrep though :/
<didrocks> thanks :)
<stefanlsd> didrocks: suuure. good luck :)
<savvas> didrocks: you're trying to "daemonize" a bash script, right?
<didrocks> savvas: not a bash script, it's a C program
<toresbe> dholbach: I found the problem, FWIW.
<savvas> didrocks: I have something here I use for a bash, maybe it'll work for you: http://bazaar.launchpad.net/~timekpr-maintainers/timekpr/trunk/annotate/head%3A/debian/timekpr.init
<didrocks> savvas: thanks. I will have a look at it :)
<savvas> I use -m -b and --startas (no idea why, but it made it work) :P
<didrocks> savvas: why --test and then, execute it. Is it mandatory?
<didrocks> savvas: ok, I see it with the man page
<didrocks> thanks, will give it a try
<savvas> didrocks: --test tests if the file is present
<savvas> there was an example init script somewhere in /etc/ I think, but I can't find it :\
<didrocks> savvas: no pb, I will work from your example and see if I can use it
<savvas> ok great :)
<dholbach> toresbe: great - what was it?
<toresbe> dholbach: I had functions with the same name in previously-interpreted files. All info was added to those files, and not to the file the function actually was in.
<dholbach> ahhhhhh
<dholbach> toresbe: that was hard to spot
<dholbach> maybe file a bug report at doxygen? would be nice to have a warning for cases like that :)
<toresbe> I'll do so
<dholbach> super
<dholbach> gaspa: do you still have the log of the Italian Getting Started session? if you do, could you please post it here:  https://wiki.ubuntu.com/MeetingLogs/devweek0901/GettingStartedIT  ?
<gaspa> dholbach: i was just waiting for them, in order to put on the page.
<dholbach> gaspa: great, thanks :)
<huats> morning !
<gaspa> dholbach: done. should I remove all time references, login/logout notifications and so on?
<dholbach> gaspa: no, it's fine as it is
<dholbach> thanks a bunch
<gaspa> ;)
<gaspa> it was amazing
<dholbach> it was
<dholbach> great work everybody :)
<gaspa> and now I need an oculist, after an hour of writing without breaks... :P
<schmiedc> oin #ubuntu-at
<al-maisan> Koon: I am trying to package the ActiveMQ message broker which is Java software .. what is a good existing Java software package to look at?
<Koon> al-maisan: I might be biased :)
<al-maisan> no problem :)
<Koon> al-maisan: I like to think tomcat6 was packaged correctly, but others might think otherwise.
<al-maisan> Thanks!
<Koon> al-maisan: ActiveMQ is a library rather than a server, right ?
<al-maisan> I am a beginner and need an example to look at.
<al-maisan> ActiveMQ is a server actually
<al-maisan> It is a message broker
<al-maisan> a JMS implementation
<Koon> al-maisan: it runs standalone ? It should be started at the end of the package installation ?
<al-maisan> Koon: yes, ideally.
<Koon> al-maisan: then I'd recommend looking at tomcat6, yes. Libraries are easier, and the commons-* are good examples for that
<al-maisan> Koon: good point, very much appreciated :)
<Koon> al-maisan: also you might find #ubuntu-java helpful.
<al-maisan> ah, OK.
<directhex> pfft, java
<directhex> ;)
<al-maisan> didn't even know such a channel existed :)
<Koon> directhex: everyone has a cross to carry :)
<Koon> 'one cross each'
 * al-maisan is not a big Java fan but that specific piece of software was written in Java
<directhex> carry cross once, get nailed anywhere?
<al-maisan> :P
<slytherin> Koon: Welcome back. :-)
<Koon> slytherin: heh thx
<jmehdi> Could someone review my package: http://revu.ubuntuwire.com/details.py?package=webstrict, I've added a debian/watch file as required
<_ruben> hm .. when building a package using pbuilder, how does one ensure the resulting .deb is signed with my key ?
<maxb> _ruben: You mean .changes, right? .debs are never signed directly
<_ruben> maxb: then what does apt-get check when downloading the debs from a mirror?
<maxb> Checksums for the .debs are listed in the Packages file.
<maxb> Checksums for the Packages file are listed in the Release file
<maxb> The Release file is signed
<_ruben> ah .. that should be enough to get me going for a bit .. thanks
<maxb> _ruben: the .changes file (the upload control file) contains checksums for the .debs, and the .changes file is signed by the uploader to authenticate themselves to the archive they are uploading to
<dholbach> ScottK: you were right about the sponsoring entries in the HoF (uploads) - thanks again
<pochu> morning dholbach
<pochu> (or should I say evening?) ;)
<dholbach> hiya pochu
<pochu> dholbach: I uploaded the logs right after you left
<dholbach> no :)
<dholbach> pochu: thanks a lot
<pochu> yw
<_ruben> maxb: ah .. so the .changes files would be signed by uploader, and the Release file by the repository ('s maintainer's special key)
<maxb> In practice, usually the repository's automatic signing key, rather than any person-associated key, but yes
<_ruben> maxb: that's what i realised during typing, hence the odd sentence ;)
<_ruben> thanks .. time to re-do some stuff properly now :)
<maxb> Incidentally, you don't have to sign .changes and source packages at time of build. You can just run "debsign" on them later (e.g. after you've tested them - or, even, on a different host to where you build them, if your key can't/shouldn't be on the build host)
<WalterMundt> I'm looking at Twisted right now; there's been a new upstream release that's apparently not packaged yet in the archives.  I'm very new to this, but given the state of the debian release/etc, would it be helpful to try and update the packaging in Ubuntu?  In what form/where would I send the work when it's done, given that (old version of) the package is currently coming unmodified from Debian?
<Laney> WalterMundt: doko_ maintains it, you should talk to him
<WalterMundt> okay, good plan; I don't want to duplicate effort
<WalterMundt> (more generally, I wonder how much interest the various Debian maintainers have in running updates through Ubuntu in the interim while the Debian release process does its thing.)
<Laney> Debian has experimental available for use
<WalterMundt> hmm, true
<stochastic> how can I get at the config.log file from a pbuilder environment?
<azeem> stochastic: you probably need to suspend it and chroot into it or something
<azeem> I don't think you can get to it after the build
<Laney> There's a hook you can set up to remain in the environment if a build fails
<Laney> I don't have it, though
<azeem> maybe CDBS should cat config.log if configure fails
<savvas> Does anyone know where can I find documentation about .update-notifier files, the ones that go in /var/lib/update-notifier/user.d/ ?
<maxb> There is some doc in the update-notifier source package, at least.
<WalterMundt> stochastic: https://wiki.ubuntu.com/PbuilderHowto mentions the "keeping shell in pbuilder after fail" hook thing btw
<WalterMundt> Laney: e-mailed doko_; may be back later depending on response
<Laney> excellent, good luck
<savvas> hm...
<savvas> I found some in kubuntu wiki https://wiki.kubuntu.org/InteractiveUpgradeHooks
<nhandler> persia: Did you need somethign?
<nhandler> s/somethign/something/
<persia> nhandler, _16ar_ changed the GPG key in LP recently, and it differs from the one in the LP database.  I don't know the command to run on spooky to fix this.  Do you?
<persia> Err, ...differs from the one in the REVU database ...
<nhandler> persia: Sorry, I don't. I don't even have access to spooky yet
<directhex> https://launchpad.net/ubuntu/jaunty/+source/kde4bindings/4:4.1.96-0ubuntu1/+files/kde4bindings_4.1.96-0ubuntu1.dsc
<directhex> bah
<persia> nhandler, You've sent a request to UWSA?
<persia> nhandler, Also, become a REVU Admin or REVU Hacker at your option: you don't really need to be either to be REVU Coordinator, as long as you get those of us who do have those roles (and Reviewer and Contributor) doing stuff.
<directhex> http://primates.ximian.com/~miguel/pictures/moon-obama.png
<directhex> bah
<directhex> shameless plug: http://ubuntuforums.org/showthread.php?p=6584115
<MaduserTr> How do I disable the executable flag in a image which executable in upstream?
<liw> MaduserTr, do you mean that the .jpg (or whatever format it is) ends up with execute permissions in the .deb? normally debhelper normalizes permissions, but if not, you can add a command to debian/rules to change the permissions yourself
<MaduserTr> liw, Yes this I mean. I use cdbs on a python program (wine-doors). Can I hook in the build to do so?
<jpds> persia: Have you relogged into REVU with the new key on LP? That's how keys get synced in.
<hyperair> MaduserTr: install/binary-package-name::
<hyperair> MaduserTr: chmod 0644 debian/<tmp or binary-package-name, depending on whether you have more than one package or not>/path/to/jpg
<persia> jpds, the user did relogin, but it didn't resync.  I had them log out and log in again, and forced the rejected .changes back into /srv/uploads
<persia> The rejected .changes was signed by the key shown as the right key on LP.
<jpds> persia: Oh, did it work after that?
<persia> No.
<MaduserTr> hyperair, thanks I will try to get it
<hyperair> MaduserTr: if you've got cdbs installed on your comp, read the cdbs doc here: file:///usr/share/doc/cdbs/cdbs-doc.html
<persia> That's why I'm asking for guidance: the last docs I have on being a REVU admin are out of date, and so I don't know how to fix this.
<jpds> Hmm, no idea either.
<mok0> persia, you have docs??
<mok0> persia: I'd like to see those, even though they are out-of-date
<persia> mok0, Yep.  sistpoty sent some out to ubuntu-motu about a year ago.
<mok0> persia: I'll search the archive then
<persia> mok0, March 2008
<mok0> persia: thx
<mok0> found it
<mok0> shoudn't we have that on the wiki?
<persia> Well, no.  We should probably have a section on the wiki that's accurate.
<persia> At least I'd find it helpful, but I think we need help from REVU Hackers to do it.
<mok0> persia: err yes, that's what I mean :-)
<persia> In that case, Yes :)
 * hyperair wonders if anybody is willing to revu some packages
<mok0> sorry hyperair, trying to get some work done...
<hyperair> okay
<hyperair> no prob
<hyperair> i'll wait another day =p
<mok0> I am going early to watch the inauguration of Obama :-)
<hyperair> =O
<mok0> in 75 minutes
<hyperair> =O
<hyperair> well before you go, do you know what's required to make a package that links fine with libxul-dev to link fine with xulrunner-1.9-dev? it uses gtkmozembed
<hyperair> -R works, but using an rpath is forbidden it seems
<hyperair> and using the XPCOM glue causes ld to throw up a hissy fit about undefined references
<slytherin> hyperair: I guess you will need to patch makefile.
<hyperair> slytherin: i've done lots. patch Makefile.am, gecko.m4, among other things
<persia> hyperair, Have you asked the Mozilla team?
<hyperair> slytherin: and configure.ac
<hyperair> eh no?
<hyperair> where can i contact them?
<MaduserTr> hyperair, liw, thanks got it
<liw> MaduserTr, you're welcome
<hyperair> MaduserTr: you're welcome
<liw> MaduserTr, we thank you for choosing #ubuntu-motu for your development questions and hope that you will choose us again :)
<liw> (do I fly too much?)
<slytherin> hyperair: https://edge.launchpad.net/~mozillateam
<MaduserTr> :)
<james_w> hyperair: #ubuntu-mozillateam
<schmiedc> liw: maybe :P
<schmiedc> otherwise we do/get the same good service as we should :)
<hyperair> james_w, slytherin: thanks
<shankhs> How can I download the source code of geany http://bazaar.launchpad.net/~vcs-imports/geany/trunk/changes contains a lot of files which gonna take a lot of time to download,moreover I dont know which files to download which not.I am a newbie in development.
<shankhs> Please help
<Laney> shankhs: bzr branch lp:geany
<shankhs> Laney: thats not working giving some erroe like:bzr: ERROR: socket.error: (111, 'Connection refused')  and asking to file a bug report
<Laney> maybe something's wrong with LP
<Laney> You can get it from geany's site too
<hyperair> shankhs: are you behind some firewall of some sort?
<shankhs> I am behind a proxy which needs authetincation
<Laney> aha
<shankhs> what should I do?
<maxb> Does it not need to be lp:~vcs-imports/geany/trunk ?
<Laney> maxb: I copied it from LP
<mok0> Laney: "bzr branch lp:geany" ... that's the coolest reply I've seen in a while :-)
<Laney> \o/
<shankhs> maxb: ya its that /geany/trunk
<shankhs> then how to make "bzr branch lp:geany work?
<Laney> look into how to use bzr behind a proxy
<james_w> python is broken behind proxies
<mok0> bzr branch lp:geany/trunk
<james_w> use the full url instead
<james_w> "bzr branch bzr+ssh://youruser@bazaar.launchpad.net/~vcs-imports/geany/trunk"
<mok0> proxies... an invention of nazi sysadms
<shankhs> mok0: I disagree
<shankhs> btw is there any security concerns with bazaar?
<james_w> like what?
<mok0> I guess proxies are needed to protect machines running Microsoft Windows...
<liw> shankhs, not in particular: every program that accesses data from the network is always a security concern, if you're paranoid enough, but bzr doesn't do anything particularly worrying
<shankhs> I am repeatedly getting bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<shankhs> liw: I got it
<hyperair> shankhs: try using tsocks
<shankhs> hyperair: and now what is that tsocks???
<james_w> shankhs: can you "ssh youruser@bazaar.launchpad.net"?
<mok0> james_w: no one can
<hyperair> shankhs: it's a wrapper, using LD_PRELOAD or something to wrap all outbound connections through a SOCKS proxy
<james_w> mok0: sure you can
<shankhs> james_w: no its saying: Permission denied (publickey).
<mok0> james_w: well I don't get a connection
<james_w> it doesn't give you a shell, but it's a connectivity/key etc. test
<james_w> shankhs: ah, have you registered an ssh key with launchpad?
<shankhs> :( no
<shankhs> how to do that?
<mok0> that's a _public_ key
<mok0> shankhs: do it from your LP home page
<james_w> shankhs: or use "bzr branch http://bazaar.launchpad.net/~vcs-imports/geany/trunk"
<shankhs> james_w: I wonder where is the ssh key in my profile...
<shankhs> james_w: where is the downloaded file saved???
<james_w> shankhs: click "change details" in the top right, the "ssh keys" at the top
<james_w> that command will create a directory called "trunk"
<shankhs> james_w: thanx a lot
<shankhs> thanx everybody
<MaduserTr> I have uploaded a new Version of wine-doors to revu (http://revu.ubuntuwire.com/details.py?package=wine-doors) maybe some can have a look
<lidaobing> help review ibus-pinyin: http://revu.ubuntuwire.com/details.py?upid=4583
<lidaobing> thanks
<ScottK> dholbach: So it's fixed now (HoF sponsoring uploads)?
<_ruben> what am i missing here .. i signed my own repo's Release file with a dedicated gpg key, i imported its public key using apt-key, but apt-get still doesnt like my repo :(
<maxb> _ruben: is it a publicly accessible repo?
<_ruben> maxb: no
<maxb> Then you'll need to provide as much information as you can manage here, if people are to be able to help
<_ruben> lets see if i can increase the verbosity or smth
<maxb> Or, you could set up a publicly accessible repo, get that working, and then apply the lessons learnt to your private one
<_ruben> lets start by reading the actual error :P ... Unknown error executing gpgv
<_ruben> W: You may want to run apt-get update to correct these problems
<_ruben> gotta love "unknown errors"
<maxb> !
<_ruben> doh .. didnt sign my release file properly .. *slaps forehead*
<dholbach> ScottK: yep
<ScottK> dholbach: Great.  Now if I get on the list it'll be honest.
<dholbach> hehe
<superm1> \
<dholbach> Ubuntu Developer Week - Day 2 just about to start in 17m in #ubuntu-classroom :)
<jpds> dholbach: Hmm, do you want the mute off or should I keep it there?
<dholbach> jpds: not necessary - it went alright yesterday without it
<jpds> Remove it then?
<dholbach> yeah
<jpds> OK; done.
<dholbach> gracias
<Ape3000> Does MOTUs also manage the main and restricted repos?
<rhpot1991> cody-somerville: ping, just checking to make sure my SRU doesn't get lost
<cody-somerville> rhpot1991, link?
<rhpot1991> cody-somerville: https://bugs.launchpad.net/ubuntu/+source/mythexport/+bug/297019
<ubottu> Launchpad bug 297019 in mythexport "mythexport relies on ffmpeg from medibuntu" [Undecided,Fix released]
<cody-somerville> rhpot1991, ah, right
<rhpot1991> cody-somerville: its a monstrosity I know :)  Just hoping to get it out of the way so I can continue working on the next version and push that out
<rhpot1991> cody-somerville: the changes are all very minor, I can discuss exactly what the code changes were for each if it helps
<Riddell> superm1: what's happening with bug 302104 ?
<ubottu> Launchpad bug 302104 in mythexport "Nominate for release" [Low,Invalid] https://launchpad.net/bugs/302104
<superm1> Riddell, nuke the upload for it, there is a new SRU in place for it that's waiting for a motu-sru ACK
<rhpot1991> Riddell: I was told to move this into bug 297019
<ubottu> Launchpad bug 297019 in mythexport "mythexport relies on ffmpeg from medibuntu" [Undecided,Fix released] https://launchpad.net/bugs/297019
<rhpot1991> so I moved the debdiff there (might be easier to just grab from bzr), and tried to update everything accordingly
<superm1> Riddell, so once that has an ack i'll reupload for rhpot1991
<Riddell> superm1: ok, I'll close that bug then
<superm1> Riddell, thanks
<cody-somerville> rhpot1991, Acked
<rhpot1991> thanks cody-somerville
<pochu> Ape3000: no, that's done by core-devs
<cody-somerville> rhpot1991, There are some extra conditions on your SRU. Please ensure you adhere to them.
<rhpot1991> ok will do cody-somerville
<cody-somerville> rhpot1991, please ensure that you have the appropriate bug number in your changelog too
<rhpot1991> cody-somerville: ok I'll check on that right now
<rhpot1991> I think it has the old SRU one
<jsmidt> Which command will merge Ubuntu and Debian changelogs?
 * pochu doesn't know of any, but would be interested if there's one
<_MMA_> Is new package freeze Feb 19th?
<quadrispro> anyone on REVU? -> http://revu.ubuntuwire.com/details.py?package=uck
<RainCT> quadrispro: advocated
<quadrispro> RainCT: ohh! thank you! and... ehm... *cough* http://revu.ubuntuwire.com/details.py?package=w-scan
<quadrispro> :D
<Laney> heh
<jmehdi> Could someone review my package: http://revu.ubuntuwire.com/details.py?package=webstrict, I've added a debian/watch file as required
<RainCT> quadrispro: did you say something I only heard you cough *g*
<quadrispro> RainCT: sorry for bothering you again :)
<bddebian> Heya gagn
<bddebian> Err gang even
<ia> if i'm going to upload some package at ppa, is it necessary that package name contains "~ppa" string?
<jpds> ia: If you want, ~ppaN would be better.
 * maxb really needs to write up a long bug discussing why ~ppaN is highly suboptimal
<jpds> maxb: I think it's on help.lp.net/PPA .
<maxb> yeah. That section really needs an overhaul
<maxb> It discusses well what constraints a PPA version should meet, but then proposes a scheme (~ppaN) which doesn't meet them as well as it could, at all
<ScottK> help.lp.net/PPA is still broken in regards to it's revision numbering recommendations.
<ScottK> It could also stand to know the difference between a version and a revision.
<asomething> any motu-swat or sru around? I've got an intrepid security update that's been waiting for review for awhile. bug 291531
<ubottu> Launchpad bug 291531 in mantis "[CVE-2008-4688] [CVE-2008-4689] multiple security vulnerabilites" [High,Confirmed] https://launchpad.net/bugs/291531
<jdstrand> asomething: hi! thanks for your patch.
<jdstrand> asomething: I am going to mark the bug In Progress, as per SecurityUpdateProcedures
<jdstrand> asomething: we have scripts to help us find community contributions like yours, but this one slipped by because it wasn't marked in progress
<jdstrand> asomething: a member of our team should be able to process the upload within the next few days, now that we know about it
<asomething> jdstrand: ya, I also just noticed that since it's targeted at intrepid and fixed in jaunty it doesn't show up in a lot of bug lists
<asomething> jdstrand: thanks for taking a look
<jdstrand> asomething: np. thanks for your help on this! :)
<tgm4883> can other keyring packages be included in universe, or is that limited to debian-keyring and ubuntu-keyring
<maxb> Would it make sense to include others?
<slytherin> tgm4883: what keyrings do you want to include?
<tgm4883> mythbuntu-keyring
<tgm4883> slytherin, it would be a the key for the weekly-builds repo, which will be the PPA now that it is signed
<maxb> Couldn't the keyring just go in the PPA? Users would accept an unauthenticated warning once only, that way?
<slytherin> tgm4883: in my opinion it doesn't make sense to include these keyrings in universe since they are not being used by officialarchives.
<tgm4883> maxb, it could, but then it couldn't be included on the ISO
<fabrice_sp> Hi! Any MOTU here to review DVDStyler, a dvd authoring tool (http://revu.ubuntuwire.com/details.py?package=dvdstyler). It has already been advocate dby mok0.
<slytherin> tgm4883: why do you want to include keyrings used by PPA on CD?
<maxb> It seems slightly peculiar to include a weekly-build keyring on CD
<maxb> (to me)
<ScottK> tgm4883: I don't think we're going to allow PPA keyrings on a CD.
<tgm4883> slytherin, maxb well the reason for the weekly builds is so people will have up to date builds of the -fixes branch (not trunk).  Using the PPA (or our own repo, as we have done in the past) is easier that trying to get a backport for it every week
<tgm4883> We can do it via apturl and in the PPA, just thought i'd check first
<maxb> If regular updates are so important that most users should be using them, then perhaps the answer is to try to make official backports easier?
<tgm4883> I suppose that would work, but would then in effect be making -backports a rolling repo
<tgm4883> which I thought was frowned upon anyway
<ScottK> tgm4883: We've reverted stuff before that took updates from a PPA due to security concerns.   Just have them add the PPA to their sources.list and be done with it.
<tgm4883> ScottK, will do
<iefremov> Hi All, reviewers needed for newly uploaded package ugene (http://revu.ubuntuwire.com/details.py?package=ugene). Ugene is a quite complex and interesting bioinformatics package based on Qt.
<ScottK> iefremov: If you see mok0 around, that sound like something he'd be interested in.
<iefremov> ScottK: OK, thanks
<maxb> Where could I go to find a pbuilder expert? Specifically, to understand why the pdebuild manpage says about --use-pdebuild-internal: "This option will not protect the working directory and its parent directories from the build scripts."
<hyperair> maxb: it bind mounts your source directory into the chroot, then performs operation there
<hyperair> maxb: meaning that the build is done using the source directory itself, not a copy of it
<maxb> Right... I get that the build can affect stuff within the bind mounted tree... it's the reference to the parent directories that I don't understand
<hyperair> maxb: it probably bind-mounts your parent directory
<hyperair> maxb: not the source directory
<hyperair> maxb: so if i have a directory called build-area/ and inside build-area a folder called source-1.2.3, then it bind-mounts build-area
<hyperair> maxb: so if you've got dsc files like.. source_1.2.3-0ubuntu1.dsc or something, it'll be overridden
<hyperair> maxb: in the parent directory of source-1.2.3 that is
<maxb> hmm. /me will experiment, but even so, parent *directories* would then be an error in the manpage?
<hyperair> oh
<hyperair> ._.
<hyperair> i have no idea
<hyperair> this is just my interpretation
<hyperair> i could be wrong
<hyperair> what you could try is run the pdebuild-internal thing and before it's done, run mount
<hyperair> and see which part is bind-mounted
<maxb> I see, you are right about the parent directory being bound
<hyperair> ah
<maxb> I reckon the manpage shoud s/directories/directory/
<hyperair> yep
<hyperair> file a bug =p
<maxb> yup
<_16aR_> Hello
<RainCT> OT, can someone recommend me a cheap bluetooth remote for the laptop? (to control a slideshow and the like; if it can also move the mouse and stuff even better)
<_16aR_> any motu revu admin ?
<jpds> _16aR_: Hi.
<RainCT> _16aR_: yes?
<_16aR_> Hello jpds
<_16aR_> I got a problem yesterday with an uploaded package
<_16aR_> with persia with thought that it was the gpg keylist not updated
<_16aR_> I uploaded ok with dput, but then, it didn't appear on the revu frontpage
<RainCT> _16aR_: did you login on REVU before uploading the package?
<_16aR_> I updated my gpg key yesterday, so it might be that
<_16aR_> the first time, no
<_16aR_> the second time, i dput -f, and I was connected to revu
<_16aR_> for the first time, I'm nearly sure I wasn't connected
<RainCT> _16aR_: which package is it?
<_16aR_> sorry :)
<_16aR_> lp: dolanor, package : hexdiff
<RainCT> _16aR_: It's up now. Not sure what the problem was, but I've just told REVU to look at it again and it accepted it
<_16aR_> ok, thanks a lot :
<_16aR_> :)
<RainCT> you're welcome
<hyperair> RainCT: got time for a revu? =p
<RainCT> hyperair: sorry, school work :(
<hyperair> ah okay no prob
<hyperair> i've got school work too =p
<mrooney> have I botched something with my last upload? http://revu.ubuntuwire.com/details.py?package=wxbanker
<mrooney> I am getting permission denied on viewing the files and the last upload says legal instead of debdiff
 * jpds takes a look.
 * mrooney waves at jpds
<RainCT> mrooney: you can't create a debdiff between the last upload and the last upload :9
<RainCT> * s/:*/:)
<RainCT> ** s/:9/:)
<mrooney> I didn't try to do anything really, all I did was update the package and run dput
<jpds> mrooney: Hi. :)
<hyperair> RainCT: yes you can =p you just get an empty file
<mrooney> I feel like the permission thing happened to me the first time I did this,hmm
<RainCT> hyperair: but with REVU you can't :P
<jpds> mrooney: Everything works, we block off the .changes file so noone can upload the package anywhere else.
<RainCT> mrooney: uhm.. it's working for me
<mrooney> debian packaging / getting packages into Ubuntu seems to have an astronomical learning curve :)
<hyperair> RainCT: point taken =p
<hyperair> mrooney: not so much if you've got some programming background and have read the cdbs documentation, as well as the debian packaging guide and/or ubuntu packaging guide
<hyperair> mrooney: it used to be steeper
<jpds> mrooney: Say a MOTU uploads a package, all a person who had access to the .changes got it and the package, they would then be able to upload it to Ubuntu, just because it's signed by a MOTU's key.
<jpds> s/all a/any/
<mrooney> jpds: ahh I see, the diff is what I was looking for I think :)
<jpds> mrooney: I can view the .diff and .diff.gz fine...
<mrooney> jpds: yeah, I can as well
<mrooney> I was thinking what I wanted was the .changes though, and was getting confused
<jpds> Ah, I thought you were trying to get to them and were getting permission denied.
<mrooney> So overall it looks fine, that's good
<mrooney> is there any way to get it to not generate a pycompat, I hear I don't need it and it is wrong anyway.
<mrooney> Other than nuking it before dput'ing
<RainCT> woho, my website is working again
<maxb> If a new package version Conflicts: and Replaces: something, shouldn't apt-get dist-upgrade remove the conflicted/replaced package in favour of upgrading to the new version, instead of the new version being kept back?
<pochu> maxb: that only if something wants to install the other package, or if the installed package provides the new one
<pochu> IIUC
<maxb> hmm
<pochu> otherwise, the other package replaces and conflicts with the current one, but why to replace it if nothing wants it? :)
<maxb> I just did an intrepid -> jaunty upgrade and was left with intrepid's gstreamer-plugins-bad
<maxb> because jaunty's plugins-bad conflicts with fluendo-mpegdemux
<xnox> what is linda? was it retired in favor of lintian?
<pochu> xnox: it was a lintian clone written in Python, but was abandoned
<maxb> hmm, still kept back even with a Provides
<pochu> maxb: that's weird
<pochu> hmm
<pochu> 21:44 <      maxb> because jaunty's plugins-bad conflicts with fluendo-mpegdemux
<pochu> does it also have a replaces?
<maxb> yes
<pochu> dunno why
<pochu> +then
<maxb> Actually, the package doesn't really have a replaces, but I added one and it still didn't work
<pochu> where did you add it?
<maxb> right in apt's /var/lib/apt/lists/*, and then vaped apt's caches :-)
<pochu> heh
<pochu> so I guess `apt-cache show` shows the Replaces
<maxb> oh well, bug 319369 filed, I'd hoped to suggest a fix, but nevermind
<ubottu> Launchpad bug 319369 in gst-plugins-bad0.10 "Package held back in intrepid->jaunty upgrade (missing Replaces: gstreamer0.10-fluendo-mpeg(de)mux, maybe?)" [Undecided,New] https://launchpad.net/bugs/319369
<pochu> maxb: did you try with aptitude? :P
<maxb> I like apt-get :-)
<maxb> Call me a traditionalist
<hyperair> maxb: hear hear
<hyperair> maxb: aptitude has messed things up for me more than it's helped me
<hyperair> anyway does anybody have some time to revu?
<maxb> I'm not a MOTU, but I can see if I can catch anything so they don't have to, if you like
<hyperair> thanks =p http://revu.ubuntuwire.com/details.py?package=sigx http://revu.ubuntuwire.com/details.py?package=vazaar http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin
<hyperair> three packages - sigx, vazaar, bansheelyricsplugin
 * hyperair needs to get some sleep before class begins
<stochastic> Does any motu want to REVU my newest upload (I think everything is fixed now) http://revu.ubuntuwire.com/details.py?package=calf
<xnox> pochu: thanks for info about linda. Sorry it took a while to respond I ran away =D to save my burning rice =D
<jsmidt> What does ACKed mean?
<jpds> jsmidt: Acknoledged.
 * jpds sighs, dumb keyboard: acknowledged.
<jsmidt> thanks jpds
<ScottK> When he comes back someone should explain to hyperair that sleep is what class is for.
<Laney> jsmidt: What is that debdiff for on the axel sync?
<jsmidt> Laney, it is for the axel in debian unstable: http://ftp.debian.org/debian/pool/main/a/axel/axel_2.3-1.dsc
<Laney> jsmidt: I know, I'm just curious as to why you'd attach a debdiff. Do you know how syncs work?
<jsmidt> Laney, maybe not.  I thought this is how you do them.
<Laney> jsmidt: No. We just copy the package from Debian.
<Laney> !sync
<ubottu> Sorry, I don't know anything about sync
<Laney> ..
<Laney> https://wiki.ubuntu.com/SyncRequestProcess
<jsmidt> Laney, thanks I will read through this.
<Laney> It's always a good idea to make sure you know what you're asking people to sponsor
<Chris`> Laney: Busy? :)
<Chris`> eww has the font changed over at revu?
<Chris`> Anyway, Laney fancying reviewing something? http://revu.ubuntuwire.com/details.py?package=partitionmanager
<Laney> give me a minute to shower
<Chris`> Positive :)
<xnox> can anyone point to an intersting python-app/module which has unittest. Want to see/learn how to package and run testsuite at build/install time.
<mrooney> xnox: oh, that sounds cool, I'd be interested as well
<Chris`> pochu: Thanks for the type notice, was that the only error?
<Chris`> *typo
<pochu> Chris`: no, I just looked into the description to see what it was about :)
<pochu> and spotted it
<Chris`> Ok thanks anyway then :)
<pochu> let me do a review of the debian/ dir
<pochu> http://revu.ubuntuwire.com/revu1-incoming/grdc-gnome-0901161833/grdc-gnome-0.3.0/debian/grdc-gnome.pod <- AWESOME
<Chris`> *Blushes*
<Chris`> I thought that it was incredibly short personally
<pochu> I've always written manual pages directly with the .TH .SH blah \fB\-\-some\-option ... syntax :P
<pochu> Chris`: it's fine :)
<pochu> I need to learn that pod thing :)
<Chris`> pochu: Yeah it's a hell of a lot easier than what groff looks like
<pochu> Chris`: comment added. Looks pretty good :)
<Chris`> pochu: Thanks a bunch, my best review so far
<proppy> Chris`: typo in http://revu.ubuntuwire.com/revu1-incoming/grdc-gnome-0901161833/grdc-gnome-0.3.0/debian/grdc-gnome.pod :)
<proppy> s/funcitons/functions
<pochu> heh
<Chris`> proppy: Thanks for the heads up
<proppy> Chris`: yw :)
<proppy> pochu: sry ;)
<pochu> proppy: it was a perfect review before you spotted it :(
<pochu> ;)
<proppy> pochu: typo on http://revu.ubuntuwire.com/ !
<proppy> s/Utnubu team/Ubuntu team/
 * proppy in typo mode
<ia> hello. for example, i made deb package with newer upstream's app version, than exist in ubuntu/debian's repos and would like that it has been included in universe/multiverse repo; so, i should to find sponsor for upload, or try to upload package in revu first?
<Chris`> "Error '553 Could not create file.' during ftp transfer of grdc-gnome_0.3.0.orig.tar.gz"
<pochu> proppy: not a REVU hacker/admin/whatever ;)
<Laney> proppy: That's not a typo
<pochu> ah, yeah
<pochu> read it from right to left :)
<proppy> oh sorry :)
<Chris`> http://pastebin.com/m35302024
<Chris`> Does anyone know how that error happened?
<proppy> Chris`: strange I thought -f meaned overwrite
<Chris`> Well strangely, http://revu.ubuntuwire.com/details.py?package=grdc-gnome has updated if you wanna double-check
<Chris`> I got the error but it seems to have worked...
<Chris`> I wasn't so sure about the copyright icon, I hope that I did that correctly
<proppy> Chris`: grep 553 in https://wiki.kubuntu.org/MOTU/Packages/REVU
<proppy> To solve this, just wait 5 minutes.  Processing of uploads is done every 5 min.
<Chris`> proppy: I think that it's now worked, it looks like dput may have tried to upload twice =\
<Chris`> It tried twice or something... http://paste.ubuntu.com/107520/
<proppy> Chris`: maybe just wait 5min and try to dput again
<Chris`> Ok successfully dputed now :D
<Chris`> http://revu.ubuntuwire.com/details.py?package=grdc-gnome -- When you have the time
<Laney> Chris`: I ran lintian -iI on the binary changes file, threw some stuff up
<Chris`> Laney: Fancy sharing? :)
<Laney> http://pastebin.com/f12cefaa9
<Chris`> Thanks
<Chris`> Ah... you have to be kidding me?
<Chris`> How is there a quilt error if quilt isn't even in the build-deps?
<Laney> Other than that, the only thing you might consider is using the machine readable copyright format, but that's optional
<Chris`> Laney: Do you mean (C)?
<Laney> Chris`: No, http://wiki.debian.org/Proposals/CopyrightFormat <- that
<Chris`> Je ne le comprends pas...   What do you mean exactly?
<mrooney> Would anyone mind giving a quick lookover of http://revu.ubuntuwire.com/details.py?package=wxbanker, I got a previous review and attempted to address the issues with a new upload
#ubuntu-motu 2009-01-21
<spitfire_> In which package will I find gnome-panel-sharp-2.24 (in jaunty)?
<Laney> none (yet)
<Laney> http://ftp-master.debian.org/new/gnome-desktop-sharp2_2.24.0-1.html
<spitfire_> Laney: I' trying to get Tomboy
<spitfire_> working
<xnox> Chris`: he means that you might want to convert debian/copyright to a new copyright format as described on that wikipage.
<spitfire_> After that gnome-sharp transition
<Chris`> xnox: I've used the one that jpds uses from his recommendation, surely it won't make it get rejected though?
<Laney> Chris`: No, that's why I said it was optional
<spitfire_> Laney: Isn't it in gnome-desktop-sharp?
<Laney> spitfire_: Yes, see that link
<spitfire_> ok
<Laney> new API -> has to go through debian NEW
<Laney> Apparently tomboy is just a b-d change after we get this
<xnox> Chris`: it is a matter of preference now. I like the new format a lot! Some don't like it, the rest are waiting for it to (not) become official copyright format.
 * Chris` will wait :)
<spitfire_> Laney: so gnome-desktop-sharp2 will probably be gnome-desktop-sharp2.24 ?
<xnox> The orig tarball I'm looking at has MANIFEST.in file can someone explain/point what it is? My google-fu failed =(
<spitfire_> Laney: but where do i get this source package?
<spitfire_> I havent found it on packages debian, nor incoming.debian.
<spitfire_> oh
<spitfire_> I'll have to wait till they in the pool:/
<spitfire_> Laney: or is there another place I can get  'em?
<ScottK> If it's in Debian New, then it's not available.
<ScottK> If the maintainers use a public VCS, you should be able to fish the packaging out of there.
<spitfire_> ScottK good idea, thanks;)
<spitfire_> scottK thanks, I've found it;)
<ScottK> spitfire_: Great.
<Majost> I am having a problem with a python modules package which I am not sure how to solve.
<Majost> Basically, the update-python-modules makes the link for the __init__.py
<Majost> and then right before it finishes it does 'remove namespace' on it __init__.py -- which seems to be unlinking it
<Majost> So my question is, how do I tell update-python-modules to stop unlinking the __init__?
<Majost> I should also add that I cannot import my module because of this issue... which, looking at what the namespace stuff is supposed to do, seems as if it shouldn't be a problem
<ScottK> At a guess, you have a different problem than you think you have.
<spitfire_> ScottK
<spitfire_> ;thanks;)
<spitfire_> again;P
<ScottK> spitfire_: No problem.
<spitfire_> ScottK: I've resolved gnome-sharp2 transition problem for tomboy;)
<ScottK> Congratulations.
<ScottK> spitfire_: But do know I'm a KDE user, so I'm not personally very affected ...
<spitfire_> ScottK: lol
<spitfire_> This is kind of big stuff, because quite much mono programs don't run;)
<hyperair> maxb: thanks
<hyperair> maxb: i fixed all the issues you mentioned, except the DEBIAN_DIR and UPSTREAM_VERSION, because they don't work properly when called with CURDIR != DEBIAN_DIR/..
<maxb> can CURDIR != the package build dir?
<maxb> (In any sane build env?)
<hyperair> maxb: can, in the case of get-orig-source
<hyperair> maxb: but only that rule
<hyperair> maxb: so if get-orig-source isn't defined, there's no need to use that workaround
<hyperair> also it seems i added my comments one upload early
<hyperair> both comments
<dholbach> good morning
<iulian> G'morning.
<dholbach> hiya iulian
<iulian> Hey dholbach.
<iefremov> Hi, All. Reviewers needed for ugene - complex and interesting bioinformatics package based on Qt. http://revu.ubuntuwire.com/details.py?package=ugene
<iulian> directhex: Hiya.  I was looking at the gnome-sharp2 transition and was wondering if I should get giver in Debian first and then sync.  Does meebey know about this?  Should I upload it to Ubuntu or commit to SVN and bug meebey?
<iulian> directhex: I see that sebner has done some uploads to Ubuntu.  Are these changes forwarded to Debian?
 * iulian takes a peek at pkg-cli-apps svn repo.
<AnAnt> Hello, I got a question about get-orig-source , is it used to build an orig tarball for the current release , or for the upcoming release ?
<AnAnt> ie. can I do a 'uscan .' in get-orig-source ?
<persia> AnAnt, It should build a tarball for the current upstream release.
<AnAnt> ok, thanks
<directhex> iulian, you have free reign over the gnome# thing, it was an unexpected requirement
<dlynch> is this a good place to ask a question about the copyright file that goes in the debian directory?
<dholbach> dlynch: definitely
<dholbach> Did you check out these pages?
<dholbach> https://wiki.ubuntu.com/PackagingGuide/PackagingOverview#The%20copyright%20file
<dholbach> https://wiki.ubuntu.com/PackagingGuide/Basic#Copyright
<iulian> directhex: OK, thanks for telling.  I will upload it today.
 * iulian is pretty busy right now, doing his homework.
<dlynch> dholbach: I didn't see that 2nd one yet - thanks. My question concerns python routines I've reused from other people, and I think the 2nd page will help me understand my responsibilities
<dholbach> dlynch: if not just ask in here
<stefanlsd> dholbach: heys. the other day I was just commenting on some UDW sessions that use pastebin for parts of what they are trying to convey...  we need to go get those and put them in the log or something
<dholbach> stefanlsd: hum, did you find any in the current logs?
<stefanlsd> dholbach: no instances atm. I was looking through some old UDW logs...
<dholbach> ah ok
<stefanlsd> shame, pitti deleted his whole class by accident!
<slytherin> anyone familiar with lexers from python-pygments? I want to add a custom file pattern to makefile lexer but couldn't find anything in api docs.
<didrocks> morning o/
<quadrispro> can anyone take a look to this? http://revu.ubuntuwire.com/details.py?package=uck
<quadrispro> (hi) :)
<iulian> directhex: FYI.  I have just uploaded giver.
<directhex> iulian, cool. feel like being a hero & looking at the gnome# issues for the mono apps in main?
<iulian> directhex: Sure. I will have a look at them today.
<sistpoty|work> hi folks
<jpds> hey sistpoty|work
<sistpoty|work> hi jpds
<null_vector> /part/part
<warp10> dholbach: FYI: http://www.oneopensource.it/21/01/2009/interview-with-daniel-holbach-ubuntu-community-developer/
<dholbach> warp10: thanks a lot! :)
<warp10> (and http://www.oneopensource.it/21/01/2009/intervista-daniel-holbach-community-developer-canonical/ if you want to excercise your italian :P )
<dholbach> errr, probably not :)
<warp10> :D
<iefremov> Hi all, reviewers needed for ugene: complex bioinformatics package based on Qt. http://revu.ubuntuwire.com/details.py?package=ugene
<ScottK> mok0: ^^^ Seems up your alley.
 * mok0 looks
<iefremov> ScottK: thanks, already asked mok0 :)
<mok0> iefremov: I'll take a look
<mok0> iefremov: you are also upstream I see
<mok0> iefremov: is this your first time you have packaged something?
<mok0> iefremov: I can see that ;-)
<ia> hello. could you clarify, please, some moment about packaging sponsorship. if i make deb packages with latest upstream version (which doesn't exist in debian/ubuntu, but older version of app does) without any changes(initial release of new upstream only) and would like, that someone, who have access to universe/multiverse section, check it and, if everything is correct, will upload it in repo, then what should i do? as i understand, i should mail to ubuntu-u
<ia> niverse-sponsors@lists.ubuntu.com with request and with information about packages, right? or what?
<mok0> ia, we have a reviewing site called REVU
<ScottK> mok0: Not for upgrades
<mok0> ah I missed that part
<ScottK> ia: File a bug and tag it upgrade.  Make your updated package and then attach the .diff.gz for the update to the bug.
<ScottK> ia: The subscribe ubuntu-universe-sponsors to the bug (not asssign and don't send mail).
<tseliot> doko_: I have a question for you: if I wanted to create a package which only has a python script (to install in /usr/bin), would it still be ok if python-central created the .egg file?
<tseliot> doko_: I mean, only one script and no library
<hyperair> could someone review my package sigx please? http://revu.ubuntuwire.com/details.py?package=sigx
<ia> ScottK: ou, let's check, have i got it - 1. create "bug" in "ubuntu" project with [need-packaging] substring in name of bug 2. include in bug description original web site, where places official tarball with information about app; send this bug 3. in next comment for just created bug apply .diff.gz 4. PROFIT ;-) right?
<ubottu> Error: Launchpad bug 2 could not be found
<ubottu> Launchpad bug 3 in rosetta "Custom information for each translation team" [Wishlist,Confirmed] https://launchpad.net/bugs/3
<ScottK> ia: Yes, except tag for a new version of an existing package is upgrade, not needs-packaging.
<POX> tseliot: python-central doesn't create .egg-info, Python>=2.5 does (and it doesn't make sense to install egg metadata for single Python script)
<ScottK> Then don't forget to subscribe ubuntu-universe-sponsors.
<tseliot> POX: I need a build-dependency on python because I use distutils
<POX> and it creates .egg-info for single script?
<tseliot> POX: yes, it does. Here's the source I uploaded to REVU: http://revu.ubuntuwire.com/details.py?upid=4581
<ia> ScottK: >tag for a new version of an existing package is upgrade // so, where i should point tag "upgrade"?
<ScottK> There's a section in the bug for tags.  Just type upgrade in there.
<POX> tseliot: just remove the .egg-info directory
<tseliot> POX: ok, so a small hack in debian/rules would be enough. Thanks
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 3 to kick off in #ubuntu-classroom in 23 minutes! :-)
<ia> ScottK: and some questions about debian/. 1. i should point in XSBC-Original-Maintainer field my name and email and in Maintainer something like ubuntu universe team, right? 2. should i create a new one changelog file with only one record, or keep changelog from previous version of package and just update it by new one record? 3. >don't forget to subscribe ubuntu-universe-sponsors. // it's so as to i could follow for maintainers' discussion about progress of
<ia>  my request, right?
<dholbach> ia: use update-maintainer of the ubuntu-dev-tools package - it will make your life easier (regarding original maintainer)
<ScottK> ia: If it's an existing package, then the originial maintainer should be what's in the maintainer field before.
<ScottK> As dholbach says ...
<ScottK> Add a new entry to the existing debian/changelog
<dholbach> was there any discussion ever why we not just automate it somewhere instead of dpkg-buildpackage failing?
<ScottK> ia: It's so they know you have a request.
<quadrispro> sistpoty|work: ping
<quadrispro> :)
<sistpoty|work> quadrispro: pong
<ScottK> dholbach: It doesn't fail, it just complains.
<ScottK> Which I think is desirable.
<ScottK> As an example, if I'm the Debian maintainer for a package and I need to upload an Ubuntu revision for some reason, I don't change the maintainer.
<dholbach> pkg-source: Fehler: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
<dholbach> dpkg-buildpackage: Fehlschlag: dpkg-source -b hello-2.2 gab Fehler-Exitstatus 255
<dholbach> debuild: fatal error at line 1329:
<dholbach> dpkg-buildpackage -rfakeroot -d -us -uc -S failed
<dholbach> is what I get
<james_w> it fails if you have "ubuntu" in your DEBEMAIL
<dholbach> ahhh
<dholbach> ScottK: I take that point though - would be nice to have it configurable, so that if I'm just an Ubuntu developer it would do the right thing for me instead of falling over :)
<dholbach> anyway... enough complaining - I know I could just write a patch :)
<ia> ScottK: and package name should have "-ZubuntuW" suffix, where Z=0 (because the same upstream version of app doesn't exist at present time in debian), and W=1 (beacause it's first initial release of this upstream version in ubuntu without any changes), right?
<ScottK> Yes.
<ia> ScottK: thank you very much for answers. it's all questions. at least for now :-) and, please, excuse me, if some questions were dummy or obvious O:-)
 * directhex mails ember cake
<mok0> iefremov: I have written a review now.
 * hyperair wonders if any MOTU is free to revu
<mbeatty> what's the appropriate course of action when creating a package for source available only in a bz2?
<mbeatty> bzcat source.tar.bz2 | gzip -9 > source.orig.tar.gz ?
<Laney> mbeatty: uscan --repack
<geser> yes, until tar.bz2 are allowed (iirc there is some work in progress)
<Laney> or gzip -9n (iirc)
<persia> -9nf
<persia> You need to force the compression to ensure that you don't get different results on different architectures.
<persia> Also, please document it by writing a get-orig-source rule in debian/rules, and leave a comment in README.source
<jmehdi> Could someone review my package: http://revu.ubuntuwire.com/details.py?package=webstrict, I've added a debian/watch file as required
<mbeatty> alright, another question: making a new package of upstream naim, version 0.11.8.3.1 .. latest ubuntu and debian packages are all 0.11.8-1 .. should new ubuntu version be 0.11.8.3.1-0ubuntu1 ?
<mbeatty> or -1, or -1ubuntu1?
<mok0> -0ubuntu1
<liw> -0ubuntu1
<mok0> liw: beat you to it :-)
<mbeatty> :>
<liw> so that when Debian packages it, and calls their version -1, merging and syncing works correctly
<bddebian> Hmm, naim looks like one that could possibly be orphaned and a QA upload done with the new upstream
<bddebian> mbeatty: Unless you want to maintain it in Debian! :)
<mbeatty> yes, I was wondering whether better to push to debian
<bddebian> mbeatty: Have you tried contacting the maintainer by any chance?  He doesn't seem to be a DD and naim seems to be the only package he "maintains"
<bddebian> And no upload since 2005 :(
<mbeatty> will do that as a first step
<bddebian> mbeatty: Let me know.
<mbeatty> or what should have been :>
<RainCT> there was a MOTU meeting?
<pochu> RainCT: not that I know of
<pochu> at least there was no announce in the list I think
<RainCT> because I've just seen the minutes for one lol
<pochu> jpds: #ubuntu-es-dev is getting some new people after Monday's session in UDW, in case you wanna join it :)
<pochu> RainCT: MOTU council maybe?
<RainCT> ah right
<RainCT> I can't read
<hyperair> anyone have time for a revu?
<mathieu> Hello MOTUs, i have a quick question
<mathieu> I uploaded my sources recently on REVU using dput
<mathieu> everything went well, the GPG sig was recognized and everything uploaded it seems
<mathieu> but it's been a week now and I still don't see it on http://revu.ubuntuwire.com
<mathieu> is it normal ?
<ScottK> mathieu: No.  When you did dput, what was the exact command you did?
<mathieu> i did dput dekiwiki_8.08.2-1_i386.changes
<mathieu> revu is the default on my dput
<ScottK> mathieu: You uploaded a binary package and those are automatically rejected.
<mathieu> yes there were sources + bin
<ScottK> mathieu: It should have been something like dput revu dekiwiki_8.08.2-1_source.changes
<mathieu> OK i try again and let you know
<co0lingFir3> hello, how can i setup a jaunty environment in pbuilder?
<asomething> ScottK: hi, you closed bug 275375, but I don't see the package in jaunty-changes, the archives, or the build queue. how do you know that a sync has been done?
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/275375/+text)
<asomething> bug 275375
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/275375/+text)
<ScottK> asomething: I see what happened.
<mathieu> ScottK : I re-uploaded my package without including the ".deb" and it worked, thanks a lot for your help.
<ScottK> mathieu: No problem.
<rugby471> hu guys, trying to fix a bug in xsane, I don't think it needs cdbs (after speaking with dholbach) however how would I coinfirm this?
<jmarsden|work> rugby471: Read its debian/rules file and see what patch system (if any) it uses?
<rugby471> k
<co0lingFir3> hello, how can i set up a jaunty pbuilder environment in intrepid?
<rugby471> jmardsen|work: where exactly would it talk about cdbs (if it does) (sorry fix bug I have ever tried to fix :-)
<rugby471> fix * first
<ScottK> co0lingFir3: Same as you would for any other release, just make sure you use intrepid-backports when you set it up.
<hggdh> question: if an updated version of a package exists in Debian, and there are no local changes, is this an upgrade or sync request?
<jmarsden|work> rugby471: Read the Packaging Guide before attempting to fix any bugs: See https://wiki.ubuntu.com/PackagingGuide/Complete#Packaging%20With%20CDBS
<jmarsden|work> co0lingFir3: See https://wiki.ubuntu.com/PbuilderHowto
<rugby471> thx
 * sistpoty|work heads home... cyas
<sistpoty|work> -s
<Majost> Is there a variable I need to set to prevent CDBS pysupport from creating .pth files, and link the __init__.py instead?
 * ScottK wonders if POX is watching ....
<james_w> JontheEchidna: you're up
<JontheEchidna> oh shit, I thought it was in an hour. but I think I'm good to go
<cjav> Hi, trying to use ppa and dput for the first time, but need to use an http proxy, does dput have this option? I have set ftp_proxy=http://myproxy.com:PORT but dput seems to ignore it
<_16aR_> Hello
<_16aR_> Can anyone of the revu team review the hexdiff package please ? http://revu.ubuntuwire.com/details.py?package=hexdiff
<Gaming4JC> I was told to check here for help on making a deb. Would anyone know why my compilation keeps ending in "Clean Error 2"?
<Gaming4JC> dpkg-buildpackage: failure: fakeroot debian/rules clean gave error exit status 2
<Gaming4JC> I found some info but I've no idea where to find "clean" to edit it. https://wiki.ubuntu.com/PackagingGuide/Rules
<Gaming4JC> I'll need to do some digging
<bddebian> There should be a clean: rule in debian/rules
<Gaming4JC> bddebian: where is debian/rules located? It's not in the ../debian folder of my sources
<bddebian> Then you have an even bigger problem :)
<Gaming4JC> :-/
 * Gaming4JC might have found something
<Gaming4JC> ok I found it
<bddebian> Did you create this package or... oh
<Gaming4JC> it's just calling itself "rules"
<Gaming4JC> and I didn't see it in the massive file list
<Gaming4JC> but now what should I do to add some cleaning rules?
<bddebian> Unless it is using CDBS, there should already be one.
<Gaming4JC> this is the error I get on compile...
<Gaming4JC> # Add here commands to clean up after the build process. /usr/bin/make clean make[1]: Entering directory `/home/luke/ngplant-0.9.7' make[1]: *** No rule to make target `clean'.  Stop. make[1]: Leaving directory `/home/luke/ngplant-0.9.7' make: *** [clean] Error 2 dpkg-buildpackage: failure: fakeroot debian/rules clean gave error exit status 2..
<bddebian> Does clean have an entry like:  [ ! -f Makefile ] || $(MAKE) clean   ?
<Gaming4JC> the rules file has this content: 	# Add here commands to clean up after the build process. $(MAKE) clean  dh_clean
<Gaming4JC> yes
<bddebian> Exactly as I have typed it?
<Gaming4JC> no
<Gaming4JC> but it has the last part
<Gaming4JC> "$(MAKE) clean"
<azeem_> Gaming4JC: which doesn't exit, hence the first part
<bddebian> If it uses Makefiles but it's not there, add the [ ! -f Makefile ] || part in front of $(MAKE) clean
<Gaming4JC> ok, I'll give it a shot :)
<Gaming4JC> lol I'm afraid my rules file is riddled with errors for some reason
<Gaming4JC> dpkg-buildpackage: failure: debian/rules build gave error exit status 2
<Gaming4JC> now that clean is fixed, build is fussing.
<Gaming4JC> "# Add here commands to compile the package."
<Gaming4JC> and the only thing it has
<Gaming4JC> is "$(MAKE)"
<bddebian> There is no configure: target?
<Gaming4JC> umm I don't see one
<Gaming4JC> lol
<Gaming4JC> I'm trying to compile ngPlant just incase anyone is wondering
<_16aR_> what is that ? some sort of neopunk canabis ?
<bddebian> heh
<Gaming4JC> :P
<Gaming4JC> no it's a 3D plant modeler
<bddebian> Is this new packaging or did you get a source package from somewhere?
<_16aR_> oh yeah ?
<_16aR_> I look into it then :)
<Gaming4JC> I got the source from the site
<jmarsden|work> Gaming4JC: Where did you get the debian/* stuff (including debian/rules) from?
<Gaming4JC> from scratch as far as I can tell, lol. I am following this tut: http://74.125.95.132/search?q=cache:mGP0ZVp9nOEJ:ubuntuforums.org/showthread.php%3Ft%3D51003+Ubuntu+how+to+make+deb&hl=en&ct=clnk&cd=1&gl=us&client=firefox-a
<jmarsden|work> Gaming4JC: And you have read and understood the Packaging Guide?  https://wiki.ubuntu.com/PackagingGuide/Complete
<Gaming4JC> hmm no I havent. I only read this tutorial and parts of https://wiki.ubuntu.com/PackagingGuide/Rules
<Gaming4JC> I do know how to "make" a generic linux binary though
<Gaming4JC> ;)
<jmarsden|work> I suggest reading all the Packaging Guide and then coming back to your packaging project.
<_16aR_> thanks Gaming4JC for ngPlant, seems an interesting project :)
<Gaming4JC> Yes, it's quite interesting. I was surprised no one had a deb for it alreadly. It's well known in the #blender community.
<_16aR_> by the way, cdbs manage scons now ?
<Gaming4JC> are there any good books for learning bash? It sure isn't like compiling in C++
<Gaming4JC> lol
<Gaming4JC> I also found it funny that gnome-terminal is different from Gentoo and KDE terminals
<_16aR_> I think Gentoo use gnome-terminal too, in its own gnome version :p
<_16aR_> What differences do you see ?
<jmarsden|work> Gaming4JC: for bash try http://tldp.org/LDP/abs/html/ for Make try http://www.gnu.org/software/make/manual/make.html
<Gaming4JC> _16aR_: emerge, no apt-get, etc.
<Gaming4JC> jmarsedn|work: thanks for info
<jmarsden|work> np
<_16aR_> Gaming4JC: ah ok ! Thats the distrib differences, not a differences between gnome-terminal, gentoo terminal and kde terms ^^
<_16aR_> Yes off course distrib can have their own package management
<Gaming4JC> ah :)
<_16aR_> That's the biggest part of their differences though
<Gaming4JC> there's no apt-get moo! What kind of a system is Gentoo with out apt-get moo.... lol jk.
<_16aR_> sourcemage with grimoire
<_16aR_> yeah, i think the moo is most important command a debian sys admin must know
<Gaming4JC> I've not read the entire PackagineGuide yet, but the rules doesn't mention the area I'm having troubles with.
<_16aR_> to create a package of an app that is using scons instead of make, you should look at those *.mk files I think : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470532
<ubottu> Debian bug 470532 in cdbs "cdbs: please add scons rules file" [Wishlist,Open]
<Gaming4JC> "build-stamp: configure-stamp "
<_16aR_> but like jmarsden|work, I suggest you read all the packagingguide before everythinhg
<_16aR_> cdbs can help you a lot to create a package if it has the .mk files to facilitate the builder integration
<_16aR_> and if you use cdbs
<_16aR_> just look at : https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml
<Gaming4JC> ok
<Gaming4JC> if it matters though, ngplant suggest compiling with scons
<_16aR_> suggest ? or oblige ? :p
<Gaming4JC> :P
<_16aR_> seriously, is there any makefile ?
<jmarsden|work> An app that uses scons is probably not really a good choice as a first ever app to package... might be better to start with fixing bugs in existing packages, get used to the whole packaging approach in Ubuntu, and *then* look at creating a new package for something?
<_16aR_> jmarsden|work: the first app I packaged was build on a scons system
<Gaming4JC> perhaps, but so far every package I look at is scons.
<Gaming4JC> RVHouse, ngplant, etc. etc.
<_16aR_> and to facilitate the thing, it was a lib ...
<Gaming4JC> scons is like the leader in program development or something, lol.
<jmarsden|work> _16aR_: I think that means you are the exception that proves the rule ;)  For most packagers IMO it pays to start simple and try more complex things later...
<_16aR_> I didn't fixed bugs, but I read every packaging guide, libpkg-guide, cdbs etc to make it build. And it did well ... But it was dependant on another package I packaged, but which wasn't accepted because of license issue (no GPL headers in every source file, and no news from upstream)
<_16aR_> no no Gaming4JC, scons is quite rare from what I see
<Gaming4JC> _16aR_: Hmm, I guess I'm just lucky enough to find the rare ones, lol...
<Gaming4JC> so bad for me :P
<_16aR_> jmarsden|work: yes, but maybe Gaming4JC wants to have ngPlant in his ubuntu before having crrected another bug :p
<Gaming4JC> ;D
 * Gaming4JC keeps reading over packaging guide...
<_16aR_> that's not a big deal Gaming4JC, but since there is no "official" cdbs mk rule for scons, you have to work a little harder to create your deb package
<Gaming4JC> hmm
<Gaming4JC> so how would get a makerule from scons
 * Gaming4JC googles...
<jmarsden|work> _16aR_: If Gaming4JC is capable of learning packaging that way, fine... if not, the slower approach is more likely to succeed.
<_16aR_> jmarsden|work: I bow down, maybe i was lucky to learn it that way
<_16aR_> Gaming4JC: do you succeed in having ngPlant compiled on your ubuntu by the way ?
<Gaming4JC> come to think of it
<Gaming4JC> I haven't tried getting a binary for this particular file
 * Gaming4JC goes to compile old fashion way...
<Gaming4JC> heh, I should have tried that first. This source may be buggy.
<Gaming4JC> scons: *** [ngput/p3dimage.o] Error 1
<Gaming4JC> scons: building terminated because of errors.
<_16aR_> yes, actually, that the first thing to do : if it FTBFS, you're ko until you patch/correct it
 * Gaming4JC why did I have to pick the hardest program on the planet to be my first deb? xD
<akb41> because after that, everything is easy?
<Gaming4JC> lol
<Gaming4JC> http://www.gs1.ubuntuforums.org/showthread.php?t=1028375 <-- Looks like I wasn't the only one with the problem
 * Gaming4JC reads article...
<Gaming4JC> some help that article was lol
<Gaming4JC> install everywhere WxWidgets in existence :P
<Gaming4JC> *every
<azeem> Gaming4JC: strcmp() is not from wxwidgets, so I doubt that's it
<azeem> it's likely a problem with your g++ version being to strict with the standard/ngPlant not ported to it
<azeem> too*
<Gaming4JC> hmm
<Ursinha> elcontador, :)
<elcontador> ????
<elcontador> uÃ©
<elcontador> vc pode ficar em maios de um canal ao mesmo tempo??
<elcontador> noss
<elcontador> moh bagunÃ§ado isso aqui
<Ursinha> elcontador, I don't know if this channel is english only
<azeem> it is
<elcontador> que lindo
<elcontador> vc fala  inglÃªs
<elcontador> ok
<Gaming4JC> speak eh English. :)
<Gaming4JC> ok so I found the line containt the problem.
<cjav> Hi, trying to use ppa and dput for the first time, but need to use an http proxy, does dput have this option? I have set ftp_proxy=http://myproxy.com:PORT but dput seems to ignore it
<Gaming4JC> " if (strcmp(Handlers[HandlerIndex]->FormatExt(FormatIndex),FileExt) == 0)" Anyone know why that won't compile on g++?
<Gaming4JC> "ngput/p3dimage.cpp:371: error: âstrcmpâ was not declared in this scope"
<azeem> Gaming4JC: try adding std:: in front of strcmp
<Gaming4JC> ok
<Gaming4JC> sadly no... "ngput/p3dimage.cpp:371: error: âstrcmpâ is not a member of âstdâ"
<azeem> then it might be a header issue
 * Gaming4JC goes to find what strcmp is a member of...
<james_w> Gaming4JC: "#include <cstring>"
<james_w> I believe
<elcontador> ursinha, could you help me?
<Ursinha> elcontador, what do you need?
<elcontador> are you  a programmer?
<Ursinha> elcontador, yes
<elcontador> I was looking for  a mentor
<Ursinha> for what?
<Ursinha> or
<Ursinha> what for
<Ursinha> :)
<elcontador> don't know any programming at all
<elcontador> I'd like to join the  MOTU team some  day
<Ursinha> well, guess people around here would be more qualified to help you than I am :)
<elcontador> why??
<Chris`> elcontador: You don't need to program to be motu
<elcontador> uhn
<elcontador> all that packaging stuff
<Gaming4JC> you can do bug fixes
<elcontador> I got tired of  watching  those videos  and going  nowhere
<Gaming4JC> https://wiki.ubuntu.com/PackagingGuide/
<Gaming4JC> https://wiki.ubuntu.com/MOTU
<Gaming4JC> :)
<elcontador> yeah, that one
<Chris`> elcontador: You can package without needing to know C, Perl, Python etc
<elcontador> ok
<Gaming4JC> you can o_O
 * Gaming4JC is working with C++ right now
<Chris`> elcontador: I'm doing it and I don;'t know any languages :P
<elcontador> then I guess that maybe it's not  what I'm looking  for
<elcontador> I'd like to learn  real programming
<Gaming4JC> james_w: #include <cstring.h> was it, now I got more problems...
<elcontador> but I just don't know  whre  to start from
<Chris`> elcontador: What do you want to be able to program? For what purpose?
<james_w> Gaming4JC: you probably don't want .h with cstring, use either <cstring> or <string.h>
<elcontador> just would like  to learn it on ubuntu
<elcontador> knowledge
<elcontador> that's all
<elcontador> all maybe help programming ubuntu  someday
<elcontador> like you all must do
<Gaming4JC> james_w: ok thanks for tip. Wikipedia mentions it as "strcmp is a function in the C standard library (declared in string.h) that compares two C strings."
<jmarsden|work> elcontador: You could learn Python, see http://wiki.python.org/moin/BeginnersGuide/NonProgrammers for some tutorials to get started??
<Gaming4JC> oh boy... "ngput/p3dospath.cpp:257: error: âmemcmpâ was not declared in this scope"
<james_w> Gaming4JC: yeah, string.h, not cstring.
<james_w> Gaming4JC: should be in the same header
<elcontador> what could I program with this  python language?
<elcontador> I don't have any ideas
<Gaming4JC> umm
<Gaming4JC> Blender plugins?
<jmarsden|work> elcontador: Anything you know how to tell a computer to do :)  Go through a tutorial first.
<elcontador> thanks
<Gaming4JC> "Hello World" ;)
<elcontador> hahah
<elcontador> ok
<elcontador> but besides learning programming
<elcontador> I have a post-installation issue to solve
<elcontador> a sound driver issue
<elcontador> could  Anyone help?
<Gaming4JC> see #ubuntu
<Gaming4JC> :)
<elcontador> ok
<jmarsden|work> ALso see https://wiki.ubuntu.com/DebuggingSoundProblems
 * Gaming4JC w00000000000tttzzz... <cstring> is working and although depreciated it is compiling
 * Gaming4JC fingers crossed!
<Gaming4JC> ah and I would like to make a comment on C++
<Gaming4JC> can some one tell me why Microsoft C++ is so different from Gnome's G++
<Gaming4JC> it's the same principle but sure is a pain to convert your code between the two
<Chris`> Gaming4JC: Just do // ;) or /* */
<Gaming4JC> arg...
<quadrispro> does anyone can review this? http://revu.ubuntuwire.com/details.py?package=w-scan
<Gaming4JC> james_w: More Bugs >_< ... scons: *** [ngpshot/p3dshaders.o] Error 1 ngpshot/p3dshaders.cpp error: âmallocâ, 'stderr', 'fprintf, and 'free' were not declared in scopes.
<james_w> malloc is stdlib.h
<quadrispro> ehm... s/does anyone can/can anyone review :)
<james_w> stderr is stdio.h
<james_w> should be all you need
<Gaming4JC> yes fprintf is stdio too
<maxb> quadrispro: You've got a debian bug number in your changelog entry....
<maxb> This is Ubuntu! :-)
<Gaming4JC> james_w: unfortuneatly no change.
<Gaming4JC> still same errors.
<Gaming4JC> :-/
<james_w> then you didn't fix it right :-)
<Gaming4JC> lol
<binarymutant> if anyone has the time to review my package charm, http://revu.ubuntuwire.com/details.py?package=charm, I would be greatly appreciative. Thanks :)
<Majost> anyone know why update-python-modules would do this: link /var/lib/python-support/python2.5/mymodule/__init__.py
<Majost> and then a few lines later
<Majost> remove namespace /var/lib/python-support/python2.5/mymodule/__init__.py
<Majost> on hardy
<maxb> quadrispro: I noted a few points, though I don't have SVB equipment so I didn't test anything
<mbeatty> :q
<mbeatty> ! :x
<ubottu> The X Window System is the part of your system that's responsible for graphical output. To restart your X, type Â« sudo /etc/init.d/?dm restart Â» in a console - To fix screen resolution or other X problems: https://wiki.ubuntu.com/X/Config/Resolution
<Majost> I found this upstream bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=484669
<ubottu> Error: Could not parse data returned by Debian bugtracker: list index out of range (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=484669;mbox=yes)
<Majost> but I haven'y any idea how to work around the issue
<akb4> no answer from an hour ago... I have a package in debian sid that I'd like to get into the next ubuntu release. How can this be made to occur?
<maxb> akb4: It's new in sid, I assume? If it had been in before Christmas it would have automatically synced
<akb4> yep, we had a few minor issues getting into sid main, just hit last week.
<akb4> (hit the repos, that is)
<maxb> https://wiki.ubuntu.com/SyncRequestProcess describes (rather tersely, admittedly) the procedure for requesting an explicit sync
<maxb> though it rather fails to comment on syncs of entirely new packages :-/
<akb4> in that case, should I still follow those directions?
<maxb> I suggest so, yes
<maxb> oh, the command line tool mentioned in the wiki page has an option specifically for new packages :-)
<akb4> ok, thank you.
<maxb> so I suggest running it and seeing what it tells you to do
<maxb> :-)
<akb4> hmm. since I don't have an ubuntu system to hand, I'll try the bug-filing method. script also has no apparent option to specify the requester's email address; in my case, trying to automatically derive it would be non-optimal.
<akb4> directions for sync request say to subscribe either ubuntu-main-sponsors or ubuntu-universe-sponsors. which should I choose? the package is a game.
<directhex> the package is rather unlikely to be in main
<EagleScreen> i think universe
<raof> akb4: If it's a new package, it'll be in Universe.
<akb4> thx
<quadrispro> maxb: thank you! I'll work on it ;)
<laprice> I'm trying to script a build to track a standard package with patches.
<laprice> I have the patches set in debian/patches/
<laprice> my question is, if I use debuild -S
<laprice> will the diff file generated include the patches?
<laprice> It's a cdbs package (postgresql) do I need to patch the rules file as well as the control file?
<raof> All these questions (apart from the debuild one) rely on a knowledge of what you want to achieve.
<raof> debuild -S will include the patches.
<laprice> ok, can I use the diff.gz file to handle changing the name/version of the package so that it will be marked as conflicting w/ the parent package?
<directhex> you don;t ever touch diff.gz by hand. it's a file generated by debuild
<laprice> ah.
<laprice> i have been doing it wrong. :/
<directhex> i've heard much worse
<laprice> so I should be editing the control file and running debuild -S
<directhex> yes, precisely that
<laprice> and the packages signing? can I do anything about that?
<directhex> make sure you're the last guy mentioned in the changelog, and make sure you have a matching gpg key in your keyring
<laprice> edit changelog dch -i
<laprice> and the key has to match my email address in the package
<laprice> I saw something about DEBEMAIL environment var, should I be using that?
<jmarsden|work> laprice: Yes.  export DEBEMAIL=you@example.com  and also  export DEBFULLNAME=Your Name
<jmarsden|work> Then dch -i puts that info into the changelog
<laprice> OK Thank you.
<jmarsden|work> No problem.
#ubuntu-motu 2009-01-22
<binarymutant> if anyone has the time to review my package charm, http://revu.ubuntuwire.com/details.py?package=charm, I would be greatly appreciative. Thanks :)
<laprice> is there a way to override dch -i putting 'jaunty' as the release?
<coppro> with a text editor?
<Laney> man dch, there is a parameter for that
<pochu> dch -D foo
<laprice> OK, found it. thanks
<laprice> So I have built the package, am I right in thinking that debsign goes out to a key repository because it gives me an error, and it never asks for my passphrase.
<laprice> building it unsigned is fine for this pass, but I probably do need get the keys figured out so that I can build official packages for replicator :-)
<james_w> it uses your local keyring
<james_w> but it looks for a key with a UID which byte-for-byte matches what is in debian/changelog
<james_w> you can tell it what key to use with the -k option, or make debian/changelog match a UID on the desired key
<sooth> Are PPA packages signed with maintainer's key?
<raof> No.
<ScottK> Source is
<nhandler> Ok, I am almost positive that there is something wrong with pbuilder (or the related packages) for intrepid
<ScottK> nhandler: Then how come you're the only one with a problem?
<ScottK> That I know of anyway....
<nhandler> ScottK: I have no clue. But I just did a fresh install (again) with the same problem.
<nhandler> Since I'm using the same pbuilderrc as some other people, I don't think that is the issue
<ScottK> nhandler: Want my pbuilder wrapper script?
<nhandler> ScottK: Let me see it. vorian already had me try one which failed
<ScottK> After I saw you discuss this last, I made a new one with it.
<ScottK> OK.
<ScottK> nhandler: http://pastebin.com/f659051c5
 * ScottK considers the very idea of php-gnupg as questionable.
<nhandler> ScottK: The wrapper script failed too.
<vorian> nhandler: which debootstrap are you using?
<vorian> backport?
<nhandler> vorian: Yeah, 1.0.10ubuntu1~intrepid1
<vorian> hmmm
<nhandler> I even tried the jaunty debootstrap a few days ago, but it didn't help
<ScottK> nhandler: What error?  I've forgotten
<tritium> wgrant: when you have a minute, please ping me re: MOTU Science team issues
<nhandler> ScottK: Err http://archive.ubuntu.com jaunty/main libcwidget3 0.5.12-3ubuntu1 Could not resolve 'archive.ubuntu.com'
<nhandler> (That comes up for all of the packages)
<Hobbsee> ie hte /etc/resolv.conf in the pbuilder is wrong.  strange...
<nhandler> Hobbsee: Is there any way to fix that? Since the chroot isn't created, I can't do a pbuilder login
<StevenK> nhandler: You can run debootstrap by hand, and try and correct any problems it comes up with
<nhandler> I'll give that a try StevenK
<Hobbsee> nhandler: use pbuilder login --save-after-login?
<mrooney> vorian: would you mind checking out my changes to http://revu.ubuntuwire.com/details.py?package=wxbanker when you have a minute?
<ScottK> I dont think you can login until after its created.
<Hobbsee> oh, the problem is creating it in the first place.  got it
<mrooney> vorian: I found a package using the same icon set as I am, so that was super helpful :)
<Hobbsee> nhandler: you're not running a local nameserver or anything, are you?
<ScottK-desktop> nhandler: You don't happen to have the resolveconf package installed do you?
<ScottK-desktop> Err resolvconf
<Hobbsee> that too
<jsmidt> I am going to ask what may sound as a dumb question but please be patient.
<jsmidt> Both the PackageUpdate and MOTU/TODO encourage us to be merging and syncing.
<jsmidt> The sync page asks that we only request syncs that improve Ubuntu.
<jsmidt> But the reaity is there are several packages that would improve Ubuntu through bug fixes and new features.  It really is subjective.
<jsmidt> What is the rule of thumb when making these requests?
<ScottK> This is correct.
<ScottK> It's a question of risk and benifit.
<ScottK> Assessment of these is subjective and requires experience.
<jsmidt> Should I just go to town and request anything I think would benifit Ubuntu?
<ScottK> I'd suggest start small.
<jsmidt> I'm only asking because it is a main todo and I want to be helpful.
<ScottK> Pick a few and suggest them.  See how it goes.
<ScottK> You're main job when you're new is learning.
<ScottK> So don't go overboard with requests.
<jsmidt> Okay, since I can't do the actual uploading and was scolded for doing debdiffs for syncs, should I at least upload a build log?
<ScottK> Focus on picking what you think are important things and see what's good.
<ScottK> You should definitely test build.  No need to actually upload the log.  The sponsor will test build it anyway.
<jsmidt> ScottK, thanks.  "You're main job when you're new is learning."  I really am trying.
<ScottK> Good.  Just keep at it.
<binarymutant> if anyone has the time to review my package charm, http://revu.ubuntuwire.com/details.py?package=charm, I would be greatly appreciative. Thanks :)
<raof> Ok, time to fix us some dbus permissions on packagekit.
<jsmidt> Is there a way to get a feed for packages with a particular tag, like patch?
<raof> jsmidt: I don't think so, but haven't dug into that particularly.
<milli> ScottK: has a freeze date been set for Jaunty yet?
 * milli would like to get Rails 2.2.2 in soon, with fixed depends
<raof> milli: It'll be on wiki.ubuntu.com.
<raof> https://wiki.ubuntu.com/JauntyReleaseSchedule
<milli> raof: ty...  guess I need to hassle the Debian maintainer first...  there are security fixes beyond 2.1.0 that's in sid too...
<StevenK> bigon: Can you please include more information in your sync requests? Having to dig up two changelogs and then compare changes is very tiresome.
<stochastic> I'm trying to package my second package, but it relies on qmake so I'm not sure how to format the changes to the debian/rules file.  Are there any good qt packaging guides around?
<Amaranth> stochastic: your best bet is to find another package that uses qmake
<dholbach> good morning
<iulian> G'morning dholbach.
<dholbach> hiya iulian
<dholbach> soren: I got ~ubuntu-motu merged into ~motu. It's done now.
<slomo_> raof: could you merge/sync banshee 1.4.2, ipod-sharp 0.8.2 and podsleuth 0.6.4 from experimental? if you need to do any changes except changing libgnome2.0-cil to libgnome2.24-cil please tell me ;)
<raof> slomo_: If you update f-spot, sure!
<stochastic> I uploaded a fix to bug #211798 a few weeks ago but there's been no sign of activity since.  Do I need to mark the bug as fixed before the debdiff is accepted into the repos?
<ubottu> Launchpad bug 211798 in jack-rack "jack-rack open file hangs" [Undecided,Confirmed] https://launchpad.net/bugs/211798
<dholbach> thekorn, jpds: do you have any idea why the new grab-attachments (using lplib) do unzip zipped attachments (.diff.gz)?
<DktrKranz> stochastic: no, unless your bug is already fixed in jaunty.
<stochastic> DktrKranz, is there anything I can do other than wait now?
<DktrKranz> stochastic: waiting is the key here. I could have a look this evening, since I've no UI here.
<DktrKranz> *GUI
<stochastic> Okay, I'm just making sure its not going under the radar for jaunty
<DktrKranz> stochastic: if you're around this evening (europe timezone), please remind me :)
<thekorn> dholbach, hmm, really? let me check, I'm sure I did not change anything related to handling of zipped files in this tool
<thekorn> dholbach, it looks like it's a 'feature' of launchpadlib, zipped content is automatically unzipped
<dholbach> narf :)
<thekorn> go, report a bug!
<RAOF> I always forget; if I upload a Banshee merge which build-depends on some new syncs, that's fine - it'll happily sit in dep-wait until the version is satisfied, yes?
<persia> RAOF, As long as you're using unsatisfied versioned build-depends, it ought.  Worst case, it's just a rebuild for the build failure.
<DktrKranz> RAOF: yes, unless there are broken inner dependencies, in that case a give-back is enough to have things done.
<persia> (and we can do give-backs with the UI now :) )
<RAOF> Oh, we can, can't we.  Yay!
 * DktrKranz hugs persia
<DktrKranz> "Yes, we can" (cit.)
<DktrKranz> RAOF: if you need a hand to clear those, count on me. I want to be able to upgrade banshee again ;)
<RAOF> DktrKranz: You're welcome to help.  The relevant bug is bug #314516
<ubottu> Launchpad bug 314516 in tomboy "gnome-sharp2 transition" [Medium,Confirmed] https://launchpad.net/bugs/314516
<RAOF> The world has no right to be 30Â°C at 9pm.
<dholbach> RAOF: 1Â°C here :)
<jpds> It's 3*C here.
<ogra> yeah
<RAOF> dholbach: Trade you? :)
 * ogra would love to be where RAOF is
<RAOF> Sydney.  Sweet, sweaty, humid Sydney.
<DktrKranz> RAOF: I know, I filed it ;)
<DktrKranz> just I hadn't time to follow it
<Quintasan> dholbach: I want to ask a question, it's related to yesterday's talk. Can I /msg you?
<dholbach> Quintasan: sure
<Quintasan> s the diffrence between Fix Commited and Fix Released?
<Quintasan> crap :S
<directhex> fix committed means the fix is published "somewhere". fix released means the fix is in a package in the archive in the right place
<directhex> fr'example it might be fixed in a package's bzr branch or svn repo, but not yet pushed to a new package
<RAOF> directhex: When's the mono packaging session tomorrow?
<Quintasan> directhex: thanks
<directhex> RAOF, it's at 8pm utc tonight
<directhex> RAOF, you can translate that into foreign
<RAOF> Ok, that's 7am at GMT+11.
<ScottK> milli: It's mid feb.  Let me know about Rails.  I'd be glad to sponsor it.
<morgs> Please remind me: I want to update a package to a new upstream version. What do I attach to the LP ticket: debdiff, or diff.gz?
<dholbach> morgs: diff.gz, the debdiff is not really helpful, as it contains all the new upstream changes as well :)
<morgs> dholbach: and a pointer to the upstream tarball, right?
<dholbach> that'd help, if the package does not have a debian/watch file
<morgs> dholbach: the upstream tarball is a tar.bz2 - I can put an orig.tar.gz somewhere, would that be better?
 * dholbach hopes to do do some sponsoring during the Jam in Berlin later on
<james_w> morgs: no need really, re-compressing a tarball is easy to do
<morgs> OK, thanks
 * dholbach nods towards james_w
<dholbach> I personally always check the contents of the new proposed tarballs anyway
<dholbach> one day... one fine glorious day - I know the sun will be shining brightly... we won't have the .orig.tar.gz limiation any more
<persia> morgs, Please do have a get-orig-source rule and a README.source if the tarball is being recompressed.
<persia> morgs, Also, if you're planning to push the same version also to Debian, and that orig.tar.gz has already been submitted, it's helpful to link to it to avoid any md5sum clashes.
<morgs> OK
<persia> conversely, if you're submitting to Debian later, and it goes into Ubuntu first, it's helpful to link to the Ubuntu orig.tar.gz for the Debian sponsor.
<morgs> OK, thanks
<mok0> hyperair: ping
<mok0> hyperair, did you see the comments why codelite was rejected?
<hyperair> mok0: rejected?
<hyperair> mok0: i didn't see anything about it
<mok0> hyperair: ah, you didn't :-)
<hyperair> where?
<mok0> I was rejected by archive-admin
<mok0> s/I/It/ :-)
<Laney> tsk tsk!
<hyperair> eh? but why?
<mok0> hyperair: https://lists.ubuntu.com/archives/ubuntu-archive/2009-January/024103.html
<hyperair> i see
<hyperair> so i make a get-orig-source rule that removes all of that?
<mok0> hyperair: you need to repackage the tar-ball, they don't want all that crud in the archive :-)
<mok0> hyperair: yes
<hyperair> alrgiht
<hyperair> and then do i need another two advocates to get it in?
<mok0> hyperair: no I'll just re-upload
<hyperair> okay
<hyperair> basically only the dlls right?
<mok0> hyperair: yes, all the binary files that don't belong on Linux
<mok0> hyperair: he mentions an .exe file too
<hyperair> eh?
<hyperair> there is?
<hyperair> yeah you're right
<hyperair> so there's just dlls and exes?
<mok0> I think, yes
<mok0> hyperair: but check the tree carefully for irrelevant stuff
<hyperair> mok0: there's a .a somewhere
<hyperair> do i remove that too?
<mok0> yes
<mok0> hyperair: If the app doesn't build without it we're in trouble
<hyperair> then i start bugging upstream
<mok0> hyperair: :-) good boy
<hyperair> heh
<hyperair> mok0: are .ico files acceptable?
<mok0> hyperair: Are they needed for the Linux version of the app?
<hyperair> i'm not sure
<hyperair> can linux even use .ico files?
<mok0> hyperair: Aren't they desktop icon things for Windows?
<mok0> hyperair: try getting rid of them & check if it hurts
<hyperair> i'll check if they're in the debs
<persia> hyperair, .ico files can be read by several applications, but can't be used in .desktop files natively.
<hyperair> yeah i thought so
<hyperair> but if it's in the source but not the debs is it really required to remove them?
<persia> Not usually.  .ico files are sometimes the preferred source for modification.  We certainly have .ico editors in the archive.
<hyperair> hm
<hyperair> i see
<hyperair> mok0: do i need to remove .bat files?
<mok0> hyperair: yep
<hyperair> and Makefile.win?
<mok0> hyperair: everything related to windows
<hyperair> *groan*
<hyperair> there are so damn many things
<mok0> hyperair: Bug upstream ;-)
<hyperair> to release a separate source tarball for linux and windows?
<mok0> hyperair: yes
<mok0> hyperair: many projects do
<hyperair> i think that'll require quite a lot of work on his part
<hyperair> ._.
<hyperair> the last time i tried getting him to do something on that scale, he took ages, and in the end i settled for using symlinks
<mok0> hyperair: yeah, probably a bad idea
<mok0> hyperair: note down the paths of all the files you remove in a file and make a script to do it
<mok0> hyperair: or "find . -name \*.bat -exec rm {}\;
<mok0> "find . -name \*.exec -exec rm {}\;
<hyperair> mok0: yeah i'll do that, but right now, i'm still trying to get all the files
<hyperair> there are dlls, exes, bats, Makefile.win
<hyperair> among other things
<mok0> hyperair: spread all over the source tree?
<hyperair> geez, even pidgin's tarball has windows specific Makefiles in them, why didn't those get removed
<hyperair> yes
<hyperair> spread all over
<mok0> hyperair: file a BTS bug about it :-)
<Laney> Huh, isn't the problem just binaries without corresponding source?
<hyperair> mok0: what's a BTS?
<Laney> There's no need to remove any trace of the windows build
<hyperair> oh
<mok0> hyperair: Debians Bug Tracking System
<hyperair> if it's just binaries without corresponding source, then .exe and .dll and .a should be enough
<Laney> right
<hyperair> and then what do i call the repackaged tarball?
<Laney> if they're needed for the build then they should be created as part of it
<hyperair> hoo boy
<hyperair> looks like i'm going to ahve to bug upstream
<hyperair> he's got a libcurl.a
<hyperair> but no libcurl sources
<Laney> can it use the system libcurl?
<hyperair> lemme grep and see
<hyperair> it seems the readme says to install the libcurl dev
<hyperair> but ./configure doesn't seem to detect it
<hyperair> no wait i found a function inside configure which detects it
<hyperair> but it isn't called
<hyperair> ah it seems it's a CURL for Windows
<hyperair> i think i'll just rm -rf the whole folder than
<hyperair> then*
<hyperair> ..come to think of it i'm going to try and build without the whole sdk/ folder
<mok0> hyperair: yikes that's a miss. You have to call the system curl
<hyperair> mok0: no the curl folder seems to belong to windows
<mok0> hyperair: ah ok
<hyperair> mok0:  in the first placei d on't think it uses curl
<mok0> hyperair: just add '~dfsg' to tarball name, after the version no. (That's tilde-dfsg)
<hyperair> tilde eh?
<hyperair> strange, i thought it was "."
<persia> No, please, not tilde.
<hyperair> heh
<hyperair> .dfsg then?
<persia> hyphen is much preferred, or even better, minus-sign.
<hyperair> erm
<hyperair> is there a difference between minus and hyphen?
<mok0> persia: tilde will let any other version override it
<persia> Yes.
<persia> mok0, Yes, but do we want that?
<persia> For dfsg, usually we don't.
<Laney> I thought it was +dfsg usually
 * hyperair sighs
<mok0> persia: if upstream packages a tarball that confirms to dfsg without altering the version no
<hyperair> that's very rare isn't it?
<persia> Laney, That's common too.
<mok0> persia: than you want to be able to override the package and still use the same version
<persia> mok0, If upstream does that, they should have versions explained to them.
<hyperair> mok0: and in the first place, i don't think he's about to package a dfsg tarball minus version change
<hyperair> mok0: his version contains the svn revision stuck on it
<hyperair> mok0: that's the 4-digit version after 1.0.
<mok0> hyperair: kk
<hyperair> persia: heh you know, the author of sigx released a tarball sigx-2.0.tar.bz2 twice, second time, setting a SONAME after i requested him to do so
 * mok0 screams in pain
<hyperair> lol
<hyperair> well considering nobody actually does use sigx yet (i haven't seen any application which uses it, or any distro which packages it), i think that as long as he doesn't do it again it'll be fine
<persia> hyperair, I do hope you asked the author to never repeat that, given the nature of web archives.  It breaks namespacing.
<hyperair> persia: web archives?
<Laney> The old tarball may have been archived elsewhere
<hyperair> oh
<hyperair> i see
<mok0> persia: TBH, that's a problem with Debian's archive structure
<persia> hyperair, archive.org for one.  There are others.  Also, there are uncountable caches, both visible and transparent.
<mok0> persia: it really OUGHT to be able to handle name-space clashes
<ScottK> mok0: Not accepting substitute tarballs with the same version name, but a different md5sum is a feature, even though it's painful.
<persia> mok0, It's not archive-specific: it's related to the fact that if two binary blobs have the same name, it causes confusion.
<persia> mok0, Yes, the real solution is to rearchitect browserspace to have persistent URNs for all binary blobs, and use URLs as redirectors for URNs, but that idea failed to catch on before the web left CERN years ago, and doesn't show any signs of getting better.
<persia> with persistent links between URNs and blobs, adding a cryptographic check doesn't matter, and the archive could just have arbitrary version codes used to reference URNs for packages
<persia> (and yes, a text file is also a binary blob, much as a square is also a rectangle)
<dholbach> mok0: "primadonnas" :-)
 * dholbach sniggers
<tritium> Good morning, dholbach.
<dholbach> hiya tritium
<tritium> dholbach: I'm considering packaging http://ngspice.sourceforge.net/index.html for jaunty, as it has not been in an ubuntu repository since hoary, but I need to check on licensing issues.
<rulus> Ik heb de vraag gekregen in welke mate details moeten gekend zijn van de verschillende entiteiten die kunnen voorkomen in het GRB en in de GRB-skeletbestekken.
<rulus> GRB-producten: 1. Datamodellering: slide 10 tem 30 --> Is het hier de
<rulus> bedoeling dat alle afkortingen en types van elk element gekend zijn?
<rulus> En in hoeverre moet dit gedetailleerd gekend zijn? Of is het enkel
<rulus> voldoende dat je kort kan zeggen wat alles is?
<rulus> De verschillende soorten entiteiten die voorkomen in het GRB dienen gekend te zijn, maar de bijhorende afkortingen en alle mogelijke voorkomende types van een entiteit dienen niet in detail gekend te zijn.
<rulus> Van elke entiteit dient er kort toegelicht te kunnen worden om welk object op het terrein het gaat of waar dit kan voorkomen. Daarom moeten niet alle geometrische eigenschappen, uitzonderingen, kenmerken... ten gronde gekend zijn.
<rulus> GRB-producten : 4. GRB-GIS: slide 7 tem 29 --> Ook hier, in hoeverre
<rulus> moet dit gekend zijn? Is het de bedoeling dat je weet hoe alles in GIS
<dholbach> tritium: alright
<rulus> voorgesteld wordt?
<rulus> Deze slides hoeven niet in detail gekend te zijn. Ze dienen vooral ter illustratie van het GIS-product en tonen een mogelijke voorstelling van de verschillende entiteiten die reeds eerder uitgelegd werden. Qua te kennen leerstof, houden deze slides geen nieuwe elementen in.
<rulus> GRB-skeletbestekken : 3. Opbouw: slide 41 tem 141 --> Hoe
<rulus> gedetailleerd moet dit gekend zijn? Is het voldoende als je van elk
<rulus> element weet wat het juist is en hoe het in een foto wordt
<Laney> erm
<rulus> voorgesteld? Of moet elk detail gekend zijn?
<tritium> dholbach: is there any specific guidance on licenses?  ngspice has a heterogenous license, as it draws from different projects with different licenses, including LGPL, Old BSD, Public Domain, and New BSD.
<dholbach> tritium: https://wiki.ubuntu.com/PackagingGuide has a chapter about licenses and debian/copyright
<tritium> dholbach: thank you
<dholbach> anytime
<mok0> persia, ScottK, sorry I had to go AFK for a while
<persia> mok0, No problems.  Happens to everyone
<mok0> persia: I agree that publishing tarballs with different content but the same name is ... erhh... stupid
<mok0> persia: but it happens
<persia> Yes, but it shouldn't :)
<persia> Anyway, there are lots of ways around it, just not aesthetically pleasing ones.
<mok0> persia: I've just reviewed software, where the newest tarball has version 0.6, and an older one 1.0
<mok0> persia: the uploader had quite a task writing a watch file :-)
<persia> heh, I bet.
<persia> perl regular expressions are *very* powerful, but man uscan doesn't provide much of a guide.
<mok0> persia: yes, you sometimes have to work to get it to do what you want
<mok0> persia: I think we ended up mangling 1.0 to 0.1 or something like that
<mok0> persia: us packagers hate upstreams even more than developers hate users ;-)
<persia> heh
<persia> I'd probably have tried to somehow find the URL near the most recent date, but it might have taken me a week to get it right.
<mok0> persia: we considered it, but the date was not systematically written on the web page.
<persia> Ugh, even worse.
<persia> Some things should just not be.
<mok0> persia: and unfortunately, uscan can't get a tarball directly from the URL
<mok0> persia: if it contains http://
<persia> Needs to scrape a web page?
<persia> Yes it can, as long as directory indexing is enabled, and there's no index page.
<mok0> persia: I think so, I haven't been able to get the other thing to work
<mok0> persia: it ought to be able to work like wget
<persia> Uh, no.
<persia> I needs a list of versions to compare.
<persia> With a single URL, one can only get a single thing.
<persia> With a regular expression, one needs to have a set of matching things as a filter.
<mok0> persia: of course, d'Oh!
<persia> Otherwise, one needs to iterate over the entire matched set, which takes until well after the heat death of the universe.
<mok0> :)
<ScottK> Still faster than Debian releases.
<bddebian> Heya gang
<mok0> hi bddebian
<bddebian> Hi mok0
<tritium> Hi bddebian.
<bddebian> Heya tritium!
<tritium> :)
<ScottK> Heya bddebian.
<bddebian> Hi ScottK
<tritium> I'm a bit puzzled by bug 246506.  The debian bug status is "Fix Committed", but only because someone has privately packaged it, as far as I can tell.  It's not yet in Debian.
<ubottu> Launchpad bug 246506 in ubuntu "[needs-packaging] ngspice" [Wishlist,Confirmed] https://launchpad.net/bugs/246506
<ScottK> tritium: It may be in Debian New too.
<tritium> ScottK: I'm not familiar with Debian New.
<tritium> Ah, found it.
<broonie> tritium: When packages are uploaded to the archive they are initially reviewed for legal problems.
<broonie> While that happens they're not downloadable.
<ScottK> tritium: After a package is uploaded for the first time it goes into the New package queue (as broonie says)
<tritium> broonie: oh, I see.  This one, having multiple licenses, would need that legal review.
<tritium> The Debian Import Freeze has passed, correct?
<ScottK> http://ftp-master.debian.org/new.html
<broonie> tritium: All new packages get this review, you can't tell if the maintainer noticed everything without review.
<ScottK> tritium: For auto sync, yes.  They can still be requested manually.
<tritium> OK.  I don't find it in http://ftp-master.debian.org/new.html
<rulus> I'd like to apologise for my paste earlier; I wasn't aware of the fact that Putty associated the middlemousebutton with paste. Sorry.
<tritium> Thanks, broonie and ScottK.  How would you advise I proceed?
<ScottK> tritium: You could email the owner of the ITP bug and ask them how soon the plan to upload it.  You might also look on mentors.debian.net.
<tritium> It seems that "Fix Committed" isn't appropriate for it, if it's not even in Debian New.
<tritium> ScottK: will do.  Can his package be brought into ubuntu directly, or should it come straight from Debian?  Should it be repackaged (by me)?
<tritium> In the mean time, I'll contact the bug owner.
<ScottK> If it doesn't come through Debian (and given the length of the New queue that's getting unlikely) then it'd have to go through REVU.  You could do that.
<ScottK> Ideally they will give you access to the draft package and you don't have to change much.
<tritium> ScottK: ok, thanks again.
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek - Day 4 to kick off in #ubuntu-classroom in 19m. :-)
<slytherin> tritium: check with motu science team if they are interested in helping you with ngspice.
<tritium> slytherin: I'm technically still the administrator of that team, but I'm no longer MOTU.  I'm not sure the team is still active.
<tritium> I've pinged wgrant about it, though.  Thanks.
 * ScottK notes mok0 is interestedin science stuff too.
<mok0> I am
<ScottK> tritium: ^^
 * tritium notes above ;)
 * mok0 notes his name is no isotope
<mok0> s/name/nick
<mok0> tritium: the science team is sadly inactive
<tritium> mok0: yes, if I pursue reinstatement as an MOTU again, I'd hope to focus on that team.
<mok0> tritium: cool
<mok0> tritium: the Debian science team is much more active
<tritium> mok0: are you part of that?
<mok0> tritium: yes
<tritium> mok0: excellent
<tritium> Have you seen anything about ngspice in particular on your mailing list or otherwise?  It's licensing is peculiar.
<mok0> tritium: No, I haven
<mok0> t
<tritium> ah
<slytherin> tritium: you may want to contact tuxmaniac. Although he is not MOTU, he is very enthusiastic about electronic related softwares.
<mok0> tritium: can I see it somewhere? URL?
<tritium> slytherin: oh, thanks for the tip.
<mok0> tritium: and norsetto
<tritium> mok0: debian bug here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489768
<ubottu> Debian bug 489768 in wnpp "ITP: ngspice -- A Spice circuit simulator" [Wishlist,Open]
<tritium> project page here: http://ngspice.sourceforge.net/
<mok0> "The group developing ngspice has written to Berkeley's copyright holders asking to change the license to the new BSD, which has the incompatibility removed, but without success. "
<mok0> I wonder if that means they refused, or that they didn't answer the request
<tritium> Not sure.  Here's the COPYING file from the new ng-spice-rework-18 package that talks about the "heterogenous
<tritium> " license: http://paste.ubuntu.com/108277/
<mok0> tritium: OMG
<tritium> mok0: pretty crazy, eh?
<mok0> tritium: yeah
<tritium> It seems I always pick the crazy stuff to try to package.
<mok0> tritium: If UC decided to remove the advertising clause from their license, why wouldn't they accept that the old BSD license be changed in this case? It doesn't make sense
<tritium> I agree.
<mok0> tritium: it's the crazy stuff out there that left...
<tritium> heh
<mok0> ScottK, you want me to fake-sync ktranslator?
<ScottK> Got to.
<ScottK> Different orig.tar.gz
<mok0> ScottK, how did that happen?
<mok0> ScottK, problems with debian's repo?
<ScottK> mok0: It's hard to say.  Sometimes upstream tarballs get published more than one place.
<ScottK> mok0: It's not rare the first time we try to sync from Debian.
<mok0> ScottK, this looks to be a new packaging, they didn't use the old ubuntu one
<ScottK> This is not unusual either.
<ScottK> So the trick is to see if there is any needed to be saved from our.
<ScottK> our/ours.
<mok0> ScottK, yes
<mok0> ScottK, I will take care of it
<ScottK> If so, then merge, but unless it's significant, just fakesync.
<ScottK> Great.
<mok0> ScottK, hrmph, ktranslator is a KDE3 program, and hasn't been updated in almost  3 years
<ScottK> mok0: Does it need more than kdelibs?
<mok0> kdelibs4-dev
<ScottK> Then it's at least usable for now.
<mok0> ok, I'll continue. /me is annoyed at this package because it doesn't build out of the box. I thought I checked that
<soc> hi
<soc> just wanted to say thank you for all your help getting ttf-droid into ubuntu!
<mok0> soc: you
<soc> it looks like it was included 2 days ago and is now generally available through synaptic after install
<mok0> soc, you're welcome
<soc> ah hi mok0!
<soc> without you help i wouldn't have gotten my package into the shape it is now ..
<hyperair> mok0: i've uploaded a new tarball of codelite to revu, along with the necessary changes regarding get-orig-source
<hyperair> mok0: could you take a look?
<mok0> hyperair: yes I'll take a look, after I've cracked the problem I am looking at ATM
<hyperair> mok0: is it something i could help with?
<mok0> hyperair: you mean you want to swap :-)
<hyperair> eh?
<hyperair> swap?
<mok0> hyperair: I take codelite and you take ktranslator...
<mok0> hyperair: I'll have it nailed soon
<mok0> hyperair: It's a configure file built in maintainer-mode, so once the build goes "make" it decides to update everything
<mok0> which is a pain
<hyperair> ah i see
<fransman> Can someone check there a updated package of flumotion in the cue.
<fransman> I already did create a bug ticket for it, https://bugs.launchpad.net/ubuntu/+source/flumotion/+bug/319204
<ubottu> Launchpad bug 319204 in flumotion "Please sync flumotion (universe) with the scoop of the Debian External Health Status" [Undecided,New]
<directhex> woo, mono session in classroom soon :o
<Chris`> If there are many reviewers/advocates free, can you please review one of my packages? - http://revu.ubuntuwire.com/details.py?package=grdc
<hyperair> nobody seems free these days =(
<Chris`> hyperair: I know I try daily for reviews :p
<Chris`> So much for aiming for the MOTU :p
<hyperair> i've got three outstanding packages
<jpds> Chris`: Does perl have to be in the build-deps?
<jpds> hyperair: lies...
<hyperair> jpds: fine, you're the only one free =p
<Chris`> jpds: Yeah isn't it included?
<hyperair> why does everyone ignore me then T_T
<Chris`> It's for the pod manpage
<Chris`> hyperair: jpds is my mentor, it's his duty ;)
<hyperair> aah
<hyperair> i should go and apply for mentoring as well
<hyperair> =\
<hyperair> how dyou apply?
<jpds> Chris`: I think perl gets pulled it anyway (it's what most of the dh_* scripts are written in).
<Chris`> jpds: I was told on the manpage tutorial to include Perl
<hyperair> a standard pbuilder login has perl installed
<Chris`> hyperair: https://wiki.ubuntu.com/MOTU/Mentoring/Junior_Contributor
<jpds> Chris`: Hmm, ok. Did you know that you can seperate paragraphs in the long desc by have a " ." line?
<Chris`> A what line?
<jpds> As in: apt-cache show ubuntu-dev-tools
<Chris`> Oh cool ok
<Chris`> *changed*
<Chris`> Anything else bad?
<jpds> Chris`: Does the applet have to be called: grdc-gnome? Sounds a bit.. vague.
<Chris`> jpds: That's what upstream called it :-/
<Chris`> Should I mix it up or leave it as upstream wishes it to be?
<jpds> irssi-otr is know as irssi-plugin-otr in Debian..
<hyperair> damn, i seriously need to write a wiki page about myself?
<Chris`> hyperair: I have :P
<Chris`> hyperair: http://wiki.ubuntu.com/Chris
<hyperair> thanks
<hyperair> 17!
<hyperair> damnit you're younger than me
<Chris`> jpds: Perhaps grdc-gnome-applet?
<hyperair> then there's always rainct -- a year younger than me, same amount of years using linux, and motu already!
<Chris`> hyperair: I'm just using it as a progress tracker, more like a blog
<hyperair> i see
<jpds> Chris`: Not too sure, can't find a Debian GNOME policy on it.
<Chris`> Safer to leave it as it is? :-/
 * jpds would like gnome-applet-grdc, but can't find any packages which follow that.
<Chris`> So other than the line break, anything worth changing?
<jpds> Chris`: Would be nice to Suggest: the applet package.
<Chris`> Ah, how does one go about that?
<Chris`> Suggests: package?
<jpds> Yep.
<Chris`> *changed*
<Chris`> I've uploaded the new grdc now
<Chris`> jpds: it's uploaded now if you wanna add a comment/avocation :D
<RainCT> hyperair: and jpds is even younger \o/
<hyperair> RainCT: aren't you born in 1991?
<RainCT> hyperair: yep
<hyperair> RainCT: so is jpds
<hyperair> and me in 1990
<hyperair> the end of it
<RainCT> hyperair: but there are some months between his and my birthday (which, btw, is in 2-3 weeks :D)
<hyperair> heh.
<hyperair> there are three months between yours and mine
 * ScottK has children born in 1991.  Urgh.
<jpds> RainCT: Can you poke grdc, looks good to me.
<ScottK> Child anyway
<RainCT> jpds: bad tab completion :P
<hyperair> ScottK: heheheh
<RainCT> lol
<laga> i feel old.
<laga> and i haven't become a MOTU yet ;)
<RainCT> ScottK: tell them to become MOTU :P
<hyperair> laga: awesome. let's race =p
<Chris`> Count me in!
<directhex> mono session now on! gogogo :p
<hyperair> Chris` no fair you've got a headstart =p
<laga> hyperair: how old are you? ;)
<ScottK> RainCT: No, they aren't that interested in computers.
<hyperair> laga: born 1990. i'm lazy to remember my age, or do the calculation
<ScottK> My best hope is the 5 year old.
<RainCT> directhex: is that a treath?
 * RainCT runs
<Chris`> I lied I'm actually 17 in a week but there's no point updating the wiki just for that
<laga> hyperair: ah. i'm turning 22 this year, so i guess i'll have to lose.
<hyperair> directhex: would you be so kind as to review a mono package for me? =p
<directhex> RainCT, yes
<directhex> hyperair, after the session, sure
<directhex> hyperair, you can ask meebey, even! he's the debian mono pope!
<hyperair> directhex: http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin thanks =p
<RainCT> directhex: so you agree that mono is evil? \o/     :P
<directhex> RainCT, yeah, but less evil than java
<RainCT> hehe
 * ScottK hugs his Python.
<laga> how's java moar evil?
<hyperair> directhex: agreed!
<hyperair> laga: because java is longwinded and stupid
<ScottK> laga: How much mono stuff in multiverse?
<laga> i actually like java. :)
<directhex> laga, because java lacks monkeys
<directhex> ScottK, none
<hyperair> laga: if you've got a good IDE, yeah it isn't that bad
<laga> ScottK: uh, dunno.
<ScottK> directhex: Yep.
<laga> hyperair: i like eclipse. i wish there was a nice debugger for python (is there o ne?)
<ScottK> laga: How much java stuff stuck in multiverse?
<hyperair> laga: but when you're writing it on paper, you tend to hate SuperLongAndObscureNamespaces.SuperLongAndObscureSecondNamespace.SuperLongClassName
<laga> ScottK: just wait for icedtea :)
<directhex> why are none of you in #ubuntu-classroom then? :o
<laga> hyperair: well, that'd be silly.
<ajmitch> directhex: because we're sensible people
<ajmitch> (and I just joined)
<hyperair> laga: it's a written paper exam
<laga> hyperair: actually, we will have an oral examination for this java class. :)
<hyperair> oral?!
<laga> hyperair: yes. :)
<hyperair> i thought written programming was stupid, but oral sounds even more stupid ._.
<laga> hyperair: heh. no, it'll be more about algorithms.
<hyperair> System dot out dot printf open bracket ...
<fransman> how do i set bug #319204 for need packaging ?
<ubottu> Launchpad bug 319204 in flumotion "Please sync flumotion (universe) with the scoop of the Debian External Health Status" [Undecided,New] https://launchpad.net/bugs/319204
<hyperair> doesn't seem like a need packaging bug
<laga> hyperair: it'll be more more high-level stuff.
<laga> hyperair: we implemented stuff like parsers and they probably want us to describe that
<hyperair> laga: then that's fine i guess, but oral still sounds weird. don't programmers draft things out on paper for complex issuse?
<laga> hyperair: we'll have time for that i suppose.
<fransman> hyperair: what does it then?
<laga> hyperair: AFAIR, we will also be graded on the home work we turned in. we did projects instead of lectures. the oral exam is just a bonus IIRC
 * directhex thinks hyperair could learn useful things in this session
<hyperair> directhex: eh wha?
<directhex> hyperair, session on mono packaging in #ubuntu-classroom
<directhex> that's better!
<hyperair> it seems...quiet
<RainCT> directhex: is that transition also on Debian?
<directhex> gnome#? ehm... sort of. the offending gnome# is in experimental, but we're not currently building things against it
<directhex> poke slomo for that
<khashayar> Â§
<khashayar> Hi all. I've built a package for pencil (http://www.les-stooges.org/pascal/pencil/), and I'm currently down to only one lintian warning, missing man page. Is it frowned upon to upload it to revu in its current state? (I'm just not going to do the man page tonight).
<RAOF> khashayar: You're welcome to upload to revu and solicit comments about the rest of the packaging.
<khashayar> RAOF: Thanks. I'll do that.
<RAOF> khashayar: Make sure to add a comment to the effect that you're not after advocation, just comment, and you'll write the man page before asking for it to be uploaded.
<hyperair> khashayar: i generally upload to revu whenever i've gotten some major changes done, and only when i've fixed all my lintian stuff i start asking for comments
<khashayar> hyperair: OK. So suggest I write the manpage first before uploading?
<hyperair> khashayar: just upload first
<hyperair> khashayar: you can always reupload if you make changes
<khashayar> hyperair: OK. Thanks.
<hyperair> revu-ers seem so scarce that if you upload within a week or so of your previous upload you're almost bound to get no comments, unless you've bugged someone to do so
<Chris`> hyperair: Talking of bugging... RainCT you there? :)
<hyperair> Chris`: ?
<RainCT> Chris`: yes, but I'm busy :(
 * Chris` bugs RainCT for just one more advocate
<Chris`> OH ok don't matter
<mok0> hyperair, you are right, revuers are very scarce. There's less than a handful of MOTUs that do any work there
<mok0> hyperair: looking at codelite now, btyw
<hyperair> mok0: ah thanks =)
<wgrant> tritium: Yes, we are rather completely inactive. I see no problem with you remaining an admin.
<tritium> wgrant: Thanks.  :)  You realize my MOTU-ship expired, though, right?
<wgrant> tritium: I do.
<tritium> wgrant: Thanks.  :)
<hyperair> MOTU-ship expires?
<RainCT> hyperair: you can renew it clicking on a link
<tritium> hyperair: on launchpad, I didn't renew in time
<hyperair> i see
<RainCT> mok0: btw, I wanted to tell you something..
<RainCT> mok0: you rock!! :P
<mok0> RainCT: heh
 * hyperair thinks so too
<tritium> wgrant: please don't hesitate to ask me to help out, if there's something you need done
<mok0> Thanks guys
 * tritium just met mok0 today, but would agree that he rocks :)
<hyperair> mok0, your friendly neighbourhood buildd ;)
 * Chris` has silently observed mok0 over the past week and thinks given enough time, he may fall in love with mok0 :(
<hyperair> lol
<mok0> hyperair: I can't see where you do the repackaging of the tarball
<hyperair> mok0: debian/rules
<hyperair> mok0: and debian/copyright, see X-something
<mok0> hyperair: in the clean target?
<hyperair> mok0: get-orig-source
<hyperair> there should be a target
<hyperair> after clean
<mok0> uh, I may have the wrong version here
<hyperair> lol
<hyperair> http://revu.ubuntuwire.com/revu1-incoming/codelite-0901221833/codelite_1.0.2674+dfsg-0ubuntu1.diff
<hyperair> heheheheheg
<mok0> hyperair: got it now
<hyperair> okay
<hyperair> mok0: could you look at this please? i've fixed the stuff you mentioned in your previous comment http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin
<tdomhan> can the merge-o-matic not be used after the DebianImportFreeze?
<pochu> tdomhan: it can, but you need a good reason to perform a merge
<pochu> bug fixes are good reason, btw ;)
<tdomhan> so MOM still checks for new versions in the debian repos? because I can't find any files of the package I'm interested in, mhhhh or indicates this, that the packages is being synced? mhh
<hyperair> mok0: thanks
<hyperair> jpds: you free for a review? =p
<jpds> hyperair: About to go to bed, what is it so I can look at it in the morning?
<mok0> hyperair: got another batch of comments for you
<tdomhan> it's about the package gpsbabel, in the current debian unstable repo it is version 1.3.6-3, the jaunty version is 1.3.5. shouldn't merge-o-matic create it's corresponding files?
<hyperair> jpds: http://revu.ubuntuwire.com/details.py?package=sigx
<hyperair> jpds: and http://revu.ubuntuwire.com/details.py?package=vazaar
<hyperair> mok0: ah i saw, thanks
<hyperair> mok0: should i document it in codelite then?
<mok0> hyperair: I've already uploaded. Let's see if it gets into the archive this time. If it does, you can prepare an update of the package fixing that
<jpds> hyperair: OK; will look at both when I can tomorrow morning.
<hyperair> jpds: thanks
<hyperair> mok0: okay
<hyperair> mok0: then how do i submit it?
<hyperair> mok0: also the get-orig-source issue seems to happen only if you've already got an orig tarball
<mok0> Normally, you prepare a debdiff and get that sponsored through LP
<mok0> hyperair: let's worry about that later
<hyperair> okay
<hyperair> mok0: by the way, regarding the get-orig-source target... how should i fix it? uscan refuses to download again if it detects a orig.tar.gz of the correct version
<mok0> Yikes 129 packages awaiting review... that's +19 from a week ago.
<mok0> hyperair: ah, is that what happens?
<hyperair> mok0: yes
<hyperair> mok0: otherwise it works.
<hyperair> mok0: perhaps i should just put &&?
<mok0> hyperair: I'd suggest not calling uscan in the target
<hyperair> why not?
<hyperair> mok0: ^
<mok0> hyperair: than you'd have to do that first, and wouldn't need to run get-orig-source
<hyperair> what?
<hyperair> do uscan first?
<mok0> hyperair: yeah, so the operator would have to run it manually.
<mok0> hyperair: perhaps, in the get-orig-source target, you could run a uscan --report-status, if the version is up-to-date, bail out
<mok0> hyperair: nice little problem to keep you awake tonight
<hyperair> mok0: more like this morning
<hyperair> mok0: it's 6.30AM and the sun's going to rise soon
<hyperair> mok0: anyway the operator doesn't have to run uscan manually. in fact, it's better if uscan wasn't called manually
<mok0> hyperair: oh... did you get up early, or didn't you get to bed?
<hyperair> haven't gone to bed yet
<hyperair> class at 12.30PM
<mok0> yikes
<hyperair> and i'm multitasking between some packages and an accounts tutorial =p
<mok0> phew
<hyperair> i'm trying to get this done so i don't have to travel half the country with the textbook this weekend (i'm heading back home for chinese new year)
<hyperair> anyway about the lintian error
<hyperair> i figured out what's wrong
<mok0> hyperair:  the dll one?
<hyperair> dh_clifixperms wasn't being called because i hooked it onto common-binary-predeb-arch, instead of -indep
<hyperair> yeah the dll one
<mok0> hyperair: ah, good!
<hyperair> yep
<hyperair> so i've fixed that issue.. and the copyright issue..
<hyperair> just add dots right/
<mok0> yep
<mok0> simple
<hyperair> hmm come to think of it codelite's didn't have dots
<hyperair> and then about the get-orig-source..
<mok0> hyperair: I missed that, dang
<hyperair> heheh
<hyperair> i'll jhave to fix that in all of my other revu packages
<mok0> great, thanks. It's not a problem yet, because copyright is in principle free-format
<hyperair> yeah
<hyperair> well lintian will start complaining later on
<hyperair> on a side note.. what do i do about the issue with uscan?
<mok0> But if you choose the machine-readable format, it should of course be correct. It's just, there's no software to check it yet
<hyperair> it dies when there's a tarball existing
<hyperair> otherwise it works
<mok0> hyperair: of course you could rm -f the tarball first :-P
<hyperair> if you rm the ../bansheelyricsplugin_0.6.orig.tar.gz
<hyperair> hmm
<hyperair> would that be a good idea?
<hyperair> hmmm
<hyperair> yeah i think i should do that
<hyperair> which means yet another change to implement for codelite as well
<hyperair> the error happens there too
<hyperair> lool
<mok0> hyperair: what about uscan --report can you use that first ?
<hyperair> nope
<hyperair> that one reports the status as up to date as long as your debian/changelog has the said version
<mok0> uscan is not really advanced enough
<hyperair> it's pretty cool already
<mok0> hyperair: yes, but it should be more scriptable
<hyperair> yeah
<hyperair> true
<hyperair> the --report thing isn't exactly very parseable
<hyperair> though --dehs is scriptable
<hyperair> <status>up to date</status>
<hyperair> with the use of grep and sed, you could extract that out
<mok0> hyperair: yes that could be done
<hyperair> yeah but it reports up to date as long as your debian/changelog has an up to date version
<mok0> hyperair: but why haven't I seen this problem before?
<hyperair> why..
<hyperair> probably because they used wget?
<hyperair> also according to the bpp, get-orig-source must be callable from any directory.
<hyperair> it's entirely possible that they didn't provide for that
<mok0> hyperair: put a dh_checkdir call in it
<hyperair> anyway i've uploaded another version
<hyperair> what's dh_checkdir?
<hyperair> there isn't a manpage
<hyperair> command not found. hmm
<mok0> dh_testdir sorry
<hyperair> ah that
<hyperair> i don't see any real application for it in get-orig-source
<mok0> hyperair: it makes sure you only call the script from $topdir
<hyperair> mok0: but you're supposed to be able to call it from other directories
<hyperair> mok0: and it's supposed to dump the orig.tar.gz into your current directory, no matter waht it is
<mok0> hyperair: that way it will work right no matter what dir it's called from :-)
<hyperair> =\
<mok0> uscan will drop it in $topdir/..
<hyperair> yeah
<hyperair> uscan drops it in $topdir, and then get-orig-source does its fancy stuff wherever it likes, dumps your resulting orig.tar.gz into your current dir, and then cleans up
<hyperair>    This target fetches the most recent version of the original source package from a canonical archive site (via FTP or WWW, for example), does any necessary rearrangement to turn it into the original source tar file format described below, and leaves it in the current directory.
<hyperair>  This target may be invoked in any directory, and should take care to clean up any temporary files it may have left.
<hyperair> there we go
<mok0> hmm
<hyperair> mok0: anyway there's a new upload
<mok0> hyperair: ok thanks
<hyperair> my my what a pretty sunrise
 * hyperair yawns
<tritium> Hello.  If my launchpad team membership expired, is there a way to reactivate it?  I understand that MOTUs can activate/deactive themselves now?
<mok0> tritium: AFAIK you need to apply for MOTUship once more
<mok0> tritium: Of course you could try writing MC asking to have your MOTUship reactivated
<tritium> mok0: I may do that.  You're not aware of any changes to the team membership rules to allow activating/deactivating at will, as schedules permit?
<mok0> tritium: no
<tritium> mok0: ok, thanks.
<hyperair> mok0: i need to document the repackaging in debian/changelog?
<hyperair> mok0: i thought it was only necessary in debian/copyright
<mok0> hyperair: it's a bit confusing. Honestly, I don't think it logically belongs in copyright, but it's in the policy.
<maco> is it intentional that there's no spim in jaunty, or has it just not been gotten around to yet?
<mok0> hyperair: however, if it's in changelog, it's certain to be noticed by other people who come along and do stuff to the package
<hyperair> mok0: i see. okay then. there's a new upload
<mok0> hyperair: f.ex. if upstream suddenly provides a tar.gz file, it is good to be able to see there what you did
<hyperair> mok0: ah. right.
<mok0> hyperair: if you promise to go to bed, i will ack it :-)
<hyperair> mok0: heh yeah i'll go to bed now
<maco> oh....its not in intrepid either. what happened to spim?
<hyperair> good uh morning
<mok0> heh
<mok0> Midnight here, I gotta go soon too
<hyperair> heh.
<mok0> Have to get up early
<tritium> Good night, mok0.
<hyperair> bye
<Chris`> mok0: Thanks for that mail to the mailing list :D
#ubuntu-motu 2009-01-23
<dnyy> Anyone care to help me figure out why I'm getting these errors while trying to build a package?
<nhandler> dnyy: What errors?
<dnyy> http://pastie.org/368082 It's the whole log, but the errors are more towards the bottom.  Some saying it can't find pkg-config and others saying theirs errors in the source when I'm almost certain there's not. ;/
<dnyy> This is my first time building, so I'm a bit clueless as to what all these errors are trying to tell me.
<nhandler> dnyy: It does look like it is a problem in the source
<dnyy> it built/installed good using debuild though, and without trying to include the dependencies. :/
<dnyy> it's just when trying to add those that i get the errors (with both pbuild and debuild)
<nhandler> dnyy: What do you mean by "and without trying to include the dependencies"?
<dnyy> to use the app you need to have libmad0-dev and libao-dev installed, but adding those to /debian/control gives me that huge list of errors.
<nhandler> dnyy: The Dependencies should not affect whether or not the package builds. Only Build-Depends should be installed by pbuilder to build the package
<dnyy> Hm, so I wonder why it's not building then. Maybe I'm making an error in the way I try to include the dependencies(syntax and whatnot), or does that not matter since it doesn't use those while building?
<nhandler> dnyy: It shouldn't matter. Are your Build-Depends correct?
<tomhinkle> I'm an upstream developer interested in releasing .debs for my users (Ubuntu packages are too slow for those who want the bleeding edge, and .debs are convenient packages for many users to test out). My app is packaged in ubuntu, but I can't seem to figure out where the debian/ directory lives in launchpad... where do I find the packaging stuff?
<dnyy> nhandler: Can I paste you the control file?
<maxb> dnyy: It would appear from your paste that it is trying to run pkg-config, but failing. You should add a Build-Depends for it
<dnyy> The build-depends is where I'm putting the 'libmado-dev, libao-dev, etc
<dnyy> Hm, I'll give that a go real quick.
<nhandler> tomhinkle: Go to launchpad.net/ubuntu/+source/SOURCENAME
<nhandler> dnyy: Yeah, go ahead and pastebin it
<dnyy> http://pastie.org/368414
<nhandler> dnyy: Are those packages really needed for the package to build?
<dnyy> Well, they are listed as so in the source package from the ubuntu repos.  This is the newer/dev version.
<dnyy> autoconf and automake made me wonder, but I figured if it was included in the source they must be. :/
<nhandler> dnyy: If the package is already in Ubuntu/Debian, there is no need to package it again to get a newer version added
<dnyy> Well I'm packaging it for personal use and for the crunchbang (ubuntu-based distro) repos.
<nhandler> dnyy: I would contact the Debian Maintainer and see if he has plans to update the version of shell-fm in Debian. If they do that, we can sync the changes
<nhandler> dnyy: If you are packaging it for personal use, you still don't need to start from scratch
<dnyy> Well how could I go about updating the older deb and repackaging?
<nhandler> dnyy: Download the source package from Jaunty using dget, pull-lp-source, or apt-get source. Then, download the .tar.gz for the newer upstream version. Then, use uupdate.
<dnyy> Hm, doing that now then.  What do you mean use update? ;o
<nhandler> uupdate is a tool in the devscripts package
<dnyy> kk, looking it up
<dnyy> does the tar.gz of the upstream need to be in the same folder as the source? i notice i have to be in the source top dir to run uupdate or will it look above the current dir?
<nhandler> I normally run uupdate from the source directory (the one that contains the debian directory). I run it like 'uupdate ../foo_x.y.orig.tar.gz'
<dnyy> aah, kk
<dnyy> then just pbuild the new dir?
<nhandler> Then cd into the new directory and make sure the changelog is correct. debuild -S -sa and build in pbuilder
<maxb> wow, this package sure has changed a lot since the jaunty version
<nhandler> maxb: What package?
<maxb> shell-fm, that dnyy is working on
<nhandler> maxb: Ok. I didn't even look at the changes. I just saw that we auto-synced from Debian
<dnyy> what version is in the jaunty repos? same as the intrepid ones?
<maxb> lyes
<nhandler> Yes dnyy
<nhandler> svn20071125.r282-1
<dnyy> ah, yuh
<dnyy> I didn't know 'til yesterday it had been worked on so much
<tomhinkle> nhandler: Thanks for the pointer. I think I've found what I needed...
<nhandler> Glad to hear that tomhinkle
<dnyy> nhandler: http://pastie.org/368425 Is my fakeroot broke?  I seem to get a lot of errors about it, too. :/
<nhandler> dnyy: Can I see your debian/rules?
<dnyy> http://pastie.org/368428
<maxb> dnyy: No, the problem is that the package has *completely* changed its buildsystem upstream, and debian/rules needs a significant overhaul
<dnyy> ah, well shucks.  I don't think I'm anywhere near knowledgeable enough to do that.
 * nhandler seems to remember suggesting contacting the DM
<dnyy> :P
<dnyy> seems like that's what i'm gonna have to do.
 * maxb has been idly fiddling with it just now, following along with the problems, let me paste a debdiff of what I've got
<dnyy> kk.  I'd really like to do this without getting the DM to do it, as it'd be a nice learning experience.
<maxb> http://pastie.org/368432
<maxb> it's a start
<maxb> there's obvious things that I haven't touched, like the fact that the upstream ships a shell-fm.1 manpage now, which would need to be reviewed against the one shipped in debian/
<maxb> upstream has also apparently dropped the example rc file that was previously shipped
<maxb> and they could really do with being told that they're misusing DESTDIR in a
<maxb> * and they could really do with being told that they're misusing DESTDIR against all common convention
<dnyy> yeah. this is all pretty new to me, but basically I need to go through and see whats different between the uupdate version and the upstream version, and clean things up in the uupdate to match the upstream?
<maxb> dnyy: erm, I didn't really understand that sentence
<dnyy> haha, I'm horrible at explaining myself.  What I mean is; In order to get things working, do I need look through the 0.4 source and the 0.6 source, find the difference, and then remove them from the package that uupdate creates?
<dnyy> remove the differences, i mean
<maxb> uhm. If you remove the differences that the update creates, you'll be back at 0.4
<dnyy> oh wait, duh. ;(
<dholbach> good morning
<fabrice_sp> Good morning dholbach. a bit early today ;-)
<dholbach> hi fabrice_sp
<dholbach> yeah, woke up early today :)
<fabrice_sp> no real activity here at this time :-)
<ScottK> dholbach: It's REVU day.  Please dive in.
<dholbach> ScottK: I try to do a few today, but I'm completely drowning in work right now :-/
<dholbach> I like the discussion on the MOTU list about REVU and automated checks - that'd be awesome
<fabrice_sp> And if you want to begin with an already advocated one, you can have a look at dvdstyler (http://revu.ubuntuwire.com/details.py?package=dvdstyler). This package only miss one advocate :-)
 * persia reviews foo-plugins
 * persia reviews gebabbel
<persia> Anyone running Kubuntu jaunty and has a GPS unit?
<ScottK> I think most of the likely candidates are sleeping.
<persia> Probably.  Pity, as I can't test this and don't like to advocate without having tested.
<coppro> http://revu.ubuntuwire.com/details.py?package=metakit
<ScottK> persia: I found one with Kubuntu Jaunty, but not a GPS.
<ScottK> persia: rgreening says hi.
<persia> heh :)  It's a GPS tool though, and as we've so few of those that work, I'd rather it actually work.
<persia> Worst case, maybe mok0 tested it for the previous advocation, in which case I can push.
<ScottK> Perhaps you can at least make that assumption ...
<persia> I'll still be about when mok0 wakes: a few hours of double-advocation pre-upload won't be significant when compared against the months it's been in queue
<tritium> Is there a simple example of source package that builds both a binary and shared library using CDBS that you could recommend?
<persia> tritium, wildmidi does that
<tritium> persia: thanks!
<persia> tritium, I can't promise it's a perfect example, but at least it's an example
<tritium> I'm sure it's better than nothing.  :)
<hyperair> mok0: sorry i forgot to upload bansheelyricsplugin this morning. i missed out the 'revu' argument to dput. realized it when i woke up
<mok0> hyperair: yeah I noticed, will take a look a bit later today
<didrocks> morning
<somaunn> didrocks: hi
<didrocks> Hi somaunn
<verwilst> hellow
<verwilst> if i have a package version like -1.0-1
<verwilst> and i want to make my own changes and make it be considered higher than the original
<verwilst> -1.0-1~verwilst1 for example won't cut it, right?
<StevenK> -1?
 * StevenK twitches
<DktrKranz> 1.0-1~verwilst1 is lower than 1.0-1
<persia> verwilst, Right.  Try +verwilst1
<StevenK> -1.0-1~verwilst1 will be lower, since ~ sorts lower than ''
<saschpe> Hi y'all, I uploaded a new upstream version package for "crawl" and request approval, as I'm no MOTU. Bug no.: #320142
<iulian> bug #320142
<ubottu> Launchpad bug 320142 in crawl "Dungeon Crawl Stone Soup (crawl) new upstream version (0.4.5) needs packaging" [Undecided,In progress] https://launchpad.net/bugs/320142
<verwilst> persia: is +verwilst1 debian-legal? :)
<persia> verwilst, How do you mean?  The tools support it.  The ftp-masters would get grumpy if you uploaded it, and tell you to use -1.1 and do an NMU, or work with the maintainer.
<iulian> saschpe: You don't need to upload it to revu, just upload diff.gz to launchpad.
<saschpe> iulian: oops, sorry. thought I'd read that that's the way to do
<quadrispro> hi maxb ! following your good suggestions, I've uploaded a new w-scan package. I want to thank you for your feedback, let me know if you see something wrong :)
<quadrispro> maxb -> http://revu.ubuntuwire.com/details.py?package=w-scan
<Quintasan> The pbuilder installs same -dev packages everytime I compile something, this is done on purpose or I'm doing something worng?
<persia> Quintasan, Assuming you're compiling similar things, it's on purpose.
<persia> If this takes a while, or you have download caps, you might consider using a package cache so pbuilder only downloads new ones.
<Quintasan> persia: thanks
<broonie> The download cache is the default.
<persia> Quintasan, The reason it does this is that it downloads the set of packages listed in Build-Depends (and their dependencies) to build the package, and let the packager specify the target environment.  This takes a little longer, but allows the packager to ensure the builds are repeatable.
<snuitje> Hello, I don't know if this is the right place to ask, but I have to backport packages from Jaunty to 8.04 and I was wondering if there's already a tool that can help automating it
<Hobbsee> prevu
<snuitje> kewl, thanks =)
<Hobbsee> no guarentees on it actually working, but it'll try
<thekorn> hi motus', I try to dive into packaging a python tool, and I get this error:
<thekorn> E: launchpad-shell source: missing-python-build-dependency
<thekorn> so my question is: what's missing there?
<thekorn> I compared my control file to other packages, some have 'python' and some have 'python-all-dev'
<thekorn> which one is the way to go?
<POX> you're missing one of: "python{,-dev,-all,-all-dev} (>= 2.3.5-11)" in Build-Depends: or Build-Depends-Indep:
<POX> -dev if you're building arch:any package, -all if you're building a module
<POX> python (without -add or -dev) if it's application
<POX> if it's arch:any, python-all-dbg should be in Build-Depends: as well (unless you're not building -dbg package)
<thekorn> thanks POX, so I will go with python for this small app
<POX> thekorn: lintian -i *changes
<Tonio_> hi there...
<Tonio_> anyone free to give a look at http://revu.ubuntuwire.com/details.py?package=k3b
<Tonio_> thanks :)
<thekorn> POX, no output, so it's working now, thanks again
<directhex> Tonio_, ehm... k3b's already in the archive, surely?
<directhex> http://packages.ubuntu.com/source/jaunty/k3b
<POX> thekorn: I meant lintian will be more verbose if you turn verbose mode on (-i)
<Tonio_> directhex: yeah, but that's major packaging rewrite, as this is the kde4 version
<Tonio_> directhex: I could upload it like this, but a second pair of eyes is always welcome :)
<directhex> they should rename it k4b imho ;)
<Tonio_> directhex: goob point :)
<POX> thekorn: of use lintian-info :)
<POX> s/of/or
<thekorn> POX, hmm, is there a way to pass this -i through debuild?
<POX> thekorn: lintian-info -t missing-python-build-dependency
<POX> debuild has a --lintian-opts
<thekorn> wow, that's nice
<saschpe> directhex: k3b means "KDE Burn Baby Burn" and is not directly related to KDE3 :-)
<directhex> saschpe, so rename it "KDE Better Burn Baby Burn" anyway!
<snuitje> what's the best way to keep updated on new uploads of certain packages to certain releases, like intrepid and jaunty?
<snuitje> so i can keep feeding prevu
<snuitje> i tried using package-import.ubuntu.com but the server is kinda shoddy
<snuitje> it gives regular proxy errors
<james_w> snuitje: launchpad will soon provide two things, package feeds, and package branches
<snuitje> package feeds as in rss?
<james_w> the first will allow you to subscribe to feeds of uploads for packages
<james_w> the other will be pretty much the same as what you are trying to do but more robust
<snuitje> kewl :)
<snuitje> well thanks, i'll keep an eye out :)
<persia> snuitje, In the meantime, there are the -changes mailing lists (see lists.ubuntu.com) which send an email for each upload.
<snuitje> okay
<snuitje> btw, woohoo prevu worked flawlessly :) already installed my 1st automatic backport, goodbye pdebuild and friends (except for ppa packages) =)
<maxb> prevu is just a thin wrapper on pbuilder
<snuitje> yes, but looking up the dsc url, then doing the dget -x, pdebuild etc dance is such a hassle
<maxb> Really, I'd recommend learning to use pbuilder directly, because then you can use cowbuilder, which vastly speeds up the process by eliminating the tar.gz unpack step
<maxb> snuitje: "pull-lp-source mypackage jaunty"
<hyperair> jpds: ping
<snuitje> hm, i dont have that...
<hyperair> jpds: thanks for the comments. regarding sigx, i've fixed removed NEWS from debian/docs, and shifted the rest of the stuff from debian/docs to debian/libsigx-2.0-doc.docs. there's a new upload at revu. if you could look at it, i'll be very grateful =p
<maxb> snuitje: apt-get install ubuntu-dev-tools
<snuitje> maxb: i did, but it must've come after 8.04
<snuitje> so i'll prevu it ;) ;)
<snuitje> prevu even managed to build despite tha fact that the new packages use a later debhelper, now that's good work
<maxb> *shrug*. That just comes from having the package available in hardy-backports for just this reason
<snuitje> maxb: of course, i haven't thought of that >.< thanks, i upgraded the package with an apt preferences exception :) thanks!
<slytherin> jdong: any idea how to disable the auto update in azureus?
<snuitje> Hello, I prevu'ed ubuntu-dev-tools and ran apt-get update, but apt-get dist-upgrade wants to keep it at the 8.04 version, how can apt be configured to upgrade to prevu packages?
<snuitje> btw, it did work for another package
<snuitje> no wait
<snuitje> yes, it did work for 2 other packages
<snuitje> lsb and lighttpd
<snuitje> (lsb-release)
<slytherin> snuitje: what is prevu?
<snuitje> it's a tool to backport packages from Ubuntu+1 to Ubuntu or Ubuntu-1, etc
<vorian> its a pbuilder wrapper
<slytherin> snuitje: oh, I was not aware of that. What is the version number you have specified for the backported package?
<snuitje> the version numbering is automatic, but it's 3.2-14ubuntu2~8.04prevu1
<snuitje> and the 8.04 version is 3.2-4ubuntu1
<slytherin> snuitje: is the backported package available in some repository?
<snuitje> of course
<snuitje> prevu does that ^-^
<snuitje> oh wait
<snuitje> the new version is 0.59~8.04prevu1 the old one is 0.30
<slytherin> snuitje: I don't see a problem here with version number. Have you verified if all the dependencies are present in hardy?
<snuitje> OIC, why didn't i think of that -_-'''
<snuitje> python-launchpadlib is missing ^-^
<snuitje> ty
<binarymutant> if anyone has anytime to review my package, http://revu.ubuntuwire.com/details.py?package=charm, I would be greatly appreciative. Thanks :)
<mok0> binarymutant: I'll bite
<mok0> binarymutant: what's it for?
<binarymutant> charm is a blogging software for the console/terminal
<mok0> binarymutant: ah! Charming! :-)
<binarymutant> :)
<mok0> binarymutant: wow, you've been through quite many cycles
<binarymutant> yeah 2 versions, I had to get a couple of patches uploaded to it
<mok0> binarymutant: you know how to use the patch system?
<binarymutant> yes, I had been using dpatch but took it off because my  patches were included in the source
<mok0> binarymutant: I
<Chris`> Any revu'ers free to check my package? I require just one more advocate :D
<mok0> binarymutant: I'd like you to include a patch then :-)
<binarymutant> :*(
<mok0> binarymutant: ... to get it perfect
<binarymutant> right, what is it?
<mok0> binarymutant: there's a number of hyphen-used-as-minus errors in upstream's manpage
<mok0> I paste a script to fix it: http://pastebin.com/f11c8da4e
<binarymutant> what's hyphen-used-as-minus mean?
<mok0> binarymutant: the minus character is used for options, for example --help, that needs to be typeset in nroff like this \-\-help
<mok0> binarymutant: you can't see it when the man page is shown in a terminal, but if it's printed you can
<binarymutant> in charm.1?
<mok0> right
<vadi21> Hi, I have a quick question about .desktop files - how can I make one use an .svg? I placed the svg with the corresponding name into /usr/share/icons/hicolor/scalable/apps, .desktop into /usr/share/applications, but it does not want to associate the picture.
<mok0> binarymutant: just run the fixhyphens < charm.1 > charm.fixed.1 and make the patch
<binarymutant> k, I see it the double -- were hyphened but not the single -
<binarymutant> anything else you can see mok0 ?
<mok0> I
<mok0> binarymutant: I've posted a message on the REVU page. Looking good...
<hyperair> mok0: http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin =D
<binarymutant> thanks mok0
<mok0> hyperair: ha! ok
<hyperair> mok0: =D thanks
<mok0> hyperair: there!
<hyperair> mok0: thanks =D
<mok0> Ah I see MOTUs have been picking the low hanging fruit :-D
<slytherin> what is the best way to merge a package from experimental?
<mok0> slytherin: you mean without a grab-merge set?
<Chris`> mok0: Busy? :D
<mok0> Chris` ready for some reviewing action, what have you got?
<slytherin> mok0: yes. I mean experimental merges are not available on MoM. ANd I want to avoid manual work as much as possible.
<Chris`> http://revu.ubuntuwire.com/details.py?package=grdc & http://revu.ubuntuwire.com/details.py?package=grdc-gnome
<hyperair> is any motu free to review bansheelyricsplugin? it's already got one advocate: http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin
<Chris`> mok0: All I need is one more advocate (if it is good enough)
 * mok0 wonders why Chris`insists on having a backslash in his nick...
<Chris`> mok0: A grave accent? ;p
<Chris`> Just Ch<TAB> :)
<mok0> a nuisance to type....
<Chris`> My name used to be `Chris :)
<mok0> Ch <Tab> = chillywilly Chipzz Chris` chrisccoulson
<mok0> Uhuh now they all think the message is for them ;-)
<chrisccoulson> yes
<Chris`> Do Chr<TAB>
<mok0> sorry chrisccoulson
<Chris`> I will be the first :)
<chrisccoulson> can i have that last 5 seconds of my life back? lol
<Webspot> Hi. If I want to package something from a git repo, what should I use as the version number?
<slytherin> Webspot: something like a.b+git<revision>
<slytherin> mok0: any idea?
<mok0> slytherin: not really
<liw> Webspot, many people like to use the date; git doesn't really have revision numbers (it uses sha-1 instead)
<mok0> slytherin: I don't know what software is used to generate those merge sets
<Webspot> liw: Yeah. I thought the revision looked too long to use as a version number. Thanks.
<liw> Webspot, more important than length is that the sha-1's aren't behaving like version numbers, you can't compare which one is the newer version
<Webspot> liw: Oh yeah. So do I use a.b+git<date>?
<slytherin> NCommander: any plan to update linux-image for powerpc?
<mok0> Damn revu is slow
 * jpds checks load levels.
<jpds> OK; it sure is using a lot of its memory.
<mok0> jpds: what's it doing?
<liw> Webspot, a.b+git<date>.<32bitid> might be most illuminating
<Webspot> liw: Ok. Thanks for your help :)
<jpds> mok0: The usual, apache, postgresql, helper scripts.
<jpds> mok0: I think this is more concerning tho: http://paste.ubuntu.com/108617/
<mok0> Chris`, you know how to use the patch system?
<Chris`> mok0: Not entirely but wiki.ubuntu.com exists to serve
<mok0> Chris`, it's a t-i-n-y problem, not a blocker, but if you want to learn how to use the patch system...
<Chris`> OK...
<jpds> include /usr/share/cdbs/1/rules/simple-patchsys.mk
<ScottK> man cdbs-edit-patch
<mok0> Chris`,  desktop-entry-contains-encoding-key /usr/share/applications/grdc.desktop:3 Encoding
<Chris`> mok0: What does that mean?
<mok0> Chris`, there's an "Encoding" statement in there that is deprecated
<mok0>  Chris` very common error
<Chris`> So what should be done?
<mok0> Chris` I can't seem to locate the .desktop file in the tree... know where it is?
<Chris`> "No Name"
<Chris`> Is the config file
<Chris`> but no .desktop
<mok0> Chris`, it's in src/grdc.desktop.in, it gets processed by configure to generate the final version
<Chris`> grdc.desktop.in doesn't exist for me :-/
<mok0> Chris`, in src/ ?
<Chris`> When I run search, nautilus displays it as "No Name"
<Chris`> ls found it though
<mok0> Chris`, look using ls
<Chris`> I am in the file using vim
<Chris`> Any alterations?
<mok0> Chris`, wait, not yet
<mok0> Chris`, instead, edit your .bashrc file, and insert "export QUILT_PATCHES=debian/patches"
<Chris`> Done
<mok0> Chris`, source .bashrc
<Chris`> Is that the same as . .bashrc?
<Chris`> Done anyway 6
<Chris`> ^
<mok0> $HOME/.bashrc
<Chris`> chris@chris-laptop:~$ $HOME/.bashrc
<Chris`> bash: /home/chris/.bashrc: Permission denied
<mok0> Chris`, now cd grdc-0.3
<mok0> source $HOME/.bashrc
<Chris`> Yeah I've done that
<mok0> ok
<mok0> Chris`, now cd grdc-0.3
<Chris`> Yep
<mok0> mkdir debian/patches
<Chris`> Done
<mok0> touch debian/patches/series
<Chris`> Yeah
<mok0> Try: quilt series
<Chris`> chris@chris-laptop:~/motu/src/grdc-0.3.0$ quilt series
<Chris`> chris@chris-laptop:~/motu/src/grdc-0.3.0$
<Chris`> No output?
<mok0> right
<mok0> now we need to add a patch
<Chris`> Sounds fun :)
<mok0> so you go "quilt add 01-fix-desktop-entry.patch"
<mok0> so you go "quilt new 01-fix-desktop-entry.patch"
<mok0> sorry
<Chris`> Ok done
<mok0> now you add (register) a file to the patch:
<mok0> quilt add src/grdc.desktop.in
<Chris`> Ok done again
<mok0> Good, now you can edit the desktop.in file and remove the Encoding line
<mok0> After that, "quilt refresh"
<Chris`> Remove the entire line from src/grdc.desktop.in?
<mok0> yes
<Chris`> Ok done
<mok0> quilt refresh?
<Chris`> Yeah
<mok0> did it say anything?
<Chris`> Refreshed patch 01-fix-desktop-entry.patch
<mok0> yay
<mok0> now look in the dir debian/patches
<mok0> there should be a patch file and a series file
<Chris`> Yeah two files
<mok0> try "quilt pop"
<Chris`> Removing patch 01-fix-desktop-entry.patch
<Chris`> Restoring src/grdc.desktop.in
<Chris`> No patches applied
<mok0> Yes!
<mok0> quilt push
<Chris`> Now at patch 01-fix-desktop-entry.patch
<mok0> Great, it works
<Chris`> Sounds cool :)
<mok0> All you need to do now is to add something to rules and to control
<Chris`> Ok sure
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek - last day going to kick off in #ubuntu-classroom now!
<mok0> In debian/rules: include /usr/share/cdbs/1/rules/patchsys-quilt.mk
<mok0> Chris`, and in control, add quilt to build-depends
<Chris`> Et voilÃ 
<mok0> Chris`, in changelog, write "Patched to fix desktop file"
<mok0> or something
<ScottK> Chris`: And then when you can't remember how to do this remember than Googling for quilt patch debian first hit gives you a good howto.
<mok0> ... and you get a lot of hits on sewing patchwork and quilt :-)
<Chris`> How does dch -i work?
<Chris`> I get changelog.dch
<Chris`> But how to apply it?
<mok0> er, just vi debian/changelog
<mok0> dch -i adds a new version afaik
<broonie> Chris`: Just edit the file dch -i gives you, when you quit the editor dch will overwrite debian/changelog with the new file.
<Chris`> Alright uploading to revu, thanks mok0, ScottK & broonie
<mok0> Chris`, finally, edit debian/control again
<Chris`> Ah what? :)
<Chris`> What I am editing in control?
<mok0> Chris`, remove "a" in "a remote...." in the summary
<Chris`> Ok changed :)
<mok0> General note on package synopses (one-line descriptions:) they should start in l
<mok0> owercase ("extract cluster data" versus "Extract cluster data",) and no precedin
<mok0> g articles ("filter for generating HTML logs" versus "A filter for generating HT
<mok0> ML logs.")
<Chris`> I need to get jpds to give me the thumbs up again now :p
<Chris`> After revu showsit
<mok0> Chris` if he's around
<Chris`> Doesn't look like :(
<mok0> Chris` I good with his advocacy,
<Chris`> http://revu.ubuntuwire.com/details.py?package=grdc --- Final stuff has been changes *Searches for advocates*
<mok0> Chris` I don't think he'll remove it just because you've fixed some minor probs
<jpds> mok0: Upload if you want to.
<mok0> jpds: great thx
<mok0> when I get the last fixes from Chris`
<Chris`> mok0: Yeah they've all been submitted since the last comment
<Chris`> 17:09
<mok0> Chris`, just to repeat what you've done: https://wiki.ubuntu.com/PackagingGuide/Howtos/Quilt
<Chris`> The time server is a bit out though, thanks mok0
<mok0> I see it
<mok0> Chris` you see, with the patch system, it is possible to fix all kinds of strange stuff in upstreams code
<mok0> ... and you still keep your changes in debian/
<Chris`> mok0: Pretty neat function
<mok0> yeah
<mok0> The other patch system is dpatch, but it requires a header on the patches which is extra trouble
<refdoc> pochu - are you around?
 * Laney likes the sound of piuparts
<refdoc> I am trying to find out about libsword, gnomesword etc packages
<refdoc> and someone said you were the last maintainer
<refdoc> or uploader
<Chris`> mok0: Did you say that you were uploading now or something?
<ScottK> refdoc: Did you send us mail yesterday?
<mok0> Chris`I am
<mok0> Chris`doing final test build right now
<binarymutant_> is it readme.source for info on patch systems?
<Chris`> mok0: Cool awesome :)
<Chris`> mok0: Will I get Karma points for fixing the LP bug?
<Chris`> Or don't they count?
<ScottK> They count.
<mok0> Chris`, I am not sure
<mok0> ah
<Chris`> Cool, I've got ~700 so far
<mok0> But they subtract some every day
<refdoc> Scottk
<refdoc> I did
<Chris`> Only if your karma is over 6months old, mine isn't :D
 * Laney eyes the new application process
<Chris`> I've been gaining like 200day over the past 2 days
<ScottK> refdoc: This is the team that maintains those packages for Ubuntu.
<refdoc> Great
<refdoc> I thought so.
<ScottK> refdoc: That and about 10000 other source packages.
<refdoc> I know :-)
<refdoc> hence the personal approach :-)
<ScottK> refdoc: One point from your mail: Not updating modules from an external source is considered a feature and not a bug in Debian and Ubuntu.
<refdoc> There is a misunderstanding
<refdoc> our "modules" are texts - ebooks
<ScottK> Ah.
<refdoc> we have 300 or 400 of them
<refdoc> and growing
<refdoc> some sell them
<refdoc> this is like project gutenberg
<ScottK> OK.  That wasn't clear in the mail.
<refdoc> you would not want their 50.000 odd books in the repo?
<ScottK> No.
<ScottK> So you have two choices:
<refdoc> so, no it is not about software update
<ScottK> 1. Convince someone active in Ubuntu to update your stuff.
<ScottK> 2.  Do it yourself.
<refdoc> either, indeed.
<sistpoty|work> hi folks
<ScottK> txwikinger: Are you interested in helping refdoc with updating sword stuff?
<ScottK> Hi sistpoty|work
<sistpoty|work> hi ScottK
<Chris`> ScottK: Is it easy?
<ScottK> Chris`: Dunno.  I haven't looked at the packages.  Sometimes it's trivial, sometimes it's painful.
<Chris`> ScottK: What's he need updating?
<refdoc> We have some packages which work on new installs. I am jkust not sure how much they fullfill all rules
<refdoc> libsword from 1.5.9 to 1.5.12
* sistpoty|work changed the topic of #ubuntu-motu to: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Grab a  merge: http://dad.dunnewind.net http://merges.ubuntu.com | http://qa.ubuntuwire.com/uehs | http://revu.ubuntuwire.com - Go review! :)  | next MOTU Meeting: Fri, Jan 30 12.00 UTC
<refdoc> gnomesword to 2.4.1
<Chris`> refdoc: I'll give it a shot if you wish?
<refdoc> I would be delighted!
<refdoc> what do you want me to do?
<refdoc> I am new to this
<binarymutant_> if anyone has time on their hands I would appreciate a review on my package, http://revu.ubuntuwire.com/details.py?package=charm Thanks :)
<Chris`> refdoc: Are you the upstream author?
<refdoc> I am one of the lot - I am not a programmer
<refdoc> but do documentation, translation etc
<refdoc> but I got fed up
<refdoc> and hence approached yoyu
<refdoc> I have svn access to a lot
<refdoc> and can do things
<Chris`> Are we talking about libsword6 in the repos?
<refdoc> yes
<Chris`> Ubuntu ^
<refdoc> and gnomesword and bibletime and diatheke
<Chris`> refdoc: Is there a LP bug open?
<refdoc> LP?
<Chris`> LaunchPad
<refdoc> there are a few
<refdoc> all either referring to the fact that our programmes are old
<refdoc> or stating that our (old) programmes have bugs
<refdoc> indeed
<Chris`> refdoc: Find me one so I can change to "work in progress"
<ScottK> I can't find a good wiki page on getting upgrades in.
<mok0> ScottK, you mean a guide telling you how to go about it?
<ScottK> refdoc: The short version if you have packages prepared is to file a bug against the package in Launchpad, attach the .diff.gz of the package to the bug, tag the bug upgrade, and subscribe the ubuntu-universe-sponsors team to the bug
<ScottK> mok0: Yes.
<ScottK> mok0: We have a stunningly detailed page on merges, but nothing on upgrades.
<refdoc> ScottK https://bugs.launchpad.net/ubuntu/+source/gnomesword
<ScottK> Yes.
<mok0> ScottK, huh? strange
<ScottK> For each package.
<ScottK> mok0: That or I'm just not able to find it.
<mok0> ScottK, I can't remember ever seeing one either
<refdoc> ok ScottK I will go ahead and do this
<refdoc> probably on Sunday night as I am now at work
<refdoc> That is brilliant. Thanks
<quadrispro> maxb, i did a little error, now w-scan builds well :)
<refdoc> Chris, sorry got mixed up with responding : https://bugs.launchpad.net/ubuntu/+source/gnomesword
<refdoc> these are the bugs againts GS.
<refdoc> The best packages we have are in http://dominique.corbex.net/gnomesword/
<Chris`> refdoc: Have you got a direct link to the package tarball for libsword?
<Chris`> This crosswire site is hard to navigate
<refdoc> there are packages for bibletime, libsword and GS
<Chris`> No matter; found it
<refdoc> Chris, wharp is one of us, he just joined
<refdoc> and my connection is flaky
<wharp> ok
<refdoc> I thinK I just missed a whole lot
<wharp> I was going to ask about replacing the old packages with the renamed packages that will result from the name change
<Chris`> mok0: You there?
<Chris`> mok0: I used the POD format and then added POD rules to the debian/rules file, how come there is no manpage?
<Chris`> wharp: What packages have changed name?
<wharp> Chris`: as of yet, none have, however, gnomesword is likely going to change project names
<Laney> The new package will have to go through NEW, but it shouldn't be a problem
<Chris`> wharp: I believe that the gnomesword package will then change to a dummy package but then relies on the new one so it downloads and installs the new one instead
<mok0> binarymutant_: +1 from me
<binarymutant_> hey hey thanks! :) :)
<mok0> Anymore REVU hopefuls lurking around?
<wharp> Chris`: are you the same Chris who just assigned himself to the Ubuntu bug?
<Chris`> wharp: Yep
<wharp> Chris`: do you need anything from us, and if so, what?
<Chris`> wharp: No nothing is required, I just need to see what the older deb contributor did and I'm checking if the same applies via lots of experimentation
<wharp> ok
<Chris`> I'm building a test .deb atm for libsword6
<wharp> ok, then you did find the tarball on crosswire.org?
<wharp> refdoc mentioned you were looking for it
<Chris`> wharp: Yeah after some navigation ;
<wharp> good, because I was looking for it for you and I sure as heck don't see it
<wharp> oh, there it is
<Chris`> wharp: Yeah that's what I feltl ike too
<wharp> Chris`: do you do packaging for Debian also, or just Ubuntu?
<Chris`> wharp: Just Ubuntu but I believe that my efforts go over to Debian too
<wharp> hopefuly so
<iulian> ubuntu-devel
<iulian> Blah
<Chris`> mok0: You there again? I have a package to double-check for upload http://revu.ubuntuwire.com/details.py?upid=4616
<mok0> Chris`I am here, looking
<Chris`> mok0: There is something strange, in the .deb, the manpage exists...
<mok0> yes?
<Chris`> But you said linitian said that it doesn't?
<mok0> Oh you wrote it in .pod format
<Chris`> Yeah it's the only one that I feel safe in :P
<mok0> Chris`educate me on how it gets installed
<Chris`> On POD or the manpage of the package?
<mok0> afaics the manpage is created in $topdir
<mok0> I can't see it being installed...
<Chris`> usr/share/man/man1/grdc-gnome.1.gz?
 * mok0 building now
<Chris`> mok0: I managed that in the debian/rules file, so I can show what I have done in debian rather than branching outwards if that is what you meant?
<mok0> Chris`hang on
<mok0> oh yes it's there
<fabrice_sp> Hi. Anyone to review dvdstyler, a dvd authoring tool (http://revu.ubuntuwire.com/details.py?package=dvdstyler). It has already been advocated by mok0.
<mok0> Chris`, Lintian complains because it wants a manpage for the app grdc-applet
<Chris`> mok0: Oh yeah, did I change the name of it?
<mok0> ... and the man page you've writen is grdc-gnome :-)
<Chris`> Blame jpds :)
<mok0> heh
<mok0> Never mind, I will fix & upload
<Chris`> Oh cool ok thanks
<jpds> I wanted to call it gnome-applet-grdc.
<jpds> RainCT: How can I merge accounts on REVU?
<Chris`> mok0: Oh, over-rides, using that quilt patching system I guess?
<jpds> RainCT: Tonio_ is having problems with his MOTU status.
<jpds> RainCT: And scripts/alter_user.py has disappeared.
<jpds> RainCT_ or RainCT__: please see above.
<mok0> Chris`, what overrides?
<Chris`> mok0: The .so versions
<Chris`> http://revu.ubuntuwire.com/details.py?upid=4567
<Chris`> mok0: Oops wrong reviewer
<Chris`> Oh right tonio has uploaded it, I misread what he said too!
<mok0> Chris` the problem from 18.1 is that you need to include quilt build-deps because you use the include ... patchsys-quilt.mk in rules,
<mok0> Chris` but if you're not patching, you might as well remove both
<Chris`> mok0: Where can I see what packages have been recently uploaded?
<Chris`> i.e. grdc?
<mok0> https://edge.launchpad.net/ubuntu/jaunty/+queue
<Chris`> Ah great thanks
<LaserJock> quick lunch
<Chris`> My first 3 packages got uploaded today ;D
<mok0> Chris`: a good day
<Chris`> mok0: Very much so :)
<bddebian> Anyone good with Gnome/Gtk2?
<tritium> superm1: update on hdhomerun-config: In order to build the gui, I'm going to need to build a lib package from libhdhomerun as well, and not just hdhomerun-config.  I should have something tonight or tomorrow.
<mok0> HMPF. Why did the FSF have to move?
<bddebian> heh
<mok0> Am I the only one who finds the README.source file comletely redundant?
<bddebian> Nope
<binarymutant> :)
<LaserJock> if the contents are redundant
<binarymutant> isn't it just a file pointing to another file
<LaserJock> is it?
<mok0> No, but most have the same boilerplate content
<LaserJock> I suppose a redudant file with redudant content would be reredundant
<binarymutant> please see /usr/share/doc/whatever/dpatch.readme
<LaserJock> oh, well that's kinda dumb though could be important
<LaserJock> it's supposed to be the stuff about the source package that isn't redundant
<mok0> Right
<LaserJock> but like everything else that's boilerplate, people like to make examples useless ;-)
<binarymutant> I thought it was to show others how you manage patches
<mok0> Repackaging and other things that concern the source tarball belongs there, but how to use the patch system? Duh!
<LaserJock> yeah, that's totally not necessarily unless you're doing something non-standard
<mok0> The patches can very well be applied manually using patch -p0 < file
<binarymutant> the easiest way :)
<mok0> for f in debian/patches/*.patch; do patch -p0 < $f ; done
<mok0> preseto
<mok0> presto
<LaserJock> I still prefer dpatch
 * sistpoty|work prefers VCS - i.e. upstream VCS *g*
<LaserJock> I don't
<mok0> LaserJock: yes , but the file is supposedly intended for people who don't use the std tools for some reason
<LaserJock> those are a pain
<LaserJock> mok0: well, I would consider "for f in debian/patches/*.patch; do patch -p0 < $f ; done" still standard :-)
<sistpoty|work> well. I guess my advantage is that I'm upstream as well for the thingy I'm packaging right now *g*
<LaserJock> sistpoty|work: yeah, that usually helps in many ways ;-)
<sistpoty|work> yep :)
<mok0> We hates upstream!
<LaserJock> except for when you get mad at upstream for doing something stupid ;-)
<mok0> We hatesssss upstream!
<sistpoty|work> luckily we're a team, so I can blame the others *g*
<LaserJock> "WTH, why did the bonehead do it *that* way!!!! oh yeah, that was me"
<sistpoty|work> heh
<mok0> ha
<binarymutant> if anyone has time on their hands I would appreciate a review on my package, http://revu.ubuntuwire.com/details.py?package=charm Thank you :)
 * sistpoty|work calls it a day and heads home
<sistpoty|work> cya
<iefremov_work> any MOTUs here to review UGENE - genome analysis suite? http://revu.ubuntuwire.com/details.py?package=ugene
<mok0> iefremov, I'll bite
<james_w> any suggestions for this developer news issue?
<mok0> iefremov, concerning zlib, just repackage the upstream tarball on our side.
<mok0> iefremov, in fact also strip windows specific directories if they exist
<mok0> iefremov, it's no problem, done with lots of packages
<LaserJock> james_w: do you have the new application process already?
<iefremov_work> mok0, do you mean repackaging with removing zlib?
<james_w> LaserJock: no need, it went to u-d-a
<mok0> iefremov, yes, and rename the tarball to something, for example ugene_1.3.2+repack.orig.tar.gz
<iefremov_work> ok, will be fixed
<LaserJock> james_w: but doesn't the developer news go elsewhere as well?
<iefremov_work> should i place any comments about it - creating special readme, etc. ?
<mok0> iefremov, then, create a script or a target in rules "get-orig-source" that does everything needed to repackage
<james_w> LaserJock: elsewhere than Ubuntu developers?
<LaserJock> james_w: doesn't it go on Fridge, for instance
<iefremov_work> mok0, ok
<james_w> LaserJock: why would it?
<LaserJock> because it's news ...
<james_w> it's news for developers
<fabrice_sp> Any MOTU to check my debdiff for Bug #318967?
<ubottu> Launchpad bug 318967 in openmovieeditor "openmovieeditor FTBFS in jaunty" [Undecided,Confirmed] https://launchpad.net/bugs/318967
<Webspot> Hey. Are there any MOTUs available to review osm-gps-map? It is a GTK+ widget for showing OpenStreetMap in apps. It's my first package! http://revu.ubuntuwire.com/details.py?package=osm-gps-map
<mok0> Webspot: I am busy atm but will take a look later
<Webspot> mok0: Thanks.
<Laney> Webspot: :O do any apps use it?
<Webspot> Laney: I don't think so yet. There are also some python bindings that I'm going to get packaged up, after this is done. And then I'm going to make a little app with it :)
<mok0> Cool then we can test it
<Webspot> In the -dev package, there's a small test script just to browse the map.
<Chris`> Webspot: I've added a comment but I'm not MOTU :)
<Webspot> Chris`: Thanks. I'll check it out.
<Webspot> Chris`: I'll work through that stuff :)
<Chris`> Webspot: Yeah cool, they're the stuff that I often get wrong so I just picked up on them :)
<Webspot> Chris`: Right. Hopefully I'll get better at this as I go along :)
<Chris`> Webspot: I've only had 3 packages into the Universe so far :P They were uploaded today as well!
<fabrice_sp> by the way, shouldn't it be better to sync gavl (bug #318658) before fixing the FTBFS, as openmovieeditor would need a rebuild after the sync?
<ubottu> Launchpad bug 318658 in gavl "Please sync gavl 1.1.0-2 from Debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/318658
<mok0> fabrice_sp: sounds reasonable
<fabrice_sp> mok0, ok. I'll link the gavl link request it in the FTBFS bug. Thanks :-)
<mok0> fabrice_sp: good to get that out of the way
<james_w> fabrice_sp: why would it need a rebuild?
<fabrice_sp> james_w, the soname is bumped, if I remember well
<james_w> I thought we already had the SONAME bump
<fabrice_sp> Have to check ,then (not sure, now that you say it)
<james_w> yeah http://people.ubuntu.com/~ubuntu-archive/NBS/libgavl0
<fabrice_sp> there is a new one (if I understand packages.debian.org)
<fabrice_sp> from libgavl0 -> libgavl-1.0-0 -> libgavl1
<james_w> ugh
<james_w> sorry, I assumed that it was libgavl0 -> libgavl1
<fabrice_sp> It would have been logical, yes
<fabrice_sp> :-/
<LaserJock> RainCT__: priority extra could be checked for
<ScottK> I think we really don't care at all in Ubuntu about optional/extra
<LaserJock> no, but there's a Policy difference
<ScottK> Even Debian is having a hard time convincing themselves they still care.
<LaserJock> and we don't know if they'll be used in the future
<LaserJock> not that I think optional/extra are particularly useful
<directhex> ScottK, some dev with a package which only works on hppa, with 4 users, might care!
<RainCT> LaserJock: How? REVU can't know if the priority is "extra" for some reason or not
<LaserJock> RainCT: sure you can
<LaserJock> if the package doesn't declare any replaces/conflicts I don't think it can be in extra really
<RainCT> LaserJock: It can. Eg, packages which require some special hardware to be useful
<ScottK> Also packages where it would be 'confusing'
<ScottK> Also if depends on extra pacakges.
<fabrice_sp> thanks for the ack mok0  :-)
<LaserJock> well, I guess it does depend a little on what part of Policy you take on that
<LaserJock> I'd take "contains all packages that conflict with others with required, important, standard or optional priorities" as being the thing to look for
<LaserJock> but I agree with ScottK that it's a fairly usless check
<LaserJock> but I think the dh_make template should do optional
<LaserJock> I'd take "contains all packages that conflict with others with required, important, standard or optional priorities" as being the thing to look for
 * RainCT would suggest fixing dh_make to not set extra by default :P
<LaserJock> exactly
<LaserJock> that would basically solve the "bad priority" problem
<RainCT> LaserJock: btw, I like the proposal from your mail
<RainCT> [wth is that RainCT_ coming from? o.O
<LaserJock> RainCT: yeah?
<RainCT> [oh, irssi running twice :P]
<mok0> RainCT: In screen?
<RainCT> LaserJock: Yeah. Although if we decide to go with it, it'll take me some weeks to do the required changes on REVU (unless someone else wants to do them)
<RainCT> mok0: yep
<mok0> RainCT: great then, can you tell me how to scroll in screen?
<pochu> Chris`: hey, I've seen refdoc pinged me. Are you going to do the work? If so, there's someone in the motu mailing list offering help and willing to maintain those packages; perhaps you want to work with him
<LaserJock> RainCT: right, yeah. I realized it would take some modification.
<LaserJock> mok0: PgUp or Shift-PgUp works for me
<mok0> ah, /me tries that
<Chris`> pochu: I would love any extra help since it is still a learning experience for me. I'll check the mailing list atm
<RainCT> mok0: by pressing some key combination to switch to another mode.. but here it's pageup/pagedown is working, let me check if i added something to the config file..
<mok0> LaserJock: nope, must be in your .screenrc
<pochu> nhandler: hey, did you use GMail to reply to ScottK's mails in your REVU thread?
<RainCT> mok0: can't find it, but I guess jpds knows
<LaserJock> mok0: I've never set up a .screenrc
<mok0> heh ok, what term are you using?
<LaserJock> mok0: PgUp works here
<RainCT> mok0: terminator
<mok0> RainCT: Hm, me too...
<LaserJock> mok0: gnome-terminal, terminator, konsole ...
<mok0> LaserJock: I feel ... like... somethings wrong with me
 * LaserJock gives mok0 a hard smack
 * mok0 wakes up
<mok0> It's probably my termcap entry or something
<mok0> 'cause PgUp doesn't work anywhere
 * ScottK finds it ironic that armel is the least backlogged arch on the buildd's right now.
<mok0> ScottK, that's because almost nothing builds on it ;-)
<ScottK> mok0: Actually it's because all the pending backports got processed today.
<ScottK> No armel in Hardy/Intrepid
 * sebner waves and is happy to be still alive =)
<mok0> sebner!!
 * ScottK wonders if that was in question?
<sebner> ScottK: yes, really xD
<ScottK> Tell us then ...
<sebner> ScottK: well, it's really hard. 16hours per day on the feet. bad meals, instructors shouting all day long
<ScottK> Sounds like you joined the army.
<sebner> xD
<sebner> of course
<laga> oh, i thought it was ~ubuntu-bugs
<sebner> for the next 6 months :(
<ScottK> Ah.
<RainCT> lol
<sebner> laga: lol
<ScottK> It's good for you.
<sebner> ScottK: NAAAAAAAAHHHHHHHHHHHHHHH
<sebner> ScottK: the bad thing is that I would have gone home last weekend already but I was ill so I had to stay there. So I'm at home the first time since 2 weeks
 * sebner asks himself if the new nvidia driver (180-glx) is now compatible with new Xorg? 492 updates to go
<james_w> fabrice_sp: nice work on openmovieeditor
 * mok0 goes for pizza!
<hyperair> is there any motu available for revu? if so, may i have a review please? http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin
 * mok0 looks the other way ;-)
<hyperair> mok0: heheh
<mok0> hyperair: it's getting awfully quiet around here...
<hyperair> mok0: if you're free for another revu, http://revu.ubuntuwire.com/details.py?package=sigx
<hyperair> mok0: and yeah, i agree.
<hyperair> imo the most noise happens when i'm asleep
<mok0> Ah, ok
<mok0> yes
<mok0> Somewhere I saw some statistics on when the channels were busy
<iulian> mok0: To scroll down/up in screen - CTRL+A+ESC works for me.
<mok0> iulian: your'e using C-A as the command sequence?
<hyperair> Ctrl+A+ESC triggers copy mode in screen ;)
<iulian> mok0: Exactly, then press esc.
<mok0> for me too
<mok0> I changed C-A to C-Z
<iulian> You can now scroll with PgUp/PgDn or with the arrows.
<mok0> Ah!
<mok0> Yay!
 * mok0 hugs iulian
 * iulian hugs mok0 back.
<hyperair> fabrice_sp: you're a motu right? could you revu a package for me? =p
<fabrice_sp> hyperair, sorry: I'm only an interested contributor
<fabrice_sp> but I can have a look at a package :-)
<fabrice_sp> just throw the URL, and I'll comment it (even if I can't advocate it)
<hyperair> fabrice_sp: http://revu.ubuntuwire.com/details.py?package=sigx
 * fabrice_sp builds sigx, to check the resulting packages
<hyperair> jpds: ping
<fabrice_sp> hyperair, sigx FTBFS:
<fabrice_sp> dh_makeshlibs: command returned error code 256
<fabrice_sp> make: *** [binary-fixup/libsigx-2.0-2] Error 1
<hyperair> how very strange
<hyperair> i saw no such error
<hyperair> and what's FTBFS?
<slytherin> hyperair: fails to build from source
<hyperair> ig'
<hyperair> oh
<hyperair> hmm
<hyperair> fabrice_sp: are you using amd64 by any chance?
<fabrice_sp> yep
<fabrice_sp> amd64 here
<hyperair> thought so
 * hyperair frowns
<hyperair> mok0: are debian/package.symbols.arch files required for libs?
<hyperair> fabrice_sp: could you try removing debian/*.symbols and see if it builds?
<fabrice_sp> ok
<mok0> hyperair: not required,
<hyperair> mok0: alright, then i'll just toss it out. lintian -I was complaining though
<mok0> hyperair: so far, it's only a recommendation
<fabrice_sp> hyperair, so will upload a new version?
<hyperair> fabrice_sp: yeah i will.
<mok0> hyperair: but it will be useful in the long run
<hyperair> mok0: i can't for the life of me understand the .symbols file generated by dpkg-gensymbols
<mok0> hyperair: can you pastebin it
<slytherin> hyperair: why do you need to understand it? Just use it. :-P
<fabrice_sp> mok0, is uploading a package to PPA mandatory before uploading to REVU? It should help fixing FTBFS before advocating the package
<hyperair> mok0: it's a C++ library so there are a whole lot of mangled names
<mok0> fabrice_sp: true. It's a good idea, but not required
<hyperair> slytherin: well, it's unmaintainable otherwise right?
<mok0> hyperair: ah yes
<mok0> hyperair: it's basically a list of (symbol  version)
<hyperair> mok0: it would also seem that the x86 .symbols doesn't work on amd64
<slytherin> fabrice_sp: not required. ppa is not the only way to make sure your package builds. use pbuilder.
<mok0> where "version" is the version of the library (no soname)
<hyperair> mok0: http://pastebin.com/f586e7665
<mok0> (NOT soname)
<mok0> hyperair: yup, looks good
<hyperair> slytherin: well it builds on x86, but i don't have an amd64 pbuilder around
<mok0> hyperair: place it as debian/<package>.symbols
<hyperair> mok0: that's what made dh_makeshlibs spit flames on fabrice_sp's machine
<mok0> hyperair: oh?
<hyperair> mok0: yeah, error 256 or something
<mok0> fabrice_sp: what version are you running? Gutsy?
<mok0> hyperair: what package is it?
<mok0> sigx?
<hyperair> mok0: http://revu.ubuntuwire.com/details.py?package=sigx
<hyperair> yeah
<mok0> Ah, about to take a look at it anyway
 * mok0 goes to other window for a while...
<hyperair> mok0: actually i removed the .symbols file
<fabrice_sp> mok0, no: it's a jaunty's sbuild
<hyperair> mok0: should i add it back?
<mok0> Uhm, the symbol file?
<mok0> I can snatch it from the pastebin
<hyperair> mok0: yeah
<hyperair> oh
<hyperair> right
<fabrice_sp> I'll paste the sbuild's log in REVU
<mok0> fabrice_sp: thanks
 * hyperair needs to bathe
<mok0> hyperair: yeah you're starting to smell
<mok0> :)
<mok0> hyperair: why do you use that strange version # for the lib?
<mok0> 2.0-2?
<fabrice_sp> bad idea to paste the build log in REVU....
<mok0> fabrice_sp: firefox crashed?
<mok0> fabrice_sp: we just need those error messages not the whole thing
<fabrice_sp> nop: it's a too long comment
<fabrice_sp> yeap: will just past the error
<fabrice_sp> done
<mok0> fabrice_sp: ah I may know what that is
<fabrice_sp> mok0, wouah!
<mok0> fabrice_sp: I get the same erros
<fabrice_sp> ok
<mok0> fabrice_sp: right now I am thinking that it has to do with that funny version no
<Webspot> mok0: You mentioned on my REVU package (http://revu.ubuntuwire.com/details.py?package=osm-gps-map) that I should have a watch file. Is this possible, when the packaged is based off a git checkout?
<mok0> Webspot: oh
<mok0> Webspot: I guess not
<Webspot> mok0: Okay. I'll just upload the other changes, ignoring that then :)
<mok0> Webspot: all right
<Webspot> I've uploaded the changes requested by people to my package. If any MOTUs are free could they please review. Thanks :) - http://revu.ubuntuwire.com/details.py?package=osm-gps-map
<Webspot> Just give it a second to show up on the site though...
<Webspot> It's up now, for those interested.
 * hyperair is back!
<mok0> hyperair: that .symbols file is from another version of the library
<hyperair> eh?
<hyperair> seriously?
<hyperair> whoops
<mok0> hyperair: why do you use that strange version # for the lib?
<hyperair> what strange version #?
<mok0> 2.0-2
<hyperair> mok0: that's not a version
<hyperair> i mean that's part of the library package name
<hyperair> isn't it?
<mok0> Package: libsigx-2.0-2
<hyperair> i read from the debian library packaging guide that if the library is libsigx-2.0.so.2.y.z, then the package name should be libsigx-2.0-2
<hyperair> or something
<mok0> hyperair: normally, you just append the major soname -> libsigx2
<loic-m> mok0: before my computer rebooted a few hours ago I read a comment from you that (C) for copyright wasn't good in a package
<mok0> loic-m: right
<hyperair> libtool params: -export-dynamic -version-info 0:0:0 -release 1.2.3 package name: libfoo-1.2.3-0
<mok0> loic-m: Either Â© or Copyright
<hyperair> taken from http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
<mok0> hyperair: errr...
<loic-m> mok0: I suggested that line in a REVU comment (my bad) : The Debian packaging is (C) 2008, Your_name <your@adress> and is licensed under the GPL, see above.
<hyperair> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id250154
<loic-m> mok0: I can just suggest "The Debian packaging is Copyright 2008, (...)
<mok0> loic-m: yes
<loic-m> or "The Debian packaging is Â©2008, (...)"
<mok0> exactly
<loic-m> mok0: thanks a lot
<mok0> You're welcome
<mok0> hyperair: 2 secs
<hyperair> mok0: ok
<loic-m> mok0: is "Copyright (C) 1999 " ok? I've seen it on a Debian package afair
<loic-m> mok0: or should i tell the uploader to correct that too?
<mok0> loic-m: It's commonly used that way, but AFAIK, the "(C)" is worthless
<mok0> loic-m: in the sense: has no legal implecations
<mok0> implications
<loic-m> mok0: thanks, I'll have to review my own package on REVU too ;)
<mok0> he
<mok0> hyperair, from Debian policy manual: "The most common mechanism is to place it in a package called librarynamesoversion, where soversion is the version number in the soname of the shared library
<hyperair> hmm =\
<hyperair> i'll change it then
<hyperair> mok0: but looking at libsigc++, it's libsigc++-2.0-0c2a
<mok0> hyperair: Ugly
<hyperair> heh
<hyperair> mok0: so should i strip the -2.0 from all the binary packages?
<mok0> hyperair: hang on, I want to be sure
<mok0> hyperair: in the meantime, read this: http://www.gnu.org/software/libtool/manual/html_node/Versioning.html#Versioning
<loic-m> Has the FSF address (in debian/copyright) changed? I've seen 2 address, but can't tell for sure which is the new one or if both are ok (and I don't want to mislead the uploader)
<loic-m> Is 675 Mass Ave, Cambridge, MA 02139, USA. the old one, and 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA the new one?
<mok0> loic-m: It's the Franklin St. one that's current
<loic-m> mok0: thanks a lot.
<hyperair> mok0: that doesn't seem to talk about -release at all
<hyperair> oh wait it does
<hyperair> mok0: basically what i infer from this is that sigx-2.0 is the name of the library, and 2 is the soname version
<hyperair> mok0: hence libsigx-2.0-2
<mok0> hyperair: Explain to me why you need that
<hyperair> mok0: umm because upstream decided to do things like that?
<mok0> hyperair: I maintain that libsigx2 is sufficient
<mok0> hyperair: if the ABI changes, upstream will bump the soname to 3 and the new library will be libsigx3
<hyperair> because the library's filename is libsigx-2.0.so.2, and the author's latching the -2.0 part to the libsigc++ -release version
<mok0> hyperair: then old and new apps using the library can co-exist
<mok0> hyperair: ok
<hyperair> mok0: similar to how libsigc++ has -1.2, -1.9, and -2.0, as well as potetntially higher versions in the future, i think sigx will follow the same way
<hyperair> mok0: in which case i think the soname would be reset
<mok0> hyperair: very peculiar
<hyperair> mok0: it's something like branching from the old one, similar to how gtk1 shifted to gtk2
<mok0> hyperair: of course this is not a libtool library
<hyperair> and yes it's not, but it uses libtool versioning, after i persuaded the author to do so
<hyperair> however, libsigc++ is a libtool library
<hyperair> author seems to really love scons
<mok0> hyperair: what is libsigc++ ?
<hyperair> mok0: signal/slot library for C++
<hyperair> mok0: used extensively in gtkmm
<mok0> hyperair: ..and this lib is on top of that?
<hyperair> mok0: libsigx is the multithreaded extension to it
<hyperair> mok0: yep
<mok0> ah
<mok0> Then why not libsigx2-2.0 ?
<hyperair> um.
<hyperair> i haven't seen any versioning that looks like that
<hyperair> have you seen any package which has a name like that?
<mok0> libofapi0 - OpenFirmware device-tree parsing library
<mok0> libnucleus5 - EMBOSS library for molecular sequence analysis
<hyperair> mok0: but that's not libofapi0-0.0 or something
<mok0> libnmz7 - full text search engine - shared library
<hyperair> mok0: i'm talking about libraries with libfiles libfoo-<some release version>.so.<soname>
<mok0> hyperair: so, like lib*-*.so.* ?
<hyperair> mok0: every library i can think of which has files /usr/lib/libfoo-<version>.so.<soname> is named similar to how i named sigx
<hyperair> mok0: more specifically lib*-\d+.so.*
<mok0> libgthread-1.2.so.0
<hyperair> uh make that [\d.]+
<hyperair> ah
<mok0> corresponding package: libglib1.2ldbl
<hyperair> but that has an even stranger package name
<loic-m> Is the fact the simple description line in debian/control starts with an upercase a big problem? I'm checking packages in the repos to make sure but some do, some don't
<hyperair> i mean you don't see the soname anywhere, and what's ldbl?
<mok0> libgtk1.2: /usr/lib/libgtk-1.2.so.0
<mok0> dunno
<hyperair> mok0: those don't seem to have sonames in their package names
<Chris`> ScottK: Nice bug fixing, you had fixed in less than 3hrs of me originally reporting it! :P
<ScottK> Turned out to be an easy one.
<hyperair> mok0: the other variant i see is libfoo<version>-<soversion>
<hyperair> mok0: as the package name, i mean
<mok0> kdelibs5: /usr/lib/libkhtml.so.5
<ScottK> If Debian hadn't aleready done 4.2.4a it'd have gone into the 'too hard, do later' pile.
<mok0> kdelibs5: /usr/lib/libkhtml.so.5.1.0
<Chris`> ScottK: Heh you have those piles too?
<mok0> hyperair: that's an example!
<hyperair> mok0: those don't have a version before .so
<ScottK> Piles of them.
<mok0> hyperair: not the library, the package
<jpds> RainCT: Know what?
<mok0> hyperair: so you can also have the earlier package:
<hyperair> mok0: but the package name has to be tailored towards the way the library was versioned
<hyperair> mok0: right?
<mok0> kdelibs4: /usr/lib/libkhtml.so.4
<RainCT> jpds: uhm?
<hyperair> mok0: okay, supposing the sigx author decides to release a libsigx-3.0.so.2, what do i call it?
<mok0> hyperair: yes, but you said it was using libtool versioning
<jpds> 18:59:11 #ubuntu-motu: < RainCT> mok0: can't find it, but I guess jpds knows
<jpds> hyperair: pong.
<RainCT> jpds: Ah, nvm, he already got an answer.
<mok0> hyperair: ok, if that's what he calls it, I guess we're stuck with that
<RainCT> jpds: (he wanted to know how to scroll with screen)
<hyperair> jpds: hi. is the package name "libsigx-2.0-2" okay for libsigx-2.0.so.2?
<mok0> jpds: I believe it was a question about how to scroll in screen
<mok0> jpds: but we figured it out
<hyperair> mok0: well if you like, it looks like there are naming conventions where the release number is glued onto the package name, like libsigx2.0-2. would that be better?
<jpds> mok0: How do you do it? I knew how to but I forgot.
<jpds> hyperair: Should be.
<mok0> jpds: first you need to go into copy mode (C-A esc) then you can use PgUp
<RainCT> jpds: ctrl+a+escape
<hyperair> jpds, mok0: scrolling in screen requires activating copy mode (C-a [)
<RainCT> jpds: here it works out of the box, though.. dunno why
<jpds> Hmm, /me writes into Tomboy.
<hyperair> jpds: ctrl+u seems to work for scrolling up
<mok0> hyperair: leave it like it is, I am convinced
<jpds> RainCT: Did you fix tonio's REVU MOTU status thing?
<hyperair> jpds: and ctrl+d for scrolling down
<hyperair> mok0: okay
<hyperair> mok0: so apart from adding a proper package.symbols file, are there any other issues?
<mok0> hyperair, now I'm gonna look at that symbols thing.
<hyperair> mok0: okay
<mok0> hyperair: haven't gotten that far yet :-)
<hyperair> jpds: when you poked around sigx last night, did it build? if so, x86 or x86_64?
<jpds> hyperair: I didn't have time to test build..
<RainCT> jpds: I don't even know who that is. (Well, thanks to google, now I know it :P)
<hyperair> jpds: i see. nevermind then.
<mok0> hyperair: anyway, I just created a totally new .symbols file from the library built, and it's different from the one included in debian/
<jpds> RainCT: He's a core-dev and motu, but doesn't have it on REVU, can't merge his accounts.
<hyperair> mok0: can i have it?
<hyperair> mok0: pastebin or something
<mok0> sure, just a minute
<hyperair> mok0: okay
<mok0> http://pastebin.com/f37431e11
<RainCT> jpds: OK, he's a reviewer now. You know that you can change the rank from the profile?
<jpds> RainCT: No, I did not.
<RainCT> well, now you do ;9
<RainCT> * ;)
<hyperair> mok0: i'm getting a different .symbols file
<mok0> hyperair: heh
<jpds> RainCT: Learn something knew everyday.
<mok0> hyperair: are we working with the same upload I wonder?
<hyperair> mok0: same upload
<hyperair> mok0: you're on x86_64, i'm on x86. that seems to be creating the difference imo
<hyperair> but then again symbols shouldn't change from one arch to another
<mok0> Hm, it shouldn't
<hyperair> mok0: how did you generate yours
<mok0> hyperair: what's the version you used to compile?
<mok0> heh
<hyperair> mok0: i ran dpkg-gensymbols -plibsigx-2.0-2 | patch debian/libsigx-2.0-2.symbols
<mok0> I used a fresh jaunty builder
<hyperair> eh mine's intrepid
<hyperair> i should use jaunty =\
<mok0> hyperair: it could be a difference in the compiler.
<hyperair> i'll just take your symbols file and see if it works lol
<mok0> hyperair: that kind of defeats the whole purpose of .symbols, though
<mok0> The C++ mangling throws off the scheme
<hyperair> yeah
<hyperair> so i should just leave it out?
<mok0> In fact, C++ almost _always_ introduces a different ABI
<mok0> Any change of a class will do it
<hyperair> meh
<hyperair> lol
<hyperair> so i should toss it out
<hyperair> =\
<hyperair> since it's pointless and adds a whole lot of useless stuff to the diff.gz
<mok0> Yeah, probably... although it would be interesting to find out what is going on
<hyperair> heh
<hyperair> o
<hyperair> i'm trying your .symbols file in pbuilder now
<hyperair> let's see if dpkg-gensymbols generates a diff
<mok0> The file will tell clients what parts of the library are still the same as the older versions
<mok0> So, it's pretty useful, but if different versions of the compiler have different mangling schemes then it's not worth squat
<hyperair> lol pbuilder threw a hissy fit
<hyperair> looks like the symbols thing just introduces probs
 * mok0 attempts an intrepid build
<Laney> hyperair: You should maintain that banshee plugin in debian-mono
<Laney> ;)
<hyperair> Laney: you mean bansheelyricsplugin?
<Laney> is there another?
<hyperair> Laney: eh?
<hyperair> Laney: you're talking about the one i uploaded to revu right
<Laney> yes
<hyperair> ah
<hyperair> heheh
<hyperair> well. i don't have a debian system =p
<hyperair> just ubuntu
<Laney> forget revu, go straight to the place where great packages are born
<hyperair> heh
<mok0> Laney: you mean, never born :-)
<Laney> You can test it in a VM, but really it's the same
<hyperair> well, are you a motu? if you are you can always add the final advocate? =p
<Laney> I'm not, and if I were I'd still ask you to bring it over
<hyperair> Laney: i'd submit it through utnubu or whatever
<mok0> hyperair: it's a good idea
<mok0> Laney: utnubu exists?
<Laney> not really
<mok0> Laney: no one here ever heard of it
<hyperair> oh it doesn't?
<Laney> It's pretty defunct afaict
<hyperair> mok0: what's a good idea?
<mok0> hyperair: to maintain the package in Debian
<hyperair> hmm
<Laney> in the pkg-cli-apps team
<hyperair> what does it take to become a debian maintainer?
<Laney> you don't need to be
<hyperair> eh? i don't?
<mok0> hyperair: you need to get it sponsored, like on REVU, but you only need 1
<hyperair> mok0: where do i upload it?
<mok0> hyperair: they keep all packages in a common svn or git repo
<Laney> And we maintain packages in SVN, so it's much more collaborative
<Laney> the preparing of an upload, I mean
<mok0> hyperair: Laney can tell you
<hyperair> Laney: i know that svn.. i have a few of slomo's packaging stuff checked out on my copm
<fabrice_sp> Anyone MOTU willing to review DVStyler and perhaps to give it the second advocate? It's a DVD Authoring tool, and it's at http://revu.ubuntuwire.com/details.py?package=dvdstyler
<Laney> right, slomo maintains a lot of packages in pkg-cli-* svn
<hyperair> Laney: yeah, i sync from them into the ppa
<mok0> I'm the only motu around I'm afraid
<Laney> awesome
<hyperair> mok0: i thought jpds was around, as was rainct
<mok0> hyperair: then they're hiding from uploaders, lol
<hyperair> time to ping
<hyperair> =p
<Laney> har har
<hyperair> heheh
<hyperair> anyway i've got to sleep
<hyperair> got a bus to catch tomorrow
<hyperair> i mean later today ;)
<mok0> heh, I'll leave a review for sigx
<hyperair> mok0: thanks
<mok0> hyperair: it depends on half the archive
<mok0> takes forever to build
<hyperair> mok0: you serious? it only takes ~5 minutes on my notebook
<cemc> hi. i was just reading this thread: http://ubuntuforums.org/showpost.php?p=2884866&postcount=46 about updating clamav. it there anything new on this subject?, the thread ends on 09 aug 2007 ;)
<mok0> I guess it's 'cause I'm watching
<hyperair> mok0: also i've got LAN access to an archives mirror =p
<mok0> hyperair: I have an apt-cacher-ng on the gigabit network
<mok0> cemc: ScottK is the big clamav person
<cemc> yea, i saw that, but wanted to ask here first instead in private
<mok0> cemc: we've mentioned his name, so he'll come around
<mok0> probably
<mok0> maybe
<cemc> :) i'll stick around then, thanks
<mok0> :-)
<ScottK> cemc: What's the question?
<cemc> ScottK: hi. well, i just installed 8.04 and saw that whole thread about clamav, and i wish to use it and have the latest in hardy, and i would like to help to get it there ;)
<cemc> i'm fairly new to this whole thing, but i would like to help somehow
<tobi__> what can be reasons for a package not being listed on merge-o-matic, although a newer version of a package is listed in the debian repos? (package: gpsbabel)
<ScottK> cemc: What do you use clamav with?
<ScottK> https://launchpad.net/~ubuntu-clamav <- we need testers.
<cemc> amavis + postfix
<ScottK> So if you could run the 0.94.2 packages from the PPA and report any problems, that would be useful.
<jcfp> if a package exists in both debian and ubuntu, and the ubuntu one gets updated (new upstream release) so it's newer than the one in debian, should the version be -0ubuntu1 or -1ubuntu1?
<ScottK> jcfp: -0ubuntu1
<jcfp> tx
<ScottK> Once Debian gets it and uses -1, we want it to be a higher version.
<jsmidt> I cannot get debuild to call my gpg key.  It always fails saying "Joseph Smidt <josephsmidt@gmail.com>": secret key not available
<jsmidt> yet here is my gpg --list-key output Joseph Smidt (Personal Key) <josephsmidt@gmail.com>
<jsmidt> Is there some config file I need to change.  I tried making a .devscripts file
<_stochastic_> does anyone wat to REVU my package: http://revu.ubuntuwire.com/details.py?package=calf
<ScottK> jsmidt: Email address and name have to match exactly.
<ScottK> jsmidt: use -k<keyid> then.
<mok0> _stochastic_: I'll take a look when I'm done with the one I'm looking at now
<_stochastic_> mok0, thanks
<mok0> _stochastic_: I've looked at it before
<_stochastic_> mok0, I've fixed it up
<mok0> _stochastic_: great!
<nhandler> pochu: Yes, I did use gmail, why?
<pochu> nhandler: because it mangled ScottK's Message-Id in your References header and that broke threading :P
<jsmidt> Found my gpg error.  I called the copied the /etc/devscripts.conf to ~/devscripts.conf but it only works if you get rid of the .conf.  Thanks ScottK though for the help.
<nhandler> pochu: Good old gmail. Is there a fix to this? Or is it just one more of gmail's faults?
<jsmidt> ~/.devscripts.conf
<pochu> nhandler: well the fix would be to fix gmail, but we can't do that
<pochu> nhandler: but it's ok, it only happened because the message-id had brackets and gmail removed them, but generally they don't have brackets so it's not common :)
<pochu> nothing to worry about too much
<directhex> BLARG!
<directhex> if this is true, i may feel a need to punch something
<lucas> A
<lucas> oops
<loic-m> Can anyone review/advocate my package at http://revu.ubuntuwire.com/details.py?package=ecm ? It's been reviewed twice by simrunbasuita and I've done the corrections, plus fixed a few more stuff since
<nhandler> loic-m: I'll look at it
<loic-m> nhandler: thanks a lot
<loic-m> it's not a so well known package, but it's quite useful for storing isos + only available as source on the homepage
<loic-m> btw, is there a team for emulation (game consoles) in Debian or Ubuntu?
<nhandler> loic-m: I believe there is a Debian game team
<nhandler> loic-m: https://alioth.debian.org/projects/pkg-games/
<postalchris> Is there a way to give a package a new version number without doing a full rebuild?
<nhandler> postalchris: Why do you need to give it a new version number?
<postalchris> I want to upload the same version to a PPA and to REVU
<nhandler> postalchris: For PPAs, you really should append ~ppaX to the end of it
<loic-m> nhandler: I've seen this team before, I thought it was only for Linux native games - do they also focus on emulation?
<nhandler> loic-m: I'm not sure
<postalchris> nhandler: Right, I mean I want the same source package in the two places with different version numbers (per the naming convention)
<nhandler> postalchris: I'm not sure if there is a better way. I normally upload to REVU, modify version to have ~ppaX in debian/changelog, debuild -S, and upload to PPA
<postalchris> nhandler: Cool. Thanks.
<loic-m> nhandler: ~ppaX do you leave X, or does X has to be replaced?
<maxb> X == a number, start at 1, increase if you need to make a revision
<loic-m> maxb: thanks
<cyberix> hey, we just transfered development of package pyliblo over from me to dooooomi
<cyberix> could someone review the new version to make sure everything went ok?
<cyberix> http://revu.ubuntuwire.com/details.py?package=pyliblo
<loic-m> When reviewing, is there a command to check there's not useless spaces in debian/ files (+ maybe number of characters in a line not >80)?
<nhandler> loic-m: I normally just skim down the line using vim (which shows the column number) to see if it is > 80 characters. Extra spaces are pretty easy to spot
<Laney> I thought there was a lintian check for >80 (maybe in -I?)
<nhandler> Laney: I think there is, but I don't remember if it checks every file or not
<Laney> the ones in debian/ that have this limit, sure
<loic-m> nhandler, Laney, thanks. I'll try lintian -l first ;) I'm still not good at spotting them with a text editor (I'll have to try vim though)
<Laney> not l, I (that's capital-i)
<Laney> loic-m: ^
<nhandler> loic-m: You also need to build the package before running lintian. Running it on the .dsc won't work
<maxb> lintian can check a source package, can't it?
<nhandler> Yes it can
#ubuntu-motu 2009-01-24
<Laney> Yes, and I'd imagine that check would work on a source package
<loic-m> Laney: thanks, I just come back from reading the lintian man page and was still confused ;) (and I was running it against the dsc...
<Laney> it's still a good idea to run it on your binary .changes file though
<ScottK> Lines longer than 80 are OK in debian/copyright if they come from copying in the license.
<loic-m> ScottK: thanks.
<loic-m> Laney: I modified a debian/control with useless spaces + one line of 91 characters, debuild -S -sa + pbuilder build the package, but when I run lintian -I on any of the files in pbuilder, I get no output
<ScottK> I think debian/copyright was the only file that used to have a lintian check for 80 characters and they ditched that due to more pain than it was worth.
<loic-m> Laney: and I checked the .deb produced has the same mistakes
<loic-m> ScottK: so there's no way command to automatise those kind of checks? I was trying to see what's feasible as per nhandler suggestion in the ml :(
<ScottK> For debian/control build-deb and dep lines longer than 80 is just fine.
<ScottK> I think there's too many exceptions and it's not worth the trouble.
<ScottK> It's really a minor issue.
<ScottK> I have my Kate set with a line at 80 columns so it's really obvious
<loic-m> ScottK: thanks.
<directhex> ScottK, minor issue, but i hear the new ftpmaster assistants will reject over it
<jcfp> Please review http://revu.ubuntuwire.com/details.py?package=sabnzbdplus - thanks
<directhex> ew, python
<jcfp> :/
<cody-somerville> python packages are a charm to review
<jcfp> I must agree it isn't designed for easy packaging
<directhex> i don't do python packages
<ScottK> directhex: Considering there was a lintian check for lines over 80 chars in debian/copyright and it got pulled, I doubt it'd result in a rejection.
<ScottK> I may well be wrong though.
<ScottK> jcfp: I'm looking at your mochikit request.
<ScottK> jcfp: Don't delete uploaders from debian/control and don't put the maintainer change in debian/changelog.
<jcfp> ScottK: no other problems?
<ScottK> jcfp: Not so far.  I fixed those.
<ScottK> jcfp: That was it.  mochikit uploaded.  Thank you for your contribution to Ubuntu.
<jcfp> ScottK: thanks :)
<ScottK> jcfp: No.  Thank you.
<hyperair> Laney: ping
 * StevenK stares at the weather applet
<StevenK> "39 degC, feels like 42.1 degc"
<lfaraone> Hi, what's the proper way to package libabiword (blocking the building of another package dropped from the last release)? It's dependent on abiword, and will only work if you have the same abiword version installed. They'd be built fromt he same source. Do they need to be split into different binary packages?
<ScottK> Did they remove 90% of the cities in Australia 'because no one knows where they are anyway"
<ScottK> StevenK: ^^
<ScottK> lfaraone: I think abiword is used by Xubuntu, so I'd talk to a Xubuntu dev like cody-somerville or NCommander.
<cody-somerville> lfaraone, That sounds about right. Is it not currently?
<lfaraone> cody-somerville: currently abiword is not built with --enable-libabiword.
<lfaraone> cody-somerville: so we can't package python-abiword, which sugar-write-activity depends (I'm a SugarLabs guy).
<cody-somerville> lfaraone, Okay. Sounds sane to me.
<lfaraone> cody-somerville: Ok, shall I prepare a debdiff where we have that flag enabled that I've tested?
<cody-somerville> lfaraone, sure.
<cody-somerville> lfaraone, upload it to a ppa
<lfaraone> Is there any pressing reason why I shouldn't use distcc for compilations?
<ScottK> superm1: Would you mind reviewing http://revu.ubuntuwire.com/details.py?package=rt28xx-linux-sta (it uses dkms, so I think it'd benifit from a look by you)?
<loic-m> In a rule file, when declaring variables, can I use a variable I declared just one line above to set another variable, like in  http://paste.ubuntu.com/108861/ ?
<nhandler> Yes loic-m
<loic-m> Thanks a lot
<fabrice_sp> Hi. Any chance to have dvdstyler reviewed? It's a DVD authoring tool, with more the 88000 downloads (at least 9000 for Ubuntu), and has already been advocated by mok0. You can find it at http://revu.ubuntuwire.com/details.py?package=dvdstyler. Thanks.
<ScottK> What the heck.  I'll look.
<fabrice_sp> Thanks ScottK !
<nhandler> fabrice_sp: Why do you have uscan_repack instead of a normal get-orig-source target?
<fabrice_sp> nhandler, it has been requested by mok0 to make it more automatic to get the orig tarball (download + repack in one shot)
<nhandler> So why couldn't the get-orig-source rule be used to do that?
<fabrice_sp> get-orig-source call that script
<fabrice_sp> and it's also called from the watch file
<fabrice_sp> so it's a way to do it the same way with a get orig or a uscan
<ScottK> fabrice_sp: Why compat 6?
<nhandler> fabrice_sp: Ok, I didn't see the get-orig-source in there
<fabrice_sp> ScottK, you're right, I'm using any special functions. I think I had to bump it to get rid of a lintian warning
<fabrice_sp> nhandler, ok
<loic-m> Is there a way to verify that a get-orig-source target in debian/rules works?
<fabrice_sp> ScottK, I'll put 4 again, and check that
<ScottK> fabrice_sp: If it's 6, then you also need to version your debhelper build-dep.
<ScottK> OK
<nhandler> loic-m: make -f debian/rules get-orig-source
<loic-m> thanks nhandler
<nhandler> fabrice_sp: I would only drop to 5
<fabrice_sp> ScottK, you're right.
<nhandler> fabrice_sp: What is ubuntu.patch?
<nhandler> And debian.patch?
<fabrice_sp> Does that mean that if I put 5, I also need the version in build-dep?
<nhandler> Yes
<nhandler> Build-Dep on debhelper (>= 5)
<ScottK> Does your desktop file have an icon?
<ScottK> Because if it does, you want at least a version with dh_icons with is about 5.0.51 or so.
<fabrice_sp> nhandler, it comes from upstream. He has a script (builddebian) that build the package for lenny and ubuntu, and it uses this script to apply it. I'm not using them as they are for control file
<fabrice_sp> ScottK, the icon comes fom upstream
<ScottK> Yes, but we have an icon cache so you want to call dh_icons.
 * nhandler heads off to bed
<fabrice_sp> ok
<vorian> nn nhandler
<ScottK> fabrice_sp: See man dh_icons.
<loic-m> nite nhandler
<ScottK> Set your build-dep to whatever version introduced that and your compat to 5.
<ScottK> Then add it to your debian/rules.
<fabrice_sp> ScottK, will do. thanks
<fabrice_sp> (good night nhandler)
<fabrice_sp> dh_icons has been added with version 5.0.51, so I'll update control, compat and rules
<ScottK> fabrice_sp: Look at the licensing header for wxVillaLib/thumb_md5.cpp.  You need to mention that in debian/copyright.
<loic-m> For my get-orig-source target, I use $(DEBIAN_DIR)/../.. so the .orig.tar.gz is created in the directory above the package directory
<fabrice_sp> ScottK, you're right. I thought I had reviewed all the source, but I must have forgotten this one. As it's public domain, I put that as licence?
<loic-m> However to make the .orig.tar.gz i need to tar a directory that's the same name as the directory I work in
<ScottK> fabrice_sp: I'd put that entire paragraph in debian/copyright.
<loic-m> It sound insane, but is it ok?
<ScottK> loic-m: Shouldn't it be the name of the new version, not the one you're in?
<fabrice_sp> ok
<loic-m> ScottK: You're right, since actually it'll only do the job if there's a new upstream version
<loic-m> ScottK: since my version is the same as upstream atm, it gives me headaches, but actually it will never be a problem, right?
<ScottK> loic-m: If your rule were smart, it'd notice it's the same version and stop.
<loic-m> ScottK, can you have a lok at http://paste.ubuntu.com/108866/ please?
<loic-m> should i add an "if" or is it ok considering nobody's going to target get-orig-source as long as there's no new upstream version?
<ScottK> loic-m: I'm not an expert on get-orig-source writing.  I'd have it test if there's a new version or not.
<fabrice_sp> ScottK, adding that (http://paste.ubuntu.com/108867/) in debian/copyright for wxVillaLib/thumb_md5.cpp is fine?
<ScottK> fabrice_sp: Looks fine to me.
<fabrice_sp> ok. I'm building the package, to check the dh_icons stuff. As soon as it gets built, I'll upload the new version
<ScottK> fabrice_sp: It FTBFS for me.  http://paste.ubuntu.com/108869/
<fabrice_sp> ScottK, that's what I'm just looking at. Changes in ffmpeg introduce this error (it has been built before for Jaunty in my PPA)
<ScottK> ffmpeg is like that.
<fabrice_sp> ScottK, I know :-/
<fabrice_sp> it seems upstream has made a patch 3 days ago. I'll apply it and build again. Thanks for your review anyway!
<loic-m> ScottK: actually testing for a new version might defeat the use of uscan --force-download, so I'd use the package directory to build the orig.tar.gz, even though I dl the upstream zip in the above directory and create the orig.tar.gz in the above directory too
<loic-m> Hopefully it's ok
<savvas> when I create a new package, do I have to subscribe any teams? the ubuntu sponsors?
<savvas> https://bugs.launchpad.net/ubuntu/+bug/95685
<ubottu> Launchpad bug 95685 in ubuntu "[needs-packaging] dcsharp" [Wishlist,In progress]
<Amaranth> wow, old bug
<Amaranth> savvas: ubuntu-universe-sponsors, btw
<Amaranth> Wait, I think that's for changes to packages
<savvas> eh, I'll just leave it like that
<savvas> I've sent it to REVU :p
<persia> REVU is the right place.  No subscription required.
<savvas> woohoo!
<savvas> oh no, damn dependencies..
<fabrice_sp> Hi. Any MOTU to review DVDStyler? I lost the advocate of mok0, because of fixing some issues detected by ScottK and fixing a FTBFS because of latest version of ffmpeg (http://revu.ubuntuwire.com/details.py?package=dvdstyler)
<didrocks> morning everyone
<fabrice_sp> Hi didrocks
<didrocks> Hi fabrice_sp
<fabrice_sp> only French guys speaking this morning :-)
<persia> C'est un bon matin pour Ubuntu :)
<fabrice_sp> wouah persia: you are a fluent French writer ;-) Perhaps, we should switch the channel' language to French ;-) (and you scared mangilimic lol)
<syockit> Hey, don't do that!
<persia> Aren't there already several francophone channels?
<syockit> Any guides to writing rules for cdbs?
<persia> syockit, google for "CDBS Documentation" and visit the duckcorp site.
<didrocks> persia: congrats' :)
<persia> didrocks, ?
<didrocks> persia: for you French :)
<didrocks> your*
<didrocks> persia: and yes, there is one channel #ubuntu-fr-devel for French people
<persia> C7est mon premiere langue, mais je ne parle jamais dans trent ans.
<didrocks> persia: ah d'accord, je comprends mieux :-)
<persia> I thought there was :)
<didrocks> persia: the other channels are not developpers related, more community or admin ones
<persia> At some point I remember there also being development stuff in #ubuntu-classroom-fr, but maybe that was just scheduled talks.
<fabrice_sp> I didn't knew about #ubuntu-fr-devel. Will have a look (even if no French channel will replace ubuntu-motu ;-) )
<didrocks> persia: yes, it's now #ubuntu-fr-classroom and we try to handle regular session. But this is more an "event" channel: most of the time, people are just idling
<persia> Much like #ubuntu-classroom.  Makes sense.
<didrocks> Exactly
<emgent> morning
<Piratenaapje> I'm currently trying to package my first application for Ubuntu, and am kind of stuck. I have to write a debian/rules files, and this allways seems to use make. The application I'm packaging does not use make to install itself, and because of that, does not use make at all. Is there a way to write this file without the use of make? Can I replace the make calls with my own installer script?
<directhex> Piratenaapje, yes and no
<directhex> Piratenaapje, debian/rules is a makefile. end of story. however, in a makefile, you can call other executables such as, say, a compile.sh file you write in debian/rules
 * persia notes that there are cases where debian/rules isn't a makefile, but use of a makefile means that most of the available documentation will be helpful.
<Piratenaapje> So I could just call my installer script instead of calling make?
<persia> Piratenaapje, debian/rules has several rules.  See http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules for the required targets.
<Piratenaapje> Allright, Ill have a look at it, thanks
<persia> So, you'd write debian/rules in such a way that for each of the required targets, it called the appropriate bits of the upstream build system to create the package.
<persia> OOh!  make is now "MUST".  Cool!
<directhex> Piratenaapje, an example of a non-make build system which you can call from inside debian/rules would be ant, which i'm sure persia here has more than enough interaction with
<persia> Python distutils is probably at least as common
<directhex> perhaps, but i see you as a java person for some reason
<Webspot> If any MOTUs are around and available, could they review my package? It's a GTK widget to embed openstreetmap into applications: http://revu.ubuntuwire.com/details.py?package=osm-gps-map
<DktrKranz> Webspot, I'll have a look
<Webspot> DktrKranz: Thanks.
<fabrice_sp> x
<persia> directhex, Certainly, although I believe in pointing at alternatives when someone is learning.  Also, ant is annoying because of the number of things that have to be installed to make debian/rules clean work.
<Piratenaapje> Hmm I'm nearly done with the debian/rules file I think, but still having a problem with the install part
<Piratenaapje> dh_gencontrol keeps failing:
<Piratenaapje> dh_gencontrol -- -pgrnotify
<Piratenaapje> dpkg-gencontrol: error: package grnotify not in control info
<DktrKranz> Webspot, commented
<Webspot> DktrKranz: Thanks. I'll check it out.
<Piratenaapje> I could just reuse the control file I allready have, but that's a pretty ugly thing to do.
<persia> Piratenaapje, debian/control must include all packages that the package will build before the package starts building them.
<Piratenaapje> It only builds 1 package: grnotify
<Piratenaapje> Package: grnotify
<Piratenaapje> Source: grnotify
<Piratenaapje> That's from my control file
<persia> Piratenaapje, please pastebin your debian/control
<Piratenaapje> http://paste.ubuntu.com/108922/
<jcfp> looking for reviewers for http://revu.ubuntuwire.com/details.py?package=sabnzbdplus - the necessary update of mochikit has been done so that problem no longer exists
<persia> Piratenaapje, You want to have two stanzas in your debian/control.  One starting Source: and one starting Package:.  Take a look at some other debian/control files for examples.
<Piratenaapje> persia, ok thanks, I'll look around a bit
<Piratenaapje> Yay, packaging is done :D. Thanks everyone
<Piratenaapje> First some food, and then time to upload it :)
<tuxmaniac> Dear All, I want to add readme.source file for dpatch in debian folder. But the first line in thewiki page says from Janty you can just link it to the existing directory. Is this a symlink that is referred to or a file which just has the link mentioned?
<tuxmaniac> because I am on Intrepid and /usr/share/doc/dpatch/README.source.gz  iss not available in there and gives me an error
<Elbrus> tuxmaniac: I think just mention the file in the text in readme.source.
<Elbrus> if a user tries to build it needs dpatch and thus has the file
<Elbrus> IIAC
<tuxmaniac> Hmm okk Elbrus thanks
<Elbrus> tuxmaniac: see http://packages.ubuntu.com/jaunty/all/dpatch/filelist
<Elbrus> and indeed not on Intrepid
<tuxmaniac> Elbrus: yep. So I also suppose it is just the link to the file as text content of Readme.source.
<Elbrus> yes
<persia> Generally, I'd recommend something of the form of "THis package uses dpatch for patch management.  Please see /usr/share/doc/dpatch/README.source for details."
<persia> Or some other phrasing, but the point is to make it pleasant for a human to read.
<DktrKranz> broonie, thanks for uploading ;)
<broonie> np
<DktrKranz> Hoping it will have a different ending than previous try
<Ape3000> Where can I find a sponsor that would accept this: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/238179/comments/17
<ubottu> Launchpad bug 238179 in nautilus "Scrolling in CompactView doesn't work" [Low,Fix committed]
<pochu> Ape3000: #ubuntu-desktop, but not likely today (I'd suggest you ask on Monday or on a working day)
<pochu> Ape3000: also, you should attach a debdiff and not a diff.gz there
<Ape3000> So where do I get the debdiff?
<pochu> debdiff nautilus_2.25.3-0ubuntu2.dsc nautilus_2.25.3-0ubuntu3.dsc > debdiff
<pochu> Ape3000: we require diff.gz for new upstream releases, but for new debian revisions, a debdiff is easier to review
<Ape3000> But you cannot find the changed code in dsc-files
<pochu> Ape3000: the debdiff command will diff the two complete packages
<Ape3000> k
<pochu> including the diff.gz and orig.tar.gz where you made your changes
<pochu> just run the command without redirecting it to a file and you will see :)
<Piratenaapje> Is there anything special I need to add to the debian/rules file to add my manual entry? I made a debian/packagename.1 file, but it's not getting included for some reason.
<persia> Piratenaapje, You want dh_installman and to create debian/package.manpages
<Piratenaapje> persia: I allready call dh_installman, it just isn't including my file for some reason
<persia> You have a debian/manpages file?
<Piratenaapje> Whoops no, silly me
<Piratenaapje> persia: Weird, I didn't read anything about a manpages file in the maintainers guide, but it works now. Thanks
<persia> Piratenaapje, It's a good idea to read the manpages for the dh_* tools when using them.
 * didrocks strongly agrees. Furthermore, those manpages (dh_*) are clear enough to understand what is currently done over the package.
<didrocks> if anyone wants to give some love to http://revu.ubuntuwire.com/details.py?package=loggedfs, she/he's very welcome :)
<quadrispro> w-scan need some love, too -> http://revu.ubuntuwire.com/details.py?package=w-scan (it's almost ready to be advocated)
<quadrispro> s/need/needs
<binarymutant> are there certain days that the archive admins check the jaunty queue and email out any problems they find, etc ?
<james_w> jaunty queue?
<binarymutant> I'm not sure how else to put it, the queue that advocated packages from revu go to
<nhandler> The New Queue
<binarymutant> ya thanks :) the New queue
<james_w> it's done every so often
<binarymutant> like a once a week or month thing?
<nhandler> binarymutant: And I would assume that the Archive Admins each have their own personal schedule for when they go through the queue.
<nhandler> Usually, it takes about a week
<james_w> more than once a week
<binarymutant> thats cool, thanks for that info :)
<persia> There are currently four archive admins that have committed to looking at the queue once a week, although it doesn't always get cleared each day.
<binarymutant> thats cool that they have made a commitment
<binarymutant> they should get more karma :)
<persia> They certainly should.
<Piratenaapje> I just uploaded my package to REVU, how long does it usually take to show up? Or does not showing up yet mean I did something wrong?
<Piratenaapje> Disregard that
<binarymutant> thanks for the help
<persia> Piratenaapje, Generally it shows up in 5-10 minutes, and otherwise ask for a REVU Admin to help (although it maybe only matters for the future)
<Piratenaapje> Yeah it just showed up :)
<d7415> hi, if I want to add an new package to ubuntu, that has already been set up for Debian (but not in their repos) should I change the Maintainer field in debian/control? And is it better to work with the source tar.gz and recompile it?
<persia> d7415, Yes, change the maintainer field, and no, don't repackage it.
<persia> d7415, If it's expected to get into Debian soon, it's probably better to just let that happen, and sync it.
<Piratenaapje> So, I should now wait untill I get feedback from a reviewer or MOTU?
<persia> Yep.
<Piratenaapje> Allright, guess it's best I start studying for my exams then :s
<d7415> persia, ok - just to check that, if I have a tar.gz with a debian/ folder and a deb, I should get the deb and open it up? or run debuild on the tar?
<d7415> and I don't think it's going in - it has a .deb available for download though
<persia> d7415, If you have a tar.gz with a debian/ folder, it would benefit from repackaging, usually.
<persia> Mind you, it's usually not best to repackage something someone else is packaging without talking to them.
<d7415> ok. I might start looking at packaging it locally and get in touch with the developer
<d7415> thanks for the help
<lfaraone> Hi, how can I tell debuild to use a different compiler instead of GCC?
<persia> lfaraone, debuild doesn't use gcc
<persia> debuild uses make
<lfaraone> persia: well, it calls make which calls gcc.
<persia> Well, it calls debian/rules, which does whatever.
<lfaraone> persia: my main workstation is slow. I have another machine which is uber-fast, and I'm thinking of using distcc to speed  it up. without editing the makefile, is there anyway to change what compiler is called?
<lfaraone> persia: (building abiword)
<lfaraone> persia: In this case, make is eventually called.
<persia> You'd have to either patch the upstream build system to use something else, pass some options in debian/rules if the upstream build system supports that, or fiddle with symlinks in your build environment to confuse the build system.
<persia> lfaraone, Confusing the build system is probably your best option.  There's a guide on using distcc with pbuilder at http://blog.edseek.com/~jasonb/articles/pbuilder_backports/advpbuilder.html
<lfaraone> persia: would it be unbearably slow to run a build on a uber-fast-processer-machine with sshfs for disk-IO? (I only have one machine I want to cluster)
<persia> Depends on your patience.  network filesystems are *slow*.
<persia> If I had that situation, I'd probably set up a build server on the fast machine, and dput stuff from the slow machine.
<persia> deb-o-matic might be a relatively lightweight place to start
<lfaraone> persia: hm, /me looks.
<gregor_> Who is responsible of youtube-dl? Can you please add support, to download higher resolution videos? keepvid.com presents me a better version to download, example link: http://keepvid.com/?url=http%3A%2F%2Fde.youtube.com%2Fwatch%3Fv%3Dlqt9_9np4-8
<persia> gregor_, For that, I'd recommend filing an enhancement request upstream.
<james_w> gregor_: http://www.arrakis.es/~rggi3/youtube-dl/
 * persia admires james_w's google-fu
<james_w> copyright file :-)
<persia> gregor_, Contact information is at Freshmeat.
<persia> james_w, I always forget to do that.
<gregor_> yes, also checking the website james give me ;)
<pochu> does it happen to you that you think you get too many mail and think you should unsubscribe from some mailing lists, but then end subscribing to some more all the time? It even looks like a loop
<pochu> while (true) { printf("I should unsubscribe from some mailing lists\n"); subscribe_ml(); }
<persia> pochu, I'd recommend filtering your mailing lists, and having an ignore bundle.  When you think you should unsubscribe, push it to the ignore bundle.  If you find yourself looking at it often enough, bring it back.
<laga> persia: i wish thunderbird had a "kill this thread" button for emails. it works for newsgroups, though
<persia> laga, You might find a local SMTP->NNTP gateway helpful ...
<laga> persia: i might find a proper MUA helpful.
<cody-somerville> Whats the correct way of regenerating autoconf files if you have to?
<persia> Depends on the problem statement :)  If the problem is "I'd like to be able to read mail in a sane way", then yes.  If the problem is "Thunderbird lacks this feature, and I'm too lazy to code it", then no :)
<laga> persia: haha. true. :)
<dooooomi> what if the maintainer of a package changes while still in revu? should this be mentioned in the changelog, or should the previous changelog entry simply be replaced?
<ScottK> dooooomi: You can credit multiple people in one changelog entry.
<dooooomi> ScottK: ok, i'll do that. i was just wondering because for all packages i've looked at the first entry only said something like "initial release" and nothing else
<ScottK> Is this based on my comment yesterday?
<ScottK> I did a comment about something like this, but don't recall which package.
<dooooomi> ScottK: it is :)
<dooooomi> ScottK: the package is http://revu.ubuntuwire.com/details.py?package=pyliblo
<ScottK> Right.
<ScottK> So here's what to do ....
<ScottK> Edit debian/changelog so that it's just got the initial entry from the previous person
<ScottK> Then do dch Updated package:
<ScottK> Then when you open the changelog in your editor, it'll have a section for you and a section for the previous person's work.
<anakron> Hi all!!
<anakron> someone here use basilisk2? a macintosh emulator?
<dooooomi> ScottK: thanks!
<persia> anakron, I have
<anakron> it doesn`t have a desktop file and i want to help doing one
<anakron> but i dont know which category i must add it
<loic-m> contrib/otherosfs like uae?
<anakron> ill copy our conversation here
<anakron> hey, i wanna know if someone here think that the search tool could be better if it looks into the bug report
<anakron> and not only headers
<anakron> because when i try to find bug reports about "desktop files" it's difficult to define a good search, because the search tool doesn't look into the body of the bug report
<persia> anakron, Categories=System;Emulator;
<anakron> ok thanks
<anakron> :)
<persia> anakron, http://standards.freedesktop.org/menu-spec/latest/apa.html lists all the Categories, and can help to pick something.
<anakron> :) thanks!
<persia> For some emulators, for instance, the correct choice would be Game;Emulator;
<anakron> ok
<anakron> ill do a desktop file and upload it to the bug report
<anakron> but now i must wash the dishes
<anakron> :)
<loic-m> anakron: actually e-uae might be a bad example, the menu file has section="Applications/Emulators"\ but nothing appears in Gnome
<anakron> ok
<anakron> bye!
<persia> loic-m, Do you have the menu and xdg-menu packages installed?
<loic-m> persia: I've backported the packages on intrepid amd64
<loic-m> and installed the deb. I've got the menu file in /usr/share/menu/
<loic-m> and the pixmaps in /usr/share/pixmaps/
<persia> loic-m, Yes, but do you have the menu and xdg-menu packages installed?
<dooooomi> ScottK: what did you mean by "the licensing for the packaging points the license"? what exactly should i change?
<loic-m> persia: sorry, I didn't understand. I don't have menu or menu-xdg installed
<ScottK> Generally it's something like "Packaging is licensed under GPL v 2 or later.  See above."
<loic-m> persia: should the e-uae package depend on both?
<ScottK> dooooomi: It's a small point, but you want to point someone to the full text of the license in question.
<persia> loic-m, Please don't make it depend on them, but if you want to see the Debian menu (constructed from menu files) you need to install those packages.
<Piratenaapje> REVU warned me that I had several common errors in my package, is there any way to generate the lintian file without uploading to REVU first?
<loic-m> persia: the problem is users will look for an entry on the menu (e-uae has a gui)
<dooooomi> ScottK: oh, ok
<persia> Actually, you might have to depend on menu when providing a menu file: check the menu package documentation, but don't depend on menu-xdg: that just makes menu files appear in GNOME/KDE/XFCE
<persia> loic-m, Then please also provide a .desktop file.
<loic-m> persia: do the package need to depend on menu if I use a .desktop file?
<persia> loic-m, Please include both a menu file and a .desktop file.
<loic-m> persia: the menu file is already in the package, I'll read menu pkg doc to see if e-uae need to depend on menu, and I'll try to make a desktop file too
<persia> loic-m, That sounds like a good plan.
<loic-m> persia: however the package comes straight from Debian and has been sponsored "recently", the maintainer seems active so I'll get in touch with him, he might be also working in Ubuntu
<persia> loic-m, I'd recommend creating a .desktop file, testing it, and filing a bug in Debian.
<Piratenaapje> I'm an idiot, why didn't I google my question first?
<persia> It's not really worth a push to Ubuntu just for a .desktop file.
<persia> Piratenaapje, Also, please run lintian on your binary build: it provides a separate set of tests.  I recommend running `lintian -iIv` to get maximum verbosity.
<Piratenaapje> persia: ok thanks :)
<Piratenaapje> Hmm, still alot of things to fix
<loic-m> persia: i'll do that, thanks
<anakron> hi again
<weboide> Hey all, I'm trying to package a tarball but it says it needs to be built into another directory than the source dir (for autoconf reasons I guess), How can I do that in debian/rules?
<persia> weboide, You could create a ./build directory and then build it there in your build: rule.
<weboide> persia: And I don't need to clean this up?
<persia> weboide, You do need to clean it up, but you do that in your clean: rule.
<weboide> persia: okay, thanks for your help :)
<anakron> one question
<anakron> if the package doesn't give an icon
<anakron> and i want to add an icon for a desktop file
<anakron> how i can do it
<persia> I like gimp for creating icons, personally.
<anakron> but i and it like
<anakron> Icon=basilisk2
<anakron> and upload the icon too?
<anakron> http://basilisk.cebix.net/ this is the homepage of basilisk2
<anakron> i should use that apple like an icon?
<persia> Dunno if you can: that was the Apple logo at one point.
<anakron> yeah i know
<anakron> im looking in source package if there is any icon
<persia> I'd recommend using an .xpm or .svg icon, as otherwise you have to uuencode and uudecode it, which is annoying (unless you can convince upstream to ship it).
<weboide> persia: Do you have any idea of a package that I can learn from?
<anakron> i found one ico file in his Windows files...
<anakron> =S
<persia> anakron, Excellent.  imagemagick can convert that into .xpm, and you're all set.
<anakron> ok
<persia> weboide, I think torcs does that, if I remember correctly.  Of course, you'd probably like a smaller source package :)
<tdomhan> does the merge-o-matic merge from debian testing or unstable?
<persia> tdomhan, I think it merges from the last sync source for a package, which is usually unstable, but can be testing or experimental.
<weboide> persia: okay, I'll check it out :)
<anakron> mmm
<anakron> there are two icons
<anakron> one is called basilisk2.icon
<anakron> and the other is basilisk2GUI.icon
<anakron> and they are different
<persia> Which seems like the right one?
<anakron> ... one is a face
<anakron> and the other is a PC
<persia> They are about the same size?
<anakron> :O
<anakron> yes
<anakron> i think that i only put there basilisk2
<persia> Then pick the one you think should be best, and submit a .desktop file that uses that one.
<anakron> and upload both
<anakron> then the maintainer should choose
<Piratenaapje> If I force an upload to REVU with the same version number, the current version will be replaced right?
<ScottK> Piratenaapje: Yes.  No need to force, just delete the existing .upload file in your local directory.
<persia> anakron, No, pick one, and present a patch the maintainer can easily apply.  Mention in the bug description that there is another one, that the maintainer may choose if they like.  That makes is easier for the maintainer if they don't care which icon is used.
<anakron> ok
<Piratenaapje> ScottK: ok thank you
<Turl> hello, I did an updated version of proxychains, how can I upload it to revu?
<ScottK> Same way you did before.
<Turl> ScottK: I'm not the package maintainer
<ScottK> So it's an existing package in Ubuntu?
<Turl> yep, this version was out long ago, but the maintainer never upgraded the package
<Turl> any way of updating it then ScottK?
<ScottK> In that case, make a bug against the package in Launchpad, attach the diff.gz to the bug, and subscribe ubuntu-universe-sponsors to the bug.
<Webspot> Hi. How can I package something, with CDBS, from a VCS that uses autogen.sh to create a configure file?
<Turl> ScottK: I updated the .orig.tar.gz too, should I upload it? or you want a debdiff?
<ScottK> Turl: If you have a particular interest in the package, you might consider asking the Maintainer to let you take it over in Debian.
<ScottK> Turl: No.  The sponsor will get the upstream tarball themselves.
<ScottK> Since a debdiff would include all the upstream changes, it's of little point.
<Turl> ScottK: I'm doing this for a friend who needs it, and well, I did it, so why not contribute it?
<ScottK> Sure
<Turl> ScottK, ok then
<Turl> ScottK: the package is in my ppa, if you want to take a look https://launchpad.net/~turl/+archive
<persia> Webspot, You can either run autogen at packaging time, or have the build system run it before configure at build-time.  Check the CDBS Documentation for the guidelines on running things pre-configure.
<ScottK> Turl: I don't have time currently.  If you do as I suggested it'll get looked at in due course by a sponsor.
<Webspot> persia: But if I run it before building, it then complains that it's changed in relation to the .orig.tar.gz.
<Turl> ScottK: done https://bugs.launchpad.net/ubuntu/+source/proxychains/+bug/250973
<ubottu> Launchpad bug 250973 in proxychains "Please upgrade proxychains to latest version 3.1" [Undecided,Confirmed]
<Piratenaapje> Hmm I can't figure out why I'm getting this warning:
<Piratenaapje> W: grnotify source: changelog-should-mention-nmu
<Piratenaapje> the XSBC-Original-Maintainer value in debian/control and in debian/changelog are byte for byte the same
<persia> Webspot, You're using a patch system?  In that case, create a patch that is the result of having run autogen if you want to do it at packaging time.
<Webspot> persia: Okay. Thanks :)
<ScottK> Turl: That's good, but for Ubuntu it should be -0ubuntu1 not -1.  If it ever gets into Debian, we want their revision to be higher.
<persia> Piratenaapje, What version number are you using?
<persia> Or rather, revision number
<Turl> ScottK: the package is in debian already iirc
<Piratenaapje> persia: of what? lintian?
<Turl> ScottK: http://packages.debian.org/etch/proxychains
<Piratenaapje> 2.1.6 if so
<ScottK> Turl: I mean this version.
<persia> Piratenaapje, Of grnotify
<Turl> ScottK: should I fix it and reupload the diff.gz?
<ScottK> Turl: Yes.  I didn't look, but I'm guessing you also need to update the maintainer for Ubuntu.
<Piratenaapje> persia: I'm currently not using any revision controls system :p
<ScottK> Turl: The simplest way to do this is install the ubuntu-dev-tools package and then run update-maintainer from the package dir.
<Turl> ok ScottK
<persia> Piratenaapje, OK.  What's the first line of your debian/changelog?
<Piratenaapje> grnotify (1.0.2) unstable; urgency=low
<persia> OK.  I see the issue.
<persia> Does grnotify have an upstream or is it Ubuntu-specific for some reason?
<Piratenaapje> It's Ubuntu-specific for now
<persia> Is it the same as grnotify.sourceforge.net ?
<Piratenaapje> yes
<persia> Then it has an upstream :)
<Piratenaapje> Oh right :s
<persia> So, the part in parentheses is of the form ${version}-${revision}
<persia> You'd want something like 1.0.2-0ubuntu1 for a first upload to Ubuntu.
<persia> We track the revision number separately from the version so that we can upload multiple revisions of the same version with bugfixes, etc.
<Piratenaapje> Oh alright
<Piratenaapje> But that doesn't fix my problem I think?
<persia> Now, the NMU warning you're getting is because without the revision, the system that tries to detect whether you are uploading to Ubuntu or Debian is confused.
<persia> Once you change to 1.0.2-0ubuntu1, it will go away.
<persia> In Debian, the changelog signer must match either the Maintainer or one of the Uploaders in order to not be considered an NMU.
<persia> We use a very trivial method to detect Ubuntu revisions: a check for the string "ubuntu" in the revision number.
<persia> So, your package is being judged against Debian uploader etiquette, which results in that warning.
<Piratenaapje> Yay, no warnings now, thanks
<Piratenaapje> So when can I expect for someone to look at my package? Next REVU day?
<persia> Piratenaapje, Well, you could ask here for reviews, although people frown on anyone asking more than once every 25-30 hours.
<persia> It may be that the queue gets down by next REVU day, but as you can see, it's currently quite large, so it may be a while.
<tuxmaniac> Piratenaapje: the other way round could also be ping someone you know and request (politely) for a review when free. I have been waiting forone package of mine since last Ubuntu dev cycle :-P
<Piratenaapje> Well, it isn't that urgent, I'm just hoping I can get it in before the freeze.
<tuxmaniac> Piratenaapje: and also I tell you this becuase you would wait for say 2 weeks and then the reviewer gives you a big list of review points
<Piratenaapje> tuxmaniac: I've filed a bug request for someone to package it about a year ago. Still no response, so I decided to do it myself :p. So I'm not really in a hurry ;).
<tuxmaniac> Piratenaapje: by the time you fix it freeze would be in place. Also since 2 advocacies are needed you might end up waiting (mostly) for the next dev cycle. So ping someone you know politely and get it done ;)
<tuxmaniac> Piratenaapje: revu link?
<Piratenaapje> tuxmaniac: I don't know any MOTU's, so no luck there ;)
<Piratenaapje> http://revu.ubuntuwire.com/details.py?package=grnotify
<persia> Piratenaapje, There are bunches of MOTU in this channel.  Also, never turn down an offer for a review, even from someone who isn't MOTU: just having another pair of eyes on something can help a lot.
<Piratenaapje> Well, if anyone has the time to review it, feel free to ;)
<Turl> ScottK: it's fixed, https://bugs.launchpad.net/bugs/250973
<ubottu> Launchpad bug 250973 in proxychains "Please upgrade proxychains to latest version 3.1" [Undecided,Confirmed]
<ScottK> Turl: Great.  I don't have time/focus for a proper review now, but someone will get to it.
<Turl> ok :)
<Chris`> Did Norbert come in here this morning?
<frith> hello does anyone here know if i can set gcc search dirs per user?   gcc -print-search-dirs
<frith> so that would include my custom dir
<loic-m> When writing a .desktop file, can I just use full path for the icon or is this frowned upon?
<Webspot> If there is an MOTU avaliable, would they be able to review the changes I've made to osm-gps-map on REVU: http://revu.ubuntuwire.com/details.py?package=osm-gps-map Thanks.
<AnAnt> Hello, I am working on a package that is mainly LGPL+BSD. But there is a perl script included with this package (which is NOT linked against anything else), is there a problem with this ?
<Laney> AnAnt: Just put its license info in debian/copyrithg
<AnAnt> Laney: thanks
<Laney> (spelt correctly, of course)
<dooooomi> if someone feels like reviewing a python extension module: http://revu.ubuntuwire.com/details.py?package=pyliblo
<persia> loic-m, please use only the bare name.  No path, no extension.
<loic-m> persia: thanks
<loic-m> persia: my desktop file passes validation, and I know I've got to use dh_desktop to install it, but I've read the complete packaging guide + man and still have questions
<loic-m> persia: the guide says I've got to use dh_desktop in binary, but binary only has this: binary:	binary-clean binary-indep binary-arch
<loic-m> since dh_menus is in binary-arch, shouldn't dh_desktop be there too?
<loic-m> Also, is the .desktop file name just ".desktop" or "name-of-pkg.desktop"?
<persia> loic-m, dh_desktop doesn't install the desktop file: you'll need to do that with dh_install
<persia> Since dh_desktop can't rename files, use ${package}.desktop
<DktrKranz> persia, are you one of the ubuntuwire admins? rcbugs could be restarted at this point.
<DktrKranz> (or pointed to the correct release)
<persia> DktrKranz, I'm not.  I'm only an ubuntuwire website editor (I can change the list of tools, but not do anything with the tools).
<DktrKranz> wgrant, please read above when you catch up, thanks ;)
<CarlFK> http://packages.ubuntu.com/jaunty/amd64/ffmpeg2theora/filelist is missing ... basically everything
<afflux> CarlFK: bug 315356
<ubottu> Launchpad bug 315356 in ffmpeg2theora "No ffmpeg2theora binary in jaunty package" [Undecided,Confirmed] https://launchpad.net/bugs/315356
<CarlFK> thanks.  been meaning to search for that
<CarlFK> should this be this: DEB_MAKE_INSTALL_TARGET := install PREFIX=prefix=\$\(DEB_DESTDIR\)usr
<CarlFK> it works, but it makes me think something isn't quite right
<CarlFK> this part: PREFIX=prefix=
<afflux> CarlFK: are you still at ffmpeg2theora? That doesn't work for me.
<afflux> CarlFK: the makefile does not pass the prefix variable to scons (which is used for building, the makefile seems to be only for compatability), so scons tries to install to /usr/local instead of DEB_DESTDIR
<CarlFK> afflux: I hacked together what is needed to make it work
<CarlFK> with trunk, which includes an updated Makefile (I got head to add that so my hack didn't have to patch Makefile, which was giving me a headache :)
<afflux> ah, I see.
<CarlFK> check the bugreport, I just dumped my script
<CarlFK> i sent a nice post to the deb maintainer, and got a generic "please follow the procedures at bugs.debian.org
<CarlFK> went there, couldn't figure out what to do, gave up
<Laney> CarlFK: Run reportbug -B debian
<CarlFK> Laney: in any particular dir?
<Laney> It'll just let you type in a bug report
<afflux> CarlFK: a debdiff is in generall far more useful than a script using echo and sed. my solution for this bug, however, would be just adding the "common-install-impl:: scons install destdir=$(DEB_DESTDIR)" target to debian/rules.
<CarlFK> that seems better
<afflux> CarlFK: note that that's a newline after ::
<CarlFK> I figured someone would improve on what I did.  it was more proof that 'it doesn't take much'
<CarlFK> afflux: I have it working for me.  run reportbug :)
<afflux> CarlFK: you mean me?
<CarlFK> afflux: yes.  I am just passing on the advice I was given when I tried to offer what was needed to make it work
<afflux> CarlFK: ok. Why do you think this should go to debian? They seem to be using an older, unaffected version.
<CarlFK> afflux: who said I was thinking?  I have 0.0 clue who to tell what.
<afflux> ah ok ;)
<Laney> Can someone advise me on what to do here: http://paste.ubuntu.com/109083/
<Laney> is adding -fPIC to AM_CPPFLAGS in Makefile.am right?
<hyperair> mok0: ping
<Laney> (or should I not care?)
<mok0> hyperair: pong
<hyperair> mok0: regarding sigx, i've fixed the issues you mentioned in your comments. could you take a look?
<mok0> hyperair: yes
<hyperair> mok0: thanks
<mok0> hyperair: don't thank me yet :-}
<hyperair> mok0: =p
<afflux> CarlFK: patch added to the bug, waiting for sponsoring.
<emet> how can I go and request Qt Creator be packaged?
<afflux> emet: no need, someone did that before you: bug 309880
<ubottu> Launchpad bug 309880 in ubuntu "[needs-packaging] qtcreator" [Wishlist,Confirmed] https://launchpad.net/bugs/309880
<Laney> grargh
 * Laney kills ghc
<hyperair> Laney: i've uploaded bansheelyricsplugin to mentors.debian.net like you suggested =p
<Laney> hyperair: I'd take it to #debian-mono
<hyperair> Laney: on which server?
<Laney> oftc
<hyperair> ah
<mok0> hyperair: Have commented, 2 small things
<hyperair> mok0: ah thanks. but regarding doc-base, are you sure it's not already hooked up?
<hyperair> mok0: see debian/libsigx-2.0-doc.doc-base
<mok0> Sorry I missed that one!
 * mok0 kicks self
<hyperair> hahaha
<mok0> hyperair, are you prepared to help with work on packages that are not your own?
<hyperair> mok0: why not
<hyperair> mok0: what brought that up?
<hyperair> mok0: and by the way, i've just uploaded sigx again, with the change done to debian/copyright as per your comment
<mok0> hyperair: you need it if you want to go for motuship
<mok0> hyperair: great
<hyperair> hmm motuship eh
<hyperair> should i apply?
<mok0> hyperair: you need a portefolio of bug fixes, merges, syncs etc.
<hyperair> merges and syncs eh? i've never done any of those
<mok0> hyperair: they are a vital part of the workflow
<Laney> they are our bread and butter
<hyperair> hm
<hyperair> i'll go poking around for details of those then
<mok0> hyperair: there aren't many merges left
<mok0> hyperair:  you know DaD?
<hyperair> mok0: never heard of it
<mok0> http://dad.dunnewind.net/universe.php
<mok0> It the one most motus prefer
<mok0> hyperair: we also have mom: http://merges.ubuntu.com/universe.html
<mok0> Mom has a nice graphics thing at the bottom
<hyperair> i see
<hyperair> so between dad and mom which is preferred?
<mok0> hm, it looks like merges are going up lately
<mok0> ah, no those are syncs actually
<hyperair> come to think of it i know nuts about merging/syncing. how does a non-motu submit a merge/sync anyway?
<mok0> hyperair: many like Dad, because you can leave a small comment there
<mok0> hyperair: you file a bug at launchpad, and attach a debdiff
<hyperair> i see
<hyperair> does launchpad keep track of whatever you've done, or do you have to dig through old archived mail for it?
<mok0> syncs are unmodified Debian packages, but we need people to check that the changes do not introduce regressions and that they are generally safe
<hyperair> mok0: would debdiffs still be required for syncs?
<mok0> So for a sync, you make a small report on a LP bug
<hyperair> ah
<mok0> hyperair: no debdiffs for syncs, only excerpts of changelogs
<hyperair> i see
<mok0> hyperair: there are some guides on how to do it
<hyperair> when are merges needed?
<mok0> hyperair: when a Debian package has been modified in an Ubuntu specific way
<mok0> hyperair: some things are different in Ubuntu, so some packages need to be modified
<mok0> When a new version appears at Debian, you need to merge those modifications to the new version of the package
<mok0> ... and then we add a "ubuntu1" tag to the package release string
<hyperair> ah
<hyperair> right
<mok0> Mom & Dad can automatically do most of the merging
<mok0> but some conflicts often remain, and they need to be resolved by hand
<mok0> There is a script called "grab-merge", but beware it deletes the cwd. I removed that line from the script
<hyperair> i see
<hyperair> so must a package be listed on mom in order for grab-merge.sh to work?
<mok0> Let's see... I use the Dad script, will just check Mom's
<hyperair> dad script eh
<mok0> yeah, mom doesn't have one it seems
<hyperair> eh? it doesn't?
<Webspot> Are there any MOTUs available to review changes I've made to my REVU package, osm-gps-map? Thanks. http://revu.ubuntuwire.com/details.py?package=osm-gps-map
<hyperair> i thought the one listed here.. https://wiki.ubuntu.com/UbuntuDevelopment/Merging is mom's
<mok0> hyperair: anyway, it's good etiquette just to check with the last person who merged
<hyperair> mok0: check that the last person doesn't have plans for it?
<mok0> hyperair: exactly
<hyperair> mok0: ah i see
<tdomhan> how long are the delays after packages appear on mom/dad after a newer version of a package was released in the debian repos?
<mok0> tdomhan: not sure. I think the script runs at least once aday
<hyperair> mok0: thanks for the advocate
<hyperair> mok0: and the advice
 * hyperair needs to head to bed now *yawn*
<mok0> g'night hyperair
<hyperair> mok0: g'night
<Webspot> I've got another package I've just made today - pyofa - It's a python module for libofa, which makes audio fingerprints. If there's an MOTU available, could they look at this too: http://revu.ubuntuwire.com/details.py?package=pyofa - Thanks :)
<fransman> mok0: does it looks into the debian experimental as well?
<fransman> talking about bug #320607
<ubottu> Launchpad bug 320607 in gst-plugins-good0.10 "Please sync gst-plugins-good0.10 from Debian gst-plugins-good0.10 (0.10.13-1) experimental" [Undecided,New] https://launchpad.net/bugs/320607
<loic-m> From what I've read, Debian uses menu files while Ubuntu uses .desktop files for including an application in the desktop (Gnome/KDE/Xfce) menus
<loic-m> Is it correct?
<Piratenaapje> Someone told me the .orig.tar.gz should have a different name then the folder name. Is this true? And if so, what should I call the folder or .orig file?
<loic-m> Piratenaapje: folder name has a - where .orig.tar.gz has a _ for separating app name and version numbers
<mok0> loic-m: yes
<Piratenaapje> loic-m Ah thanks, I already somehow fixed that without knowing :s
<loic-m> mok0: so if an app synced from Debian doesn't have a desktop file, what do Debian devs prefer - that we submit the .desktop file + rules patch to them or just patch the package when it arrives in Ubuntu?
<loic-m> s/desktop/.desktop/
<mok0> loic-m: heh, good question. The best for us is of course if the Debian maintainer puts the .desktop entry in the package.
<mok0> loic-m: but we do carry many merges that are basically only the addition of a .desktop file
<loic-m> mok0: and the lines in debian/rules no? Can they do that if they don't use the .desktop file (=it will install it on Debian systems too)
<tobi_> is it only a sync if you drop the ubuntu changes of a, until then, merged package? Or if a package that was synced before gets updated in debian, and this version shall be used in ubuntu, too, is that a sync too?
<mok0> loic-m: I am not sure what the Debian policy on .desktop entries are... if they actively disencourage it
<mok0> tobi_:  yes it's always a sync if the package is unmodified
<tobi_> ok thx
<mok0> tobi_: but after the Debian Import Freeze, every sync needs to be argued for and tested
<loic-m> mok0: I might just email the Debian maintainer then, but if I file a bug in Debian do I just add the .desktop file, or a diff bw the diff.gz?
<coppro> apt-get usage quqestion: I'd like to stop using packages from a specific PPA. Is there a quick command to, once I've removed it from my sources.list, downgrade all the packages to the repo versions?
<tobi_> mok0: what are good reasons for a sync? bug fixes/features?
<mok0> tobi_: yes. Bug fixes are important.
<mok0> tobi_: often people paste excerpts of the changelog to document upstream's work
<mok0> tobi_: https://wiki.ubuntu.com/SyncRequestProcess
 * RainCT hugs VirtualBox
<jdong> `.
 * RainCT watches jdong 
<jdong> oh don't worry at the success I'm having with WDS/802.11N, you'll see some mangled ^A's too.
<maco> does motu handle multiverse too?
<jdong> yrd
<jdong> err, that's one-handed yes.
<maco> haha
<maco> ok
<maco> is sun-java6-jre broken in hardy?
<maco> i got a call from a 9 year old asking why her laptop wont update. it's giving her this error "E: I wasn't able to locate a file for the sun-java6-jre package. This might mean you need to manually fix this package. (due to missing arch)"
<SherokiX> good night
<jdong> I could've sworn I just brought a hardy system (with Java) up to date this afternoon
<jdong> I would be more suspect of local breakage
<maco> er ok...
#ubuntu-motu 2009-01-25
<jmarsden> Lintian warning of debian-changelog-file-is-a-symlink (using CDBS on Intrepid) is a Debian/Ubuntu philosophy difference I can ignore, right?
<mok0> right
<mok0> The symlinks are a Ubuntu specialty
<mok0> To save space on the CD
<Laney> Anyone got a pending sync? I want to test a fix to requestsync
<mok0> Laney: can't you use staging?
<Laney> If I knew how to tell requestsync to
<mok0> Laney: I'm sure it can be done but I can't tell you how
<Laney> right
 * Laney trolls the rcbugs page
<mok0> Laney: are you hacking the requestsync code?
<Laney> mok0: Just a small fix
<Laney> for bug #320984
<ubottu> Launchpad bug 320984 in ubuntu-dev-tools "requestsync fails with 401 unauthorized when adding subscribers" [Undecided,New] https://launchpad.net/bugs/320984
<Laney> I filed it and then felt guilty about being too lazy to fix it
<Laney> so decided to do so
<mok0> Laney: good for you!
<mok0> Laney: the file common.py has a lot of refs to launchpad
<Laney> I think it's get_launchpad
<mok0> get_launchpad? I don't see that anywhere
<Laney> ubuntutools/lp/libsupport.py
<mok0> Hm, my copy must be out-of-date
<Laney> this is latest bzr
<mok0> I have revision 99
<Laney> oh, interesting. requestsync seems separately broken
<Guest56275> Hi, I packaged the new version of zekr (0.7.2), the old version in ubuntu is 0.5.1. Can anyone take a look please? http://revu.ubuntuwire.com/details.py?package=zekr
<Laney> jpds: functions.py misses copyright info
<Laney> (it was you, right?)
<Laney> yes, it was
<Laney> bah, staging seems interminably slow
<Laney> mok0: If you have time, I proposed my branch for merging
<mok0> Laney: ok... what do you want me to do
<mok0> where's your branch
<Laney> mok0: bzr merge lp:~laney/ubuntu-dev-tools/dev in your copy
<Laney> review my changes then push it up if you'd be so kind
<mok0> Laney: actually, my copy is my own experimental branch
<mok0> I don't think I can push that elsewhere?
<Laney> you can bzr get a fresh copy of trunk
<Laney> I don't know if there's a better bzr workflow, probably is
<mok0> Laney: yeah... I only have a very rudimentary understanding of bzr... I use git mostly
<mok0> Laney: I'm getting a whole bunch of error message
<Laney> mok0: when doing what?
<mok0> bzr branch on your branch
<mok0> but the source is here now
<Laney> you should branch from trunk and then merge my branch
<Laney> I think that's the proper way
<mok0> Ah, ok, I'll try that
<Laney> hope I didn't break bzr...
<mok0> Well, it did something... let me pastebin the error message for your reference
<mok0> http://paste.ubuntu.com/109200/
<Laney> Oh yeah, I think that's just LP not supporting the newest bzr repo format yet
<mok0> Laney: I dunno... is it your branch that needs bzr upgrade??
<mok0> Ah
<Laney> maybe, it's harmless anyway
<Laney> laney@chicken:~/bin/ubuntu-dev-tools$ bzr upgrade
<Laney> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
<mok0> Anyway, what should I look at?
<Laney> you can "bzr diff" to see my changes
<mok0> bzr diff?
<Laney> then test a sync if you'd like, to see if it sets the bug as wishlist
<Laney> obviously I couldn't test that as I'm not in the team
<mok0> The change in functions.py, is... ?
<mok0> ah
<Laney> using the same name caused an error
<mok0> urlopener?
<Laney> yep
<Laney> urlopener = urlopener...
<mok0> oh yes of course
<mok0> was that never tested?
<mok0> Hm, so now I need to find a sync
<Laney> check multidistrotools
<Laney> pretty easy to find something worth syncing on there
<mok0> multidistrotools?
<Laney> quadrispro: syncs should be new until acked
<Laney> mok0: http://qa.ubuntuwire.com/multidistrotools/
<Laney> Sid version > Jaunty version is a good place to look
<mok0> Oh that
<quadrispro> oh Laney, I'm very sorry (and very tired) :) good bye
<Laney> heh
<Laney> night
<quadrispro> bye guys!
<mok0> Laney, hang on looking for a good one
<Laney> mok0: I'm not off yet
<maxb> Can syncs ever happen from places other than Debian?
<Laney> yep
<mok0> Laney: ./requestsync --help gives traceback
<Laney> not here
<mok0> NameError: name 'EDGE_SERVICE_ROOT' is not defined
<mok0> I'm an edge user
<Laney> I am too, but I don't see that. Where does the traceback come from?
<mok0> libsupport.py
<Laney> maybe it's your version of python-launchpadlib
<Laney> python-launchpadlib: Installed: 0.2~bzr25-0ubuntu1
<mok0> I don't have it
<Laney> that'll do it
<mok0> yep
<mok0> Is it using staging?
<Laney> if you add from launchpadlib.launchpad import STAGING_SERVICE_ROOT and then pass STAGING_SERVICE_ROOT as the second parameter to get_launchpad
<Laney> but I don't think staging is working atm
<mok0> I tried, and got a stacktrace
<Laney> try and visit http://staging.launchpad.net - it's dead
<mok0> http://pastebin.com/f35d63435
<mok0> He, yes, it's off on weekend
<Laney> you need the --lp param to use the new code
<mok0> oh yes
<mok0> That gave another problem but no exception
<Laney> (and to ./manage-credentials -c ubuntu-dev-tools)
<mok0> http://pastebin.com/f29502c64
<Laney> yep, you need credentials to use lplib
<mok0> That's new
<mok0> I need to give my lp password?
<Laney> no, you just need to authorise the application in launchpad
<Laney> manage-credentials will open a browser window to do this
<mok0> Oh, I'm remotely connected to my box via ssh
<Laney> heh
<mok0> I'm on my mac right now
<Laney> I don't know what it'll do then
<Laney> jpds wrote the tool
<mok0> I'm more trouble for you than it's worth
<mok0> Ah, it open elinks
<mok0> cool
<mok0> Laney: so now I'm on a screen where I need to authorize application
<Laney> yeah, that's right
<mok0> What privs does it need?
<mok0> "Read non private data"?
<Laney> and write, I think
<mok0> "Change non-private data"?
<Laney> sounds about right
<mok0> That can't hurt
<mok0> Ah credentials succeeded
<mok0> So now I will try requestsync again
<mok0> OK, it printed the changelog, and asks me if I want to edit the report
<Laney> good, that's what it should do
<mok0> (I wander wtf this rcconf is for )
<mok0> done. Bug 321004
<ubottu> Launchpad bug 321004 in rcconf "Please sync rcconf 2.0 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/321004
<Laney> wishlist \o/
<mok0> Laney: well thanks for the intro to launchpadlib
<Laney> you're welcome. It's going to be the way for apps to interact with lp
<skorasaurus> hi, how do i figure out what packages are required for a package ?
<mok0> Laney: so apps need to be authenticated, but can then manipulate the LP database?
<mok0> skorasaurus: for what purpose?
<mok0> dpkg-checkbuilddeps may be what you are looking for
<skorasaurus> mok0, the package (jabref) is updated upstream (by the dev), but debian hasn't updated their package to the newest stable upstream
<skorasaurus> if it's not too big of a task for me, I'd like to update for ubuntu.
<Laney> That's how I understand it, yes. You authenticate applications to manipulate LP on your behalf
<skorasaurus> http://packages.qa.debian.org/j/jabref.html
<mok0> skorasaurus: hm, normally you download the existing source package, and use uscan
<mok0> skorasaurus: but the watch file for jabref is broken
<skorasaurus> mok0, which src package ? the debian one ?
<mok0> skorasaurus: no, the ubuntu one
<mok0> skorasaurus: because jabref is a merged package
<ryakubo> hello
<mok0> goodnight!
<skorasaurus> g'nite.
<ryakubo> http://www.debian.org/doc/maint-guide/ch-start.en.html <-- this mentions being updated for potato and woody. is there anything newer I should be reading?
<DGMurdockIII> if you go there http://www.nvidia.com/object/product_geforce_9400m_g_us.html click buy now you will see who is using them
<ScottK> ryakubo: https://wiki.ubuntu.com/UbuntuDevelopment/FAQ has link to a number of good docs.
<ryakubo> ScottK: yeah, I'm checking everything out. This was linked from the wiki, I just wasn't sure if it was the most recent copy... looks like it is.
<ryakubo> mm, videos
<ryakubo> i'm a sucker for convenience :)
<DGMurdockIII> if you go there http://www.nvidia.com/object/product_geforce_9400m_g_us.html click buy now you will see who is using them
<DGMurdockIII> http://developer.nvidia.com/object/nvapi.html
<ScottK> DGMurdockIII: Spamming every Ubuntu IRC channel isn't going to win you any friends.
<DGMurdockIII> http://developer.nvidia.com/page/home.html
<ryakubo> i don't think nvidia even needs to spam. definitely not in a linux channel... :P
<sooth> Is there an easy way to add keys from the keyserver?
<sooth> (to apt)
<ScottK> Look at the instructions on backports.org.  It tells you how.
<sooth> Thanks
<ScottK> YW
<dooooomi> ScottK: weird, the pyliblo package built fine for me. i take it instead of adding debian/tmp to the paths i could also just take the manpages directly from the scripts directory?
<ScottK> dooooomi: Are you building in a pbuilder or similar chroot?
<dooooomi> ScottK: no, i'm afraid not
<ScottK> You have the package installed on your system, right?
<ScottK> dooooomi: ^^
<dooooomi> ScottK: pbuilder?
<ScottK> dooooomi: No. pyliblo
<dooooomi> ScottK: yes, but after your comment i tried uninstalling it and then rebuilding the package, still worked fine
<ScottK> OK.  You're .manpages file had /usr/share/man/man1/send_osc.1 in it.
<ScottK> Note the leading /
<ScottK> So that absolute path is where it was looking.
<ScottK> I'm guessing it worked for you because it was picking up the installed man pages.
<dooooomi> ScottK: oops, you're right. for some reason there were uncompressed manpages in /usr/share/man/man1 which didn't get deleted when i uninstalled the package
<ScottK> So that explains it.
<dooooomi> ScottK: ok, but scripts/send_osc.1 instead of debian/tmp/usr/share/man/man1/send_osc.1 would work?
 * ScottK looks
<ScottK> dooooomi: Yes.  Use that instead and delete the copies from your debian dir.
<ScottK> I didn't realize upstream shipped man pages.
<dooooomi> ScottK: there are no manpages in the debian dir, except for the "installed" ones in debian/tmp
<ScottK> Oh.
<ScottK> Ah.  Youre setup.py installs them.
<ScottK> Sorry.  It's late and I'm doing too many things at once.
<ScottK> dooooomi: In that case debian/tmp/usr/share/man/man1/send_osc.1 is the way to go.
<ScottK> dooooomi: This is also a good lesson on why building in a clean chroot is important.  The fact that you weren't masked a bug in your package.
<dooooomi> ScottK: ok, i've changed the paths and uploaded a new package
<dooooomi> ScottK: and setting up pbuilder is very high up on my todo list :)
<ScottK> dooooomi: If you install ubuntu-dev-tools it's as simple as pbuilder-dist jaunty create
<AnAnt> ScottK: Hello
<ScottK> AnAnt: Hello.
<AnAnt> ScottK: I have a question regarding zekr package
<AnAnt> ScottK: the one in REVU
<ScottK> Right.
<ScottK> It's 0.7.2.  All I found at zekr.org was 0.7.1.
<AnAnt> ScottK: if I attach a diff.gz file to a bug report, how will you get the orig tarball ?
<ScottK> From upstream.
<AnAnt> ScottK: oh, I will see with upstream about that
<AnAnt> ScottK: 0.7.2 was in SVN, and not tarball'ed it seems !
<AnAnt> ScottK: I
<ScottK> If you want to adjust your package for 0.7.1 we could go ahead.
<ScottK> Then you could update it once 0.7.2 is released.
<AnAnt> ScottK: I think they just forgot to release 0.7.2
<ScottK> OK, well I can't upload something called 0.7.2 until they do.
<ScottK> Anything particularly wrong with 0.7.1?
<AnAnt> ScottK: yes, of course, I'll contact upstream about that
<ScottK> OK
<AnAnt> ScottK: I dunno what's new in 0.7.2 actually, I am just co-maintaining the package with Derakhshani
<AnAnt> ScottK: so, will it be reviewed when attached to bug report ?
<AnAnt> ScottK: 0.7.2 is released it seems
<AnAnt> ScottK: http://zekr.org/quran/quran-for-linux
<AnAnt> ScottK: last link
<ScottK> Looking
<ScottK> AnAnt: Got it.
 * ScottK will look at it.
<AnAnt> thanks
<ScottK> dooooomi: Looks good.
<ScottK> AnAnt: You need to consolidate all the ppa debian/changelog entries.  Those packages weren't in Ubuntu so they aren't relevant.
<ScottK> Just add the useful bits into the current entry.
<ScottK> AnAnt: You also need to set the Maintainer to MOTU again.
<AnAnt> ok
<AnAnt> thanks
<AnAnt> can it be set to a team mailing list ? Ubuntu Muslim Edition Team <ubuntume.team@lists.launchpad.net>
<AnAnt> ah, nevermind, the team name must change anyways
<thepxc> hi! I have a quick question about my freshly created PPA. I've uploaded a package using dput, which does not let me upload again (since I already did). However, the package hasn't yet shown up in my PPA. When should I expect it/what can I do?
<ScottK> thepxc: PPA's have nothing to do with Ubuntu.  Ask in #launchpad.
<EagleScreen> it takes some hours
<thepxc> thanks and sorry for asking in the wrong place
<thepxc> I didn't mean to interrupt :-P
<ScottK> No problem.
<binarymutant> Am I allowed to change setup.py like a Makefile so that everything installs under /usr/bin instead of /usr/local/bin?
<jpds> Laney: manage-credentials opens up w3m if it can't open Firefox.
<jpds> And I'll add the copyright to functions.py.
<Webspot> If there are any MOTUs available, would they be able to review my packages on REVU: http://revu.ubuntuwire.com/details.py?package=osm-gps-map http://revu.ubuntuwire.com/details.py?package=pyofa - Thanks :)
<fabrice_sp_> Webspot, I'm not a MOTU, but I saw in your diff that you change a file outside the debian directory (build.cfg). Either patch it or if it's a temporary file. delete it in clean target
<Webspot> fabrice_sp_: Thanks. I'll take a look at that.
<fabrice_sp_> by the way, it's a huge version: 1.0.3+hg20090101+a08112357b80
<Webspot> fabrice_sp_: Is that bad? I included the date of the code checkout and the revision ID.
<fabrice_sp_> Webspot, I thnik the date is not usefull if you have the revision id
<Webspot> fabrice_sp_: The revision ids aren't ordered though, so a new revision could have an ID that is less, when ordered, compared to the last one, meaning it's not a newer version.
<fabrice_sp_> arghhh
<fabrice_sp_> Webspot, then only put the date
<Webspot> fabrice_sp_: Okay. Will do. Thanks for your help :)
<fabrice_sp_> Webspot, you're welcome :-) I'll continue to check you're packe, to see if I see errors
<ia> hello. i have a question about reprepro (it's a tool for creating deb repo) - does exist some way to turn off asking passphrase(but not signing packages for repo) each time, when package are putting in repo?
<binarymutant> is it allowed in the packaging policy to change a setup.py like a makefile so that everything is installed in /usr/ instead of /usr/local/?
<directhex> no package can install to usr/local
<binarymutant> I know, but am I allowed to change an upstream's setup.py like a makefile so that the source builds in /usr ? setup.py defaults to /usr/local
<binarymutant> if that makes sense...
<Laney> binarymutant: Is it normal for setup.py to install in /usr/local or is this a particular upstream curiosity?
<fabrice_sp_> binarymutant, by patch, yes
<Laney> you can either patch it, or use dh_install to put the files in the right location, or maybe cdbs/dh7 will take care of it automatically if this is a common case
<binarymutant> I'll patch it, thanks for the help
<binarymutant> what if my package made it to the new queue but I know there's something wrong with it? Should I reupload to revu?
<fabrice_sp_> binarymutant, yes. It's quite common to upload several times, without review
<binarymutant> thanks for the info :)
<fabrice_sp> Webspot, your package FTBFS
<fabrice_sp> I think you miss some build dependencies
<Webspot> fabrice_sp: Sorry? FTBFS?
<Webspot> Oh
<Webspot> Right
<fabrice_sp> Fail To Build From Source
<fabrice_sp> :-)
<Webspot> I'll have a look at that. Thanks again for looking at it.
<fabrice_sp> do you want the log?
<fabrice_sp> I can pastbin it
<Webspot> Yes please.
<fabrice_sp> http://pastebin.ubuntu.com/109335/
<fabrice_sp> good luck ;-)
<Webspot> Thanks
<DktrKranz> Laney, hi! Do you plan to manage haskell transition? I was looking at it, so we can share efforts
<Laney> DktrKranz: I was going to look at it today, shouldn't be too bad
<DktrKranz> Laney, good! quadrispro is after it too, so we can have this done very soon.
<Laney> btw we needn't have had it at all
<Laney> the merge wasn't necessary for us :(
<DktrKranz> yup, but now it's in, so we have to do it anyway
<Laney> correct
<fabrice_sp> Hi mok0: do you have time to re-review dvdstyler? ScottK find some things that I fixed in the last upload (like splitting the package in 2). You can find it at http://revu.ubuntuwire.com/details.py?package=dvdstyler. Thanks.
<DktrKranz> Laney, I'll add some more tasks on bug #320946, just to make sure we won't miss anything
<ubottu> Launchpad bug 320946 in haskell-utf8-string "Packages require rebuild due to new GHC6" [Undecided,Fix released] https://launchpad.net/bugs/320946
<DktrKranz> (unless you already filed similar bugs)
<Laney> DktrKranz: No, I just had to do that one for darcs. Please add all that are affected and I'll pitch in in a bit
<Laney> some will be syncs fro sid
<DktrKranz> good. please ping me for sponsorship once ready :)
<Laney> just playing l4d \o\
 * directhex startles the witch
<Laney> expert is pretty imposible
<Laney> +s
<mok0> fabrice_sp: yeah, sure
<mok0> fabrice_sp: I'll look at it later today
<bmm> If I run "sudo mount --bind -o ro /bin bin" from my home directory, then the files in bin are not read only and sudo vim bin/zless can still change the files. Mount says (ro,bind), but still ro is not applied. What is going wrong?
 * bmm thinks he is overlooking something stupid, but can't figure out what
<quadrispro> hi! anyone on bug 321124?
<ubottu> Launchpad bug 321124 in installation-report-generator "Please update installation-report-generator 0.2.0" [Undecided,New] https://launchpad.net/bugs/321124
<bmm> Ooh! I found it, I need to issue a remount after the mount :D
<Laney> bmm: Try #ubuntu for support
<quadrispro> hi Laney!
<Laney> howdy
<bmm> Laney: just found it and already tried that. But found the solution online already :D
<bmm> Laney: seemed you need to remount ro after the bind to get it to work.
<loic-m> james_w: ping
<Laney> DktrKranz: Just building everything
<Laney> debdiff flood imminent
<DktrKranz> Laney, cool!
<Laney> there's a couple that have to be done before some others
<DktrKranz> I'm testbuilding packages to be synced and file them once ready
<Laney> oh, I Was doing that too
<Laney> be aware that hdbc needs to be done before any of the hdbc-* ones
<directhex> sigh, i dislike the debian bts
<Laney> more than LP?
<DktrKranz> Laney, no problem then, I'll ACK syncs once they catch up
<Laney> nhandler: Haha, I just found an amusing bug in pull-debian-source
<Laney> laney@chicken:~/dev/ubuntu/packaging/haskelltransition/sync$ pull-debian-source omg-h unstable
<Laney> USAGE: pull-debian-source [-h] <source package> [target release]
<Laney> it parses the -h in the package name as asking for help
<Laney> easy fix, add a ^ anchor to the regex
<directhex> Laney, more than LP. debian has no "invalid" or "notabug" for one thing
<didrocks> I have my package waiting in REVU and have some typos issues and some sentences to rephrase. Can somebody just correct typos as I am not en English native speaker? Thanks: http://paste.ubuntu.com/109419/
<Laney> DktrKranz: debdiffs are up
<Laney> bug #320946
<ubottu> Launchpad bug 320946 in haskell-utf8-string "Packages require rebuild due to new GHC6" [Medium,Fix released] https://launchpad.net/bugs/320946
<DktrKranz> Laney, I'll have a look right now (and I commit pull-debian-source fix to bzr branch)
<Laney> DktrKranz: I'm off out but I will file any remaining syncs when I get back. They all seemed to build except for hdbc which I expected to fail
<DktrKranz> Laney, sure. Once filed, please ping/mail/subscribe me and I'll ACK them
<anakron> hi all
<Webspot> Hi. I'm having problems with pkg-config, while trying to package something for jaunty. On my intrepid system, "pkg-config --cflags libavcodec" gives me the cflags back, whereas jaunty just sends back a blank line. Can someone help me please?
<anakron> Hi all
<anakron> what do you think about it
<anakron> https://bugs.launchpad.net/ubuntu/+source/xsane/+bug/312123
<ubottu> Launchpad bug 312123 in xsane "xsane name in .desktop file is too long" [Undecided,New]
<anakron> it must be changed or not? im asking because i wanna know if it's right to do changes to this desktop file
<mok0> anakron: yes
<loic-m> didrocks: there's at least a spellchecker in gedit and kate. Running your text through it is a good habit if you want to contribute any text/doc in English
<anakron> ok ill do some changes in the desktop file
<anakron> but
<anakron> mok0
<mok0> anakron: it's a merge anyway
<loic-m> didrocks: f.e., "essentiel" would never pass any spellcheck afaik
<anakron> do you think that english comment and french must be changed
<anakron> or only french
<anakron> because french is too large
<anakron> its obvious that is a program
<mok0> anakron: what the bug suggests sounds perfectly reasonable
<didrocks> loic-m: hum, I will see how to have a English spellchecker in gedit in addition to my French one :)
<anakron> ok thanks :) ill watch it in debian too
<mok0> anakron: great
<pochu> Webspot: do you have the appropriate -dev package installed in jaunty?
<didrocks> loic-m: I think this is you who reviewed my work. Was my English so awful? :)
<loic-m> loic-m: tools>choose language... the English one is there by default
<Webspot> pochu: Yeah. I've also looked in the libavcodec.pc file in /usr/lib/pkgconfig. The Cflags line seems to be missing "/libavcodec" on the end. Is this right, or am I totally wrong?
<loic-m> didrocks: tools>choose language... the English one is there by default (sorry for the bad copy/paste)
<didrocks> loic-m: thanks. I am on it (I am more worried about rephrasing some complicated sentences)
<loic-m>  didrocks: tools>Set language actually ;)
<didrocks> loic-m: yes, I corrected myself :)
<anakron> mok0
<anakron> but is this issue is real
<loic-m> didrocks: split them so it's simpler, the rest a native English speaker might improve, but at least you get a good habit for other uploads
<anakron> i must take out all the "program" added
<anakron> or i must adjust to the bug
<didrocks> loic-m: ok. I will try. I have fixed other changes. Just this one is remaining
<anakron> in russian in can't do something
<anakron> XD
<loic-m> didrocks: pastebin it when you're done
<didrocks> loic-m: ok, thanks :)
<anakron> ping mok0
<pochu> Webspot: it can be ok as is, look at the changelog for what the reason was
<Webspot> pochu: Ok. I'll have a look. Thanks.
<mok0> anakron: ah you did ping me :-)
<Turl> surely a n00b question, but is there any way I can set up dch to use my correct mail and address?
<Turl> I hate to edit them by hand every time
<Webspot> pochu: Sorry. I'm quite new to all of this, shouldn't pkg-config --cflags libavcodec show "-I/usr/include/libavcodec/"?
<jcfp> Turl: set DEBEMAIL and DEBFULLNAME
<Turl> thanks jcfp :)
<didrocks> loic-m: is it better http://paste.ubuntu.com/109443/ ?
<loic-m> didrocks: I'm having a look
<didrocks> thanks a lot :)
<mib_pt8tdy91> hi
<fabrice_sp> mok0, did you had time to have a look at dvdstyler?
<fabrice_sp> hi mib_pt8tdy91
<mok0> fabrice_sp: not yet
<fabrice_sp> ok. Thanks anyway! :-)
<mib_pt8tdy91> fabrice_sp: hi
<mib_pt8tdy91> fabrice_sp: whats dvdstyler?
<fabrice_sp> a DVD Authoring tool that I packaged, and uploaded to REVU
<mib_pt8tdy91> fabrice_sp: is it like anyother DVD authoring tool or its special? :)
<fabrice_sp> well, it's the only one that really worked for me in Ubuntu
<fabrice_sp> (and I was using it in Windows before switching)
<Turl> fabrice_sp: is it like devede?
<mib_pt8tdy91> fabrice_sp: give a link to your app
<fabrice_sp> you can find it in my ppa
<fabrice_sp> (https://launchpad.net/~fabricesp/+archive)
<fabrice_sp> Turl, yes, it seems so
<Turl> fabrice_sp: does it allow you to set several soundtracks and subtitles for 1 movie? I need that functionality, and devede doesn't provide it
<fabrice_sp> Turl, I have to check, but I remember making DVD with 2 audio tracks
<loic-m> Turl: Avidemux doesn't either, I had to use mencoder :(
<Turl> devede uses mencoder iirc, it won't be difficult to add that functionality then
<fabrice_sp_> Turl, it can: http://dvdstyler.wiki.sourceforge.net/FAQMultipleAudio
<mib_pt8tdy91> QUESTION: How are versions made?If I start a new project is there any standards that I should follow?( for learning purposes)
<slytherin> Does anyone have any idea why would /dev/null have permissions 600?
<Turl> slytherin: no idea :/ mine is crw-rw-rw- (read-writeable by all)
<slytherin> Turl: yes, that is correct.
<fabrice_sp_> mib_pt8tdy91, what do you mean by version? Packaging an existing program, you mean?
<mib_pt8tdy91> fabrice_sp_: no I want to start a new project I have just packaged it and I want to give it some meaningful name that corresponds to [project name]+[stable release no]+[beta release no]+etc
<mib_pt8tdy91> fabrice_sp_: I think thats when version comes into the scene..Am I right?
<fabrice_sp_> mib_pt8tdy91, sorry, I don't understand what you mean. Are you asking for the package name of the app name?
<Guest92828> Hi ScottK, ScottK-desktop, thank you for reviewing zekr. Will you be kind enough to look over my new upload again.
<mib_pt8tdy91> fabrice_sp_: yes exactly
<Guest92828> ScottK: Sorry I forgot to give the link: http://revu.ubuntuwire.com/details.py?package=zekr
<Turl> mib_pt8tdy91: iirc, it's packagename_upstreamversion-debianrevision
<Turl> so for example, if my app is called hello and version is 3.9, bash_3.9-1 for a first revision of that version
<slytherin> Turl: he is not talking about versions in debia/ubuntu
<Turl> slytherin: then I don't get what he means :p
<slytherin> mib_pt8tdy91: I don't understand how can we advice you on the version number for your project.
<mib_pt8tdy91> slytherin: I am asking what is the importance of version number and why its so complex like bash_3.9_1 instead of hello1, hello2 and so on...
<Turl> what does this mean? W: aircrack-ng source: patch-system-but-direct-changes-in-diff patches/000-Airmon_needs_bash.diff and 1 more
<mib_pt8tdy91> Turl: I didn't get u!!!
<slytherin> mib_pt8tdy91: probably to separate name from version
<slytherin> Turl: you are using some patch system in the package. but some source is directly patched.
<Turl> yeah, I'm using quilt
<Turl> but quilt pop -a reports no source is patched
<mib_pt8tdy91> slytherin: There are many releases and patches and to separately identify the order they were released we use version numbers...right?Are there any standards?or simply we keep it as we like?
<rugby471> quick question, if you were replacing an image in a deb, how do you create a debdiff?
<Turl> mib_pt8tdy91: the version number should be the same as upstream, if that is what you want to know
<bholtsclaw> rugby471: uuencod'ed patch ?
<slytherin> Turl: can't help much without looking at package.
<rugby471> bholtsclaw:what's that?
<Turl> for example, application "myapp 5.9.8 was released". package would be myapp_5.9.8-1 for a first debian revision
<fabrice_sp_> Turl, did you export QUILT_PATCHES ?
<bholtsclaw> rugby471: a way to patch images in deb's
<mib_pt8tdy91> Turl: I am kinda new to ubuntu devs can you explain whats upstream?
<Turl> fabrice_sp_: nope
<fabrice_sp_> Turl, should point to debian/patches
<mib_pt8tdy91> Turl: I got it
<mib_pt8tdy91> Turl: but whats upstream?
<Turl> mib_pt8tdy91: upstream is the (group of) people who code the app
<rugby471> bholtsclaw:how does it work? is documentation of it on the wiki?
<mib_pt8tdy91> Thanx Turl slytherin fabrice_sp_
<Turl> for example, the "dd" upstream is GNU, ubuntu's upstream is debian, ...
<imbrandon> rugby471: i'm sure, lemme look
<rugby471> thx
<mib_pt8tdy91> Turl: The debian people develop and you distribute?
<mib_pt8tdy91> Turl: *you means Ubuntu
<Turl> mib_pt8tdy91: not really, but debian is the "source" of ubuntu
<Turl> ubuntu is based on debian
<mib_pt8tdy91> Turl: so Ubuntu takes some of the apps from debian edit its source code and then release it.
<mib_pt8tdy91> great
<Turl> sometimes, sometimes not
<mib_pt8tdy91> ya thats why I wrote "some" of the apps
<Turl> sorry, that one is a bad example
<mib_pt8tdy91> which one?
<Turl> the debian-ubuntu one
<mib_pt8tdy91> anyways I got the essence
<Turl> you know gcc, the C compiler? upstream is GNU
<mib_pt8tdy91> ya
<Turl> or brasero, the upstream is the GNOME guys
<mib_pt8tdy91> Turl: OK
<Turl> well, the W: aircrack-ng source: patch-system-but-direct-changes-in-diff patches/000-Airmon_needs_bash.diff and 1 more still is there, even after reextracting the original source and copying the debian dir, reimporting the patches and debuilding
<fabrice_sp> Turl, do you have a patches directory in the root directory?
<fabrice_sp> it seems that upstream is shipping this file
<Turl> fabrice_sp: i have debian/patches
<fabrice_sp> Turl, and not patches/000-Airmon... ?
<Turl> the patches in /patches are a totally different thing, except for the one "000-Airmon_needs_bash.diff" one
<fabrice_sp> so it seems you modified this one
<fabrice_sp> do you have patch to modify this patch?
<Turl> nope
<fabrice_sp> have a look at you diff file to see what has been changed
<Turl> it's the same patch I have in debian/patches
<Turl> ok fabrice_sp
<rugby471> don't owrry I found it https://wiki.ubuntu.com/PackagingGuide/Howtos/BinaryFilesInDiff
<Turl> fabrice_sp: it seems quint modifies both series files
<fabrice_sp> Turl, if you set QUILT_PATCHES to debian/patches, it shouldn't
<Turl> fabrice_sp: working fine now, thanks :)
<fabrice_sp> Turl, you're welcome ;-=
<Turl> how much time can it take for a sponsor to look at a bug?
<fabrice_sp> Turl, it depends. Did you subscribed u-u-s?
<Turl> fabrice_sp: yep
<fabrice_sp> Turl, if you put the status to Confirmed, it should be a couple of days
<Turl> it's already confirmed
<fabrice_sp> ok
<quadrispro> hi guys
<quadrispro> w-scan needs some love :) -> http://revu.ubuntuwire.com/details.py?package=w-scan
 * Turl hugs w-scan
<Piratenaapje> Is anyone welcome to fix the [needs-packaging]-bugs in the ubuntu launchpad buglist?
<fabrice_sp> Piratenaapje, I think that you will be more welcome if you fix others bugs report
<fabrice_sp> :-)
<quadrispro> bye
<Webspot> Hey. If there are any MOTUs around and available, could they review my packages at REVU? One is osm-gps-map, which is a GTK widget for embedding openstreetmap. And the other is pyofa, which creates audio fingerprints for files. http://revu.ubuntuwire.com/details.py?package=osm-gps-map http://revu.ubuntuwire.com/details.py?package=pyofa - Thanks :-)
<Piratenaapje> I should just reply to the bug and say that I'm trying to package it?
<Piratenaapje> Or do I need to offer mentorship?
<Webspot> Piratenaapje: I understand you assign the bug to yourself, and set it to in progress.
<slytherin> Piratenaapje: if you are going to package it, assign the bug to yourself
<Piratenaapje> Ah alright, thanks
<Piratenaapje> I have a question again: I want to package a program of which upstream development has stopped, but I've made some changes to it myself, to make it work a bit better.
<Piratenaapje> It isn't ok to package it with a higher version number I guess, so what should I do with it?
<pochu> Piratenaapje: put your changes in a patch, and patch the upstream version when building using a patch system
<Piratenaapje> pochu: Is it ok to release under a new version number then?
<pochu> Piratenaapje: no
<pochu> use what upstream has
<pochu> but patch it before building
<pochu> e.g. if upstream is 1.0
<pochu> you package it as 1.0-1, put a patch in debian/patches, and when building the patch is applied with your modifications
<pochu> the version is 1.0-1, that's not a problem
<Piratenaapje> pochu: But what if I want to actively develop it further?
<pochu> (if it's free software)
<pochu> Piratenaapje: then take over upstream
<Piratenaapje> Release it under a different name?
<Piratenaapje> Hmm ok, guess I'll try to contact the old developers
<pochu> Piratenaapje: you can do either that, or contact upstream telling you want to continue the project
<mabafu> hi there
<pochu> hi mabafu
<mabafu> hi pochu
<mabafu> I don't know if this is the propper... channel...
<mabafu> would like some hints on ubuntu development
<pochu> yeah, this is a good place
<pochu> mabafu: https://wiki.ubuntu.com/MOTU/Contributing is a good place to start
<mabafu> tks pochu
<fabrice_sp> One hour to start building a package in my ppa! Is there something heavy building?
<hyperair> pochu: you're a motu right? could you revu some packages for me? =p i'm missing a final advocate for two of them
<pochu> hyperair: which ones?
<hyperair> sigx and bansheelyricsplugin
<hyperair> pochu: ^
<pochu> hyperair: for bansheelyricsplugin, you want a review from directhex, but he's not a MOTU yet
<hyperair> pochu: hmm?
<hyperair> pochu: actually regarding bansheelyricsplugin i've uploaded it to mentors.debian.net
<pochu> ah, cool
<hyperair> pochu: so perhaps i should archive it or something
<pochu> I'm gonna review sigx
<hyperair> pochu: thanks
<pochu> hyperair: you can get it uploaded... jpds reviewed it and said he was happy, perhaps he would advocate it now
<pochu> hyperair: if you want it in jaunty, I suggest you get it uploaded to Ubuntu directly too
<directhex> with the same orig!
<directhex> fakesync sucks
<pochu> heh
 * directhex is still waiting for moon to pass NEW
<directhex> and i suspect mono 2.2 will need to be 0ubuntu1's due to NEWness
<fabrice_sp> ScottK, I've split dvdstyler in 2 packages, but doing so, I lost your advocate. Can you please check it? (or any other motu ;-) ). It's at http://revu.ubuntuwire.com/details.py?package=dvdstyler
<hyperair> jpds: could you advocate sigx please? you've reviewed it before
<hyperair> pochu: get it uploaded directly meaning?
<pochu> hyperair: weird that Debian #470532 isn't fixed
<ubottu> Debian bug 470532 in cdbs "cdbs: please add scons rules file" [Wishlist,Open] http://bugs.debian.org/470532
<pochu> hyperair: yeah, I mean don't wait for the package to get into Debian and pass NEW, because then it may be too late for Jaunty
<hyperair> pochu: in that case i should attempt to get one more advocate for bansheelyricsplugin on revu?
<pochu> hyperair: yes
<pochu> (not me)
<hyperair> pochu: heheh why not?
<pochu> if there were no advocates, maybe, but I'm not used to C# packages, so... :)
<pochu> hyperair: have you already asked sigx upstream to release a .tar.gz tarball for you? :)
<hyperair> pochu: eh no?
<pochu> hyperair: then do it so that you don't need to repakcage their tarballs ;)
<hyperair> sigh
<hyperair> but i've already repackaged it
<pochu> hyperair: yeah, I mean for the future
<pochu> scons -c distclean || return 0
<pochu> I think you want || true
<hyperair> oh
<hyperair> right
<hyperair> pochu: i'll upload another with the change
<pochu> hyperair: wait, I may find something else :)
<hyperair> pochu: alright
<pochu> I would use the changelog version for $UPSTREAM_VERSION, but that's just my opinion, it's fine as is
<pochu> hyperair: and $(DEBIAN_DIR) is just ./debian, no need for so many hacks ;)
<hyperair> pochu: according to the get-orig-source spec, it's supposed to be callable from any directory
<hyperair> pochu: ./debian only works if you're calling from the source directory
<pochu> hyperair: ah, ok
<pochu> hyperair: are you using debhelper compat 7 for any reason? if it works with 5, use 5
<pochu> (doesn't look like you use anything from 7)
<hyperair> pochu: i think dh_make made it like that =\
<pochu> hyperair: so change it :)
<hyperair> alright
<pochu> hyperair: and remove libsigx-2.0-dev.lintian-overrides, that's just a warning, it's Ubuntu specific and you can ignore it
<hyperair> pochu: i thought lintian had to be clean
<pochu> hyperair: mostly, but that's from an Ubuntu hack
<pochu> hyperair: and hiding a warning isn't exactly cleaning it :)
<pochu> i.e., if there's a reason to ignore it, just say so and we will ignore it when reviewing ;)
<hyperair> pochu: oh. okay then
<hyperair> heh. i had a whole bunch of lintian overrides for this issue in codelite
<hyperair> =\
<hyperair> and that's already accepted
<hyperair> no wait, uploaded, but not accepted
<pochu> hyperair: and remove the other override too, that's not even a warning! :)
<hyperair> pochu: eh okay
<hyperair> should i document all of this in README.source or something?
<pochu> what? the lintian warnings? nope
<pochu> ./usr/lib/sigx-2.0/sigxconfig.h
<pochu> ^ that looks not very FHS compliant...
<pochu> s/looks not/doesn't look/
<pochu> hyperair: libsigx-2.0-doc.docs shouldn't have docs/html, that should be in libsigx-2.0-doc.install
<hyperair> pochu: some other MOTU told me to shift it from .install into .docs
<hyperair> pochu: i think it's in the comments somewhere
<hyperair> pochu: also, why not?
<pochu> that's not a doc, they are a bunch of files :)
<hyperair> pochu: those are docs
<hyperair> pochu: once you run scons doc
<hyperair> pochu: also, in my defence about /usr/lib/sigx-2.0/sigxconfig.h.. there's a similar file in sigc++
<pochu> hyperair: README looks more something to be read by the person building it than the one using it... I'd remove it from docs
<hyperair> pochu: alright.
<bmhm> hi all
<pochu> same for TODO (looks for people developing sigx)
<pochu> hi bmhm
<bmhm> can someone help me with pbuilder pls?
<bmhm> just a small issui (i guess)
<hyperair> bmhm: ask and ye shall receive
<bmhm> http://paste.ubuntuusers.de/393885/
<bmhm> where does the+ trap - exit sighup come from?
<hyperair> pochu: i think the TODO might be good for telling the developers who use sigx what hasn't been implemented and so on
<pochu> hyperair: ok
<pochu> hyperair: the -dev package should be arch: all
<hyperair> ah
<pochu> hyperair: I think other than that, it's good
<pochu> well, I haven't looked into copyright
<hyperair> pochu: okay i'll make another upload
<pochu> hope you got that fine :)
<hyperair> pochu: well i followed licensecheck's output and made sure i covered everything =\
<bmhm> anyone got an idea?
<pochu> hyperair: looks fine, yes
<hyperair> pochu: are you sure the -dev should be arch: all? i get some non-binmuable lintian error
<pochu> hyperair: I also do `grep -Ri copyright *`
<pochu> hmm
<hyperair> pochu: and it seems i need to work around it by using Depends: libsigx-2.0-2 (>= ${source:Version}) and (<< ${source:Version}.1~) or something
<bmhm> :-/
<hyperair> bmhm: dyou have any strange pbuilder hooks?
<bmhm> well I'll post my pbuildrc, second
<bmhm> MIRRORSITE=http://archive.ubuntu.com/ubuntu
<bmhm> DISTRIBUTION=intrepid
<bmhm> OTHERMIRROR="deb http://archive.ubuntu.com/ubuntu intrepid universe multiverse"
<pochu> hyperair: ok, leave it as arch:any, its size is small so it's fine
<pochu> hyperair: ok, I think that's all from me :)
<hyperair> pochu: okay
<bmhm> oh and I just found a hook
<bmhm> http://paste.ubuntuusers.de/393886/
<hyperair> pochu: okay, i've made a new upload. could you look through it, and if nothing's wrong, advocate it please? =p
<jmehdi> Could someone review my package: http://revu.ubuntuwire.com/details.py?package=webstrict, I've fixed the latest problems (I hope)
<bmhm> well... any ideas now?
<pochu> Logged in as pochu (Contributor).
<pochu> WTF
<pochu> RainCT: ^ I want my Advocate checkbox back pliz :)
<RainCT> pochu: uhm?
<pochu> RainCT: REVU thinks I'm not a MOTU :/
<RainCT> REVU doesn't like you :P
<RainCT> did you do something bad to it?
<pochu> not really... I almost never visit it :)
<RainCT> pochu: so, you did something bad *G*
<RainCT> ok, you're reviewer
<pochu> doesn't REVU know that from LP anymore?
<pochu> hyperair: advocated
<hyperair> pochu: thanks
<RainCT> pochu: nope, that's on some long TODO list :P
<pochu> RainCT: ah, ok
<hyperair> mok0: sorry to ask this of you again, but could you look at sigx again? i've made a new upload.
<nellery> if a new copyright year is added to a new upstream release, should that be added to debian/copyright?
<dtchen> yes
<pochu> RainCT: ~motu is a member of ~revu-contributors so that MOTUs can upload to REVU, right?
<RainCT> pochu: revu-contributors is deprecated, obsoleted and whatever you want :P
<pochu> err, ~revu-uploaders
<RainCT> err, revu-uploaders ;P
<pochu> ah, good
<jpds> Que raro.
<pochu> so I want ~motu not be a ~revu-uploaders member anymore please :-)
<RainCT> pochu: logging in once is enough to be able to upload
<nhandler> pochu: We stopped using that team when we switched to openID for the logins
<jpds> hyperair: sigx looks good to me. Better without the *.symbols file.
<pochu> RainCT: so, can you remove MOTU from https://edge.launchpad.net/~revu-uploaders/+members? thanks :)
<hyperair> jpds: thenn could you advocate it? =p
<RainCT> pochu: won't that send a mail to everyone?
<pochu> RainCT: don't think so, there's a ML for the motu team
<pochu> and it will get moderated I guess
<RainCT> pochu: ML is only for bugmail
 * RainCT learned that the hard way :P
<jpds> RainCT: Well this time if something bad happens, you can blame pochu.
<pochu> ah, right
<pochu> hehe, yeah
<pochu> and I will blame Launchpad :P
<Piratenaapje> Hmm I've run into a problem: the program I'm currently packaging installs ode by downloading it, this is not the same version as is included in Ubuntu, which it won't compile with. Is it a problem if the configure downloads and installs a package?
<jpds> Piratenaapje: Yes, there is no networking on the build daemons.
<Piratenaapje> Ah crap
<Piratenaapje> jpds: would it be ok to have configure just build it, without downloading it?
<jpds> Piratenaapje: Could you upgrade the other package needed in Ubuntu first?
<jpds> Piratenaapje: Or you could patch the one you're working on right now so that it didn't download the other.
<bmhm> well
<bmhm> where can I ask about my problem then?
<Piratenaapje> jdps: It's a custom version of the library, so that's not a possibility
<jpds> Piratenaapje: Hmm, tricky.
<Piratenaapje> jpds: Patching the configure, and including the ode.tar.gz is allowed?
<Laney> convincing upstream to not need it is the best way
<Piratenaapje> "ODE is released     by distros in a lot of various versions (0.3x, 0.5, 0.6, CVS), wich makes     things very complex for us" is the reason they give for using their own version
<Piratenaapje> so not going to happen I'm afraid
<Laney> ?
<Laney> They can require a particular version (say 0.5), and then for a distro to use their software they must update the lib to 0.5
<jpds> Laney: They use a custom version appartently.
<Laney> broken distros aren't really their problem
<Laney> Then they should try to upstream their patches
<Piratenaapje> Well anyway, there hasn't been a new version released in 2.5 years, so I doubt anything is going to change :p.
<Laney> then you should consider whether we want to maintain unsupported software
<Piratenaapje> I was trying to package it because a [needs-packaging] bug was filed in launchpad
<Piratenaapje> Not by the actual developers I suppose
<Laney> we don't have to fulfill every needs-packaging bug
<bmhm> well can someone tell me why pbuilder gets an sigHUP?
<bmhm> http://paste.ubuntuusers.de/393885/
<Piratenaapje> Laney: so I suggest I stop trying to package it?
<Piratenaapje> *you
<Laney> Piratenaapje: It certainly sounds like something we don't want to maintain
<Laney> but if you want to fork it and become upstream...
<Piratenaapje> Guess it won't be packaged then :p
<ScottK> fabrice_sp: Why put all the usr/share/ stuff in the main package and not in the -data package?
<hyperair> jpds: thanks for the advocate
<Piratenaapje> Laney: thanks for saving me work :)
<jcfp> Laney: could you take a look at sabnzbdplus? You reviewed it recently, all issues you raised have been fixed (including upgrading the mochikit package)
<Laney> jcfp: I'm not a MOTU sadly
<bmhm> oh wait... http://paste.ubuntuusers.de/393888/ line 1063++
<bmhm> can you just take a look at it please?
<jcfp> Laney: bummer, you should be ;)
<Laney> soon
<Laney> jcfp: I never looked into it before, but the /etc/default behaviour seems odd. Did you get that from somewhere?
<Piratenaapje> What would be the best way to take over a old package? Take over upstream, or just fork it?
<jcfp> Laney: no created that myself, what's odd in it?
<Laney> jcfp: I'd expect it to just work I guess
<Laney> is there any reason why you can't create a sabnzbd user?
<pochu> RainCT: so, are you gonna remove it? :)
<jcfp> Laney: that creates other problems, such as permissions on download (they'd be owned by that user, etc)
<Laney> jcfp: The most similar package I can think of is torrenflux. Maybe you could look into how that package does it?
<jcfp> and also not everybody will want to run it at boot
<jcfp> i'll check
<Laney> jcfp: Right, then /etc/defaults/sabnzbd becomes a boolean flag
<Laney> startonboot = true
<jcfp> it already is, just that in this case the user being filled in or not functions as the kill switch
<jcfp> Laney: is there any "best practice" when it comes to creating users accounts like this?
<Laney> I really don't know - that's why I referred you to torrentflux :(
<jcfp> k, np
<Laney> actually, maybe that wasn't a good example
<Laney> I think torrentflux might be a PHP script
<Laney> think of your favourite daemon and see how it does this
<Laney> how strange, I don't get bugmail for new syncs any more
<oojah> Piratenaapje: If you can contact upstream and they're happy to hand on development, then I'd say doing that would be better than forking. Just my opinion.
<Piratenaapje> oojah: I've sent them a mail, but I'm not really expecting a response, their sourceforge page has been dead for over 2 years, and all I had was their sourceforge addresses :S
<Piratenaapje> I'll wait a week or 2 to give them a chance to respond though
<oojah> Piratenaapje: Sounds reasonable.
<dtchen> woops
<dtchen> forgot to sub u-u-s, done now if someone wants to sponsor the fix for bug 313820
<ubottu> Launchpad bug 313820 in ircd-ratbox "built source package crashes with buffer overflow" [Medium,Fix committed] https://launchpad.net/bugs/313820
<dtchen> (see the #ubuntu-devel irclogs from 2009-01-04 for verification from the reporter)
<Webspot> Hey. If there are any MOTUs around and available, could they review my packages at REVU? One is osm-gps-map, which is a GTK widget for embedding openstreetmap. And the other is pyofa, which creates audio fingerprints for files. http://revu.ubuntuwire.com/details.py?package=osm-gps-map http://revu.ubuntuwire.com/details.py?package=pyofa - Thanks :-)
#ubuntu-motu 2010-01-25
<dupondje> gotto sleep, thx for the help crimsun
<shadeslayer> jmarsden: there?
<shadeslayer> ok if the builder says dependency wait on some-dev file,is problem at my end?
<dupondje> oh its accepted :) thx :D
<shadeslayer> any ideas?
<crimsun> shadeslayer: which source package?
<asac> shadeslayer: depends on the case ;) ... if you are wondering about this, it probably means the problem is on your end, yes.
<RAOF> shadeslayer: That depends on whether some-dev is meant to be available in the archive.
<shadeslayer> https://launchpad.net/~rohangarg/+archive/kde-extra/+packages << choqok karmic package
<shadeslayer> i just sent it for a rebuild about 2 mins ago
<RAOF> That doesn't look like it's in dep-wait?
<RAOF> It's built successfully on lpia.
<shadeslayer> RAOF: yeah but for amd 64 it said dep-wait on libqt4-dev
<shadeslayer> RAOF: and btw are PPA archives expanded on requests?
<crimsun> it doesn't say anything of that sort for the amd64 karmic build
<shadeslayer> crimsun: yeah i sent it for a rebuild 2 mins ago
<shadeslayer> and what about : 1 failed
<shadeslayer> in completed builds
<RAOF> I think he might mean kopete-facebook?  That's dep-wait for libqt4-dev, which has a versioned dependency against a version that's not in Karmic.
<shadeslayer> RAOF: had the same error for choqok too
<shadeslayer> RAOF: can you explain the error?
<RAOF> shadeslayer: Does it really require libqt4-dev >= 4.6.0~rc1?  Because Karmic has 4.5.2
<shadeslayer> RAOF: 4:4.6.0-1ubuntu3~karmic1~ppa1
<shadeslayer> RAOF: in : 500 http://ppa.launchpad.net karmic/main Packages
<shadeslayer> RAOF: does this mean itll not build? or its just searching for that package?
<RAOF> shadeslayer: Yeah, but your PPA isn't building against that other random PPA; It's grabbing the libqt4-dev from the official archives, which have 4.5.2.
<shadeslayer> RAOF: so,will it build eventually?
<RAOF> No, it won't.
<crimsun> i.e., local repos have no bearing on repos available to your PPA
<shadeslayer> RAOF: ok so how do i get the required dep?
<crimsun> (could you imagine the chaos otherwise?)
<RAOF> If you add the PPA which contains 4.6.0 as a dependency of your PPA then it will build.
<RAOF> (And people who don't have that PPA in their sources.list won't be able to install your packages)
<shadeslayer> RAOF: where do i add this? im new to building stuff :P
<shadeslayer> RAOF: ok ill mention it in the PPA description
<RAOF> It's somewhere in the PPA setup page; I forget quite where.
<shadeslayer> ok
<shadeslayer> found it :)
<shadeslayer> and on what basis are PPA sizes increased?
<crimsun> Uploaders.gz, nice.
<ajmitch> crimsun: hm?
<crimsun> ajmitch: just musing over bits from planet.debian, 'tis all
<ajmitch> ah, I probably glanced at that post at some point
<ajmitch> or the rss client has yet to catch up :)
<ajmitch> now to convince wgrant to add it to soyuz...
 * wgrant is home now.
<ajmitch> wgrant: a nice quiet flight back?
<wgrant> ajmitch: The first was quite full, but the second not so much.
 * ajmitch went along to the open day on saturday for a bit, which was sort of interesting
<wgrant> Wellington seems to like pouring during the weekends.
<ajmitch> yeah, the weekend wasn't exactly useful for exploring wellington
<wgrant> We did wander around quite a bit on Saturday, while it wasn't raining.
<StevenK> ajmitch: Sort of useful?
<ajmitch> for about 5 minutes then?
 * StevenK had to leave the hotel at 4am for his flight
<wgrant> ajmitch: More like 5 hours.
 * ajmitch is glad he had a 7pm flight yesterday
<ajmitch> much easier to be awake then, and not have to stay up all night
 * wgrant was on the wonderful 6am flight too.
<ajmitch> now it's back to work, with a large pile of stuff to catch up on
<StevenK> ajmitch: Ditto.
<StevenK> wgrant: Ouch
<ajmitch> StevenK: since you hassled me about not doing much ubuntu work, got anything in mind that I should look at? :)
<StevenK> ajmitch: FTBFS? :-)
<ajmitch> ah, the rusty spoon option
<crimsun> speaking of which, why was libglade2.0-cil-dev demoted to universe?
<crimsun> some mono packages in main now FTBFS
<crimsun> even stranger, it only appears to have been demoted on i386? ...
<persia> Maybe an accept accident?
<crimsun> well, I haven't updated in a couple hours, so I could be outdated
<persia> ajmitch: If you want something simpler than FTBFS, NBS is always a good way to pass a few hours.
 * ajmitch sees a lot of zope.* packages in depwait
<persia> That would be the python-van merge.
<ajmitch> it requires a merge now? I'm seeing 1.3.0-3 on my lucid VM
 * persia gets confused and looks again
 * ajmitch doesn't know how often the autosync is still running
<ajmitch> https://edge.launchpad.net/ubuntu/+source/van.pydeb claims it was updated 38 hours ago, but the zope.* packages already want something newer
<persia> Indeed, it needs a sync.  I wonder how that worked, as it should have been caught in sid -> testing.
<ajmitch> I won't bother filing sync bugs for those ones just yet
<persia> Somehow the zope stuff migrated 17th Jan, and python-van.pydeb not until Saturday.
<ajmitch> odd
<persia> So probably just needs the archive-admin of the day to run a script (which shouldn't happen for many hours, given the identity of the AAotD, and their local timezone)
 * ajmitch doesn't know the archive admin rotation
<persia> Indeed.  Maybe it identifies some issue with sid->testing, because it's based on binary promotion, and doesn't guarantee buildability.
<persia> https://wiki.ubuntu.com/ArchiveAdministration#Archive%20days
<ajmitch> thanks
 * ajmitch wonders if james_w is even back home yet
<ScottK> I lot of Zope stuff is in churn right now due to python2.4 removal in Debian.
<ScottK> I/A
<persia> NCommander: Are you up for some bootstrapping today?
<RAOF> crimsun: libglade2.0-cil-dev is new, and arch:all (as are the rest of the -cil-dev packages).  We in the debian-cli team probably need to pay a bit more attention to what's happening in Lucid.
<ScottK> python-stdlib-extensions finally built on mips, so we should see python2.6 in Testing tomorrow.
<crimsun> RAOF: yeah, the rmadison output threw me
<ajmitch> ScottK: so the binNMU list will get processed sometime soon in debian, and things will settle down?
 * ajmitch has been following debian-python a bit
<ScottK> ajmitch: For a fairly wild definition of settle down, I imagine.
<ajmitch> but not -release
<ajmitch> I'm sure it'll be smooth & ponies will rejoice, etc
<ScottK> The binNMU list for dropping 2.4 was ~40 packages.  The binNMU list for adding 2.6 is over 300.
 * james_w is not here, but can run an auto-sync
<ajmitch> james_w: sorry, wasn't meaning to wake you from your jetlag or holiday :)
<james_w> no problem :-
<james_w> )
<ScottK> As long are you aren't breaking any of your rules about logging into the server holding the actual Ubuntu archive...
<james_w> heh, I think that rule has to be based on local timezone, or it would be too confusing :-)
<ScottK> The one I was thinking of was based on blood alcohol content.
<james_w> oh yeah, it's a little too early in the day for that to be a worry
<ajmitch> if you're still in NZ, then surely it's not too early?
<persia> Somehow that says more about NZ than about the time of day
<ajmitch> persia: true :)
<ScottK> It's always after 5PM somewhere.
<persia> Maybe I'm missing somewhere, but I don't think it's after 5PM Monday anywhere right now.
<persia> (should be about 16:45 furthest east)
 * ScottK didn't specify a day.
<ajmitch> persia: currently 17:15 in the chatham islands
<persia> ajmitch: I keep forgetting about them, and their special summer timezone.
<ajmitch> most people would forget about them
<persia> Well, it's only in the summer that it matters.  In the winter they have a more westerly timezone, and fall behind other places.
<shadeslayer> good morning :)
<NCommander> persia, of what?
<persia> fp-compiler on powerpc
<persia> NCommander: Essentially, it means stripping down the fpc source, building just fp-compiler, and then installing that result to be able to build fpc (which includes all the libraries).
<NCommander> persia, *cries*
<NCommander> persia, my PPC is semidead though :-/
<persia> NCommander: I thought that bootstrapping had to be done on the buildds.  If I give you some signed .debs, would that work?
<NCommander> persia, I can give lamont done debs, then he does a rebuild, but I can't do binary uploads
<NCommander> unless I have powers of which I'm thus unaware of
<persia> NCommander: Ah.  I picked on you because you're listed as in the assigned team for the bug :)
<persia> But if you could pass on bug #67544 that would be lovely.  I'm happy to generate a .deb if it helps, but I'm not convinced the buildds *should* trust me.
<ubottu> Launchpad bug 67544 in fpc "PPC build of fpc fails" [Undecided,Confirmed] https://launchpad.net/bugs/67544
 * james_w would like to remind everyone that we are still in the autosync time, and so don't need bug reports for syncs of unmodified packages
<james_w> oh, I see what's going on
<persia> unstable?
<james_w> yeah
<persia> While it's tempting to call it impatience, I know that we've seen a few things that FTBFS or DEPWAIT because sid->testing doesn't seem to check build-deps.
<james_w> I'm happy that it now takes longer for the automated parts of sync processing than the manual parts though
<StevenK> \o/
 * StevenK fixed that bit
<persia> Adding several "sleep 300" calls to the automated part?
<StevenK> persia: No, I wrote a script that automated large parts of the manual syncs
<persia> Oh, cool.
<StevenK> persia: Which james_w fixed to be even cooler
<persia> So, last I remember one just fed a bug number, and it did stuff.  Does it now automatically grab the bugs from LP rather than requiring one to type the numbers?
<StevenK> persia: That's the first script. I wrote a script that grabbed the bugs from LP and spat out lines suitable to be fed to the first script.
<persia> And it somehow detects when they are requests from unstable/experimental/testing?
 * persia remembers pain on this point previously
<StevenK> No, you can switch it, and it changes the output
<persia> Oh, so the script only pulls bugs from LP that match some specific debian pocket?
<StevenK> persia: http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/annotate/head%3A/sync-helper.py
<hyperair> am i allowed to call apt-get source within debian/rules?
<StevenK> hyperair: No
<hyperair> =(
<hyperair> hmm this makes it a tad bit harder..
<StevenK> hyperair: Well, explain why you want to?
<persia> Um, why not?  It should be fine as long as something has been arranged so it doesn't need network access.
<hyperair> StevenK: i'm working on packaging poppler-sharp
<hyperair> StevenK: poppler-sharp generates bindings based on the poppler code.
<StevenK> persia: You can't expect that it has on the buildds, for example
<persia> That's what build-dependencies are for :)
<hyperair> StevenK: i'm thinking it might be nice to use apt-get source to get the most current poppler source code so rebuilds are easy if poppler gets updated.
<persia> But the better way to solve it is to either build-dep on some poppler binary (generating a poppler-source binary is the least good way: doing it from header analysis probably easiest).
<hyperair> header analysis?
<persia> OR to have poppler-sharp be a patch against the poppler source and build as part of that.
<hyperair> hmm
<hyperair> that's an interesting idea.
<hyperair> i hadn't thought of that
<persia> Sure.  Presumably poppler exports some headers so stuff can build against it's C API.  Those should describe everything you need for bindings.
<hyperair> good point, i'll try looking into that
<persia> Investigating the other code is just asking to end up exposing a private interface that changes without warning.
<hyperair> what does gapi2-parser look at?
<RAOF> The headers.
<hyperair> alright. i'll see if i can force it to make do without the source then
<persia> StevenK: That is nifty.  I can think of ways to abuse it ("Please never, never sync this"), but it must save heaps of time.
<StevenK> persia: The script has a "Skip" for that
<RAOF> hyperair: Actually, poppler-sharp does that analysis at build-time?
<hyperair> RAOF: yes
<hyperair> http://github.com/jacintos/poppler-sharp
<hyperair> there isn't a tarball release
<persia> StevenK: That's not what I'm talking about (although, yet), but I'm not going into details here (plus I'll stop distracting you).
<RAOF> hyperair: Ah.  Generally, gapi users ship the pre-extracted raw symbols; that's how gtk#, gnome#, etc do it.
<hyperair> i see.
<hyperair> RAOF: should i convince the author to do that, or generate a tarball with pre-extracted raw symbols?
<RAOF> It's entirely possible that you want to generate the raw xml as a part of constructing the original tarball, given that you'll need to generate the tarball anyway.
<RAOF> Heh.  Too slow.  Yes, I'd generate the raw xml and shove it in the original tarball.  Convincing upstream to ship the raw xml is probably a good idea, too.
<RAOF> Um... they already *do*
<RAOF> http://github.com/jacintos/poppler-sharp/blob/master/poppler-sharp/poppler-api.raw
<RAOF> I don't think you actually need to have the poppler source available at build time.
<hyperair> RAOF: oh yeah, you're right!
 * hyperair facepalms
<hyperair> i was reading too much into the README
<RAOF> You may need to do steps (2) & (3) when generating the tarball, depending on how rapidly poppler's API changes.
<hyperair> hmm
<dholbach> good morning
<shadeslayer> dholbach: mornin
<dholbach> hi shadeslayer
<runasand> hm, how long does it usually take before a package is synced from debian to ubuntu? Or is this something I need to file a bug for? :)
<shadeslayer> dholbach: whats : https://wiki.ubuntu.com/MeetingLogs/devweek1001/AdoptUpstream
<dholbach> shadeslayer: Jorge and I will talk about https://wiki.ubuntu.com/Upstream/Adopt
<dholbach> brb
<shadeslayer> ok
<randomaction> runasand: if the package is in testing and Ubuntu version has no Ubuntu-specific changes, it usually takes 1-2 days
<runasand> randomaction: ok, thanks :)
<shadeslayer> how long does it take to be a MOTU?
<shadeslayer> *become a
<persia> shadeslayer: There's no time rule, but there is a typical expectation of having been involved in Ubuntu Development for a complete development cycle (although there have been exceptions).
<dholbach> I personally like the question "how long until I can start contributing?" better :-)
<persia> But that has the simple answer "No time at all, you can do it today" :)  Plus, shadeslayer was already working on the kopete-facebook update and backport
<persia> (and maybe other stuff I didn't see)
<hyperair> mok0: could i bother you with bug #511375? =)
<ubottu> Launchpad bug 511375 in codelite "codelite high cpu usage from ubuntu package" [Undecided,Confirmed] https://launchpad.net/bugs/511375
<mok0> hyperair: 2 secs
<SevenMachines> hi there, i was looking to merge gstreamer0.10-plugins-bad from debian unstable but the lv2 plugin fails all its tests. is it better to leave it in even though its probably broken or disable it? http://paste.ubuntu.com/362562/
<persia> SevenMachines: You may have identified why it FTBFS on all arches (see http://qa.ubuntuwire.com/ftbfs/)
<persia> Does lv2 work even though it fails the tests?  Maybe we need newer lv2 libs?
<persia> ScottL: Do you know anything about gstreamer & LV2 ?
<SevenMachines> i fixed the FTBFS with 0.10.17-1ubuntu2 but it was recommended to merge with sid since it essentially contains the same patches but also fixes a crash they introduce
<SevenMachines> ah, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549189. i guess it shopuld be disabled then
<ubottu> Debian bug 549189 in gstreamer0.10-plugins-bad "gstreamer0.10-plugins-bad: Crashes every gstreamer-aware app" [Critical,Fixed]
<persia> heh.  So if you merge 0.10.14-4, you disable with no crash :)
<persia> And if ScottL (or someone) can figure it out, it can be re-enabled (I pick on ScottL because I know he was working on lv2 stuff)
<SevenMachines> 0.10.14-4 isnt even in sid yet for whatever reason, 0.10.14-3 with lv2 disabled should be ok though?
<persia> Erm, we've both missed something critical :)
<persia> 0.10.14-4 << 0.10.17-3
<SevenMachines> :)
<SevenMachines> i'll give it a test with lv2 enabled and see what happens, i'll probably disable it though unless someone who knows about these things thinks different
<persia> Really, I think you need to connect with ScottL, if you can.
<persia> There may be someone else, but that's the name that shows up with LV2 the most in my logs.
<persia> You might need a newer LV2 or something, but I'm not sure.
<MohammadRRR> Hi , I Have A Lot Of Deb Files And I Have Created Packages.gz file now i want to create Release File What Should I do ?
<persia> Capitalise less?
<persia> Aside from that, apt-ftparchive is a quick'n'dirty way to do things.
<mok0> hyperair: you need sponsorship I guess...
<hyperair> mok0: yeah i do.
<MohammadRRR> persia : could you plarese help me what should i exactly Enter . i am a beginner
<mok0> hyperair: great, I'll take a look after lunch
<hyperair> thanks =)
<persia> MohammadRRR: I don't remember precisely.  `man apt-ftparchive` may be useful.  You may also want to try the support channel (#ubuntu)
<MohammadRRR> persia : First i have gone there but they said I sould come here . i have read the manual but i have not learn anything please help
<persia> Hrm.  Well, I don't remember precisely, so I'm not the best person.  We don't generally create archives here (we use Soyuz), but maybe someone else can help you.
<mok0> MohammadRRR: usually the tools create the Packages.gz etc files
<SevenMachines> looks like libgstlv2 really does segfault gstreamer, its not just failing tests
<persia> Can you get a stacktrace?  Is it just unsafe coding and easy to fix?
<shadeslayer> persia: hey
<persia> shadeslayer: Hey.
<shadeslayer> persia: ive built packages for lucid and need sponsors for updating the packages there... where do i find motu sponsors?
<shadeslayer> persia: file a bug in launchpad?
<persia> !sponsorship
<persia> !sponsor
<persia> Grr.
<shadeslayer> https://wiki.ubuntu.com/SponsorshipProcess
<persia> Right.
<shadeslayer> yeah as it says.. file a bug,against what?
<persia> shadeslayer: The package that has the "problem"
<shadeslayer> persia: ah ok
<shadeslayer> was reading https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue
<shadeslayer> persia: do i give them a link to my PPA too where the package is being held?
<shadeslayer> or do i attach the files..
<persia> I usually prefer a debdiff against the current source, or an attached diff.gz for an update.
<shadeslayer> hmm
<SevenMachines> persia: i'll try and get a trace, i can see why debian never actually put it in the .install though, although they do build it
<persia> SevenMachines: If you install pkg-create-dbgsym in your local builder, it gives you ddebs, which can be handy for that.
<persia> Do you know how to track down the crash once you get the trace?
<SevenMachines> probably not
<persia> Well, if you can get a trace (with symbols) within the next hour, ask me, and I'll debug it with you.
 * geser sees persia giving an ad-hoc "Interpreting stack trace" session :)
<persia> If it takes longer, ask here and maybe someone else will.
<persia> geser: That's the way I prefer them, really.  Nobody asks enough questions in formal sessions.
<geser> yes, it's often easier to learn from own cases (you're more interested)
<SevenMachines> i've seen enough stack traces in my own c++ stuff but i know literally nothing about gstreamer
<persia> Doesn't matter.  Code is code.  I remember foolishly picking an ObjC crash for a session once, and it ended up that the attendees (largely geser, IIRC) helped me understand it :)
<persia> At the final stage, when you find the problem function, then you need to know, but at that point the entire framework doesn't much matter anyway.
<mok0> hyperair: "patch unexpectedly ends in middle of line"
<hyperair> huh?
<hyperair> O_o
<hyperair> how are you getting that?
<mok0> hyperair: patch -p1 < ../codelite-debdiff
<hyperair> weird..
<mok0> hyperair: it successfully patched 3 files
<mok0> hyperair: "Hunk #3 succeeded at 40 with fuzz 1."
<hyperair> hmm
<hyperair> maybe the uploaded package to the archive does not match my local git tree
<mok0> hyperair: I'm concerned that debian/patches/03_move-helper-binaries.patch might be screwed up
<hyperair> it was screwed up
<hyperair> that's the cause of the bug.
<mok0> hyperair: can you send me the proper one?
<hyperair> http://paste.ubuntu.com/362595/
<hyperair> gimme a moment to dget codelite
<hyperair> mok0: the patch uploaded seems to be screwed up for some reason or other. weird.
<mok0> hyperair: I think it's a missing newline at the end
<hyperair> http://paste.ubuntu.com/362600/
<hyperair> use this instead
<hyperair> i generated it the same way
<hyperair> i'm thinking something happened while i was uploading the attachment
<mok0> hyperair: ok
<hyperair> yeah it seems to be missing a newline.
 * mok0 tries again
<hyperair> weird. i wonder if thunderbird's whacking up my patches..
<mok0> hyperair: patch works now w/o problems
<hyperair> mok0: that's good =)
<mok0> hyperair: doing a test build now...
<hyperair> that can take a while, depending on the machine =p
<mok0> hyperair: I know, I've compiled codelite several times :-)
<hyperair> figures =p
<mok0> hyperair: my machine is pretty fast though
<hyperair> that's good
 * hyperair uses ccache to compensate
<mok0> hyperair: it's a quad6600
<hyperair> that is fast
<hyperair> i had to undervolt my CPU to get codelite to testbuild on my notebook
<hyperair> there are only two compilations that can drive my CPU that mad -- codelite, and the kernel.
<mok0> hyperair: I've had it a couple of years now, I'm still very happy with it
<mok0> heheh
 * hyperair still runs a dual core..
<mok0> the q6600 was the best price/performance cpu you could buy for a long whle
<mok0> Haven't checked TomsHardware for a while now
<hyperair> hmm
 * hyperair didn't go shopping for desktops
<hyperair> live in a dorm overseas, can't drag that many things along with me
<mok0> hyperair: you don't have to. Have you ever heard about something called "Internet" :-D
<hyperair> mok0: mm yeah. it's a very familiar sounding word. i wonder what it was again..
<hyperair> =p
<mok0> :)
<hyperair> my desktop's still going strong
<hyperair> my single-core P4
<hyperair> ;-)
<mok0> hyperair: nice and CO2-friendly
<hyperair> well everything about it except the CMOS battery holder which doesn't seem to want to connect my CMOS battery to the motherboard (so when it's unplugged, the clock resets), and the stupid nvidia GPU flickering away..
<persia> CO2-friendly?
<hyperair> but i'm sure the nvidia GPU flickering is a fault of the stupid legacy driver.
<mok0> persia: uhm, older CPUs tend to use a lot less energy
<hyperair> mok0: do they?
<mok0> Yeah
<hyperair> mok0: iirc multicores use less..
<hyperair> because they can run at lower frequencies, yada yada
<persia> It really depends on the CPU.
<hyperair> oh it doesn't help that acpi-cpufreq conveniently removed support for my CPU.
<Laney> I thought P4s weren't so good on energy consumption
<mok0> hyperair: yes that's true. Hmm, I guess you have to go back to P3's to get a lot lower power consumption
 * persia has single-cores that run <1W and multicores that run >70W and vice-versa
<hyperair> O_o
<hyperair> 70W?
<hyperair> i can power several notebooks with that you know?
<hyperair> like three notebooks.
<mok0> 70W is what I've read
<hyperair> three notebooks playing music and compiling kernels at the same time
<mok0> hyperair: indeed
<persia> hyperair: There are >100W processors available, if you have the cooling.
<hyperair> with maximum panel brightness
<persia> Lowest number I've ever seen is 0.2W
<hyperair> 0.2 is tiny
<hyperair> seriously tiny.
<mok0> persia: for what....?
<mok0> persia: ARM?
<hyperair> that'd explain why our ARM buildds are so slow =p
<persia> ARM & SH both get that low.
<hyperair> (at least, i think it was arm that was slow)
<persia> The ARM buildds aren't anything so low :)
<mok0> I think the marvell wall-plug server uses a couple of watts
<persia> sparc seems slowest from my "rebuild foo on all arches" tests.
<persia> SheevaPlug?  I think that's 5-10 or so.
<mok0> persia: OK, I stand corrected
<persia> Unfortunately, dist-upgrade to karmic on that crashes hard.
<hyperair> ouch.
<mok0> persia: is that a kernel related issue?
<hyperair> speaking of dist-upgrade, i should probably dist-upgrade to lucid one of these days.
<mok0> hyperair: ugh
<hyperair> mok0: is lucid in a bad state at the moment?
<mok0> hyperair: I dont know.... karmic was in a pretty poor shape even at release time
<persia> mok0: ISA issue  The processor doesn't support the ISA used for armel in karmic.  Like trying to run Karmic on an i386
<hyperair> mok0: but karmic now is splendid!
<hyperair> mok0: and i was pretty happy with karmic from the betas all the way up
<hyperair> make that alphas
<mok0> hyperair: it's fine now
<mok0> I've become very sceptical about the fixed release schedule
<hyperair> i'd say karmic's the best ubuntu release since intrepid.
<hyperair> but yeah, the fixed release schedule is a little annoying sometimes.
<hyperair> perhaps we need to push freezes earlier?
<persia> kernel doesn't work either, but due to the annoyances of ARM kernels, you basically need a separate kernel for *every* board, and there's only a couple supported in the archives.
<persia> We need to push testing harder.
<mok0> Yes
<persia> Way back when, we used to close lots of the bugs.
<mok0> Now it doesn't matter how many bugs are open
<mok0> Release before all
<persia> Now, we have lots and lots of bugs, and lots of people don't even bother to try to get all the merges done immediately or fix all the NBS / FTBFS right away.
<persia> No, it was Release-on-Release-Day back then too.
<persia> We just tried harder.
<mok0> persia: "well, we can always fix those bugs in the next release"
<hyperair> afaik 6.06 was pushed back
<hyperair> i mean why wasn't it 6.04?
<hyperair> maybe we should do the same for lucid.
<persia> I don't think it's worth it.  it didn't help much for Dapper.
<mok0> There should be 1 year of development for the LTS
<persia> Things age too quickly for that.
<hyperair> agreed
<persia> Essentially, there's 2 years of development for an LTS.
<persia> But it's a mindset thing.
<mok0> persia: how's that?
<persia> Well, right now FTBFS and NBS are full of stuff.  Those need clearing.
<hyperair> i can't seem to bring myself to spend the effort backporting things all the way down to hardy in my PPA despite it being a LTS
<persia> Once clear, we should chase UEHS.
<hyperair> what's NBS?
<hyperair> and UEHS?
<persia> If that's clear, then it becomes worth doing things like piuparts testing or autopkgtest.
<persia> But if we're not even keeping up with NBS and FTBFS, it's hard to suggest doing more QA stuff to make sure the release is clean.
<persia> hyperair: NBS is stuff no longer built from source.  Transitions.
<hyperair> i see.
<persia> So if Package A used to build libfoo1 and now it builds libfoo2, we need to migrate everthing.  The NBS page lists everything needing work.
<persia> UEHS is the Ubuntu External Health System.  For all the packages that aren't maintained in Debian, it checks what has watch files, and tells us what we need to merge directly with upstream (as opposed to just what we need to merge from Debian).
<hyperair> i see.
<persia> In my opinion, if we manage a release with clean FTBFS, NBS, UEHS, and rcbugs, we'll be in very good shape.
<persia> But it's been a while since we managed that.
<mok0> persia: I agree, but there's no concerted effort
<persia> hyperair: If you want more info: read https://wiki.ubuntu.com/UbuntuDevelopment/NBS
<hyperair> i should spend some time looking at these lists. i admit i haven't actually looked much
<persia> mok0: How do you think it should be concerted?  In the past, we used to just put QA tools in the /topic, and people did them.
<mok0> persia: I don't see the MOTU working as a team anymore
<persia> How can we improve that?
<mok0> persia: I don't know... but now the MOTU team seems to be disbanded anyways
<hyperair> aren't the MOTU disappearing?
<ScottK> No
<hyperair> yeah like that
<mok0> yep
<hyperair> disbanding.
<ScottK> That was the plan at one point, but not anymore.
<hyperair> oh it isn't?
<hyperair> so what's the plan now?
<ScottK> The plan is that we're working on a plan, but it ought to look a lot like what we had before, but with combined SRU/release/sponsorship teams.
<persia> The discussion is very current, and likely to come to conclusion on 2nd February.  https://wiki.ubuntu.com/Specs/MOTULucid has more.
<persia> Err. https://wiki.ubuntu.com/Specs/LucidMOTU
<hyperair> aj
<hyperair> ah*
<persia> The DMB is expected to review that spec on the 2nd, and we should understand the future more clearly.
<mok0> That discussion has been going on waaay too long, and without the participation of the MOTU team
<persia> But, yeah, I think the uncertainly (since Intrepid) hasn't helped any.
<ScottK> mok0: We had a session at the last UDS that had a lot of MOTU participation.
<persia> mok0: I'm not sure that's accurate.  Many MOTU have been involved in the discussions.  I know I've been vocal, and I've seen others.
<mok0> persia: ... out of the 80+ motus?
<persia> And lots of MOTU participation at the UDS sessions in Prague and Mountain View as well.
<ScottK> persia: That's true, but I think that it's also fair to say a lot of the work was done in isolation from MOTU.
<persia> mok0: Well, let me ask you this: why haven't you been involved in the discussions?
<hyperair> are there only 80+ MOTUs? i thought there were more than that
<ScottK> No, and many of those aren't active.
<mok0> persia: Things have been discussed at the UDS'es like you say.
<mok0> persia: ... and I haven't been able to go
<persia> ScottK: I think that's a perception thing.  I feel like I've been involved in a lot of the discussions, and not because of any non-MOTU roles I may have.
<persia> mok0: Well, w.u.c/ArchiveReorganisation was drafted on the wiki, and mostly discussed in #ubuntu-devel or #ubuntu-meeting during TB meetings.
<ScottK> I think the MC was much more involved than MOTU in general.
<mok0> ScottK: I think you are right
<persia> I think that was true, but aside from one teleconference, I believe that's been a matter of self-selection.  Some MC members have not been very involved.
<ScottK> persia: The reason I scheduled the future of MOTU session at the last UDS was this very concern.
<ScottK> It may just be that I wasn't aware of how to be involved before.
<persia> It's like anything else: speak up and do stuff.
<persia> But yeah, I don't think there was any call for participation or anything.
<sistpoty|work> hi folks
<mok0> It's very difficult to become involved in a discussion that nobody really knows anything about
<persia> I think that's part of why it's taken so long, because nobody really knew.
<persia> It takes discussion to come to conclusion.
<mok0> The feeling is that it's something decided by the "higher-ups" and canonical
<sistpoty|work> DktrKranz: thanks for sponsoring my nmu for ktoon! :)
<xteejx> Waht is the standard for Ubuntu packages. Is it "all files except the binary to run the program go in /usr/share/, and the executable binary goes is usr/bin"? Or is it something else?
<sistpoty|work> xteejx: it's FHS (documents can be found in debian-policy package)
<persia> See, I've always believed there are no "higher-ups" in MOTU.  I even consider MC mostly having a judicial or review role.
<xteejx> Ok, I'll Google
<xteejx> Now I know what to look for..thank you :)
<mok0> persia: that may be true on paper
<sistpoty|work> xteejx: "file hierarchy standard" should give you good results ;)
<xteejx> sistpoty|work: Great! Thank you :)
<persia> And the Ubuntu Governance stuff explicity restricts Canonical from making some classes of decisions (although Canonical has a huge influence, and many decisions are taken by Ubuntu people who are involved with Canonical).
<mok0> persia: that fact is that some ppl carry more weight than others
<persia> Well, I like to think that's because of what those people do.
<persia> Like I think ScottK carries huge weight because he's willing to speak up on lots of things.
<mok0> persia: circle completed
<persia> Right, but that's not something externally imposed.
<persia> Anyone who does stuff carries weight.
<persia> I picked on ScottK precisely because he doesn't have that many formal roles right now.
<mok0> persia: that proposal doesn't come from ScottK
<persia> Which proposal?
<mok0> persia: disband MOTU proposal
<sistpoty|work> motu will go away?
<ScottK> No, but the one persia pointed to did happen because I pushed at UDS for something like it.
<ScottK> sistpoty|work: No
<sistpoty|work> ah, good :)
<persia> As far as I know, that proposal comes from sabdfl thinking nobody would want to be negatively defined, and nobody being able to come up with a positive definition until ScottK did.
<persia> ("Can only upload to packages not considered special" being an example of negative defintion)
<mok0> What I'm saying is that the discussion itself is detrimental to the morale of the team
<ScottK> Personally I can't find the difference between that and packages not in Main/Restricted.
<ScottK> mok0: I completely agree.
<persia> There isn't one.
<persia> mok0: Absolutely, and I think it's shown effects in the quality of what we ship.
<mok0> We are seeing the result of that with the poor state of karmic at release time
<persia> Hardy was the best universe we've shipped in my opinion.
<persia> So, if we want to keep MOTU, we need to step up and say things.
<DktrKranz> sistpoty|work: np, it will be accepted later tonight, though
<mok0> persia: yes, fortunately
<sistpoty|work> DktrKranz: yes, read that :)
<DktrKranz> :)
<mok0> persia: well, the MC ceased
<persia> Well, that's because we don't have quorum.
<persia> And we didn't want to have an election with the uncertainty, because we didn't think the right people would get nominated or selected.
<mok0> persia: If you prefer to put that way... the consequences are the same
<persia> If you really want to push for an MC election, reply to my mail.  We can have one.
<ScottK> mok0: MC != MOTU
<persia> I'm not special in MOTU just because I'm MC, until it gets to the point where oversight is required.
<persia> And I fully expect ALL MOTU to oversee the MC.  Otherwise it doesn't work.
<mok0> ScottK: well, it's very hard to have a large team without elected leadership
<persia> But we've never had elected leadership.
 * ScottK agrees with persia.
<persia> We've always been led by the people who are in this channel doing.
<persia> w.u.c/MOTU/Leaders is a good page
<ScottK> mok0: MC is more like the judge than the leader.
<persia> And while some of those positions are elective, many are not.
<persia> Yes.
<mok0> Perhaps "leadership" was not the exact right word
<persia> MC is *not allowed* to make decisions on it's own unless otherwise nothing will happen.
<persia> We could decide not to hold an election, but that's just an announcement of what is happening.  Anyone can call for an election if they want.
<mok0> persia: but MC is allowed to make initatives, call for meetings etc
<persia> Personally, I don't think it's worth it right now.
<persia> The MC is not allowed to call for meetings.
<persia> MOTU calls for meetings.
<persia> The MC is supposed to attend meetings and be available in case things get out of hand.
<persia> So, if you want a MOTU Meeting, update the wiki page and send out an announcement.
<persia> I used to do that all the time.  I don't now, just because I think we've solved most of the policy issues that were hassles then.
<mok0> ... but we haven't solved the decreasing quality of the repo
<persia> No.
<persia> But the MC can't solve that: it's not an MC thing.  See https://wiki.ubuntu.com/MOTU/Council which limits MC activities.
<mok0> ... and we haven't solved the diminishing morale of the team
<persia> MOTU has to solve that.
<persia> Well, I hope that redefinition will help with that.
<persia> Do you agree with the definition in the proposal that will be reviewed on the 2nd?  If so, please attend and argue for it.  If not, please mail ubuntu-motu@ and start a discussion.
<mok0> Just look at the zero activity on ubuntu-motu
<mok0> persia: I don't know where to start and where to end
<persia> mok0: Well, where are you now, and where do you want to be?
<xteejx> Hmm, the FHS in the Debian Policy Manual says nothing specifically about where things should be stored, whether "pictures and media should be stored in /usr/share/" or not. So am I right in assuming that an entire python package can install to /usr/bin/foo/* and not to worry about where the media files for package foo actually go? It's just that it appears that everything is linked specifically to each other in order to work correctly.
<xteejx> FHS just says not to put anything in /usr/local
<persia> xteejx: /usr/lib/foo/*
<persia> /usr/bin/foo
<xteejx> persia: So everything can go in /usr/bin/foo/...
<xteejx> ?
<persia> /usr/share/foo/* (for graphics and sound)
<persia> No.
<persia> /usr/lib/foo/* should have arch-specific stuff, and, annoyingly, python
<persia> /usr/share/foo/* should have arch-independent stuff like graphics and sounds and text files
<persia> /usr/share/doc/foo/* should have the documentation
<persia> /usr/bin/foo should start the program
 * sistpoty|work wonders if a picture of an pention 3 is arch-specific :P
<sistpoty|work> pentium even
<xteejx> So let me get this straight in my head.... /usr/share/foo/ = media  /usr/lib/foo/ = python .py files  /usr/bin/foo is the actual .py file to run  and /usr/share/foc/foo/* is the documentation?
<persia> :)
<xteejx> I meant doc :)
<persia> Except policy states no extensions in /usr/bin, so /usr/bin is a python script with #! /usr/bin/python as the first line.
<persia> Otherwise, yes.
<persia> (unless someone with more python packaging knowledge wants to correct me)
<xteejx> persia: So /usr/bin/* is *purely* the initial .py file to run the game?
<persia> Except it's not a .py file.
<xteejx> Ohh... I understand I think.... it's a small file that tells python to run the game and invoke the .py from the /usr/lib/foo/blah.py ?
<sistpoty|work> xteejx: if it's a game the executable can also go to /usr/games (just to add more confusion)
<persia> And /usr/lib/games/
<xteejx> Huh?
<persia> And there's /var/lib/ and /var/cache as well, to make it more complicated :)
<persia> Games are special.  They use /usr/lib/games/foo/* instead of /usr/lib/foo/* and /usr/games/foo rather than /usr/bin/foo
<xteejx> Well...I *was* beginning to understand! lol
<xteejx> So /usr/share/foomedia/* is the same?
<persia> No, /usr/share/foo/*
<xteejx> That's what I meant :)
<persia> and /usr/share/games/foo/*
<xteejx> The first for applications, second just for games?
<persia> Right.
<xteejx> Whew! Talk about confusing, but I think I got it now.
 * persia completely fails to understand why games have this super-special hierarchy, but they do
<geser> I can understand to not put games into /usr/bin, but see no benefit for the other own directories
<persia> geser: Why?
<sistpoty|work> maybe FHS creators have forseen that game data is usually quite large?
<persia> There's namespace rules anyway, so there can't be a file conflict.
<sistpoty|work> (so a different partition might be suitable)
<persia> Ah, that makes sense.
<xteejx> What about game documentation, is that /usr/share/doc/games/foo/* ?
<persia> Or it might need to be local vs. remote on /usr/share/ or users complain about access times.
<sistpoty|work> or that ;)
<persia> xteejx: No, that's still /usr/share/doc/foo*
<geser> persia: if you not put games into /usr/bin/ you can exclude them from appearing in PATH (and tab-completetion)
<xteejx> Ahh ok
<xteejx> persia: I'm saving this for reference, can you check I've 100% got it right please? I don't want to start off and get it wrong and then have to mess about starting over
<xteejx> http://paste.ubuntu.com/362636/
<persia> Looks right.
<xteejx> Cool
<persia> Try to make /usr/bin/* be /usr/bin/foo, except when you need to distribute multiple executables.
<xteejx> Ok. Just a double check again sorry... /usr/games/foo (executable) for games, not /usr/bin/games/foo ?
<POX> xteejx: if your package is arch:all, use /usr/share/foo/ for .py files, if it's arch:any - use /usr/lib/foo/ (.py and .so files have to be in the same directory)
<POX> (or symlink .py files from /usr/share/foo if you want)
<xteejx> I'm beginning to wonder why I'm trying heh :)
<SevenMachines> does this look like a problem in libslv2 rather than the lv2 plugin for gstreamer? http://paste.ubuntu.com/362620/
<xteejx> POX: I thought python could compile natively on any arch, as it's just a language?
<POX> xteejx: .py files, Python extensions are written in C
<xteejx> POX: Oh :)
<xteejx> Probably a stupid question... how do I know whether to choose arch: any or all?
<POX> if you have .so file in you package, it's arch:any
<xteejx> So, as it's all .py it's all and the .py files go in /usr/share/foo/*
<POX> (that check works for most Python related packages)
<xteejx> ?
<POX> yes
<xteejx> Ok
<POX> or /usr/share/games/foo
<xteejx> Ok, it's a game, so there then I assume? :)
<persia> SevenMachines: Which program has rdf_uri.c ?
<xteejx> POX: What about a arch: any python game, is that still /usr/lib/foo/* or is it /usr/lib/games/foo/* ?
<POX> one of them, yes (probably the second one)
<SevenMachines> persia: librdf0 (redland)
<SevenMachines> thats what i'm looking at just now anyway
<persia> SevenMachines: It looks to me that slv2 is either calling some librdf function unsafely, or there is a bug in librdf.
<xteejx> Ok, sorry if I keep going on about it, I just want to make sure 100% I learn exactly how it should be, so thank you all for your help I really appreciate it, and once I get used to all this you will definitely start seeing a few more games in Ubuntu! :)
<persia> SevenMachines: Look at src/world.c:154 and see what happens if one passes world=0x17958c0
<persia> And read the librdf docs to see if maybe slv2 should be trapping an error conditoin.
<persia> (with exception handling)
<persia> Alternately, look in librdf and see why librdf_free_uri would be crashing with that input.
<xteejx> In the upstream source package I have /font /gfx and /sfx - these would go in /usr/share/games/foo/* ... /plugins - would go in /usr/lib/games/foo/* ... /i18n < don't know ... and in / .py files go in /usr/share/games/foo/*.py ... / the .sh game start script goes in /usr/games/*.sh ... and there's the changelog.txt, options.cfg and README.txt in /  is that all correct, and also where do the 4 unknows go? Sorry to be a pain
<hyperair> mok0: thanks for the upload =)
<mok0> hyperair: you're welcome :-)
<persia> i18n usually goes in /usr/share
<persia> And drop the .sh from /usr/games/foo.sh  It should just be /usr/games/foo
<persia> The docs (changelog, options, readme) belong in /usr/share/doc
<xteejx> persia: http://paste.ubuntu.com/362651/ I hope I have it right now :)
<persia> xteejx: You're going to end up with the entire text of the FHS if you keep at it :)
<persia> And not every .sh or .py file needs the extension stripped, just the ones in the default path
<gnomefreak> what controls the processes in ps aux? im looking for a source package for the [flush-*] process
<xteejx> persia: The FHS was of no use to me, all it said was don't put anything in /usr/local :(
 * gnomefreak thinks 18 is too many
<persia> xteejx: Hrm?  It gets more specific than that.
<xteejx> persia: I'm not worried though, I'd rather know all this stuff and get it all right and learn :)
<persia> xteejx: Look at http://www.pathname.com/fhs/pub/fhs-2.3.html
<xteejx> persia: Ohhhhhhh - I was reading http://www.debian.org/doc/debian-policy/ch-opersys.html
<sistpoty|work> gnomefreak: pdflush? I think these are kernel threads
<persia> xteejx: Um, that's only the exceptions :)
<gnomefreak> sistpoty|work: thanks i will ask in -kernel
<xteejx> persia: I did wonder why it didn't say much.
 * xteejx is embarrassed
<xteejx> It does make a bit more sense now ;)
<xteejx> But I have the basics noted down for future use, which should be sufficient in most cases
<xteejx> persia: Can I restructure the upstream source I downloaded into these folders, so that it can just all be installed to / ? with the directories branching off of course. And I know I'll need to edit some python script to re-point to each other won't I?
<xteejx> i.e. /home/me/build/usr/share/games/foo/font , etc so that all the /usr stuff in my /home/me/build/ can be installed with a script to the correct place when packaged?
<xteejx> Anyone?
<persia> Don't repack the source.  Use dh_install
<xteejx> Can dh_install be told where to put each of these files?
<Laney> yes, see the manpage
<xteejx> Ok...also (I must be really annoying now!!)...will I have to edit the pointers in the .py files to these new directories, or does dh_install do this too?
<xteejx> I see, so dh_install moves the files from the temporary build section to the required directory?
<xteejx> Does it matter that there is no Makefile or ./configure script, I don't need to make these do I?
<persia> Not if nothing needs be made
<persia> This guide is a bit out of date, and I now recommend dh(1) rather than CDBS, but https://wiki.ubuntu.com/MOTU/School/PackagingWithoutCompiling may help./
<cjohnston> Don't forget... Ubuntu Developer Week is starting in 30 minutes in #ubuntu-classroom and #ubuntu-classroom-chat  - http://wiki.ubuntu.com/UbuntuDeveloperWeek
<SevenMachines> it seems a no change rebuild of libslv2 gets rid of all gstreamers lv2 woes, any idea why that is? just so i can put something in the changelog if nothing else
<xteejx> persia: That would be better, since it's all just python scripts, nothing needs built from the source it just works
<persia> SevenMachines: debdiff the repo deb and the rebuild deb and see if anything changed.
<persia> xteejx: So use rules.tiny, an install file, a docs file, and a manpages file :)
<xteejx> persia: Ummm.....one step at a time hehe ;)
<persia> Nah.  Big lumps, and ask questions.  Same as the buggy package you made yesterday that you then had to fix.
<xteejx> persia: Lol
<xteejx> persia: I just want to pee people off by asking so much! I did enough of that in #ubuntu-bugs, now I've triaged a good 2000+ bugs and am part of Bug Control hehe
<xteejx> *DON'T want* oops
<SevenMachines> seems like [-librasqal1-] {+librasqal2+} is the relevant bit here
<persia> SevenMachines: So the changelog should read "Rebuild for librasqal1 to librasqal2 transition"
<Laney> Just put "No-change rebuild to pick up new xxx as part of yyy transition" or similar
<persia> And the version should be 0.6.6-2build1 (not -2ubuntu1) so we know we can safely sync if a new version appears in Debian.
<Laney> (you can use dch -R to create the correct changelog entry)
<SevenMachines> ok, will do. should be safe to enable lv2 in gstreamer build once libslv2-9 is updated at least
<SevenMachines> persia: yep, i remember that, i made that mistake last time
<persia> SevenMachines: Nice bit of research, and very nice conclusion to an initial FTBFS fix.
<xteejx> I think #ubuntu-classroom will be helpful in 13 mins for me
<SevenMachines> persia: thanks for the help, it started out as a relatively simple merge (my first one) and escalated rapidly out of control :)
<persia> This was your first merge?  Wow!
<persia> Very nice work indeed.
<SevenMachines> gstreamer plugins bad
<SevenMachines> would enabling lv2 in a merge be the right thing to do? or keep the changes from debian as small as possible
<SevenMachines> and maybe add lv2 as part of another fix
<persia> I think it's better to make as many improvements to a package as possible in a single upload, so you can improve a different package.
<persia> Just be careful with the changelog indentation to indicate what is from previous Ubutnu versions and what is new.
<SevenMachines> theres a format to do that?
<persia> SevenMachines: https://lists.ubuntu.com/archives/lucid-changes/2010-January/002506.html has an example
<persia> I don't personally think that class of Maintainer change needs a changelog entry, but it's clear which changes are retained from previous Ubuntu versions, and which were added anew.
<persia> Of course, when uploading these, it's better to use debuild -S -v${last-ubuntu-version} so that one can also see the Debian changes.
<xteejx> persia: One more question sorry, if the files are going to be moved around during install, surely they will need editing to comply with the locations? Am I right in thinking that I'll need to edit the .py files to point at the new location before I build?
<SevenMachines> i was following the merging guide and having a debdiff from new debian to new ubuntu and old ubuntu to new ubuntu
<persia> xteejx: It's better to ask questions generally.  I'll probably answer them anyway, but soemone else might be faster, especially if I go to bed.
<persia> xteejx: If you need to change files, patch them.  Adding --with quilt is an easy way to do that with rules.tiny.
<xteejx> persia: Sorry I forget about timezones sometimes
<persia> Read about quilt in the patch systems section of the packaging gude
<xteejx> Will do. And that will patch the files to the needed way I take it?
<persia> SevenMachines: I usually just want the debdiff from Debian to new Ubuntu (as it matches the tar.gz).  I can generate the rest locally easily enough.
<persia> xteejx: That can patch the files however you want.
<xteejx> Really? Cool, just what I need :)
<SevenMachines> ok, i'll take care of that once slv2 is rebuilt. thanks again
<persia> SevenMachines: Just as a note, we'd really prefer a legal name in changelogs for proper attribution of authorship.
<SevenMachines> ok, i'll see about changing that in the future
<ScottK> persia: I think that goes too far.  I think we prefer something that appears to be a legal name.
<persia> No, I think we prefer a legal name, and don't bother to check carefully, so are easily duped.
<persia> Because the rationale for using such a name is related to attribution.
<persia> So we don't care if it's a real name, only that it's a name that can take attribution and grant licensing.
<persia> But that requires a legal name.  That we don't bother to enforce a WoT is just failure of due dilligence.
<SevenMachines> Guy Incognito it is then :) I'll put my actual name in future, i just tend to default to seperating id's, its no problem though
<persia> And without a WoT, any effort to enforce accurate reporting of legal names is a bit questionable.
<ScottK> That's all true, but I think it goes a bit too far to say we actually prefer something we make no effort to get.
<MTecknology> How can I mark that one package conflicts with another in the debain/control file?
<persia> ScottK: Hrm.  I think we have different semantic weightings to "prefer".  I prefer to eat waffles for breakfast, but I probably make them twice a year because I'm lazy.
<persia> MTecknology: Conflicts:
<MTecknology> persia: it's just simple enough to make sense :P - thanks
<bddebian> Heya folks
<MTecknology> hi
<sebner> huhu bddebian :)
<persia> bddebian: Hey.  I wanted to ask you about libticalcs and libtifiles and libtifiles2 and friends.
<persia> Do you remember any of this by any chance?
<bddebian> Heya sebner, persia
<persia> (you last appear to have worked with those several years back)
<bddebian> persia: Aye, what about them?
<kamalmostafa> persia: Um...  hi folks -- I've been working on libticalcs and libtifiles {with and without the 2} at ScottK's request.
<persia> Well, you put libtifiles2 in Ubuntu a long time ago, and since then there was a libtifiles in Debian, and then an update in Ubuntu.  Never any versions in common, but there's namespace collision that seems to be causing build/dependency issues.
<persia> And kamalmostafa will benefit from your memory and wisdom :)
<kamalmostafa> I've actually got them fixed (the 2-package changes merged into the non-2 packages) -- they await ScottK's review.
<bddebian> I thought libtifiles was recently removed finally?
<kamalmostafa> (Not to say that I wouldn't benefit from any wisdom that may be imparted!)
<persia> bddebian: You filed a removal in Debian?
<bddebian> No, I thought someone else had recently.  I might be mistaken though.
<persia> bddebian: So, what's your recommendation.  Merge?  Drop?  Upload the nice versions kamalmostafa prepared to Debian?
<kamalmostafa> bug 507741
<ubottu> Launchpad bug 507741 in libtifiles "libtifiles failed to upload: conflicts with libtifiles2" [Undecided,In progress] https://launchpad.net/bugs/507741
<kamalmostafa> bug 507740
<ubottu> Launchpad bug 507740 in libticalcs "libticalcs FTBFS: missing libtifiles-dev" [Undecided,In progress] https://launchpad.net/bugs/507740
<kamalmostafa> I don't think my versions need to go to Debian -- the other way 'round I think.  Per ScottK, we will be keeping libtifiles and libticalc (from Debian) from here on in -- and removing our libtifiles2 and libticalcs2 packages.  (there are actually a couple more in the libti family which I will get to next).
<persia> kamalmostafa: The only reason I added that option was because bddebian seemed to think they would be removed from Debian.
<persia> (and he uploaded the *2 versions originally, and is now very active in Debian QA)
<bddebian> Whichever makes more sense.  I would say lets remove one or the other.
<persia> kamalmostafa: Also, aren't our packages newer upstream versions?
<persia> bddebian: Nicely avoided :)
<bddebian> persia: That wasn't my intent, I just don't have a vested interest in the packages, I just wanted to have the latest back then.  I'll gladly help where I can.
<persia> bddebian: Understood.  I didn't mean to imply you were trying to get out of anything :)
<bddebian> :)
<kamalmostafa> persia: Yes, but I merged in the changes from our "2" versions so we don't lose any functionality -- I think we're just trying to get the package naming aligned between us and Debian.
<kamalmostafa> (those changes were relatively minor -- Debian is almost caught up to the latest up-up-stream version at this point).
<persia> kamalmostafa: That makes lots of sense.  I just got confused by the bug when I saw it a couple days ago and it seemed to imply that our stuff was newer than Debian's.
<persia> When as far as I could tell, they were independent packagings of leapfrogging versions.
<persia> So I figured it was worth asking the original Ubuntu uploader, especially because Debian didn't seem to be getting a lot of maintenance on those packages.
<persia> But I've done that now, so will go back to ignoring these packages :)
<kamalmostafa> Well, as stated, ScottK set me on this task, so he needs to review the work before I propose for merge, but if anyone else wants to take a look the branches are attached to those two bug reports.
<persia> bddebian: Thanks for your insight and explanations.
<bddebian> NP, sorry I am not more help. :(
<mok0> q
<mok0> Any users of bzr buildpkg here?
<mok0> I have deliberately constructed my tar.gz file so it doesn't contain some of the bzr specific files, such as .gitignore. However, when I build the source package using bzr builddeb, those file end up in diff.gz... annoying
<persia> mok0: You might be able to pass "-- -i -I", but that might break something else.
<mok0> persia: yeah, but it's a longish list of files
<mok0> persia: for example, there's a README.bzr file which is not relevant for those downloading the package in tar.gz format
<persia> Are they really stuff that's not already in the -i -I default list?  For me, 99% of what I want to ignore works without adding any globs.
<mok0> persia: .gitignore files
<persia> Oh.  Yeah.  Won't help that.
<persia> .gitignore ought be ignored.  If not, that's probably a bug.
<mok0> persia: guess I'll have to construct a long  -i -I line. Really would be nice to have a .bzr-builddeb-ignore file to contain all those
<persia> Maybe construct one?
<persia> Done once, it can be reused indefinitely :)
<mok0> persia: perhaps I should consider submitting a branch merge proposal :-)
<persia> And then accept it in the packaging branch?
<persia> Where I get confused is, that if this is done, how does one ensure it gets uploaded?
<persia> How can a developer know if the right source is that in the archive or that in the branch?
<mok0> persia: hm I need to think it throug
<mok0> h
<geser> DktrKranz: I've seen the comment in your gpsd upload. Is there a way to resolve the DEPWAITs on a newer libgps-dev in lucid?
<geser> Laney: lucid has some DEPWAITs on mono-devel >= 2.4.3. Do you have an idea when lucid will get it?
<Laney> geser: hopefully v soon. Transition is almost ready to roll over now
<sebner> hi geser Laney
<Laney> hiya sebnerkins
<ScottK> bddebian, kamalmostafa, and persia: My thought was to align to the Debian packages and then look at what should go back to Debian.  As we have it now, we have different source package names and that needs to be fixed first.
<\sh> guys, very strange problem...dpkg --purge tries to remove the whole /opt directory...but should only remove /opt/<whatever> ... any clue about this problem?
<\sh> forget about that
<\sh> found my answer
<mok0> \sh: what was it?
<\sh> mok0: read http://www.mail-archive.com/debian-devel@lists.debian.org/msg230790.html
<\sh> it's a false positive this strange warning
<mok0> ah interesting
<kamalmostafa> ScottK: i'm available if you need me re: the libti stuff.
<ScottK> kamalmostafa: Thanks.  I'm sorry it's take me so long to look at.
<kamalmostafa> ScottK: really no problem Scott.
<randomaction> so, was the problem with TeXLive uninstallable solved?
<ScottK> Yes
<randomaction> cjk still FTBFS with the same error: https://launchpad.net/ubuntu/+source/cjk/4.8.2+git20090105-4/+build/1461227
<randomaction> (and it's in universe)
<ScottK> Then it's not the problem I was solvling.  Mine was just a Main/Universe mismatch
<randomaction> hmm ok, when will the texlive-base-bin binary go away? (It's not built by any source package anymore) Is a removal bug required?
<randomaction> it seems its presence leads to FTBFS
<Laney> does it have any rdepends?
<randomaction> a lot, but it's provided by a new binary, texlive-binaries
<randomaction> so actually texlive-base-bin should become a virtual package, but there's still an old and uninstallable version of it (at least that's what geser suggested)
<ScottK> It'll go away when it doesn't have any rdepends.
<geser> Laney: most rdepends of texlive-base-bin are unversioned, so texlive-binaries providing texlive-base-bin works for them
<ScottK> Right, virtual provides aren't versioned and so will always fail.
<ScottK> (if the depends is versioned)
<geser> ScottK: do you know if the archive-admins will remove it although its NBS file is not empty?
<ScottK> geser: Generally not, but if there's a good reason, perhaps.
<ScottK> One of the reasons not to remove it is that it's then hard to find what packages still need to be adjusted.
<Laney> a combination of edos-debcheck and grep-dctrl could do it
<geser> ScottK: the NBS file lists also those packages which have an unversioned dependency on texlive-base-bin
<ScottK> geser: I think the solution then is to make a list of the versioned ones, get them fixed, and then ask for removal.
<randomaction> that sounds doable :)
<geser> ScottK: a quick check with grep "texlive-base-bin (" in /var/lib/apt/lists shows me only one package left: jadetex (bug #511399)
<ubottu> Launchpad bug 511399 in jadetex "Update versioned build-dependency from texlive-base-bin to texlive-binaries" [Undecided,New] https://launchpad.net/bugs/511399
<ScottK> geser: Sounds easy enough then.
<randomaction> What's needed to bootstrap a package? (eigenbase-resgen build-depends on its own binary)
<geser> in the worst-case: a build-admin :(
<geser> try to get the package build without itself, and once you got it, undo it in the next step
<dupondje> what is quite easy to help a bit in Ubuntu ? :) Easy to help with ftbfs packages ?
<geser> dupondje: ftbfs might be easy (because the build happened at a wrong time, and the issue is resolved now -> give-back) or hard (needing patching)
<Laney> maybe turning bugs with patches into bugs ready for sponsoring
<randomaction> looking at the FTBFS list, we still have a fair number of const char* cases
<dupondje> geser: well it can be the patch is quite easy also :)
<geser> true, depending on the patch
<dupondje> just don't know what the steps are exactly to fix ftbfs packages :)
<geser> randomaction: if you're a familiar with ant build files, you could check if you manage to build it without itself
<geser> dupondje: the first step is: find out why it failed and how to fix it
<dupondje> geser: just apt-get source ? and then trying to fix so it builds ?
<geser> dupondje: I usually start with looking at the existing build log to see if I have an idea what's the problem is
<MTecknology> What's the best place to ask about packaging? I've been told this isn't the right place for that
<geser> it is the right place
<dupondje> and what is 'Newer in Debian' ? :) means its quite useless to fix it as it needs to be synced from debian first ?
<dupondje> or
<geser> dupondje: can you provide a little more context? (which page/url are you talking about?)
<dupondje> http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi, first package cdrkit
<geser> ah, that FTBFS page
<geser> Debian has a newer package which might (or might not) fix this problem (needs checking)
<MTecknology> I'm trying to compile something before trying to package it; It's complaining about xft not being found and I can't figureout where to get it from, libxft2 is installed
<ScottK> Is there a -dev package?
<geser> MTecknology: have you the exact error message at hand?
<MTecknology> geser: No package 'x11' found
<MTecknology> ScottK: ya, it's a virt package, I'll try installing everything in it
<geser> MTecknology: what has now "x11" to do with your problem that xft is not found?
<MTecknology> geser: just comes up when I run make
<MTecknology> That fixed; and now it won't build - with a great error this time - http://paste.ubuntu.com/362848/
<MTecknology> I can tell I need X11/StringDefs.h; how can I figure out what provides that?
<randomaction> MTecknology: http://packages.ubuntu.com/search?suite=lucid&arch=any&searchon=contents&keywords=X11%2FStringDefs.h
<MTecknology> I installed libxt-dev...
<MTecknology> oh...
<geser> MTecknology: ah, "X11" was a library name it was looking for -> libX11.so -> libx11-dev (found with packages.ubuntu.com)
<MTecknology> So to build this needs libxt-dev and libxft-dev; that'll be useful when I try to package this
<randomaction> generally, when configure complains about "foo" missing, first package to check is libfoo-dev
<geser> don't forget libx11-dev (for that -lX11 part)
<MTecknology> I just ran make again; and now - make dies with no decent error
<MTecknology> All I get is this - http://paste.ubuntu.com/362854/
<randomaction> MTecknology: do you have ./configure script?
<geser> what gived "ls -l lal"?
<geser> s/gived/gives/
<MTecknology> hrm... It was still able to build; just with that error
<randomaction> geser: I'll leave eigenbase-resgen to java people, too complex to me :)
<geser> it's a warning not an error :)
<MTecknology> there isn't a ./configure script
<geser> MTecknology: if you want you can fix this warning (the security guys would probably prefer it if you do it)
<MTecknology> ok - I'll check it out
<randomaction> so, is this some software with a single .c file? pretty simple to build it seems :)
<MTecknology> now.. those are only build deps; right?
<MTecknology> randomaction: It's not yet packaged - I figure it's a great one to learn on
<randomaction> the best way to check correctness of build-deps is to build in a clean environment, such as pbuilder
<MTecknology> ya, and then lintain to make sure I didn't screw up; then upload
<MTecknology> I'll try to do this the right way :)
<MTecknology> is it possible to get verbose output of the build process?
<hyperair> export DH_VERBOSE=1
<sebner> hola hyperair :D
<hyperair> hola sebner :D
<dupondje> dpkg-gencontrol: warning: unknown substitution variable ${python:Provides}
<dupondje> ${python:Provides} is correct right ?
<MTecknology> hyperair: sorry, I meant when I run make
<MTecknology> I want to figure out what's causing something to be sent to the die function
<hyperair> MTecknology: ah. try make V=1 (it effectively unsilences [is that a valid word?] automake, but i'm not sure if it does anything to make)
<dupondje> ?
<MTecknology> hyperair: nope, nothing - there's also almost no comments at all in this file
<hyperair> MTecknology: hmmm. how bout make --debug =p
<MTecknology> hyperair: there's --debug; the only error is "Updating goal targets...  File `all' does not exist. Must remake target `all'."
<randomaction> MTecknology: if you want to fix that warning, the general idea is to change "printf(somestring)" to "printf("%s", somestring)"
<MTecknology> randomaction: that line is fprintf(stderr, str);
<dupondje> dpkg-gencontrol: warning: unknown substitution variable ${python:Provides} => whats wrong with ${python:Depends} ?
<MTecknology> randomaction: I guess that is the only line causing issues. I comment it out and it's perfectly fine. So now I guess I need to learn enough C to fix that :P
<randomaction> nope, don't comment it out, better leave it as it is
<MTecknology> randomaction: I just tried it without to see what happened
 * hyperair wonders what make has to do with fprintf
<randomaction> never comment out code you don't understand: http://xkcd.com/424/
<dupondje> geser: is there a bug created for every ftbfs?
<geser> no, e.g. a MOTU or core-dev can fix it directly with an upload and doesn't need to file a bug first
<dupondje> hmz ok, cause I fixed one error
<geser> then the usual sponsoring process applies
<dupondje> geser: ok, and what about dpkg-gencontrol: warning: unknown substitution variable ${python:Provides} ? does that needs to be fixed ? if so, how exactly ? cause I think that is correct ..
<geser> no, it just a warning
<ScottK> dupondje: It's a normal thing for Python packages, just dpkg-gencontrol doesn't know about it.
<geser> ScottK: do you know if it is possible to configure LP that only the Kubuntu devs gets build logs for their PPA?
<ScottK> No idea.
<ScottK> I'm generally pretty unhappy with it's spammyness.
<geser> I guess I've to live with it :/
 * ajmitch hasn't seen any recent build logs in the lp catch-all mailbox here
<deadwill> heya
<geser> I just got a log about a FTBFS in the kubuntu-ppa-staging PPA a few minutes ago (thanks to indirect membership)
<dupondje> https://bugs.launchpad.net/ubuntu/+source/burn/+bug/512509
<ubottu> Ubuntu bug 512509 in burn "ftbfs in Lucid" [Undecided,New]
<dupondje> geser: the fix :)
<geser> dupondje: looks good, can you please forward this change to Debian (so we can hopefully sync in future again)? and don't forget to subscribe ubuntu-universe-sponsors (or ubuntu-main-sponsors for packages in main) if you want your fix get sponsored :)
<ari-tczew> if I'm doing a fakesync, do I need to change DebianMaintainerField?
<ScottK> ari-tczew: No
#ubuntu-motu 2010-01-26
<mde88> hi.
<mde88> i was wondering if you guys knew how i could take a .deb
<mde88> and make a .dsc
<RAOF> The dsc is a part of the source package; it's not possible in general to go backwards from a binary package to a source package.
<mde88> RAOF, oh, ok.
<MTecknology> How can I see sections available for a package?
<MTecknology> I'm not entirely sure where it should wind up
<MTecknology> I'm guess a clock that sits in your dock should be in the x11 section..
<RAOF> MTecknology: The canonical list of sections is in debian policy.  Let me grab the link for you.
<MTecknology> RAOF: I'm guessing this - http://www.debian.org/doc/debian-policy/ch-controlfields.html
<RAOF> It might depend on what dock, but x11 seems safe.
<MTecknology> thanks :)
<RAOF> http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections is what I was thinking of.
<MTecknology> thanks :)
<MTecknology> only two files left to figure out - changelog and one other, the other is going to be the hard one..
<MTecknology> for now, break time :)
<persia> MTecknology: changelog is trivial.  dch --create for a new one, dch to edit the current one, or dch -i to add an entry.
<directhex> MTecknology, the hard one is debian/copyright. the rest have a much faster turnaround on discovering issues
<persia> Well, depends.  I've seen lurking issues in debian/control as well :)
<ajmitch> or a debian/rules more complex than the source it's for
<directhex> ajmitch, i've done difficult rules and difficult copyright. copyright is far more infuriating
<directhex> the openjdk maintainers might benefit from looking at debian/copyright in ikvm, since it's got a mostly-complete DEP5 for openjdk in it
<persia> Why?  Is there that much source duplication?  Could it be avoided?
<directhex> it's not feasible to avoid it
<persia> ajmitch: There's very few packages that really need complex debian/rules: I'd rather see use of dh(1) (or even CDBS) to avoid manual mistakes.
<persia> directhex: Hrm?  Why not.  Worst case, openjdk could generate openjdk-source on which ikvm could build-depend.
<ajmitch> persia: I have seen a few complex examples, but they're usually for fairly large packages
<directhex> persia, the openjdk-source package misses some of the more esoteric bits & pieces, and the whole thing is mildly forked here & there
<persia> Generally, although sometimes they seem to be because the maintainer is trying to fit into something they aren't.  sendmail is a lovely example of that.
<ajmitch> now there's a dirty word
<persia> directhex: Missing bits are bugs in openjdk.  Forked bits can be handled with build-time patching.
<persia> Which?  Sendmail?
<ajmitch> yes
 * persia remembers lovely afternoons spent pondering rule 3
<directhex> persia, you're free to take a look, but you're proposing a maintenance nightmare
<persia> directhex: Short-term, yes.  My actual proposal is for deeper coordination to avoid build-time patching.
<dhillon-v10> hi all, I just finished a merge, and am about to upload it, so in the patch there are a lot of po files, should I keep that in the diff or remove it, I think its just some noise so it should be removed
<persia> Generally we prefer Debian translations.
<persia> The exceptions being when we've deliberately changed something, but this should appear in the changelog.
<persia> If something is deliberately changed, please only merge those msgids in the .po files.
<dhillon-v10> persia: so here: http://paste.ubuntu.com/362997/ i should remove all the .po changes right
<persia> Well, I think you're merging too much there :)
<dhillon-v10> persia: really ? this package had a lot of changes, especially the .po stuff, but if that's going to be removed then its not that much really
<persia> Firstly, I think the update to debhelper 7 is worthless: I don't think we should be fixing lintian issues in stuff maintained in Debian.
<persia> Standards-Version too.
<dhillon-v10> persia: they updated it to 7 and same for standards, so I should just change them and not mention that in the changelog
<ScottK> Standard version is something Ubuntu Policy says specifically not to touch
<persia> Just revert to Debian, and drop it from the "Remaining changes"
<dhillon-v10> persia: alright :)
<persia> Same with overrides, in my opinion.
<dhillon-v10> persia: this is from the debian's control file: Standards-Version: 3.8.3 so I just put that there, but will remove it
<dhillon-v10> persia: so remove the overrides too, that file was renamed to a different one, so I didn't know how to put that down in words
<persia> dhillon-v10: You want to use whatever Debian has for Standards-Version, debhelper compatibility, and lintian overrides *UNLESS* the package has an unlikely bug like some dh7 feature being used with declared compat level of 5.
<persia> What is this diff anyway?  It doesn't appear to be a Debian->candidate or Ubnutu->Ubuntu.
<persia> For Debian->candidate it doesn't have enough old changelog entries.  For Ubuntu->Ubuntu it includes some old Ubuntu changelogs.
<dhillon-v10> persia: alright :) my mentor told me to document *every* single change I make so I did so but i will remove that, this one was done using bzr diff --old lp:debian/squeeze/ssl-cert
<dhillon-v10> persia: why is that patch wrong, that's what the wiki page said
<dhillon-v10> persia: I have actually had a couple of wrong ones like this, but don't know what to do
<persia> dhillon-v10: I'm not saying the patch is wrong, just that it doesn't match either of the patches I'm used to reviewing.
<persia> As a result, I'm uncertain about everything.
<persia> But I know that we're not supposed to change Standards-Version and lintian stuff Ubuntu-local unless it makes some significant user-visible difference.
<dhillon-v10> persia: alright, so I'll remove  that stuff, so what can i do to fix my patch, sorry I am taking a lot of your time
<persia> I choose to spend my time answering questions in this channel, in hopes that it makes up for not uploading enough.  Don't worry about that :)
<persia> I don't know how to tell you what to do with your patch.  I usually compare my candidate to both the package in Debian and the package in Ubuntu.
<persia> Comparing against Debian lets me confirm that I included all the changelog entries and all the related patches.
<persia> Comparing against Ubuntu lets me confirm that I included all the improvements from Debian.
<MTecknology> And back at it.. I know I've been told this before.. so- is there any wiki that describes how packages should be named? mostly just the piece after app_version***
<persia> MTecknology: You should never do anything manually that affects that unless you have a very special case and already know how to do it.
<dhillon-v10> persia: so I should debuild the package and then compare the two candidates
<MTecknology> persia: new package that will be in a ppa
<persia> Just worry about the "app" part, and accept the dfaults for everything else.
<MTecknology> persia: then try to make it into the repos
<persia> dhillon-v10: I build source packages and compare those, but that's the idea.
<MTecknology> What I have is this - lal (1.0-1) karmic; urgency=low
<persia> MTecknology: Right.  Doesn't matter.  Accept the defaults.  Anything else is going to cause you more problems than you want to understand how to fix.
<persia> I'd recommend lal (1.0-0Mtecknology1) for a ppa, and 1.0-0ubuntu1 for Ubuntu.
<MTecknology> persia: ok, I've just always seen thins like ubuntu# or ppa#
<persia> Ah, you want the revision number :)
<persia> I thought you were talking about the architecture ID strings and the like.
<MTecknology> oh
<MTecknology> no thanks, I don't want to play with that :P
<persia> Doesn't matter what you use.  Just pick something lower than -0ubuntu1 if you're out of repo, and -0ubuntu1 if you're in repo.
<MTecknology> ok, there's actually no package yet :P
<persia> dpkg --compare-versions lets you check various strings.
<MTecknology> ok - two more things... I want to create a man page before going any further with this..
<persia> help2man can be a useful way to get started, depending on the package.
<dhillon-v10> persia: E: ssl-cert_1.0.25ubuntu1_source.changes: bad-ubuntu-distribution-in-changes-file lucid
<persia> There's also txt2man, rst2man, info2man, djbdoc2man, docbook-utils, podulators-perl, etc.  Depends how you want to write the docs in the first place.
<MTecknology> extremely simple; right now it's one .c that builds one binary
<dhillon-v10> persia: what does that mean?
<persia> dhillon-v10: It means you're not using the lintian from lucid.
<persia> More specifically, it means that the lintian you're running doesn't know about lucid.
<persia> Upgrade lintian.
<dhillon-v10> persia: alright :)
<MTecknology> persia: care if I pm you a political question?
<persia> I prefer to just receive /queries without being asked.  Depending on the topic, I can't promise to discuss at length.
<MTecknology> persia: I tried txt2man and that gave some really ugly output :P
<MTecknology> as in, an ugly man page
<persia> Right.  Now fix it :)
<persia> But it's easier than creating a manpage from scratch (at least for me)
<ScottK> "Fear.  Run.  Save yourself.  No user-serviceable parts." <-- comment from a man page nroff preamble.
<RAOF> Heh.
<MTecknology> persia: so.. html2man won't help because this app continues if it doesn't recognize --version :P
<persia> MTecknology: Feel free to draft from scratch.  I just find that getting the framework from a tool (especially if it there are already convertible upstream docs) is easier to start.
<MTecknology> persia: thanks
<MTecknology> persia: jsut talked to the maintainer; they're excited
<MTecknology> I'm going to just write this file from scratch :P
<MTecknology> this isn't that hard... I'm kind of amazed
<MTecknology> just not dure what .RE and .RS are for yet..
<MTecknology> I think I get that part now too :)
<zooko> Greetings, folks!
<MTecknology> zooko: hi
<MTecknology> persia: You going to be around a little bit longer?
<ScottK> Heya zooko.  How's the release going?
<zooko> Hi!  I decided today to stop trying to finish the last feature and start packaging and documenting and all that.
<zooko> My goal is to release Tahoe-LAFS v1.6 this week and upload it to Ubuntu on Thursday.
<zooko> http://allmydata.org/pipermail/tahoe-dev/2010-January/003664.html
<zooko> I'm excited!  Cory Doctorow invited me to submit a news item about Tahoe-LAFS to Boing Boing.
<zooko> ScottK: how is Lucid coming?
<ScottK> Hard to say.  Lots of good stuff done, lots more to do.
<zooko> Hm, this reminds me to mark a ticket in Nevow as review-needed...
<zooko> Because I want the version of Nevow in Lucid to stop emitting DeprecationWarning...
<zooko> Oh I suppose that picky exarkun will ask me to submit a unit test showing that it doesn't emit a DeprecationWarning!
<zooko> ScottK: what are the sorts of things you're thinking of when you say "lots more to do"?
<ScottK> Quite a number of features still being implemented, tons of bugs, lots of packages to merge from Debian.
<ScottK> zooko: It might be worth it for you to look and see if any of the tahoe build depends/depends need updating.
 * zooko checks http://allmydata.org/trac/tahoe/log/_auto_deps.py
<zooko> We haven't changed the Tahoe-LAFS dependencies since v1.5.0 of Tahoe-LAFS.
 * zooko looks at https://bugs.launchpad.net/ubuntu/lucid/+source/linux-mvl-dove/+bug/505772
<ubottu> Ubuntu bug 505772 in linux-mvl-dove "Some python scripts trigger system hang" [Critical,Confirmed]
<MTecknology> Do I 'need' a ./configure script?
<MTecknology> The app doesn't have any options to be passed to it..
<fabrice_sp_> MTecknology, no, it's not mandatory
<MTecknology> fabrice_sp: thanks
<kamalmostafa> Hello motu's...  Is there a problem with openssl in Lucid?  Various packages (e.g. libavg) FTBFS with "ld: cannot find -lssl".
<ScottK> Do they build-depends on libssl-dev?
<kamalmostafa> well, not directly at least, but I imagine that libssl-dev is supposed to get pulled in by some dependency -- only because several unrelated packages are showing the same "cannot find -lssl" failure.
<kamalmostafa> Here is libavg's build-deps
<kamalmostafa> Build-Depends: cdbs, debhelper (>= 5), libavcodec-dev, libavformat-dev,
<kamalmostafa>  libboost-python-dev (>= 1.34.1-8), libboost-thread-dev, libdc1394-22-dev,
<kamalmostafa>  libgraphicsmagick++1-dev, libpango1.0-dev, libsdl1.2-dev, libswscale-dev,
<kamalmostafa>  libtool, libxml2-dev, libxxf86vm-dev, python-all-dev, python-central (>= 0.5),
<kamalmostafa>  quilt
<ScottK> If packages were depending on an indirect depends to get the libssl headers, that's a bug in the package.
<ScottK> If adding libssl-dev to the build-depends fixes it, then that's a correct fix in almost all cases.
<kamalmostafa> ScottK: Ok, that's easy to try anyway.  But it doesn't look to me like the libavg actually refers to "ssl" directly at all.  Isn't it possible that it is pulling in "-lssl" from some build-time thing (pkgconfig of one its dependencies?) so that libavg wouldn't actually know that it needs libssl-dev?
<ScottK> In that case it should be a depends of that dependency.
<kamalmostafa> ScottK: That's what I meant by "supposed to get pulled in by some dependency".  Maybe one of its deps recently accidentally dropped its (required) dependency on libssl?  How can I trace that?
<ScottK> If it did, it wouldn't have built.
<ScottK> Alternatively it can be an actual bug in the package.
<kamalmostafa> a bug in which package?
<ScottK> Could be libavg in this case.
<ScottK> Here's an example of another package that had this problem: http://git.quassel-irc.org/?p=quassel.git;a=commit;h=ab66db150c3eadf225fab28af591ba74093950f6
<kamalmostafa> ScottK: Eight unrelated packages on http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi get the same failure.  Can they all be buggy?  ;-)
<ScottK> kamalmostafa: If they all made the same incorrect, but common, assumption: Yes.
<dupondje> https://bugs.launchpad.net/bugs/512509 feel free to sponsor :D
<ubottu> Ubuntu bug 512509 in burn "ftbfs in Lucid" [Undecided,New]
<ScottK> kamalmostafa: As an example, the Quassel bug was exposed by the qt4-x11 dev package dropping libssl-dev as a build-dep for this exact reason.  It wouldn't suprise me if there were several packages that broke just because of that.
<kamalmostafa> ScottK: But Quassel (if I understand correctly) actually itself cares whether ssl is or isn't present, right?  Certainly its source refers to "ssl".  But libavg doesn't refer to "ssl".   Anyway -- lets set libavg aside for a moment...
<ScottK> Right, I'm just speaking in general.
<ScottK> In libavg's case it may be bug that it tries to build against it when it doesn't need to.  No idea.
<kamalmostafa> Consider package 'dia' which shows a clean ubuntu build months ago, but recently FTBFS with the "cannot find -lssl" error in the udd.debian list.   Could we do a retry build on 'dia' now and see what happens?
<ScottK> Is it FTBFS in the archive, or just in the rebuild test?
<kamalmostafa> Or wait -- I could just pbuilder that myself.
<ScottK> Yes.
<ScottK> Then if it fails, add libssl-dev to the build-deps and see what happens.
<kamalmostafa> ScottK: Okay, I will try that -- but I expect that in all cases, it would fix the build problem -- but still might not be the "right" fix.  Anyway -- it'll be informational.
<ScottK> "Right" is one of two possibilities: Either that's right, or the package is buggy and looking for somethig it shouldn't during build.
<ScottK> relying on indirect depends is a bug.
<persia> In many cases where there's an indirect dependency on libSSL, it may be worth checking if there is a gnutls solution also available.
<persia> (just because of the license checking requirements when linking against SSL)
<kamalmostafa> I think the primary question (for e.g. libavg) is *why* is -lssl appearing in its link line at all?
<persia> Probable a pkgconfig thing.  Dig through the ./configure output
<geser> does libavg build a python extension?
<geser> if yes, it might use LOCALMODLIBS (which contains -lssl) which it shouldn't use
<kamalmostafa> geser: I do see a reference to "LOCALMODLIBS" in its configure script.
<kamalmostafa> libavg's control file is here: http://pastebin.ubuntu.com/363080/
<geser> "LOCALMODLIBS is a macro used to link the python binary against libaries needed for the binary. It must not used to link extensions."
<geser> so you need to patch configure to not use LOCALMODLIBS
<dholbach> good morning
<geser> good morning dholbach
<kamalmostafa> geser: Bingo. I do see the reference to -lssl in the definition of LOCALMODLIBS.  Thanks geser!
<geser> kamalmostafa: I had a similar issue to fix yesterday. you might want to look at http://bugzilla-attachments.gnome.org/attachment.cgi?id=147050 to get an idea how to fix it and adapt this then on libavg
<kamalmostafa> geser: Excellent -- thank you.  Note that libavg isn't the only package showing this problem.  Did something recently change in python that exposed this issue?
<geser> if "recently" == "since lucid", then yes. As far as I understand it LOCALMODLIBS was never intended to by used outside the python interpreter itself.
<dupondje> is there a way to set like 'depend on python-docutils (>6.3) or on (python-docutils <= 6.3 and docutils-writer-manpage) ?
<persia> Not trivially.
<persia> One *could* set up some dummy packages and then depend on the disjuction of the dummies, but that would be annoying.
<persia> Why not just depend on python-docutils > 6.3
<randomaction> what about "python-docutils, python-docutils (>>6.3) | docutils-writer-manpage" ?
<persia> Alternately, if python-docutils > 6.3 provides docutils-writer-manpage, then it should say so in the package declaration.
<persia> randomaction: I don't think versioned dependencies and disjunctions work well together (although I could be wrong).
<persia> Anyway, I think one should never have to do this.  One should depend on python-docutils, docutils-writer-manpage, and if python-docutils supplies docutil-writer-manpage it should Conflict/Replaces/Provides.
<persia> at some point the transition will be considered complete (docutils-writer-manpage is not a package in any supported release), at which point one can drop the Provides from python-docutils.
<persia> That will trigger NBS updates of thngs that depend on it.
<randomaction> persia: that sounds more maintainable in the long run
<persia> I think so :)
<randomaction> my suggestion was only based on formal logic anyway :)
<persia> randomaction: Theoretically, it should work.  I have a feeling it might not in practice, just from the set of apt bugs I've heard about.
<persia> I imagine the various package management tool maintainers would appreciate patches to make the dependency logic formally correct, but I also presume there are better ways for anyone capable of doing that to spend their time :)
<randomaction> dkpg design must have been base on the fact that there's a disjunctive normal form for any logical expression :)
<persia> randomaction: I'm not convinced it was that fancy.  I suspect it started with just foo, bar, baz
<persia> And then someone said "But either of these things could work" and filed a bug, so we got
<persia> foo, bar, baz | quux
<persia> And then someone said "But it only works with version 1.4!", and filed a bug, and so on.
<persia> randomaction: For an extended example of how complex it has become: see http://algebraicthunk.net/~dburrows/blog/entry/package-management-sudoku/ :)
<randomaction> that's great :)
<superm1> tseliot, looks like vdpau works for me in both mythtv and mplayer w/ a fresh install
<superm1> so if someone has a problem with an old upgrade, then you probably just need c/r on an old package (if that package is present)
<tseliot> superm1: what happens if the old vdpau is installed?
<siretart`> superm1: did you already fix the package wrt libvdpau-dev build dependency in lucid by chance?
<superm1> other than not working?  I'm not really sure
<superm1> siretart`, no i didn't want to go trumping on your stuff since you maintain it all in debian
<siretart`> superm1: no worries, I need to be able to git-import-dsc ubuntu uploads anyway
<siretart`> a proper git-format-patch would be of course ideal to preserve attribution and commit messages in our git properly
<superm1> bjsnider might actually already have a diff ready.  i dont currently
<tseliot> superm1: do you think I need to take care of the vdpau-dev package too (with c/r) or would vdpau be enough?
<superm1> tseliot, it wouldn't hurt to do it on the -dev too i suppose
<tseliot> superm1: ok
<superm1> although, you know wait a min?  why is this even necessary?
<superm1> i thought that it's the exact same library that's in libvdpau1
<superm1> so it shouldn't be installable side by side
<superm1> so when mplayer grows the proper depends, there will be an error at that time too
<tseliot> superm1: we install libraries in their own directories now
<superm1> but i'm saying /usr/lib/libvdpau.so.1
<tseliot> there may still be a link in /usr/lib though
<superm1> the one that comes from the package libvdpau1
<superm1> since mplayer doesn't yet have a depend on it, there wasn't an error for having the old package in place
<tseliot> superm1: are you suggesting that we don't use c/r?
<ideasman42> Hi there, Im wondering about licensing for upstream, its a practical matter
<superm1> tseliot, lets get the new mplayer sorted out first, and see if this problem is persisting for upgraders
<ideasman42> How should I license 3D models that have no header?
<ideasman42> I was told that I had to license every file
<superm1> there's still plenty of time to add the c/r if it's necessary
<tseliot> superm1: but still that would break the alternatives system
<ideasman42> they are all creative commons, but does each file need to explicitly state this somehow?
<persia> ideasman42: In what format are the models?
<ideasman42> blend
<superm1> tseliot, which would? the c/r?
 * persia hunts up file format specs
<ideasman42> blender-3d
<tseliot> superm1: not having c/r
<directhex> ideasman42, are the copyright owners and specific CC version clearly defined in a file accompanying the models in the source distribution?
<superm1> tseliot, i'm not entirely familiar enough with how the alternatives system is working, can you elaborate why it would break it by not having it?
<ideasman42> directhex, when we distributed the DVD yes, from our SVN repo its not so clear
 * persia doesn't really understand why it's not listed at http://wiki.blender.org/index.php/Dev:Ref/File_Formats
<ideasman42> persia, its an internal file format - basically a memory dump
<persia> ideasman42: Well, my general recommendation is that if the format supports internal tags, to have the tag contain at least the license name.  It the format is text-based, include the license information has a comment, and if the format restricts comments reference it in a README file.
<tseliot> superm1: /usr/lib/libvdpau_nvidia.so is installed by the old vdpau and it's a link in the nvidia package. Even if the latter overwrites the link from the former, when you remove the former you break alternatives (as that file is removed)
<ideasman42> persia, ok, thanks. will add some README / COPYING file
<superm1> Ah, because a real file trumps a symlink in terms of a package - and the alternative happens postinst, it's not owned by a package
<ideasman42> as downstream requires
<tseliot> superm1: right
<persia> ideasman42: tags or comments are best though, if possible.  When using tags or comments, also reference in the README, and don't forget to include a copy of the license with the upstream source so that people who download can be confident they are reading the same text the authors read.
<directhex> ideasman42, if it's a binary format then a README of some kind should be fine. and you really want "svn export" to pick up on it if downstream is meant to package frmo svn
<superm1> so yeah, definitely need a c/r if there is an old package that is providing that file in karmic
<persia> No, just needs replaces.
<directhex> ideasman42, i think there's a #debian-games on oftc too
<ideasman42> directhex, have a makefile for svn export and fedora use this
<persia> c/r is only needed if in addition to overwriting that file, the rest of the files need to be removed from the system.
<persia> In face, #debian-games@oftc is where many of those who maintain games in Ubuntu hang out.
<persia> s/face/fact/
<ideasman42> thanks guys. back to bugfixing :D
<directhex> (yo frankie discussion on planet/reddit)
<directhex> (pabs & runa seemingly both gave up on it)
<persia> licensing issues?
<runasand> ah, that one
<runasand> persia: yes
<directhex> oh, a runasand!
<persia> heh.  That keeps more stuff out of the archive than just about anything else.
<directhex> well now i feel like i'm talking about people behind their back
<persia> At one point there were about 40 games that were well-packaged in d-g svn that were under license negotiation.
<runasand> directhex: :)
<directhex> i'm happy to do packaging for tricky packages, as i enjoy a challenge - but that excludes debian/copyright which isn't challenging, it's just unfun
<runasand> directhex: that's what I figured as well
<persia> I usually do debian/copyright first, so that I know I don't want to package something before I get too excited about making it work.
<runasand> persia: that's one of things I learned :)
<persia> (of course, this fact also helps keep me from packaging new stuff much)
<jetienne> q. how do i know the content of a .deb ? all the files in it i mean
<sebner> persia: sounds familiar to me *ehehehehe*, huhu btw :)
<directhex> jetienne, dpkg -c /path/to/file.deb
<jetienne> directhex: thx
<hyperair> is it possible to copy a package from lucid to karmic-proposed?
<hyperair> say podsleuth for example.
<hyperair> no nevermind, it isn't possible for podsleuth's case due to a transition
<xteejx> Is there a mentoring scheme for packaging?
<xteejx> Also this "Quickly" thing, is it usable for packaging anything?
<persia> um, kinda sorta.
<persia> It does have a module that creates a package wrapper.
<persia> And you can start from that to have a package.
<xteejx> Hmm
<persia> There isn't really a mentoring scheme, although lots of people are always happy to explain.
<persia> Did the recipe I gave you before not work sufficiently for something?
<mira|AO> hi, I have a strange problem; if this is the wrong channel please tell me a better oneâ¦
<mira|AO> I need to package a TTF (OTF, actually) font for hardy.
<mira|AO> defoma segfaults on me.
<xteejx> persia: I'll be honest I got really annoyed with it. I'm not sure if packaging is my thing, it's too damn difficult, and there's too many things to do with the rules file (poorly documented). Its a real shame, because I think that's the reason why there are very few new packagers :(
<mira|AO> There is Debian #477435 but I did install libft-perl
<ubottu> Debian bug 477435 in defoma "defoma-hints crashes on some OTF files" [Important,Open] http://bugs.debian.org/477435
<mira|AO> does anyone have a solution? debian seems to have dropped defoma, but that was post-hardy AFAICT
<persia> xteejx: As I tell nearly everyone at some point, despite packaging being deceptively easy, the best way to learn is really to debug existing packages and get a feel for how things work :)
<MTecknology> persia: You want to check out the man page and let me know what you think?
<persia> MTecknology: Please ask generally.  I'm a bit busy now, and surely someone else can help.
<xteejx> persia: Easy!? I know what *needs* to be done, I just don't know how to do it. I know what goes where, and how it *should* all tie in.
<MTecknology> Anyone up for letting me know what they think of this man page I made up? Nit picking welcome :)  http://paste.ubuntu.com/363246/
<persia> xteejx: Just ask for each problem, but again, looking at other examples can help give you ideas.
<xteejx> I think MOTU should have a school or session on how to create a package from scratch. Just pick an unpackaged upstream from ...wherever really... show the complications that can arise, how to effectively write a rules file, using debhelper and the dh_** things in the rules file, etc.
<persia> xteejx: I've offered to teach such a class to the developer training group.  Watch their wiki to see when it gets schedule.
<persia> d
<xteejx> I'd be surprised if after reading something like that, we wouldn't have new packagers, this is probably one of the main problems they face as I am :(
<xteejx> persia: This Dev OpenWeek?
<persia> No.
<persia> DEveloper Training is compeltely separate from Open Week.
<xteejx> ok
<MTecknology> xteejx: I'm packaging something that was never packaged before using the complete guide - so far I don't think I've been stuck (help from here too)
<xteejx> MTecknology: Did you have any previous experience?
<mira|AO> is there maybe a more appropriate channel for font packaging related issues?
<persia> The wiki page keeps moving, but I *think* it's currently https://wiki.ubuntu.com/Packaging/Training
<xteejx> Every Thursday?
<MTecknology> xteejx: not really
<persia> Well, assuming there is sufficient faculty, yes.
<\sh> grmpf...
<xteejx> MTecknology: Don't you have problems with debhelper and all the commands in debian/rules as well? It's doing my head in! lol
<\sh> regarding this http://www.mail-archive.com/debian-devel@lists.debian.org/msg230777.html discussion, dpkg --purge / apt-get remove --purge shouldn't delete the /opt dir, but somehow it does exactly that, because of exactly the reasoning the threads tells us
<\sh> how can someone avoid that?
<xteejx> persia: If you do a session for something like that I can guarantee I'll be there!!
<MTecknology> xteejx: I tried to work on existing packages but I coudln't figure it out - I'm hoping that a new app will be easier to package and a good place to start
<persia> \sh create opt.deb that contains only /opt as an empty directory and pin it?
<xteejx> That's my thought, and then I can see the whole process too
<MTecknology> xteejx: debian/rules - last thing I think I have left; this part could use more explanation
<persia> New packages are really harder.
<\sh> persia: or we include /opt in base-files and not creating it in base-files postinst?
<persia> Because there's so much that can go wrong.
<persia> 95% of new packages I see from new packagers are wrong in several ways, and even after all the issue are corrected fail to follow best practices.
<ogra> just touch /opt/blah :)
<persia> \sh: No idea.
<ScottK> \sh: It's optional in FHS, so failing to provide it isn't wrong.
<ogra> dpkg wont delete non empty dirs
<\sh> ogra: it will...
<ogra> thats a bug
<\sh> ogra: it already has in my test
<ScottK> ogra: I think the problem is not deletion on removal, but deletion on purge.
<MTecknology> persia: will lintain help me with that?
<ogra> oh, purge
<ogra> i messed that
<ogra> *missed
<persia> MTecknology: Not really, no.
<MTecknology> persia: oh..
<persia> lintain clean != cleanly packaged.
<xteejx> MTecknology: I got up to that point, and started hitting my head on the wall... and then the files/folders have to comply with the set /usr/bin/ /usr/share/ directory structure!
<persia> So, that's why it's nice to work with existing packages.
<persia> They already work, except for something that's wrong.
<xteejx> Yeah, but chances are that will lead to coding....
<persia> So one can adjust packaging issues, or apply patches, or similar in an isolated fashion within a working framework.
<mok0> persia: actually, that should be an implication: linitan clean <= cleanly packaged
<MTecknology> xteejx: actually.. I did some coding on this :P
<xteejx> heh...
<persia> mok0: Hard to do, because there are many unclean but correct ways to package.  Better to have another tool for that.
<mok0> persia: I was just commenting on your statment containing the != unequality :-)
<persia> Right.  I think it *should* be an unequality.
<persia> I think there is huge value in having something that validates policy and common practices.
<mok0> Uhm, no. A clean package will also be lintian clean
<persia> But I think that's a different tool than something that validates style.
<persia> Not necessarily.
<ScottK> mok0: Generally, yes, but not always.
<persia> There's lots of times you want to do something lintian doesn't like, but you know it to be correct.
<ScottK> Lintian documents general best practice.  It's not always appropriate.
<mok0> Assuming the tool works
<persia> Not all of these are bugs in lintian.
<ScottK> In Debian the now autoreject uploads for some issues that lintian flags.
<ScottK> My favorite so far was the autorejection of zlib for containing an embedded copy of zlib.
<persia> heh :)
<persia> Does autorejection ignore overrides?
<ScottK> Depends on the tag.
<persia> Oh my.
<ScottK> Some are over-rideable, some aren't.
<mok0> Nice way to limit the size of the archive :-)
<persia> Well, no.  It doesn't do that.
<persia> It's possible to construct many huge lintian-clean packages.
<persia> But it may not be possible to construct a lintian-clean distribution.
<mok0> Right. It limits the growth in the size of the archive
<xteejx> Is that correct, we don't *actually* build the .deb files, and that the autobuilders do that for us from the source and the rules file?
<persia> (or at least it puts a huge load on the installer and image building tools)
<ScottK> I'm OK with that in general, although I think delegating to the lintian authors is probably not the best way to do it.
<persia> xteejx: Most of us build .deb files for testing and throw them away, and then the autobuilders make trusted ones.
<xteejx> Is that the debuild -sa ?
<persia> mok0: It *doesn't* limit the growth.  Like I said, it's possible to construct lots of large lintian-clean packages.
<persia> xteejx: No.  -sa makes sure that the orig.tar.gz is listed in the .changes file.
<xteejx> Ohhh, it's just debuild on its own :P
<persia> xteejx: I use sbuild for building .debs.  Some people use pbuilder.  Other tools are cowbuilder, qemubuilder, dpkg-buildpackage, etc.
<persia> No.  That builds source *and* binary.
<MTecknology> alrighty; the rules file has me lost
<xteejx> ahhhh
<persia> debuild -b builds a binary.
<persia> But any binary built locally is suspect because the build-depends haven't been validated.
<xteejx> that's why we use pbuilder right?
<persia> MTecknology: 90% of the time /usr/share/doc/debhelper/rules.tiny should do 90% of what you need.
<persia> Right.
<xteejx> woohoo I'm learning :)
<ScottK> But understanding what you are doing is still recommended even if rules.tiny works.
<persia> OK.  So lets fix some bugs.
<MTecknology> persia: I have one man page that wasn't there when I started and there's one file.c that produces one binary.
<xteejx> Who?
<persia> MTecknology: Hrm.  You probably need special stuff then.
<persia> (or create a Makefile)
<persia> xteejx: You.  Me.  Someone else :)
<MTecknology> persia: sorry, there's a Makefile there, also README and COPYING
<xteejx> Ohhh hehe I do enough triage as it is ;) I wanna get my hands dirty with packaging and then I can work through both
<persia> Then it probably works for you.
<xteejx> Makefile should be easier ./configure make make install thing
<persia> xteejx: OK.  go pick a bug that you've triaged (so you understand it) on a package in universe, and let's fix it.
<xteejx> Oh God
<xteejx> I'd love to fix bug 230258
<ubottu> Launchpad bug 230258 in ubuntu "[needs-packaging] anim2000" [Wishlist,Confirmed] https://launchpad.net/bugs/230258
<xteejx> but it's packaging
<persia> Right, but it doesn't give you an example package to work within :)
<persia> Pick something that looks like a packaging bug that isn't a needs-packaging bug.
<xteejx> Ummmm..........
 * xteejx hunts
<xteejx> Trying to find one is hard!!
<persia> OK.  I'll give you one if you want.
<xteejx> ok
<persia> libpam-alreadyloggedin FTBFS on i386 and powerpc because there's an issue with ld and stack-smashing-protection.
<persia> So it needs to use gcc instead of ld to build the final library.
<xteejx> bug number?
<persia> Dunno if it's filed yet.  Go check :)
<xteejx> lol
<MTecknology> persia: wow - rules.tiny is micro.. I'll try that out..
<xteejx> persia: Not filed
<persia> OK.  File it.  Assign yourself.  Bug title is something like "libpam-alreadyloggedin FTBFS on i386 and powerpc"
<EtienneG> hello all
<persia> Hey EtienneG
<xteejx> FTBTS = fails to build from source right?
<xteejx> Hi
<persia> Right.
<EtienneG> just curious: is there any plan for Moonlight 2 in Lucid?
<MTecknology> Is this bad output from debuild -S?  WARNING generated by debuild:  Making debian/rules executable!
<EtienneG> hello persia!
<persia> MTecknology: No.  That's safe.
<xteejx> persia: bug 512806
<ubottu> Launchpad bug 512806 in ubuntu "libpam-alreadyloggedin FTBFS on i386 and powerpc" [Undecided,New] https://launchpad.net/bugs/512806
<persia> OK.  Now grab the lucid source, and look around at it.  You'll see how everything fits together.
<MTecknology> 5min download for build deps.... hurray 90k network
<xteejx> persia: That's a small lib
<persia> Yep.  That's part of why I picked it as an example :)
<xteejx> persia: Anything I should be looking at?
<xteejx> I run i386, so try to build?
<persia> Well, I'd start by looking at debian/rules and Makefile, to make sure I understood how the package gets built.
<persia> We know we have to change ld to gcc, but we need to make sure we know how it gets called first.
<persia> Build log for i386 is https://launchpad.net/ubuntu/+source/libpam-alreadyloggedin/0.3-1/+build/1428110/+files/buildlog_ubuntu-lucid-i386.libpam-alreadyloggedin_0.3-1_FAILEDTOBUILD.txt.gz
<xteejx> I'm guessing from the build log that the problem is: pam_alreadyloggedin.c:267: undefined reference to `__stack_chk_fail_local'
<MTecknology> It was building so nice - until the man page - http://paste.ubuntu.com/363263/
<persia> Right.  If you want details on why the fix is switching from ld to gcc you can check backscroll in -devel and -meeting when I discused it previously.
<persia> This was my bug, I just hadn't gotten to it yet.
<xteejx> ok
<xteejx> I'm looking at pam_alreadyloggedin.c line 267
<xteejx> and it's gibberish
<xteejx> same as rules and Makefile lol
<persia> Yeah.  Ignore that.  The fix is in how it builds (packaging), not in the code.
<persia> (another reason I picked this exampe)
<xteejx> cool
<MTecknology> Is this error just because my Makefile doesn't have anything about the man file?
<xteejx> persia: I'm guessing its one of the first 2 lines in the Makefile
<persia> xteejx: Those are just variable defintions.
<persia> xteejx: You may want to read the make manual section about variables and about rules to get a good understanding to read this file.
<xteejx> I know what variables are
<geser> MTecknology: have you a debian/lal.docs file?
<persia> You don't have to read the entire manual, but skim through until you understand debian/rules and Makefile
<xteejx> Just....
<MTecknology> geser: no, there's a docs/lal.1 file
<geser> then why does cp say the file isn't there? (docs/lal.1)
<xteejx> persia: Quick question... the $(MKDIR) $(FAKEROOT)$(SECUREDIR) bit in the Makefile, is that just how they insert the defined variables above, so for this one it'd be to run "mkdir -p /lib/security" ??
<xteejx> btw its the first install: line
<MTecknology> geser: I have no idea.. I just created that file yesterday
<persia> Right.
 * xteejx holds back from swearing in a good way hehe
<MTecknology> oh well - I need to run, I'll figure it out later
<xteejx> Yippee!
<xteejx> :P
 * MTecknology runs off
<xteejx> and the next would be "install -m 700 pam_alreadyloggedin /lib/security" ?
<persia> Let's not review every line, but you're getting the idea.
<persia> Just make sure you understand every line :)
<xteejx> I think I'm getting it yes
<xteejx> some bits a little confusing though
* ScottK changed the topic of #ubuntu-motu to: Ubuntu 9.10 released! | Lucid Alpha 2 Released! | Want to get involved with the MOTU? https://wiki.ubuntu.com/MOTU/Contributing | Sponsor queue: http://is.gd/2y76G | http://qa.ubuntuwire.com/ftbfs | http://people.canonical.com/~ubuntu-archive/NBS/ | http://qa.ubuntuwire.com/debcheck | latest rebuild failures: http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi | Outstanding merges: merges.ubuntu.com or http://people.ubuntuwire.com/~lucas/merges.html (
 * ScottK tries again
<xteejx> persia: So in reality, assuming I want to make a package from scratch, I could just redefine the variables, or insert new ones to get things in the right place?
* ScottK changed the topic of #ubuntu-motu to: Lucid Alpha 2 Released! | Want to get involved with the MOTU? https://wiki.ubuntu.com/MOTU/Contributing | Sponsor queue: http://is.gd/2y76G | http://qa.ubuntuwire.com/ftbfs | http://people.canonical.com/~ubuntu-archive/NBS/ | http://qa.ubuntuwire.com/debcheck | latest rebuild failures: http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi | Outstanding merges: merges.ubuntu.com or http://people.ubuntuwire.com/~lucas/merges.html (MoM fixed)
<persia> xteejx: Sure, but we're working with an existing package now.
<xteejx> Of course :) Just wondering how it all fits
<persia> The idea being that working with a few existing packages will help you understand how everything works, and make packaging easier.
<xteejx> :)
<persia> So just let me know when you have a suggestion as to how to swtich from ld to gcc.
<mira|AO> nm, got itâ¦ Invalid_File_Format â cf. /usr/share/doc/libttf-dev/docs/apiref.txt.gz
<mira|AO> libttf doesnât seem to handle *.OTF files
<xteejx> persia: Replace the LD = ld variable with LD = gcc ?
<xteejx> Or change the $(LD) $(LDFLAGS) $(OBJS) -o $@ line to be $(CC) $(CFLAGS) $(OBJS) -o $@  ?
<persia> I'd probably try $(CC) $(LDFLAGS) $(OBJS) -o $@ first.
<persia> (can you tell me why?)
<xteejx> So that gcc still uses the -lpam.... part? (I don't understand why though)
<persia> OK.  Check the gcc and ld manpages, to figure out what the arguments do.
<mira|AO> usually, CCLD is used as linker, which is the same as CC, as ld cannot, by itself, know enough to link a regular unix userspace utility
<persia> Often, yes.  In this case, it's only linking a shared library, which ought to work.
<persia> But there's some little-understood interaction with the stack-smashing protector, and it's confusing LD.
<mira|AO> even shared objects need things like crti.o, crtbeginS.o, â¦
<mira|AO> so, no
<mira|AO> ;)
<persia> mira|AO: This is a PAM plugin.  Works fine with ld in debian :p
<xteejx> persia: I can't see a "gcc -lpam" option in the man gor gcc
<xteejx> *for
<persia> xteejx: search for -l
<persia> the "pam" part is a library name.
<xteejx> It searches for pam using the -l option ... I can read it fine, it's understanding it that's the problem
<persia> Hrm.  Anyone have a good link to an intro doc on using gcc as a compiler and linker?
<xteejx> Anyone able to tell me what those 2 words mean? :P
<mok0> "compiler" and "linker" ?
<xteejx> I think a compiler is a program that compiles code, right?
<mok0> right
<xteejx> to what end?
<mok0> a linker combines several chunks of compiled code to one executable
<mok0> xteejx: a compiler "translates" human readable program code (for example C, C++, FORTRAN, etc) to machine code
<xteejx> so in essense one makes the code the linker needs to pull into an executable?
<xteejx> I understand
<mok0> xteejx: yes, because a program is often split into many files
<mok0> xteejx: and each file is compiled separately
<xteejx> ohhhhhh, so all these .c files or whatever are just the code that's needed, and things like gcc read them, put them into machine code from the 'human readable' code that can be passed on to a linker to compile *that* into an executable?
<persia> Well, for the linker to *link* into an executable, but yes.
<mok0> xteejx: yes
<xteejx> cool
<mok0> xteejx: but with gcc, those two functions (compiler and linker) are both carried out by the "same program"
<persia> OK.  Now that this has been explained (thanks mok0), do you understand why I suggested that substitution?
<persia> Err, let me revert that, since there is more explanation (which may be useful)
<xteejx> huh?
<persia> I had thought the explanation was complete, and so was proceeding, but the explanation may not have been complete, so I wanted to withdraw the next question until you understood enough to move forward.
<xteejx> phone call brb
<xteejx> back, sorry about that
<xteejx> persia: Is the answer so that it can compile the pam library for use with pam_alreadyloggedin?
<persia> Rather that we want to use gcc in the first case to compile the objects, and in the second case to link against the pam library.
<persia> So we need to pass different arguments to gcc to achieve this.
<xteejx> the objects being the .o files?
<xteejx> and shared libraries are .so ?
<persia> Right.
<xteejx> This is a rather steep learning curve, but getting there :)
<persia> Indeed, but by working with an existing package, this is the *only* bit you need to learn to fix the bug.
<persia> And for the next bug, you'll learn a different bit.
<persia> And eventually you'll be an expert :)
<xteejx> Hopefully! :D
<persia> OK.  So do you understand the change?
<xteejx> That we need to change from ld to gcc (for whatever reason to fix the bug), and we need to keep the same flags so that gcc can replace ld, but without replacing what it was meant to do, i.e. continue to use LDFLAGS so that the objects can be compile and linked to the libraries?
<persia> RIght.
<persia> I don't 100% understand why it needs to change either, but I have it on good authority that it needs the change.
<xteejx> :D :D :D :D :D :D
<persia> So, make that change.
<xteejx> done, saved
<persia> This package stores all the patches in the diff.gz, so we don't have to worry about patch systems.
<persia> Some packages store patches in debian/patches, and we'd have a different procedure to make the change.
<mok0> persia, probably has to do with options that are silently set when gcc calls ld
<persia> Next, run `dch -i` to add a new revisoin to the changelog, and describe your changes.
<xteejx> thought that would come next :)
<persia> mok0: There's some special hints for the SSP involved that were added to gcc, but not yet to ld.
<mok0> ok, yeah
<xteejx> what would i write for description? "changed usage from ld to gcc Closes (LP: #*****)" ?
<sistpoty|work> hm... http://qa.debian.org/developer.php?login=ubuntu-motu@lists.ubuntu.com
<persia> That ought be sorted.
<persia> xteejx: http://irclogs.ubuntu.com/2010/01/25/#ubuntu-devel.html contains the log of the discussion I had about it.
<persia> (near the top)
<xteejx> i'll have a look at that later, bookmarked :)
<persia> I'd probably put something like "Use gcc to call the linker to take advantage of improved .spec files (LP: #xxxxxxx)"
<persia> Oh, I wsa referencing it to help you write the changelog.
<persia> It's not worth bookmarking.
<xteejx> ohh
<persia> It's maybe 10 lines of discussion from around 4:35
<kamalmostafa> Motu magic needed...  "bzr branch lp:ubuntu/libavg" pulls a slightly stale revision.  (Last time I had a similar problem with another pkg, geser and james_w declared it to be a "spurious failure to import" and fixed it instantly).
<xteejx> Ok, changelog done
<persia> xteejx: Great.  Next `debuild -S -uc -us` to get a candidate source package.
<xteejx> persia: Standards-Version: 3.8.1  .... bump to 3.8.3?
<persia> Nope.  We leave that alone for packages maintained in Debian.
<xteejx> ok
<persia> We only update it for stuff that doesn't have a Debian maintainer, and for which we are willing to put in the effort to maintain properly.
<xteejx> debuild: fatal error at line 1340:
<xteejx> dpkg-buildpackage -rfakeroot -d -us -uc -S -uc-us failed
<persia> OK.  Why?
<xteejx> Pass
<persia> Then paste more context.
<persia> (in a pastebin)
<xteejx> its my fault
<xteejx> -uc-us should have a space :P
<geser> kamalmostafa: unless james_w can help you, you need to do it the "old" way: apt-get source libavg
<xteejx> persia: Done, it complained about standards version, but mehh
<persia> xteejx: Now, try compiling it for i386 or powerpc (using pbuilder or sbuild or something)
<xteejx> i386 here
<xteejx> how to I clean pbuilder?
<xteejx> dw
<dholbach> Day 2 of https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in #ubuntu-classroom (on irc.freenode.net) in 17 minutes!
<xteejx> persia: No build errors
<persia> xteejx: Just to confirm, try building the original package to make sure you can replicate the failure.
<xteejx> persia: I did 'sudo pbuilder build --architecture powerpc libpam-alreadyloggedin_0.3-1ubuntu1.dsc ' but it built an i386.changes
<xteejx> .deb even
<persia> That's correct.  It built it for i386, right?
<xteejx> yes
<persia> That's how it says which arch the .deb is for.
<xteejx> I tried --architecture powerpc
<persia> Your machine probably can't be a powerpc :)
<xteejx> ohhh I see, it only builds on that hardware for that arch?
<persia> Well, there are ways to fake it for certain architectures, like using i386 on amd64, or using qemubuilder for armel.
<persia> But mostly, yeah.
<xteejx> shame my ps3 won't run ubuntu well .... lol
<kamalmostafa> geser: okay, but it sure seems like that flow will involve more work later -- someone will eventually have to apply my patch to a branch, right?
<kamalmostafa> (BTW, as suspected package 'dia' also exhibits the "cannot find -lssl" problem if I try to build the current Lucid source -- it has the same python LOCALMODLIBS problem)
<xteejx> persia: the original .dsc failed :)
<persia> In the same was as the buildd log?
<xteejx> yup
<persia> Excellent.
<xteejx> ld final link failed, etc
<persia> Now use debdiff to generate the differences between your new candidate version and the old version.
<persia> Make sure that the debdiff only includes the changes you intended to add.
<xteejx> which one is first i forget is it "A Bubuntu1 > C"
<persia> debdiff old new
<xteejx> ok
<geser> kamalmostafa: as we can't build from branches yet, your sponsor has to upload a source package anyways. as the libavg branch isn't uptodate anyways getting it more outdated shouldn't matter much
<xteejx> persia: Done :)
<persia> xteejx: Attach the debdiff as a patch to the bug, and subscribe ubuntu-universe-sponsors.
<persia> Someone will either upload or critique your work.
<xteejx> Ok :)
<persia> And thanks for fixing a bug.  Now go find another one and fix that.
<kamalmostafa> geser: okay, thank you.
<persia> I won't walk you through it again, but you should have the basic procedure down: 1) understand the bug, 2) get the source, 3) understand the part of the source related to the bug 4) fix the bug 5) document the fix 6) create a source 7) test to confirm the change did what you wanted 8) request sponsorship
<ubottu> Launchpad bug 4 in rosetta "Importing finished po doesn't change progressbar" [Medium,Fix released] https://launchpad.net/bugs/4
<ubottu> Bug 5 on http://launchpad.net/bugs/5 is private
<persia> oops :)
<xteejx> done...bug 512806 :) Again, persia you have been brilliant! Thank you.
<ubottu> Launchpad bug 512806 in ubuntu "libpam-alreadyloggedin FTBFS on i386 and powerpc" [Undecided,New] https://launchpad.net/bugs/512806
<xteejx> lol
<xteejx> I can delete all this libpam stuff now right?
<persia> If you're sure the patch on LP is correct, yeah.
<xteejx> Cool
<xteejx> I'll be back later, gonna get some food, thanks again persia you're just brilliant!!
<NateW> im getting "gpg: skipped "Nate Wiebe <nate@natewiebe.com>": secret key not available" when building a source file using debuild -S
<NateW> i have already created a gpg key
<persia> NateW: Did you add a comment to your identity when creating your GPG key?
<NateW> yes
<persia> Did you put the same comment in your name in the changelog entry?
<NateW> no.. so i should change it then?
<persia> yes.  The two have to match exactly.
<persia> So you either need to edit your key, or your changelog.
<NateW> how would i edit the key?
<geser> did you upload your key to a keyserver yet?
<NateW> yes
<persia> I find that using the GUI tools tend to be the easiest way to edit the key.
<geser> just add a new uid and revoke the old one (if wanted) but you can keep the old uid too (revoking is the only option, you can't delete it)
<persia> Are you sure you can't edit it.
<geser> or just use the comment in your changelog entries too
<persia> My signatures are preserved over the edits I've done.
<persia> So I've presumed my UIDs have been preserved.
 * persia uses seahorse to edit the gpg key
<NateW> after editing i have to reupload correct?
<persia> RIght.
<geser> you can't change the uid after creating (not sure about comments) as this would make signature useless (collect first signatures and change later the uid to something different)
<persia> Maybe it only works for the comment.
<persia> But I could be wrong.  It's been a *long* time since I had a comment in a GPG key (and that was probably a PGP key, back then)
<NateW> alright.. its working.. thanks for the help
<kamalmostafa> geser: please have a look at bug 512861 -- is my description of the problem correct?  its ready for sponsor review, I think.
<ubottu> Launchpad bug 512861 in libavg "libavg FTBFS: python LOCALMODLIBS causes -lssl link failure" [Undecided,Confirmed] https://launchpad.net/bugs/512861
<geser> kamalmostafa: looks ok, I see that you set py_localmodlibs="" (which is ok). have you looked if dropping this variable at all is possible or would that channge too much?
<kamalmostafa> geser: I wanted to minimize the change (and make it obvious as to "what happened to py_localmodlibs" if anyone was looking for it in the future).  But it would be easy to remove it altogether, if you'd prefer that.
<geser> ideally this should get included by upstream, so we don't have to look at it again in future :)
<kamalmostafa> geser:  oh, and btw, I see the *exact* same construct in package 'dia' also, and it also FTBFS in my own pbuilder.
<kamalmostafa> geser: I will file an upstream bug and submit the patch, once its approved here.
<xteejx> Hey guys, I'm trying to fix FTBFS in emacs-chess-2.0b6, but http://paste.ubuntu.com/363328/ it appears the command emacs cannot be found. Do I have to explicitly tell it /usr/bin/emacs ?
<xteejx> the error I think is in the makefile
<geser> is emacs installed through build-depends?
<xteejx> geser: No there is no emacs in build-depends
<xteejx> oops, that's the problem :P
<xteejx> thanks geser I'll try that ;)
<xteejx> Can I do "Build-Depends: emacs23 | emacs 22" ?
<geser> sure
<xteejx> I ran the updated .dsc through pbuilder, where can I find the build log?
<xteejx> (I have more problems with menus)
<geser> in your terminal, but pbuilder has an option to also write it into a file
<xteejx> geser: What's the option for that, I can't scrollback far enough :(
<geser> pbuilder build --logfile mypackage.log mypackage.dsc (the same works if you use the pbuilder-dist wrapper)
<xteejx> pbuilder-dist??
<xteejx> No worries, that's one to learn methinks, thanks geser :)
<sistpoty|work> xteejx: I find PKGNAME_LOGFILE=yes in .pbuilderrc quite useful
<xteejx> oooh didn't know about that :)
<kamalmostafa> xteejx: fyi, pbuilder-dist is good stuff -- essentially, it lets you set up pbuilders for different release/architectures so that you can, for example, build Lucid packages on a Karmic machine, or build i386 packages on an amd64 machine.   The man page 'man pbuilder-dist' explains in more detail.
<xteejx> kamalmostafa, as good as that sounds, I'm running Lucid i386 at the mo anyway, I don't think it's of any use to me, I would use AMD64 Ubuntu, but my laptop is too new, something to do with the instruction set isn't supported by the kernel, but 32 bit mode is
<xteejx> otherwise, I'd be building for amd64 and i386 or testing them anyway
<xteejx> but it's another snippet that I'm putting in Tomboy for future reference :)
<xteejx> Another missed build-depends: texinfo heh least this one seems to be easy so far :D
<shadeslayer> persia: around?
<shadeslayer> ok well  ok apparently debuild -S -sa does not recognise the original tarball and gives me : http://paste.ubuntu.com/363387/
<shadeslayer> the orignal tarball is rekonq_0.3.33.orig.tar.gz
<shadeslayer> as you can see from line 49 it seems to be a tarball problem.... or am i wrong?
<sebner> shadeslayer: it seems the tarball is b0rken. download the sources again and make a new .orig one
<shadeslayer> sebner: the thing is its a git clone and i archived it with git archive
<sebner> shadeslayer: ah, haven't worked with git archive yet, I'm sorry
<shadeslayer> sebner: it worked till yesterday,today they updated the git repo and now its broken?
<shadeslayer> weird
<shadeslayer> maybe im archiving wrong with : git archive <revision no.> >rekonq
<MTecknology> This rules file is throwing me for a loop; I try to compare to others but they all seem to be so different and some are really ugly
<fabrice_sp> a package that has entered into testing on the 23rd should have been automatically synced in lucid?
<fabrice_sp> or no "automatic" synced has been performed since the 23rd?
<fabrice_sp> s/synced/sync/
<fabrice_sp> it's for bug 512667
<ubottu> Launchpad bug 512667 in ubuntu "Sync xfoil 6.97.dfsg-3 (universe) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/512667
<MTecknology> How do I include a man page? There's a debian/docs file. I added docs/lal.1 to it. I have the docs/lal.1 file as well....
<randomaction> MTecknology: dh_manpages does it, you need to add it to debian/PACKAGENAME.manpages
<randomaction> I mean, add filename to debian/PACKAGENAME.manpages
<MTecknology> randomaction: how do I install dh_manpages?
<randomaction> it should be called from debian/rules. If you use rules.tiny, this happens automagically.
<MTecknology> alrighty, so I was just in the wrong file
<MTecknology> I'll try it now :)
<MTecknology> last problem.. I ran lintain and it gave me this.. http://paste.ubuntu.com/363419/
<MTecknology> In the changelog it's 1.0-0ppa1
<shadeslayer> sebner: it worked out.... people from #git helped :)
<fabrice_sp_> MTecknology, this happen when you don't have a .orig.tar.gz tarball
<fabrice_sp_> debuild generate in that case a native package
<MTecknology> fabrice_sp_: so I don't need to worry about it?
<geser> in most cases you want non-native packages
<randomaction> MTecknology: do you have an upstream tarball?
<fabrice_sp_> MTecknology, you should have a upstream source tarball
<MTecknology> fabrice_sp_: randomaction: I only got the git source from upstream
<randomaction> you should probably export it as a tarball
<fabrice_sp_> randomaction is faster ;-)
<randomaction> it they provide some tarball, your life is easier
<MTecknology> they don't, it's a new package too
<fabrice_sp_> MTecknology, rename the git export directory to <source>.orig, and copy it to add the debian directory
<fabrice_sp_> this way, you will have a <source> directory with the packaging changes and <source>.orig directory with original source
<MTecknology> fabrice_sp_: so mv lal-git lal-1.0/debian/lal.orig ?
<fabrice_sp_> MTecknology, nop: cp lal-git lal-<version>.orig and mv lal-git lal-<version>
<fabrice_sp_> you should have both directory at the same level
<MTecknology> thanks :)
<shadeslayer> ok anyone around to look at : http://paste.ubuntu.com/363430/ : lines 51 and 52
<shadeslayer> please explain those warnings to me :)
<fabrice_sp_> shadeslayer, you created 2 new empty files in the root directory of your source. Just delete them
<fabrice_sp_> if it's something produced during the build process, you should delete them in the clean target of debian/rules
<shadeslayer> fabrice_sp_: ah nice catch
<shadeslayer> fabrice_sp_: no apparently i also copied the original tarball into the extracted source.... dont know how that happened :P
<randomaction> shadeslayer: you're using CDBS, right?
<randomaction> and there's tarball.mk in your debian/rules?
<shadeslayer> yeah
<MTecknology> fabrice_sp_: that gave me two top level directories, lal-1.0 and lal-1.0.orig; with lal-git inside of lal-1.0/
<shadeslayer> and for the second question lemme check
<fabrice_sp_> MTecknology, lal-1.0 should contain the content of lal-git, so no intermediate directory there
<shadeslayer> randomaction: i have : /usr/share/pkg-kde-tools/makefiles/1/cdbs/kde.mk
<MTecknology> fabrice_sp_: fabrice_sp_ ok, so that's something I already did before :P
<shadeslayer> randomaction: anyways ive deleted both those files and it worked :)
<randomaction> great
<shadeslayer> wth... 32 bit version was compiled too!
<shadeslayer> thats quick :P
<MTecknology> fabrice_sp_: lal-1.0.orig has no debain/ directory in there
<fabrice_sp_> MTecknology, ok :-D So the content of lal-1.0 and lal-1.0.orig should be almost the same. lal-1.0 should contain an additional debian directory
<fabrice_sp_> right
<MTecknology> fabrice_sp_: I also made a code change and added a man page to the new one
<fabrice_sp_> MTecknology, if it's a new application, you should use a patch system
<MTecknology> fabrice_sp_: oh...
<fabrice_sp_> and add the man into debian directory, and use <paxkaga>.manpages to install it
<fabrice_sp_> s/<paxkaga>/<package>/
<MTecknology> fabrice_sp_: oh, I had docs/lal.1 and debian/lal.manpages
<fabrice_sp_> MTecknology, did  you add docs/lal.1?
 * fabrice_sp_ keeps typing lala! :-)
<MTecknology> ya; it'll be in the next git version though
<fabrice_sp_> MTecknology, it's better to keep separate what comes from upstream, and what comes from packaging, so the manpage should go into the debian directory
<MTecknology> ok
<MTecknology> so next verion it'll move
<MTecknology> actually... I should maybe just wait until they finish the patches I requested from them... or just make the changes myself and submit a patch..
<fabrice_sp_> MTecknology, as you want. If you are adding a patch system, you could use source format 3.0, with quilt
<MTecknology> fabrice_sp_: that's entirely new territory for me :P - any guide for that?
<fabrice_sp_> http://wiki.debian.org/Projects/DebSrc3.0
<fabrice_sp_> MTecknology, it explains you the format, and how to convert an existing package to it
<MTecknology> thanks
<MTecknology> wow... there's a LOT to packaging
<bdrung> fabrice_sp_: we got an collision. ;)
<bdrung> (bug #512648)
<ubottu> Launchpad bug 512648 in cstocs "Please sync cstocs 1:3.42-2 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/512648
<fabrice_sp_> bdrung, oooppps
<fabrice_sp_> doble ack, then :-)
<bdrung> tested twice.
<bdrung> fabrice_sp_: btw, the build+ack script is nearly finished
<fabrice_sp_> with piuparts, in my case ;-)
<fabrice_sp_> I can send you the piuparts part also: it took me some time to have the right command line
<fabrice_sp_> (and hacked a bit the source, to get rid of the huge generated log)
<bdrung> fabrice_sp_: let me put it in a bzr branch
<fabrice_sp_> fabrice_sp_, ok
<fabrice_sp_> ?!
<fabrice_sp_> bdrung, ^ (I'm beginning to be tired: I speak to myself :-D )
<bdrung> haha
<bdrung> fabrice_sp_: here it is: https://code.launchpad.net/~ubuntu-dev/+junk/ack-sync
<fabrice_sp_> bdrung, nice!
<bdrung> fabrice_sp_: i added my default python parameter handling snipped after i forgot one parameter ;)
<fabrice_sp_> :-)
<geser> bdrung: I'm looking at the code: you sure line 54 is correct? "group = package[0-3]" shouldn't the - be a :?
<bdrung> geser: you are right - do you fix it?
<geser> bdrung: I leave it to you (busy with other things and don't want to start an other task)
<bdrung> fixed
<bdrung> and pushed
<fabrice_sp_> by the way, pbuilder build will build also -all packages in amd64? Or it requires a -A, like sbuild, to build them?
<blueyed> it will build all, fabrice_sp_
 * fabrice_sp_ is not using pbuilder anymore :-/
<sebner> shadeslayer: how did you fix it?
<fabrice_sp_> ok. thanks blueyed
<blueyed> fabrice_sp_: took me some time to get used to -A with sbuild.. ;)
<bdrung> fabrice_sp_: you could add an option for using sbuild (or and system environment variable)
<fabrice_sp_> bdrung, I was thinking about that (and also add piuparts support)
<bdrung> fabrice_sp_: that would be nice
<geser> by default pbuilder behaves like a "i386 buildd" (uses debian/rules binary), if you want to behave it like an "amd64 buildd" (debian/rules binary-arch) you need to specify an option (-B)
<geser> s/-B/--binary-arch/
<fabrice_sp_> that's different from sbuild, then
<shadeslayer> sebner: git archive HEAD | gzip > rekonq.tar.gz
<fabrice_sp_> I still remember telling people that I was missing -all packages, when I first switched to sbuild :-D It was my fault! :-/
<shadeslayer> sebner: also used a --prefix
<sebner> shadeslayer: k, thx for the info
<shadeslayer> sebner: #git is a pretty good place if you tell them youre fed up of git :P
<shadeslayer> same for #kubuntu #ubuntu etc
<sebner> shadeslayer: heh, I'm still happy with it
<shadeslayer> sebner: :)
<shadeslayer> sebner: well its just that people help half heartedly unless you use the magic words
<shadeslayer> the magic words being im fed up of so and so not working
<sebner> shadeslayer: heh, did you try the git community book already?
<fabrice_sp_> bdrung, are you using windows? ack-sync is full of ^M ;-)
<shadeslayer> sebner: yeah but its not that detailed...
<shadeslayer> missing some stuff here and there
<bdrung> fabrice_sp_: windows? what's that?
<fabrice_sp_> lol
<bdrung> fabrice_sp_: ^M?
<fabrice_sp_> yes
<bdrung> ^M = ?
 * fabrice_sp_ will try to pastebin
<fabrice_sp_> http://pastebin.ubuntu.com/363464/
<fabrice_sp_> this is how it appears in vi
<bdrung> fabrice_sp_: fixed
<bdrung> fabrice_sp_: that's maybe because i grabbed this file through pastebin
<fabrice_sp_> hmm, could be, yes
<MTecknology> fabrice_sp_: I just made the code changes and sent the patch to the author. He's going to apply it, create a new version, then I'll resume packaging :)
<fabrice_sp_> MTecknology, sound good :-)
<MTecknology> fabrice_sp_: this is hard stuff, but it's fun
<fabrice_sp_> we all began this way ;-) (in my case, it was because of dvdstyler :-) )
<MTecknology> How can I update a Makefile to handle a man page?
<cody-somerville> MTecknology, If you're packaging, you don't need to do that.
<cody-somerville> MTecknology, Theres a debhelper for that.
<cody-somerville> If you need to build the manfile from another format or something, you can just do that in your debian/rules instead of patching the Makefile.
<MTecknology> cody-somerville: thanks
<xteejx> bug 512890, I've been told to subscribe and assign Universe Sponsors, but that's what I did before the assignee was removed....
<ubottu> Launchpad bug 512890 in ubuntu "[lucid] emacs-chess-2.0b6 FTBFS i386" [Undecided,New] https://launchpad.net/bugs/512890
<MTecknology> So- is it a big deal ifI accidentally have too many build dependencies?
<ajmitch> xteejx: what he really meant was subscribe, not assign
<geser> no, the build just takes a little bit longer
<xteejx> ohhhh I see, thanks ajmitch, didn't realise :)
<MTecknology> ok, I think I might have one extra dep, but I know it's related
<MTecknology> now lintain
<xteejx> Is it Ok to go ahead and fix the FTBFS errors without getting shouted at? :P
<xteejx> Or at least try...
<MTecknology> Any ideas what I should be doing here? It's a new package but I do plan on getting it into debian and ubuntu - http://paste.ubuntu.com/363496/
<ajmitch> xteejx: it should be fine, any shouting should be done in a loving & caring way
<xteejx> ajmitch: Lol ;) But cool :)
<xteejx> MTecknology: It's a suggestion to create a debian/watch file
<MTecknology> xteejx: the packaging guide doesn't describe that at all
<xteejx> Its in the Debian Policy manual I think
<MTecknology> eh - I looked at the wrong wiki page :P
<xteejx> ;) hehe
<porthose> https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch
<xteejx>  I've given up on packaging for now... doing some "Failed to build" stuff :)
<zooko> How do I request that Ubuntu upgrade the version of a package?
<cody-somerville> zooko, file a bug against that package in launchpad
<statik> hey zooko, nice to see you
<ajmitch> zooko: it'll depend on the package, whether it was modified from debian or not
<ajmitch> or if you want a version not in debian
<statik> i want to use the new ubuntu distributed development tools for updating a package to a new upstream release. uscan gets me the new tarball, and i've got the lp:ubuntu/packagename branch already. do i need to do anything special to import the tarball to bzr?
<MTecknology> porthose: if tarballs aren't published at all.. then what should I do? I could import the project to launchpad and start importing the git source and use that for release tarballs
<zooko> Hello statik!
<MTecknology> porthose: This is a new package too- so I'm kinda fumbling around some
<RAOF> MTecknology: If there are no tarball releases then you create a debian/watch file with nothing but a comment explaining why you can't write a debian/watch file.
<MTecknology> RAOF: ok, thanks
<kjele> Hello
<kjele> Is it possible to pack a package without autoconf?
<MTecknology> RAOF: it's only available via git and a single tarball - no directory listing available. I could try to ask the author if they could offer that
<RAOF> MTecknology: If they're not cutting proper releases then there's not much point.
<MTecknology> RAOF: I meant ask them to offer releases like that, He's been happy for my help so far - maybe he'd be up for that too
<RAOF> If he wants to offer releases then your watch file can pick them up.
<MTecknology> RAOF: Just a directory on a web server that lists all tarballs in it would work?
<MTecknology> I guess. that would look like this then - http://people.canonical.com/~dholbach/motu/ :P
<MTecknology> I'm sure that he'll be up for that idea
<MTecknology> Then maybe I can package the rest of his software :P
<xteejx> Fixing FTBFS bugs are rather easy once you get started :)
<MTecknology> xteejx: FTBFS?
<MTecknology> I'm just waiting on the LP email..
<xteejx> Failed to build from source.... i.e. autobuilder problems
<MTecknology> oh
<MTecknology> accepted - now waiting for build
<MTecknology> xteejx: unless you're up for hosting on sourceforge..
<xteejx> MTecknology: hosting what?
<MTecknology> xteejx: wrong person - sorry
<xteejx> lol :)
<MTecknology> xteejx: I want to convince the author of this app to host the files so a watch file can keep track of it
<MTecknology> actually - does anybody want to review my package for correctness once it builds?
<xteejx> MTecknology: Well there several good reasons ... most important one being he'd have his package shared with the world, ~10 million people use Ubuntu
<xteejx> bug 512890 - how long does it take for someone to look at my debdiff? Is there a waiting process?
<ubottu> Launchpad bug 512890 in ubuntu "[lucid] emacs-chess-2.0b6 FTBFS i386" [Undecided,New] https://launchpad.net/bugs/512890
<MTecknology> xteejx: I think he'll go for it; the two options are 1) +Indexes on Apache for the directory or 2) host on something like sf.net
<xteejx> hmm... if I had an app I wanted to give away, I'd be doing it through sourceforge
<MTecknology> package built
<MTecknology> xteejx: two days of learning - and this is what I have to show for it - https://edge.launchpad.net/~mtecknology/+archive/ppa
<xteejx> MTecknology: Wow, a whole package?! What's it do?
<geser> xteejx: small improvents for your debdiff: don't forget to update the maintainer (update-maintainer does it for you) and don't forget to close your bug in the changelog entry (lp: #xxx)
<geser> and please also forward the patch to Debian (if you didn't already did it)
<MTecknology> xteejx: that sounded mean :(
<xteejx> MTecknology: Mean?? Not at all, I'm intrigued :)
<xteejx> Is it a new package?
<MTecknology> ya
<xteejx> Cool :D
<MTecknology> xteejx: In my defence, I also wrote some patches for the code and got them pushed upstream; and made a man page for it
<xteejx> MTecknology: Bloody hell, that's really good!!! :)
<MTecknology> thanks :)
<xteejx> geser: I've removed the packages, I assume it's safe to edit debdiff by hand?
<MTecknology> now I need to convince him to do the directory listing so the watch has a purpose; I also need to get this into Debian so Ubuntu will import it
<MTecknology> ugh
<MTecknology> Apparenlty the man page goes where it's supposed to - but the binary doesn't
<xteejx> :(
<MTecknology> xteejx: hurray, 'find / -name lal' came up with nothing
<MTecknology> well - this /usr/share/doc/lal
<geser> xteejx: if you know how to edit patches that they still work afterwards sure (else grab the source package and apply your current debdiff)
<xteejx> geser: How do I apply a debdiff, I've only ever created one?
<geser> apt-get source package; cd package; patch -p1 < debdiff
<MTecknology> geser: any chance you could grab that source and tell me what I did wrong?
<xteejx> geser: Great thanks :)
<xteejx> Also, why do I need to update the maintainer?
<xteejx> I mean it's a Debian sync package
<xteejx> geser: ^
<geser> it's not anymore when we touch it, so we need to update the maintainer and point to us
<xteejx> ohhhh I see...any changes we make reverts it to us? That's cool
<MTecknology> this sucks... I thought I hadit
<MTecknology> At least the man page went where it was supposed to
<xteejx> ^ hence the reason I tried something other than packaging :P
<geser> MTecknology: sure, url?
<MTecknology> geser: https://edge.launchpad.net/~mtecknology/+archive/ppa/+packages
<xteejx> geser: bug 513014 that one should be ok
<ubottu> Launchpad bug 513014 in ubuntu "[lucid] freecol_0.8.4+dsfg-2 fails to build from source FTBFS" [Undecided,New] https://launchpad.net/bugs/513014
<geser> xteejx: yes, just a very small issue: as updating the maintainer field is a common change (we must do it for every package we modify) we don't have to document it
<xteejx> oh hehe
<geser> and please file the bugs against the package and not ubuntu in general, it makes it easier for someone else to see if fix waiting for sponsoring (e.g. an other contributor or dev fixing FTBFS)
<xteejx> geser: I forgot to do that :) new debdiff uploaded though :)
<geser> MTecknology: your problem is the missing binary in the package?
<MTecknology> geser: ya
<MTecknology> geser: manual stuff works perfect; I'm working on adding a watch
<geser> simple: you only build it but don't install it (below the staging directory from where the package gets constructed)
<MTecknology> geser: I have no idea how to make it install it..
<geser> this is usually done by "make install" but your Makefile doesn't support this (which is no problem itself)
<geser> echo "lal usr/bin" > debian/lal.install
<MTecknology> it's that simple?
<geser> yes, man dh_install if you want to know more what happening
<MTecknology> /usr/bin or usr/bin ?
<geser> usr/bin (but doesn't really matter) as debian/$package/ gets prefixed
<MTecknology> thanks :) - I'm making a sf project for the watch right now
<geser> in the end it's a "cp lal debian/lal/usr/bin/" what this does
<MTecknology> geser: do I need only the tarball in the sf project, without the debian/ in it?
<geser> yes, the just the contents of the .orig.tar.gz
<MTecknology> geser: I suppose the watch file can't be tested until this is uploaded to debain, huh?
<geser> as I don't know who exactly uscan and debian/watch and sf.net work together, I can't answer this
<MTecknology> ok, I'll just trust that it'll work correctly
<geser> I heard that uscan can't "access" sf.net directly and needs some sort of "mirror/proxy" (don't know the details)
<MTecknology> that's probably why it complained; I pretty much copied the exact syntax of stalonetray for the watch which is on sf.net; it complained about debian.org
<MTecknology> I'll assume I did this part right.. :)
<MTecknology> geser: I'm uploading the new package hopefully this one builds correctly
<MTecknology> :D
#ubuntu-motu 2010-01-27
<geser> did you update it to -0ppa2? if not, it gets rejected
<cyphermox> MTecknology, geser, there is a special cgi proxy thing somewhere on debian.org that translates calls to sf.net.. it was broken for a while this summer
<MTecknology> geser: ya, I did
<OrgulloCachanill>   Forum welcomes anybody who hates niggers and isn't a nigger.      Asian?  No Problem!  Jewish?  We have Jewish mods!  Mexican?  Bienvenido amigo!  No matter what race you are, join us if you hate niggers!
<sebner> far too quick for an op :(
<MTecknology> hurray spam
<MTecknology> sebner: ya, but staff got them instead :P
<sebner> lol
<sebner> anyways
<sebner> far too late already .. gn8
<MTecknology> geser: is there any chance you could check over that package for errors?
<MTecknology> It builds fine, installs correctly now, and lintain sees no issues - just the way I did everything..
<MTecknology> So when I have something I want to push to Debian, what should the version number look like?
<MTecknology> in the changelog..
<persia> MTecknology: Is it maintained by Debian QA or someone else?
<MTecknology> persia: I'll probably be the one maintaining the package, somebody else manages the code
<persia> Oh, a new package.
<persia> Generally one uses a revision number of 1 for a new package, so something like 1.2.3-1
<MTecknology> ok, thanks :)
<MTecknology> I didn't know if I wanted anything like ubuntu0 at all
<persia> The reason I ask is that I believe it to be poor manners to attach changelog changes to a patch one is submitting to a Debian maintainer not oneself, except in certain special cases.
<MTecknology> does that get attached on import from there?
<persia> No.
<MTecknology> I like to think I have good manners - I want to do that :P
<MTecknology> I wonder if this is what I want for the watch... http://projects.l3ib.org/lal/files/ lal-(.*)\.tar\.gz debian debian/orig-tar.sh
<MTecknology> :P
<MTecknology> looks good     => remote site does not even have current version
<MTecknology> 1.1 will get released tomorrow, it'll just be a small Makefile change
<persia> Does the watch file work?  You can test with `uscan --report-status` and `uscan --force-download`
<MTecknology> persia: so when a new tarball gets published and it gets scanned, what happens?
<persia> Nothing, unless someone decides to update.
<persia> It might show up in UEHS and DEHS reports.
<MTecknology> where's that?
<persia> http://qa.ubuntuwire.org/uehs/ and http://dehs.alioth.debian.org/
<persia> (It's at times like these that search engines are handy)
<MTecknology> so once I get this latest version packaged; I upload it to debian.mentors.net; then something happens there; then it gets sync'ed into 10.04?
<hyperair> mentors.debian.net
<persia> Well, you'll want to contact the debian mentors to get it uploaded, but ideally.
<MTecknology> hyperair: ya, that one :P
<hyperair> you upload it to mentors.debian.net, you get the RFS template and mail it to the debian-mentors mailing list, you wait for a sponsor to get back to you, and once the sopnsor has uploaded, it'll get synced.
<MTecknology> cool :)
<hyperair> but unlike revu, it's actually very difficult to get a sponsor for new packages in debian-mentors.
<hyperair> you can wait for months on end
<persia> hyperair: You clearly haven't looked at REVU recently :)
<hyperair> persia: er. i guess not.
<persia> I think the latency is about the same: in both cases some stuff moves very quickly, and some stuff sits there for months.
<hyperair> persia: i haven't attempted to get anything into ubuntu via revu for a long while.
<MTecknology> via revu means it's in ubuntu only?
<hyperair> MTecknology: yes.
<hyperair> MTecknology: rather, ubuntu and its derivatives.
<ajmitch> both debian & ubuntu suffer from the problem of reviewing & sponsoring not being much fun :)
<MTecknology> I have something I want to pckage later that will be Ubuntu specific
<hyperair> MTecknology: submitting to debian would mean it'll get into debian and its derivatives, and since ubuntu is a debian derivative, that has a wider reach.
<hyperair> ajmitch: but stuff i've attempted to get into ubuntu via revu entered much faster than through mentors.debian.net
<ajmitch> hyperair: it depends on how persistent you are, and responsive with making requested changes
<persia> hyperair: Mostly that's a function of timing.  Sometimes REVU gets lots of attention.  Sometimes mentors.  When things are especially fast is when both sets of sponsors are competing, but that doesn't happen often.
<hyperair> ajmitch: i've been quite responsive with revu imo, but with mentors.debian.net, it's kinda hard to be responsive when you don't even get a reply to begin with.
<persia> Well, some things on REVU haven't been reviewed in months as well.
<MTecknology> I like to think I'm extremely responsive..
<persia> You may just be better at advertising your stuff on REVU.
<hyperair> perhaps.
<MTecknology> I'm reading the intro on m.d.n
<hyperair> codelite entered ubuntu in a few weeks.
<hyperair> it's been many months since then
<hyperair> and codelite is still sitting in mentors.debian.net
<hyperair> i just gave up trying to get it in
<cyphermox> hyperair, with an email on the ML too?
<hyperair> the only response i got was "isn't it just like code::blocks? we don't need another editor"
<hyperair> cyphermox: weekly mails, which is the maximum allowed frequency for RFS's
<cyphermox> wow.
<hyperair> it's easier to get stuff into debian if you can find a team with a DD, or otherwise find a DD who's interested.
<MTecknology> DD?
<hyperair> debian developer
<MTecknology> oh
<hyperair> people with upload privileges
<MTecknology> I want to be able to call myself an Ubuntu developer someday
<RAOF> Or there's an interested team; the cli-{apps,libs} team is responsive.
<persia> The same is true with Ubuntu.  Packages of interest to Ubuntu Developers tend to pass through REVU faster.
<hyperair> MTecknology: so would i. =)
<cyphermox> two fairly specialized packages I've uploaded through mentors finally, got almost immediate attention, compared to revu with few comments after weeks.
<cyphermox> getting the input from the two sides was very interesting and useful though
<hyperair> i guess the size of the package also matters. codelite is a behemoth.
<cyphermox> probably
<persia> Definitely.  It's much easier to review small stuff.
<hyperair> on top of that, upstream insists on including the windows specific files (especially the binaries) in the tarballs, so i have to get those repacked out.
<MTecknology> the actual code in this is about 300 lines
<cyphermox> persia, even small packages can get complicated :)
<hyperair> that's tiny.
<MTecknology> ya
<MTecknology> but dang this thing is awesome
<MTecknology> I figured it's the perfect point to learn
<persia> cyphermox: Yes, but they tend to take less time to download, less time to build, and less time to read.
<cyphermox> yup
<MTecknology> I learned .. a lot .. in the last two days
<MTecknology> Intro page - "Besides from not being able to upload the package directly into Debian you are treated as a full member of the community."
<MTecknology> heh.. most debian folke I know aren't friendly enough to call anyone but the few l33t part of their community
<persia> Then you're not looking in the right places.  Several Debian folk have previously contributed to this very conversation in the past hour.
<cyphermox> MTecknology, I think when it's apparent that you do a good job or that you are eager to learn, you're taken seriously
<MTecknology> persia: I meant when I popped into #debian
<cyphermox> E.g. my first emails with my regular sponsor seemed a little cold... which was really just a perceived thing on my end it seems, because he's been extremely nice and useful.
<MTecknology> I only have experience asking for support in the main channel
<MTecknology> persia: you're probably right..
<MTecknology> Thanks for all the help everyone - I appreciate it :)
<MTecknology> persia: are debian channels mostly on freenode or oftc?
<persia> OFTC
<persia> Although I find that Debian is largely mail-driven, rather than IRC-drvien.
<MTecknology> oh
<MTecknology> that could also be part of my experience..
<dholbach> good morning
<Omar87> dholbach: good morning. :-)
<dholbach> hi Omar87 :)
<stochastic> On an upgrade request bug what's the best way to attach a patch?  In the form of a debdiff from the previous version, or as a .dsc file for the new package?
<randomaction> stochastic: attach diff.gz and live a link to source tarball
<stochastic> okay, thanks
<hakaishi> Hello everyone! Anyone up to advocate/review qt-shutdown-p? - There are no lintian warnings or other errors. http://revu.ubuntuwire.com/p/qt-shutdown-p
<abogani> Hi All, Little questions: if the source of a don't-yet-packaged software don't contains automated build procedures (autotools, Makefile, ant etc etc) what I should do for packaging it in the right way? Thanks in advance!
<mok0> abogani: it really doesn't matter how you build the software.
<mok0> abogani: just compile it and install it in the debian/tmp tree
<abogani> mok0: Can I insert gcc command into debian/rules?
<abogani> directly?
<mok0> abogani: sure
<mok0> abogani: although it might be more maintainable to write a Makefile
<abogani> mok0: Ok. Thanks a lot! :-)
<mok0> np
<xteejx> How do I apply a debdiff to a downloaded source?
<xteejx> I've made a debdiff for emacs-chess FTBFS, but I removed the source and the things I changed, can I reapply the debdiff to redo what I deleted?
<mok0> xteejx: yes, that's how the sponsor would do it
<randomaction> xteejx: typically you go to source directory and "patch -p1 </PATH/TO/DEBDIFF"
<xteejx> No...how do I do it, I need to change a couple of other things
<xteejx> randomaction: Thanks. Will that make the changes I made in debian/ folder appear again, or do I need to unpack or anything?
<randomaction> to go to source directory, you need to unpack the package
<xteejx> apt-get source already did that
<xteejx> and I have my debdiff
<randomaction> good for you :)
<xteejx> So just the patch -p1 and that's it? That's handy :)
<mok0> yep
<randomaction> that's why people ask for debdiffs
<xteejx> I see now, it saves a lot of messing about :)
<mok0> old package + debdiff = new package
<xteejx> I suppose that's also the reason why we aren't supposed to mess around with the actual source code, only make patches, right?
<randomaction> no, reason for this is that you have a handy patches directory an can at any time review any changes you have made
<mok0> xteejx: exactly
<xteejx> I see, it all makes a lot more sense now.
<xteejx> Is the patch -p1 command meant to take any more than a few seconds?
<mok0> there's a bunch of tools that can analyze diffs as well. lsdiff is one of my favourites
<randomaction> xteejx: did you miss the "<" symbol?
<mok0> xteejx: you need to read from stdin
<xteejx> oops :P
<mok0> Unless you enjoy typing diffs :-)
<xteejx> read form stdin?
<mok0> xteejx: yes, with a redirect (<)
<xteejx> *from
<mok0> patch < file
<xteejx> I don't know what the techincal thing is for that, but yeah I missed the < ;)
<xteejx> I'll just call it greater than :P
<randomaction> xteejx: http://en.wikipedia.org/wiki/Redirection_%28computing%29
<mok0> xteejx: that a different context thoug
<mok0> h
<xteejx> I see
<xteejx> So it means "do this to that"
<mok0> xteejx: huh? It means "instead of reading from stdin, read from file"
<xteejx> Ok, I'm consued in the space of 2 minutes then, don't worry I'll pick it up eventually ;)
<mok0> xteejx: good
<mok0> because redirects and pipes are among the most amazing useful features ever invented
<hyperair> mok0: hear hear!
<mok0> hyperair!
<hyperair> mok0!
<mok0> :)
<hyperair> =P
<mok0>  cat  /etc/dictionaries-common/words |rev|sort|rev|less
<hyperair> mok0: why reverse it twice?
<mok0> hyperair: to regenerate the words... it's a rhyme dictionary
<hyperair> ah
<hyperair> i see
<hyperair> that's interesting.
<mok0> cool huh :-)
<mok0> Ooops gotta go, see you later
<hyperair> yeah cool
<angelabad> Hi, can anyone review pidgin-embeddedvideo? Embedded video is a GTK+ plugin for pidgin. http://revu.ubuntuwire.com/p/pidgin-embeddedvideo
<ScottL_> persia:  last night I ran "lintian -iIv" and "lintian --pedantic" against my zynjacku.source.changes file and only received "bad distritibtuion type"
<ScottL_> persia: which was expected as this is for lucid - thank you again for your help
<xteejx> https://launchpad.net/ubuntu/+source/zshdb/0.03+git20090920-1/+build/1341562 shows failed to build on i386 but I don't see any obvious errors in the build log...am I missing something?
<geser> "19 of 19 tests failed" but I can't tell you why
<xteejx> oh i see that
<geser> see also Debian bug #560665
<ubottu> Debian bug 560665 in src:zshdb "zshdb: FTBFS: tests failed" [Serious,Open] http://bugs.debian.org/560665
<xteejx> Hmm....
<xteejx> In the rules/debian it says $(MAKE) - my question is, where is $(MAKE) defined, or does it just go through the Makefile in that directory?
<xteejx> debian/rules even
<geser> $(MAKE) gets defined by make itself
<xteejx> so it's just the command 'make' alone
<geser> yes
<xteejx> Also, if there is a Makefile.am and Makefile.in which is the one that is read? Am I right in thinking the .am is used my automake to make Makefile.in ?
<xteejx> cool
<geser> yes, and configure usually turns Makefile.in into Makefile which gets used in the end
<xteejx> I see
<xteejx> i don't see any striaght Makefile... I suppose configure is called somewhere in the rules?
<xteejx> duh! I can see it, why am I asking : ./configure --prefix=/usr --with-zsh=/bin/zsh --disable-maintainer-mode --with-lispdir=/usr/share/emacs/site-lisp/zshdb
<xteejx> thx geser :)
<geser> re $(MAKE) see http://www.gnu.org/software/make/manual/make.html#MAKE-Variable
<xteejx> I get it... so $(MAKE) just calls make to make... lol instead of typing /usr/bin/make which could be wrong on other systems
<xteejx> I think the error is just after : /usr/bin/make  check-TESTS
<xteejx> How do I search the directory for files containing "TESTS"?
<xteejx> grep something
<kklimonda> how can I get bzr branch for debian package uploaded to sid?
<geser> lp:debian/sid/package
<kklimonda> how often is it updated?
<geser> I don't know and it also depends if the package import into the branch works (there are several packages where this fails)
<kklimonda> or a more direct question - why is the last transmission version 1.77 when 1.82 was uploaded few days ago? can I check it somewhere?
<kklimonda> or maybe it's a broken upload.. hmm..
<geser> http://package-import.ubuntu.com/transmission: AssertionError: Can't handle non gz tarballs yet
<kklimonda> ach, thanks
<kklimonda> it doesn't make any sense but I have a new link to play with :)
<kklimonda> ach, orig is in bz2
<jpds> kklimonda: Not according to https://edge.launchpad.net/ubuntu/+source/transmission/1.80~b5-0ubuntu1
<geser> jpds: but according to http://ftp.debian.org/debian/pool/main/t/transmission/transmission_1.82-1.dsc
<kklimonda> jpds, I guess debian maintainer have changed it recently to not repack original .tar.bz2 to .tar.gz
<sebner> debsrc3.0 ftw!
<ari-tczew> I'm learning to use bzr, I got a problem :-/
<kklimonda> I was hoping to play with the new bzr merges but it looks like I just should do that in the old fashion way :/
<geser> ari-tczew: what problem?
<geser> kklimonda: or pick an other package to merge :)
<ari-tczew> I used: bzr launchpad-login ari-tczew then I've asked about key, I give YES, then OK. Now I put: bzr branch lp:~ari-tczew/+junk/gambas2 and it fails
<geser> error?
<ari-tczew> bzr branch lp:~ari-tczew/+junk/gambas2
<ari-tczew> Permission denied (publickey).
<ari-tczew> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<geser> you use the same SSH key as listed on your LP page?
<ari-tczew> I don't know
<ari-tczew> if no, how can I sync key with LP?
<geser> just add it like you did with your first SSH key
<geser> use the link besides "SSH keys" on your LP page
<ari-tczew> I don't understand
<ari-tczew> _now_ what I have to change?
<ari-tczew> any thing on my pc? or any thing on LP?
<ari-tczew> fu*king keys...
<geser> have you an SSH key on the PC you try to push from?
<ari-tczew> yes, I created ssh key on my PC and succefly imported to LP
<geser> and it doesn't work? -> try #launchpad then
<ari-tczew> I lost inclination, another time
<kklimonda> hmm, could anyone check if mozilla-noscript from repository actually works with seamonkey in karmic?
<xteejx> Hey guys, I have 3 files, the orig.tar.gz, the -1ubuntu1.diff.gz and the .dsc... how do I extract the source from that, i.e. not the original, the Ubuntu-edited one, as it's in a PPA without any debdiff ??
<sistpoty|work> xteejx: dpkg-source -x *dsc
<xteejx> Cool thanks :)
<xteejx> Also, what is the correct Ubuntu version if the PPA version is 0.6.4-1~name1? Is it 0.6.4-1-0ubuntu1?
<ari-tczew> no
<ari-tczew> ppa is unofficial, personal repositories
<xteejx> Oh... :)
<hyperair> anyone from motu-release here? i'd like to request for clearance to get the new banshee into lucid during the featurefreeze (banshee upstream has now committed to a schedule and will release 1.6.0 on march 31st)
<sistpoty|work> hyperair: /me looks
<hyperair> sistpoty|work: http://banshee-project.org/about/calendar/
<hyperair> xteejx: you generally add stuff to the version number that your package is based on
<xteejx> hyperair: Well I was thinking about repacking some PPA stuff into debian policy standards, don't know if that's possible
<hyperair> xteejx: and don't add another "-", it's usage is strictly restricted to separating upstream from debian revisions
<xteejx> ohh i see
<hyperair> s/it's/its/
<sistpoty|work> hyperair: hm, that's (only) two weeks away from final freeze...
<sistpoty|work> hyperair: do you plan to track the release closely?
<hyperair> sistpoty|work: yes
 * sistpoty|work shrugs
<hyperair> sistpoty|work: as usual, banshee will get a bucketload of bugfixes per release -- generally an amount large enough that it's not practical to backport all
<hyperair> sistpoty|work: not to mention that the current banshee in ubuntu, 1.5.1 is labelled as "1.6.0 beta 2"
<sistpoty|work> hyperair: I think I'm generally in favor of it, but can you please also mail to ubuntu-motu@luc to reach other motu-release members as well?
<hyperair> sistpoty|work: okay, will do. thanks.
<sistpoty|work> oops, keyboard shortcut accident :)
<sistpoty|work> thanks hyperair
<hyperair> =)
<xteejx> Are there any guides on packaging python games for Ubuntu?
<randomaction> xteejx: today will be a UDW session on python application packaging
<xteejx> randomaction: Oh cool :) Is it on lernid?
<strycore> Hi
<xteejx> Hi
<randomaction> xteejx: don't know, check 20:00 UTC
<xteejx> yeah it's at 8PM. I'll try to be there, thanks randomaction :)
<strycore> I'm filling a bug against inkscape because it suggests ttf-bitstream-vera and this package was removed since Karmic , I'd like to find out why this package was removed
<strycore> it's still in debian
<randomaction> strycore: check https://launchpad.net/ubuntu/+source/ttf-bitstream-vera/+changelog
<acicula> where is the python packaging demo, in ubuntu-classroom?
<strycore> ok thanks
<strycore> that was useful , I'll replace the suggestion by ttf-dejavu instead of removing it
<xteejx> What happens with the copyright/licensing if the website states it is GPL licensed, but there are no obvious authors and no provided license files in the source? I mean, how is the debian/copyright written in that case?
<randomaction> acicula: yes
<strycore> debian/control: Replaced ttf-bitstream-vera suggestion with ttf-dejavu
<strycore> is that ok for a changelog entry ?
<acicula> randomaction: thnx
<bddebian> Heya gang
<sistpoty|work> hi bddebian
<directhe`> it's the ever-sexy bddebian!
<bddebian> Heh, heya sistpoty|work, directhe`
<randomaction> xteejx: you should beat upstream with a stick and tell them to include AUTHORS and COPYING files in the source
<xteejx> hmmm .... not a bad idea heheh
<xteejx> Hi bdebian :)
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 3 starting in #ubuntu-classroom (on irc.freenode.net) in 16 minutes
<randomaction> jdong: ping, looking for an SRU ack for bug 424249
<ubottu> Launchpad bug 424249 in gscan2pdf "locks when trying to save as PDF" [Undecided,Fix released] https://launchpad.net/bugs/424249
<jdong> randomaction: you're ACKed :)
<randomaction> jdong: thanks, uploading then
<zooko> statik: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567145
<ubottu> Debian bug 567145 in python-foolscap "please upgrade python-foolscap to v0.5.0" [Normal,Open]
<statik> zooko, thanks!
<jariq> How often are advocated packages from revu processed by archive admin ?
<geser> if a package on revu gets two "advocated" it should get uploaded by the 2nd dev advocating it to the archive where the archive admin process it (review it from the NEW queue)
<jariq> geser: is there any way I can check if it was uploaded ?
<randomaction> jariq: https://launchpad.net/ubuntu/lucid/+queue
<jariq> I cannot find package ipwatchd in queue at https://launchpad.net/ubuntu/lucid/+queue Does it mean it was not uploaded yet ?
<persia> jariq: Better to check https://launchpad.net/ubuntu/+source/ipwatchd if you're looking for a specific package.
<persia> jariq: You might want to check with iulian to see if it was uploaded, or if it waits on the requested minor modifications.
<jariq> persia: thx
<xteejx> Hey guys
<RAOF> Good morning.
<xteejx> A source is trying to install to /usr/local/bin/ I've tried adding DESTDIR=$(CURDIR)/debian just above the %: of my rules file (template from rules.tiny) what am I doing wrong?
<xteejx> Good evening RAOF ;)
<RAOF> You need to work out what part of the upstream buildsystem you need to fix - is there a Makefile that you call to install?  If you pass that Makefile DESTDIR=foo, does it install into foo?
<xteejx> rules http://paste.ubuntu.com/364139/ Makefile http://paste.ubuntu.com/364138/  .... I *think* it may be that I need to add --PREFIX=/usr/ or something...
<xteejx> and no, it doesn't
<xteejx> I'm very new to this as you probably know :)
<RAOF> Yeah :)
<RAOF> Ok, so what you want to do is to override their PREFIX variable.
<xteejx> to just /usr/ ?
<RAOF> You can do that by passing PREFIX=/usr to the make call.
<RAOF> Because you're using dh7 which is all kinds of awesome, you can do this by adding a override_dh_autobuild: target.  Like so:
<xteejx> I'm not sure how to do that :( Is it something like dh_install --PREFIX=/usr/
<RAOF> http://paste.ubuntu.com/364141/
<xteejx> So I don't need that DESTDIR bit then?
<RAOF> Sorry: that should be override_dh_auto_build and dh_auto_build.
<xteejx> Is there any space between the -- and PREFIX=/usr i.e. -- PREFIX or --PREFIX?
<RAOF> xteejx: Right.  That makefile doesn't use a DESTDIR variable, so whatever you set it to it won't make any difference.
<RAOF> Yes, there is a space - the â--â tells dh_auto_build that we've finished giving options to dh_auto_build, and the rest of the command line should be passed as arguments to the makefile.
<xteejx> Ohhh I see :)
<xteejx> It acts as a kind of separator
<RAOF> So, that's telling dh_auto_build to pass PREFIX=/usr (acually, we want PREFIX=$(CURDIR)/debian/tmp).
<RAOF> Exactly.  It's a separator to tell dh_auto_build that we've finished passing arguments to *it*.
<xteejx> I see :)
<xteejx> Does it matter that it wants to do it directly to /usr/bin or /usr/share  or should it be building in a temporary directory?
<xteejx> Its not building with debuild -us -uc
<geser> be careful with setting PREFIX to something other than /usr/ for this package
<geser> as CFLAGS include a define that uses PREFIX (via SHAREDIR) it might get included into the binary (needs checking) so the final binary looks for its files in the wrong place
<RAOF> If PREFIX gets encoded into any part of the binaries, then yeah.   That's certanily something to look for.
<xteejx> Well, it's not building because it wants root access, I guess I want to do it in a temporary directory and then copy it to /usr/whatever at the end
<RAOF> It looks like you'll need to patch that makefile, actually.
<xteejx> I did think I may need to rewrite it :(
<RAOF> No, not rewrite it.
<RAOF> It'll be pretty easy.
<xteejx> It installs fine btw
<xteejx> I meant rewrite it in a patch :)
<xteejx> Well I'm guessing the two things I would need to do would be fix that PREFIX bit and the install: section to copy it to root / when built - correct me if I'm wrong
<RAOF> http://paste.ubuntu.com/364148/ would make âmake installâ it respect DESTDIR.
<xteejx> The install: section? I see
<RAOF> xteejx: You need to ensure that the code has the right DATADIR - somewhere in the code it will (presumably) be referencing that define, so that will need to be set to where it'll end up on the user's system.
<RAOF> You also need to, during the build process, install the stuff into a subdir of debian/
<xteejx> I'm confused... this change allows the rules file to make the Makefile install to *current directory*/debian right?
<geser> yes
<RAOF> Yes.  With that Makefile, you'd pass âdh_auto_install -- PREFIX=/usr DESTDIR=$(CURDIR)/debian/tmpâ.
<xteejx> I thought I couldn't change the source files? Or is that the idea of the patch?
<RAOF> That's the idea of the patch.
<xteejx> cool
<RAOF> We quite often need to touch the source; we use patches to do that so that (among other reasons) it's obvious what's from upstream and what changes we've made.
<xteejx> What happens then after it's built? Will it copy itself to / to install itself?
<RAOF> I think you'll need to clarify what you mean by âitâ in that sentence.
<RAOF> You want upstream's build system to install to debian/$SOMEDIRECTORY (where $SOMEDIRECTORY can quite happily be tmp), while at the same time knowing that it will end up in /usr.
<xteejx> the result of the install: section ... I assume this builds the executables to run to play the game, so .... actually hang on.... I need a bigger patch don't I because game executables get installed in /usr/games and the media in /usr/share/games/foo/ right?
<RAOF> Then in the process of building the binary deb those files will be copied into the deb; when the deb is unpacked, they all end up in the dpkg root prefix (which is only ever /, really; it passing other roots to dpkg doesn't really work)
<MTecknology> I thought I had this working perfect - but now it's not.. any ideas why I'm getting this error? http://paste.ubuntu.com/364155/
<xteejx> RAOF: Ohhhhhhhhhhhhhhhhhhhhh I see now!!
<xteejx> RAOF: Because of gdebi or synaptic or whatever that installs it as root, it'll go in / ahhhhhh :)
<RAOF> MTecknology: Your upstream's âmake installâ is trying to install the man page in /usr/local; that isn't going to work.
<xteejx> Didn't realise there was a man page
<MTecknology> RAOF: oh... what should I do?
<xteejx> oops
<RAOF> MTecknology: That'll depend on your upsream's build system.  Scrollback where xteejx & I are discussing almost exactly this problem might be helpful :)
<xteejx> MTecknology: Hey again :)
<MTecknology> xteejx: hi
<xteejx> More problems?
<geser> MTecknology: packages get installed into a staging dir (debian/packagename) from where the deb gets build. And dpkg installs them later relative to / so the paths are correct after installation
<geser> this also means you can't (and shouldn't) install outside the package directory (you want to install the file into the package and not into the host system (buildd))
<MTecknology> This is the Makefile - http://paste.ubuntu.com/364158/
<RAOF> :)
<MTecknology> RAOF: exact same thing?
<xteejx> RAOF: If I edit the Makefile to how I want it (as a draft example) can I paste it to have a look at please?
<geser> first make install respect $(DESTDIR) and make the installation prefix configurable (packages shouldn't install in /usr/local, that's directory is reserved for the local admin)
<RAOF> xteejx: Certainly.
<xteejx> Thanks guys
<RAOF> xteejx: Where by âpasteâ, you mean âpastebinâ :)
<xteejx> Of course ;)
<MTecknology> geser: so I need to correct the Makefile install section?
<geser> yes
<MTecknology> sounds like fun
<MTecknology> Is there any idiots guide to make files?
<RAOF> The GNU documentation is quite readable.
<RAOF> http://www.gnu.org/software/make/manual/make.html
<xteejx> Think I got it
<xteejx> rules: http://paste.ubuntu.com/364164/ Makefile (to be patched like this): http://paste.ubuntu.com/364165/
<xteejx> actually I think it should change to SHAREDIR=$(PREFIX)/share/doc/XorCurses
<xteejx> as well
<geser> what's inside this dir? if it needed during runtime it shouldn't be inside /usr/share/doc
<xteejx> the maps for the game and documentation, but I thought docs had to be split
<xteejx> SHAREDIR=$(PREFIX)share/XorCurses/  but MAPDIR=$(SHAREDIR)maps   PREFIX=/usr/
<xteejx> but then again... under install: install -t $(SHAREDIR) help*.txt
<geser> are the help files needed during the game? e.g. for an in-game help system
<xteejx> I'm not sure I'll check
<xteejx> No they're not
<geser> then either patch the Makefile to support the installation of the documentation to an other directory or don't install them with the Makefile but use dh_installdocs for it
<xteejx> I think I got it :)
<geser> "Packages must not require the existence of any files in /usr/share/doc/ in order to function" (from Debian Policy)
<geser> (the admin is allowed to removed /usr/share/doc)
<geser> so you can't install the map files there
<xteejx> geser: So any txt files that were called within the game would need to be with the game itself?
<xteejx> the maps go in /usr/share/xorcurses/maps/
<geser> yes, those help files should go to /usr/share/package/
<geser> http://www.debian.org/doc/debian-policy/ch-docs.html#s12.3
<xteejx> Ok I think I got it now :) How do I make a patch to patch the Makefile?
<geser> like any other patch, the Makefile is not special
<xteejx> I don't know how to do that
<geser> do you use a patch system?
<MTecknology> RAOF_: thanks for thaat link
<xteejx> I haven't told control to use one, no.
<geser> do you want to use a patch system?
<xteejx> If it makes it easier to fix the Makefile, yes
<geser> the "easiest" way is to use no patch system and simply edit the files (all changes will appear in the .diff.gz)
<geser> the downside is that with many changes you don't know anymore what changes belong together
<MTecknology> xteejx: In my case I can make about any patch I want and the maintainer will apply it :)
<xteejx> Ok I understand, I'd rather go with a patch system then
<xteejx> :)
<MTecknology> time to get my hair cut :)
<randomaction> best patch system is debsrc3 :)
<xteejx> What's the easiest one for a beginner?
<xteejx> I only need to patch 1 file, I've seen one with a 00 list thing that looked ok
<angelabad> Hi, can anyone review pidgin-embeddedvideo? Embedded video is a GTK+ plugin for pidgin. http://revu.ubuntuwire.com/p/pidgin-embeddedvideo
<micahg> xteejx: quilt is pretty easy
<xteejx> I'll look into it thanks micahg :)
<xteejx> I'm now getting this error: "install: cannot create regular file `/home/teej/build/xorcurses-0.1.2/debian/xorcurses/usr/bin/games': No such file or directory"
<xteejx> Can I tell the Makefile to mkdir $CURRENT/debian/xorcurses/usr/bin/games ?
 * ajmitch was about to answer that question, too...
<Nahsei> hei guys
<Nahsei> I'm having some problems here
<Nahsei> (nobody says anything... I will assume someone is waiting for me to say something more...)
<Nahsei> I've tried to follow this recipe   https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
<Nahsei> I was able to create the diff... but then when i tried to patch a new source code i had this error:
<Nahsei> Hunk #1 FAILED at 2.
<Nahsei> 1 out of 1 hunk FAILED -- saving rejects to file debian/control.rej
<Nahsei> patching file debian/changelog
<Nahsei> Hunk #1 FAILED at 1.
<Nahsei> 1 out of 1 hunk FAILED -- saving rejects to file debian/changelog.rej
<Nahsei> can someone help me please?
<geser> that's because the context for the patch changed, so patch can't apply it anymore
<geser> you need to apply this changes by hand (look at the .rej files what couldn't be applied)
<Nahsei> what do you mean by context? what changed, besides the working directory?
<geser> the constant lines around the changed ones for a chunk of the patch
<geser> patch uses 3 lines at the beginning and 3 lines at the end to determine the place where to do the changes
<geser> if those lines changes between the versions, patch won't find where the patch should get applied
<Nahsei> hmmm.... I see
<Nahsei> so... what is the solution for this?
<geser> apply the changes manually (you are smarter than patch :) so you figure the correct place for the changes)
<Nahsei> yes... of course... but then there wouldn't be a meaning for doing patches right?... I would like to do it automaticaly
<geser> if the files you try to patch don't change between new version (or in parts you don't touch) then you can use a patch for several versions
<Nahsei> ok
<Nahsei> from the begining..... I tried to patch and I got that error... what should I do?
<geser> open debian/changelog, look into changelog.rej what couldn't get applied (probably the new changelog entry as the version who got patched isn't the topmost one anymore) and apply the changes (put the Ubuntu changelog entry into the correct position)
<Nahsei> ok... i'll try that. thanks
<Nahsei> well ... in the top of changelog there is a version 2-3   and in the bottom of changelog.rej the version is 2-2... maybe that's why
<Nahsei> patch could not see the correct line, saying that the version was 2-2 ... it saw 2-3 and rejected the modification
<Nahsei> is this correct?
<geser> yes
<Nahsei> ok :) now i understand thanks
<Nahsei> but then the tutorial is not up to date... or was made this way, on purpose, for people to understand better what is behind patching...
<Nahsei> anyway... I know now.. that's what matters
<Nahsei> :)
#ubuntu-motu 2010-01-28
<rmunn> Aspiring MOTU / new packager here with a question about licensing: I'm trying to package the NLTK library for Python (http://www.nltk.org/), and the upstream tarball has a minor licensing issue. It's licensed Apache-2.0, and the upstream tarball also distributes a yaml library that I identifyed as pyyaml (http://pyyaml.org/). Pyyaml is MIT-licensed, but the NLTK tarball doesn't include a copy of the MIT license, nor any attrib
<rmunn> ution for pyyaml. I plan to create an NLTK package that doesn't install pyyaml (and instead simply Depends: on python-yaml), but what's the best way to remove the yaml/ directory from the upstream tarball? Modify the tarball and create a dfsg.tar.gz, or remove it in the .diff.gz?
<rmunn> If I modify the upstream tarball, it makes it harder for people to verify that I made no changes to upstream -- but if I don't, then under one reading of the MIT license (which says "you must include this license will any redistributions"), redistributing the upstream's tarball would not be legal.
<ajmitch> removing it, creating a new upstream version with +dfsg in the name, note what you did in debian/README.source
<rmunn> Best solution is, of course, to get upstream to fix it and release a new tarball with the PyYaml code's license properly included -- but that might not happen before the Lucid freeze.
<dhillon-v10> hi all, I just finished doing a merge, and here's the diff: http://pastebin.com/d7ccd7ad0 I do know I am supposed to remove the .po stuff and the patch applies cleanly too :) so can any one just have another look at it
<Burzmali> Hello everyone.  Anyone available to give me some advice about how to set up a group of packages?
<rhpot1991> persia: I'm told you are a good person to ping about a library soname question
 * vorian has heard he's a good person to ping about a lot of things
<RAOF> Even better is to ping the whole channel!
<RAOF> And by ping the whole channel, I mean: ask your question.
<RAOF> Because persia, awesome as he is, sadly isn't active in here 24/7 :)
<vorian> but please, do not /ping #ubuntu-motu :P
<rhpot1991> well I'm working with some upstream code and they do not have any soname data associated with their library
<rhpot1991> I am trying to work with them to fix the issue, they aren't really sure how to handle the numbering procedure as their version numbers are nothing more than a date (yyyymmdd)
<RAOF> Do they expect other people to be able to use their library?
<rhpot1991> so for soname data should it be, 0.yyyymmdd, yyyy.mm.dd, or just yyyymmdd?
<RAOF> Neither.
<rhpot1991> RAOF: its pretty much specific to their source
<rhpot1991> RAOF: not sure if code example would help at all here
<RAOF> Then you don't need to care about the soname; if other people shouldn't link against it, don't put it into the public link space.
<rhpot1991> RAOF: then its safe to ignore the lintian warnings about soname data?
<RAOF> As long as the library isn't installed into /usr/lib (or other public library path)
<rhpot1991> RAOF: that is where it gets installed to
<rhpot1991>  /usr/lib/libhdhomerun specifically
<RAOF> If the library is private to this application it shouldn't go there.
<rhpot1991> RAOF: ok well lets see here, I have 2 packages from the same upstream
<rhpot1991> http://www.silicondust.com/downloads/linux
<rhpot1991> so there is a lib source and a gui source
<rhpot1991> pastebining my controls
<rhpot1991> http://mythbuntu.pastebin.com/d2010eaf8
<RAOF> Hm.
<RAOF> Well, http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html might be helpful for you.
<rhpot1991> RAOF: reading now, thanks
<RAOF> As long as upstream make an effort to not break ABI, it looks like you want to make that a regular library package.
<rhpot1991> RAOF: what do you mean by regular library package?
<RAOF> I mean, packaged as per that library packaging guide.
<rhpot1991> RAOF: my view coming in was that my work as a packager was done and I just needed upstream to get some soname data into the library
<rhpot1991> trying to understand what that entails so I can help them with that
<RAOF> What that entails is ensuring that they keep the ABI as stable as possible.
<RAOF> The libpkg-guide has a nice description of that.
<rhpot1991> RAOF: ok reading on then
<RAOF> Particularly: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi
<rhpot1991> RAOF: so is it normally to start at 0 and them bump from there?
<RAOF> Yes.
<rhpot1991> RAOF: so then the package name should always match the soname, example libhdhomerun1 when the soname is 1
<RAOF> rhpot1991: Correct.
<rhpot1991> RAOF: I'm pretty sure this library falls into this situation: "Refer to libssl and other packages which used to handle it. They basically had SONAME version numbers which matched the package version, and every version: e.g. 0.9.4 and 0.9.6 had incompatibility. The solution was to create a SONAME containing 0.9.6, so that : "
<rhpot1991> they release a new library with every release
<RAOF> Yeah, but does that new library break existing users.
<RAOF> We've had a *lot* of libc releases since the SONAME bump to 6, including switching to a different source tree.
<RAOF> The SONAME hasn't been bumped, because they've been binary compatible.
<rhpot1991> RAOF: so where does a private library get installed to?
<rhpot1991> via dpkg of course
<RAOF> rhpot1991: Generally into a subdirectory of /usr/lib.
<rhpot1991> RAOF: thanks, you wouldn't happen to have any documentation about how a library gets soname data in the first place would you?
<rhpot1991> google isn't helping me find what I'm looking for
<RAOF> rhpot1991: I'm fairly sure that's in the libpkg-guide I linked you.  The answer is generally âfrom libtoolâ
<rhpot1991> RAOF: thanks, I need to learn to read better :)
<RAOF> rhpot1991: It's a big guide; library packging is much more complex than application packaging because it affects packages outside of itself.
<rhpot1991> RAOF: yes, it is quite complex
<superm1> anyone have any good documentation they can link me to on v3 source format?
<superm1> my google-foo is apparently failing
<jmarsden> superm1: man dpkg-source
<jmarsden> In Debian sid...
<Hobbsee> superm1: i think you want http://wiki.debian.org/Projects/DebSrc3.0
<superm1> yes Hobbsee that's what i'm looking for.  jmarsden the man page didn't talk much about converting packages to v3, just about some nice things in it from what i saw
<superm1> thanks Hobbsee
<Hobbsee> you're welcome
<jmarsden> superm1: It defines what the format is, which is what I thought you were looking for... the web page dances around what v3 format really *is*, IMO.
<hyperair> what are those little flame icons at the top right of a bug report?
<hyperair> Bug #XXXXXX reported by ____  on yyyy-mm-dd, <flame icons>
<ajmitch> bug heat
<micahg> What do I have to check when bumping the standards version on a package?
<jmarsden> micahg: That it really does meet the newer standards version.  See /usr/share/doc/debian-policy/upgrading-checklist.txt.gz
<micahg> thanks jmarsden, I didn't know that existed :)
<jmarsden> You're welcome.
<dholbach> good morning
<shadeslayer_> dholbach: morning
<dholbach> hi shadeslayer_
<iulian> Good morning dholbach!
<dholbach> heya iulian!
<xaka> anybody knows where i can find the history for the latest training Python Applications Packaging? (it was yeasterday)
<shadeslayer_> !logs | xaka
<ubottu> xaka: Official channel logs can be found at http://irclogs.ubuntu.com/ - For LoCo channels, http://logs.ubuntu-eu.org/freenode/
<xaka> shadeslayer_: great! big thx!
<xteejx> Morning all!
<geser> xteejx: Hi, the answer to your last question yesterday: debian/package.dirs (man dh_installdirs)
<xteejx> geser: I havent' looked at the packaging stuff today, will do in a bit, but can't remember what the question was now
<geser> xteejx | Can I tell the Makefile to mkdir $CURRENT/debian/xorcurses/usr/bin/games ?
<xteejx> so create a file with those directories listed name it debian/package.dirs ? That's cool
<geser> yes, just put "usr/bin/games" into debian/xorcurses.dirs and dh_installdirs will create it for you
<xteejx> Cool :)
<xteejx> Thanks
<randomaction> it's probably a bad idea as /usr/bin should have no subdirs, games should be installed to /usr/games
<geser> right
 * geser blames it on the auto correction in his brain
<xteejx> It's ok I know game executables go in /usr/games/bin :)
<xteejx> I wrote it all down
<xteejx> What is the correct way to create a package.dirs file so that dh_installdirs can create the needed directories?
<hakaishi> Hi everyone! Anyone up to review qt-shutdown-p? I think everything is fixed; no lintian waringins or other warnings. http://revu.ubuntuwire.com/p/qt-shutdown-p
<hakaishi> * no lintian warnings or errors.
<jcfp> hakaishi: why install the standard gpl text via debian/docs?
<freeflying> http://revu.ubuntuwire.com/p/ailurus
<shadeslayer> hmm. any ideas why this failed : http://launchpadlibrarian.net/38489013/buildlog_ubuntu-lucid-i386.kopete-facebook_0.1.5-0ubuntu1%2Blucid1~ppa3_FAILEDTOBUILD.txt.gz
<Laney> jcfp: what's up with sab? :'( :'(
<jcfp> Laney: on lucid you mean?
<Laney> yeah
<Laney> aptitude wants to rip it out
<jcfp> 1) python-cheetah is broken
<jcfp> 2) someone broke the sab package a few days ago
<directhex> bloody python
<shadeslayer> hehe...
 * shadeslayer hates it when he gets a FTBFS
<jcfp> bug #511547 and bug #512079
<ubottu> Launchpad bug 511547 in cheetah "module Cheetah not available in python2.5 on lucid" [Undecided,New] https://launchpad.net/bugs/511547
<ubottu> Launchpad bug 512079 in sabnzbdplus "sabnzbdplus depends on elementtree and celementtree " [Undecided,Fix released] https://launchpad.net/bugs/512079
 * Laney spanks porthose
<jcfp> on the positive side, 0.5.0 is almost out and via my ppa things do work, of course :)
<Laney> so you have fixes?
<jcfp> nope, a newer version that works with python2.6 so it isn't hit by the cheetah bug
<jcfp> but that's still rc status for now
<jcfp> Laney: and that in turn needs a newer python-cherrypy3 before it could go into an official repo
<Laney> all good fun
<shadeslayer> um anyone aware of the fact that libqt4-dev no longer depends on pkg-config and needs to be added as a build dep?
<jcfp> Laney: not really, work is claiming enough of my time to make cleaning up someone else's mess a very unwelcome addition to my schedule
<dupondje> https://bugs.launchpad.net/ubuntu/+source/gnome-do/+bug/513802 => would be cool if sponsored :)
<ubottu> Ubuntu bug 513802 in gnome-do "Please sync gnome-do 0.8.3.1+dfsg-1 from debian sid" [Undecided,New]
<bddebian> Heya gang
<directhex> bddebian! your nation needs you!
<bddebian> To stop Obama? :)
<directhex> bddebian, to help get a transition done, by prioritizing gsf-sharp which is in NEW
<directhex> so we can sync it. for great justice
<bddebian> directhex: I'll see what I can do. :)
 * Laney feeds bddebian cookies
<directhex> thanks :)
<rmunn> Question about redistribution requirements from a new packager / aspiring MOTU: I have an upstream package (from http://www.nltk.org/) I'm trying to Ubuntuize. It contains MIT-licensed code (from http://pyyaml.org/) but no copy of the MIT license (which is a violation of the MIT license terms that require a copy of the license to be redistributed along with the code).
<rmunn> Does this mean the .orig.tar.gz would not be legal to redistribute, and therefore I'd have to modify the original tarball?
<rmunn> Or could I put a copy of the MIT license into the .diff.gz and be in compliance that way?
<rmunn> I've notified upstream of the license compliance problems and expect they will fix it, but I don't know if their fix will come in time for the Lucid freeze or not, so I might have to package the current version and solve the licensing issue myself.
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 4 starting in 15 minutes in #ubuntu-classroom (first: Adopt-An-Upstream)
<abogani> Hi All, What is the right way to try to package a software when it isn't available a source package but only the SVN tree and this tree contains a lot of all types of unwanted stuff (binary stuff, driver for other OS, etc etc)?
<abogani> RTFM is welcomed.
<daurnimator> RTFM then?
<daurnimator> :P
<shadeslayer> abogani: you archive it,well git has git archive,dunno about svn
<shadeslayer> abogani: apparently it doesnt
<statik> abogani, do you have a good relationship with the upstream developers? are they open to making it easier for you or do you need to package it without any cooperation from them?
<abogani> statik: Are cooperative.
<statik> abogani: the smoothest thing is when you can convince upstream to start making some tarball releases that have good contents. if you can't do that, there are some other tools which can generate tarballs but it's a lot more work to manage
<statik> one is bzr-builddeb
<abogani> statik: Ok I'll try this way.
<abogani> statik, shadeslayer: Thanks!
<shadeslayer> isnt there *any* svn archiving tool?
<shadeslayer> if not,then svn is truly outdated :)
<_stink_> i'm playing around with packaging.  since i need to give pbuilder a .dsc file, it seems like i need to do debuild *first* always to generate the .dsc file, then do pbuilder.  is there a way to cut out the debuild step?
<slytherin> _stink_: nope
<_stink_> okee :)
<slytherin> _stink_: debuild generates a source package. Then you ask pbuilder to build a binary package from that source package.
<_stink_> gotcha.  and i guess the signing takes place in debuild, too.  i think.
<_stink_> thanks.
<slytherin> yes
<cyphermox> slytherin, _stink_, i recall there is pdebuild. I just tried it and it created the source package (it seems) and tried to proceed to run pbuilder to build the binary but failed... it would be cool to make sure it does work properly throughout ;)
<slytherin> cyphermox: never used pdebuild
<hakaishi> Hi everyone! Anyone up to advocate/review qt-shutdown-p? - I corrected the desktop file, the copyright file and the docs file as jcfp asked. http://revu.ubuntuwire.com/p/qt-shutdown-p
<dupondje> https://bugs.launchpad.net/ubuntu/+source/gnome-do/+bug/513802 => can somebody check to sponsor ?
<ubottu> Ubuntu bug 513802 in gnome-do "Please sync gnome-do 0.8.3.1+dfsg-1 from debian sid" [Undecided,New]
<slytherin> dupondje: why sid?
<dupondje> slytherin: only sid contains 0.8.3.1
<slytherin> dupondje: Is it likely not to enter squeeze soon?
<dupondje> testing version is already in ubuntu, but contains some bugs fixed in 0.8.3.1
<dupondje> it will get into squeeze prolly, but just don't want to miss it .. as it contains really needed fixes
<slytherin> dupondje: The Debian packages get auto synced till DIF date provided there is no Ubuntu specific changes to the package.
<slytherin> dupondje: gnome-do is just three days away from entering squeeze. http://packages.qa.debian.org/g/gnome-do.html
<om26er> For being a MOTU one must be a developer? even for updating packages?
<slytherin> DIF is set on 11th February. So the bug was not really needed.
<slytherin> om26er: It depends on what you mean by developer?
<om26er> slytherin, patcher/code writer
<slytherin> om26er: Most of the packaging work require that you have basic understanding of patches/code writing. Hence people only get involved with packages they actually use.
<slytherin> om26er: The basic packaging itself requires knowledge of make (at least).
<om26er> slytherin, if I dont know any programming but still I can compile sources can I become a MOTU
<maco> yep
<maco> packaging is all you need to know
<maco> well and policy
<dupondje> slytherin: it will automaticly getting added to squeeze after 3 days ?
<slytherin> om26er: yes you can in theory. How well it works in practice I can not say.
<slytherin> dupondje: yes and soon after that to lucid.
<dupondje> okay, so it will be in lucid in ~5 days ?
<slytherin> yes
<om26er> where should I start
<om26er> any documents?
<slytherin> om26er: check the links in channel topic
<shadeslayer_> om26er: i dont know any programming and yet i compile stuff and just learnt to package
<om26er> shadeslayer_, so you are the right person to ask where to start
<cyphermox> om26er, you might be interested in following the sessions in #ubuntu-classroom as well, since it's DeveloperWeek
<cyphermox> nevermind that, I see you're already there ;)
<nyu> hi
<nyu> how do I go about requesting that a package is imported from debian sid?
<Laney> nyu:  you can use the requestsync tool in ubuntu-dev-tools
<nyu> Laney: is there no other way?  I don't have an ubuntu system handy
<nyu> (I'm the debian maintainer for that package)
<Laney> nyu: it's in debian :)
<nyu> oh
<Laney> (or you can just file a bug on the package in Launchpad)
<nyu> got it, thanks
<Laney> but requestsync will grab the changelog entries and such for you
<MTecknology> I want to submit this package to Debian so it reaches a wider audience but I'm starting to think it's not worth the hassle and I should just get it into Ubuntu
<Laney> what hassle?
<blairzajac>    g
<blairzajac> oops, mistype
<MTecknology> Laney: so for I've submitted the ITP twice but never heard back
<MTecknology> Laney: You see anything wrong with this? http://paste.ubuntu.com/364730/
<MTecknology> except the extra ) in line 12
<Laney> MTecknology: an ITP isn't something you hear back from
<Laney> it's just a bug that says 'i am packaging this'
<MTecknology> Laney: You're supposed to..
<Laney> no
<MTecknology> Laney: that's what I was told in #debian-mentors
<Laney> you need to ask someone to sponsor your package
<Laney> just like you do in ubuntu
<MTecknology> Laney: Even if it doesn't; it's still supposed to show up here - http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=wnpp;dist=unstable
<Laney> then your reportbug is broken
<MTecknology> Laney: aptitude install reportbug
<Laney> you should try setting the smtp host
<Laney> (and blaming your own setup before writing debian off)
<MTecknology> Laney: you're being pretty rude
<MTecknology> Laney: http://paste.ubuntu.com/364733/
<Laney> well if your bugs aren't showing up then there is something wrong with the way you are reporting them, yes?
<Laney> you probably want smtphost not mta :)
<nyu> E: The package 'mingw-w64' does not exist in the Debian primary archive in 'sid'
<nyu> uhm damn
<nyu> I guess it won't import from incoming? ;-P
<Laney> nyu: usually have to wait for dinstall + archive push + all that fun stuff
<MTecknology> Laney: I'm trying that out now.
<nyu> okay then
<nyu> thanks for your help
<Laney> no worries
<MTecknology> Laney: there way go - you do get an email response.. - thanks for that s/mta/smtphost/
<hyperair> banshee builds on intrepid!!
<hyperair> oops wrong channel
<dooooomi> are ubuntu packages required to contain manpages for command line apps? i think i remember reading something like that about debian...
<randomaction> dooooomi: this is a near-requirement for new packages
<randomaction> and absence of manpage counts as a bug for existing ones
<dooooomi> randomaction: thanks, i guess i'll need to write one then...
<randomaction> help2man is a useful tool
<dooooomi> randomaction: great, that will makes things a lot easier!
<knipknap> i am trying to build a ubuntu package that shows no errors in "revu". when I add a debian/watch file, lintian reports "debian-watch-file-in-native-package"; when I don't, revu reports an error. which one is correct?
<randomaction> add watch file and make package non-native :)
<knipknap> how would i make it non-native?
<randomaction> you need an upstream tarball for that
<directhex> knipknap, a "native package" is one where ubuntu is the upstream, i.e. where there's no "orig" tarball downloaded from anywhere
<randomaction> named PACKAGE_UPSTREAMVERSION.orig.tar.gz
<knipknap> ok; i am actually trying to integrate the debian directory directly into the upstream makefile; there is no tarball at the time at which the debian package is created - does this mean that a tarball is absolutely required anyway?
<randomaction> native format is usually used for Ubuntu infrastructural packages
<randomaction> from https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews: "Package should not be native without an approved spec"
<randomaction> how can you have a watch file without tarballs anyway?
<knipknap> the watch file points to already published releases. but the release that is currently being built doesn't exist there at the time when the debian package is prepared. in other words, the package is built before the source package is officially released.
<knipknap> i guess i'll have to change the release workflow for this to work
<randomaction> you don't need to, it's a common situation
<randomaction> you can check out versions from your VCS and turn them into tarballs
<randomaction> if, for example, previous release is 1.2.3 and next is 1.2.4, you can name your resulting tarball 1.2.3+git20100128 or 1.2.4~git20100128
<randomaction> or replace git with your VCS
<knipknap> ah! that looks nice. i'll give it a try
<knipknap> huh. now locally, i don't get any errors. but revu still claims "This is a native Debian package, with no .orig.tar.gz tarball", even though the orig.tar.gz was uploaded by dput. (http://revu.ubuntuwire.com/p/gelatin) i'm confused
<randomaction> version in changelog should be 0.1.12~git20100128.gb1f8fdd-0ubuntu1
<randomaction> also, your tarball seems to be missing doc/ and syntax/ directories, as well as other files
<stochastic> If I'm already an ubuntu member and want to eventually become a motu, is there a documented process of doing so?
<geser> stochastic: start contributing :)
<randomaction> stochastic: then apply to DMB
<stochastic> I have been contributing
<stochastic> I just seem to remember there was an intermediate stage like 'universe contributor' or something
<stochastic> geser, randomaction, ^^ ?
<randomaction> stochastic: https://wiki.ubuntu.com/UbuntuDevelopers
<geser> there still is but as a Ubuntu member isn't give you any additional benefit (only one badge more on your LP page)
<randomaction> yep, no upload rights
<stochastic> ahh, okay
<stochastic> thanks.
<geser> 'universe contributor' is just an other path to become Ubuntu member
<knipknap> randomaction, yay, all bugs on revu disappeared (except for the launchpad bug reference). thanks!
<knipknap> so.. against which package must i file a bug...?
<knipknap> ugh, too late
<Nahsei> Hello! I would like to ask some basic questions....
<Nahsei> I followed this recipe:   https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch
<Nahsei> and in point 5, just like it says in the recipe, the procedure failed
<Nahsei> then it says that the best solution is to dch -e, and that i should get some result show my current version...
<Nahsei> but i got confused... i ran the same command on both the old and the new sources and i couldn't understand what i was supposed to do
<Nahsei> because de new source code already had my version... the old source code should remain the same, right?
<Nahsei> (in changelog...)
<Nahsei> can someone help me?
<Nahsei> thanks
<xteejx> Hey guys, I'm trying to package another new project, the last one was already packaged, I didn't check...doh!
<xteejx> The one I'm doing now has no configure/make abilities, it is simply source code. How can I Ubuntu-ize it?
<xteejx> How do I package without a configure/make file?
<xteejx> ^To put it another way
<neversfelde> how do I skip dh_auto_test for debehlper in debian/rules?
<xteejx> Remove it from rules I would've thought or comment it out with #
<neversfelde> xteejx: I use dh --with kde $@, so I guess I have to add an override
<xteejx> dunno then, sorry
<xteejx> I'm new, seemed logical
<geser> xteejx: what does upstream write about how to install it?
<xteejx> I've just looked again...there's a Makefile.am and Makefile.in
<xteejx> The README says "./configure && make"
<xteejx> I get ./configure: No such file or directory - there simply isn't a configure script
<xteejx> make fails with or without telling it the Makefile.in/am .... all the files are .hpp or .cpp
<xteejx> With "No rule to make target `Makefile'."
<xteejx> :(
<geser> do you have a configure.in?
<dooooomi> hi everyone, i've uploaded a new package to REVU: klick is a command-line metronome using the JACK sound server. http://revu.ubuntuwire.com/p/klick
#ubuntu-motu 2010-01-29
<xteejx> Hi all
<crimsun> Laney: is #227505 reproducible for you in a current daily live of 10.04?
<xteejx> I found a script to tell me the depends and build-depends from the source... but I lost it, anyone know where to find it? I've googled for ages!
<zooko> Greetings, people of #ubuntu-motu!
<zooko> What does this mean? http://thread.gmane.org/gmane.linux.ubuntu.motu/6441
<zooko> (Seen on lwn.net's Distribution page this week.)
<zooko> Oh I guess I should read the referenced articles about ongoing discussion...
<zooko> Huh. Interesting
<dhillon-v10> hi all, while doing a merge, I find this one file present in Ubuntu but not in the Debian package, the changelog for debian doesn't mention about this file, so what's the best course of action here, keep that file or remove it
<persia> dhillon-v10: The best course of action is always to understand what things do, and make your best determination as to whether it should keep being done.  What is the file in this case?
<dhillon-v10> persia: thanks for the reply, the file is called: libecryptfs0.shlibs and it contains: libecryptfs 0 libecryptfs0 (>= 77)
<dhillon-v10> persia: that's it
<dhillon-v10> persia: bzr gives me this: Contents conflict in debian/libecryptfs0.shlibs
<dhillon-v10> persia: but there's no marker in that file to cause a conflict
<persia> Right.  Read the dh_makeshlibs manpage
<dhillon-v10> persia: okay, just a minute
<dhillon-v10> persia: so basically look for: dh_makeshlibs in the rules and if its there then i keep that file, because it basically contains the shlibs, and if its not there (which is the case) I can remove that file right?
<persia> No.
<persia> So, if dh_makeshlibs isn't there, then that's its own problem, because you're dealiing with a library.  Note that dh_makeshlibs is implied by dh(1) or cdbs.
<persia> If it is there, then you might want to check the common ancestor to see if it was there before, or whether it's really an Ubuntu addition (you may also be able to check this from patches.ubuntu.com, depending).
<dhillon-v10> persia: alright, I'll check patches.ubuntu.com
<persia> Also, you might try building the package, and see if the binary shlibs files differ with and without that file, and also inspect the binary packages produced by recent uploads.
<persia> (because dh_makeshlibs can generate one from scratch under some conditions).
<persia> Your target goal should be to make sure that the binary packages (especially the -dev package) are constructed in such a way that other packages build-depending on the library on which you are working get the correct run-time dependencies from ${shlibs:Depends}
<persia> You may or may not need to preserve (or modify) that file in order to reach this goal.
<dhillon-v10> persia: yeah you are right, the file is indeed an ubuntu specific change, so I'll have  to keep it :)
<dhillon-v10> persia: the patch says that
<persia> dhillon-v10: Note that you may have to modify it, if the ABI has changed.
<dhillon-v10> persia: so is that the cause of the contents-conflict bzr is giving, an outdated file
<persia> I've no idea about that.  I can only tell you about the contents of the packages.
<wrapster> i was trying to build libtspi and i get this error... http://pastie.org/799908
<dhillon-v10> persia: another question: the po stuff that shows up in the diff should be removed right, the patch right now looks really long, because a major change was the formatting of changelog and control files
<wrapster> what does this even mean?
<persia> dhillon-v10: Best to ask questions generally.  Someone else may have a faster or better answer.
<dhillon-v10> another question: the po stuff that shows up in the diff should be removed right, the patch right now looks really long, because a major change was the formatting of changelog and control files
<persia> That said, Debian translations are preferred except in special cases (which would be noted in the changelog).  In cases where there are translations changes, it is important to migrate only the translations that are intentionally changed, and otherwise keep the Debian translations.
<persia> wrapster: Check your build-depends.  If that doesn't work, try regenerating the autoconf stuff (but I think that's happening at build-time, from your log).
<segler> hi, i am searchin' for advocates for my rhythmbox plugin, please help me. http://revu.ubuntuwire.com/p/rhythmbox-radio-browser
<wrapster> persia: there were no buid-depends issues.
<wrapster> yet i still get the same error
<persia> wrapster: You're sure the desired version of all the libtool related stuff is being installed during the build?
<persia> If so, you may have to relibtoolise (which is something I've not yet mastered), or it may be something else.
<wrapster> persia: i just saw and one of the chid pkgs, has a dependency on libssl-dev.
<wrapster> and thats not installed
<persia> I doubt that's the cause of issues with LIBTOOL definition.
<persia> That might be another issue though :)
<wrapster> yeah.. its not.. it was my mistake.. thats already installed. :)
<wrapster> persia: well this is what i want... Im trying to build the 64bit version of libtspi.so
<wrapster> persia: reading across google seems to tell me i might need to have automake >=1.9 and i do have it.
<wrapster> yet i dont really understand about this issue.. could you please help me/
<persia> wrapster: I don't know anything beyond that included in your paste.  It appears AC_PROG_LIBTOOL isn't defined.  All I can suggest is investigating other build logs (especially ./configure output from a successful build of libtspi), and either following the advice from the error messages or something else.
<persia> It may be that aclocal and autoconf aren't being run for some reason (if AC_PROG_RANLIB and AC_PROG_LIBTOOL are defined), or it may be something entirely different.
<persia> I know lots about packaging and debugging crashes, but I only have a passing knowledge of autotools, and that mostly by running stuff and seeing the effects, rather than from any comprehensive source.
<persia> (and asking please doesn't make me any more able to help you :) )
<wrapster> persia: yeah i know.. but thats just courtesy.
<wrapster> ;)
<MTecknology> makefiles are ugly..
<persia> Why?
<MTecknology> persia: I can't get my head around this thing at all
<persia> This is because of an aesthetic concern, or something else? :)
<MTecknology> partly that possibly - I'm trying to fix up an itty bitty make file; it doesn't like me
<persia> How are you trying to fix it?
<MTecknology> lemme pull up the vm
<MTecknology> I decided to do any development in a vm only
<MTecknology> http://paste.ubuntu.com/364991/
<MTecknology> I know there should be an uninstall: - I don't think it needs a clean: but should probably have one
<persia> OK.  Which bit hates you?
<MTecknology> beyond that - I'm clueless
<MTecknology> I'm beed reading this - http://www.gnu.org/software/make/manual/make.html - and just getting confused
<persia> make is an immensely powerful tool, and so confusing :)
<MTecknology> The install: isn't right - I know that
<persia> It's mostly right.  Use `install -m 644 -D` instead of cp for the manpage, and `install -m 755 -D` instead of cp for the binary.
<MTecknology> If anything the man should be gzipped and sent to /usr/share/man/man1/lal.1.gz
<persia> Also, you probably want to install to ${DESTDIR}/bin or ${INSTALLDIR}/bin or something, rather than /usr/bin
<persia> Same for the manpage.
<persia> Or, if you just want the makefile to play nice with a standard debian/rules, install to ${DESTDIR}/usr/bin and ${DESTDIR}/usr/share/man/man1
<persia> If you want to be fancy, you could use ${DESTDIR}/${PREFIX}/bin and ${DESTDIR}/${PREFIX}/share/man/man1 and add a PREFIX ?= usr/local somewhere earlier (which you'd then override in debian/rules with PREFIX := usr)
<MTecknology> any reason I'd do that over the other option?
<persia> Your all: rule definitely isn't right.  all: should generally not have any specific activities, but rather just depend on other rules.  You might add a lal: rule, and have all: depend on lal:
<persia> The fancy way I described installs into /usr/local/* (unless overridden) for a local make; make install, and installs to ${DESTDIR}/usr/* if PREFIX is overridden in debian/rules, thereby building the package you want.
<MTecknology> how do I override that?
<persia> Other tricks that might be useful would be things like CFLAGS ?= $(shell pkg-config x11 xft --libs --cflags), and then using ${CFLAGS} in your calls.
<persia> If you want to be fancy, you could use ${DESTDIR}/${PREFIX}/bin and ${DESTDIR}/${PREFIX}/share/man/man1 and add a PREFIX ?= usr/local somewhere earlier (which you'd then override in debian/rules with PREFIX := usr)
<MTecknology> sorry
<persia> No problem: it's just easier for me to quote myself than retype :)
<persia> actually, for CFLAGS, you'd probably want += rather then ?=.  That way you can take advantage of any extra cflags that get defined somewhere else.
<MTecknology> so in rules:   %:    PREFIX ?= usr/local    dh  $@
<persia> No.
<persia> Put your variable defintion above your rules.
<MTecknology> oh - you said put that part in the makefile - override in rules
<rhpot1991> hmmm no RAOF tonight
<MTecknology> so in deb/rules I have PREFIX = usr/bin  ?
<rhpot1991> persia: (or anyone else), mind taking a quick peak at this: http://mythbuntu.pastebin.com/d306a3b3d
<persia> rhpot1991: It's best to just ask a question.  Whoever happens to be around will probably answer.
<rhpot1991> oh wait, I think I see my issue
<rhpot1991> persia: ignore me till I fix a path issue
<persia> rhpot1991: I don't see the point of a manual postinst: read the dh_makeshlibs manpage
<persia> Also, install the file to libfoo.so.n and the link to libfoo.so
<persia> MTecknology: I'd probably use "export PREFIX := usr", but it might work without all the syntactic sugar.
<persia> You don't want usr/bin, because you're using ${DESTDIR}/${PREFIX}/bin/ so you already have the "bin".
<MTecknology> so export pre.... goes after %: in deb/rules ?
<persia> Before.
<persia> Actually, if you use "export PREFIX := usr", it doesn't matter, but the convention is to define the variables before the rules.
<MTecknology> ok
<MTecknology> so how do I require something else?
<MTecknology> in the makefile
<persia> How do you mean "require"?
<MTecknology> inside all: require lal:
<persia> "all: lal"
<persia> That means the all: rule depends on either the lal: rule or the lal file.
<persia> (typically rules are named after the files they generate.  For other types of rules, there'S the special .PHONY: rule which one uses to indicate make shouldn't check files.  For more information, read about .PHONY in the make manual)
<MTecknology> and lal: is where I build thing?
<persia> The lal: rule should create the lal: binary.
<MTecknology> and and for lal.1? the man page
<MTecknology> since it will need to be gzipped
<persia> You could create a lal.1.gz: rule for that.
<persia> If you did, you probably want your install: rule to depend on lal and lal.1.gz
<rhpot1991> persia: let me run this by you then, upstream wasn't including any soname data at all, I'll be submitting a patch for this.  In their build process they reference libhdhomerun.so directly.  Can I handle the symlinking myself in the packaging, or does this need to be done at the build phase?
<persia> rhpot1991: You can handle it in the packaging if you like.  If upstream isn't including SONAME data, I strongly encourage you to create a symbols file to track ABI shifts.
<persia> dh_link is probably interesting.  dh_install can't rename files, so you'd have to do that in debian/rules directly.
<wrapster> what does Provides: mean in the control file?
<MTecknology> persia: so if you run 'make' will that do what's in all: ?
<persia> Yes.
<MTecknology> and in the install command, how do I specify the source I'm moving?
<rhpot1991> persia: happen to have a link or anything a symbols file?
<MTecknology> install -m 755 -D ${DESTDIR}/${PREFIX}/bin/ lal
<persia> !symbols
<persia> Hrm.
<persia> https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols
<persia> MTecknology: man install :)  I'll give you make syntax, because programming language manuals are tricky, but simple commands are easy :)
<MTecknology> I wasn't aware of an install command :P
<MTecknology> Looks like I want this -   install -m 755 -D ${DESTDIR}/${PREFIX}/bin/ lal lal
<MTecknology> I know one way to know for sure :)
<persia> heh :)
<MTecknology> yup - that was wrong
<persia> Maybe drop one of the spaces?
<rhpot1991> persia: whats the proper way to handle this whole issue, currently their makefile just inserts empty soname data, I have modified this to insert some real data but now my link are backwards, should the makefile handle the linking or should everything build off the full soname file version?
<MTecknology> persia: I thought I was supposed to have a space after the -D /dir/ because it said that sets up everything except the last piece in man install
<persia> rhpot1991: In an ideal world, the upstream makefile will build shared library into a versioned binary.  My personal preference when this doesn't happen is to wangle this in debian/rules and add a symbols file, but patching the upstream makefile is arguably more correct because it produces a patch one can send upstream.
<persia> MTecknology: install [OPTION]... [-T] SOURCE DEST
<MTecknology> persia: install -m 755 lal ${DESTDIR}/${PREFIX}/bin/lal worked
<MTecknology> I'm lost with the -D
<MTecknology> google isn't nice in finding examples :P
<MTecknology> something about a command being called install
<persia> -D creates any directories that didn't exist.  Like mkdir -o
<persia> Err, mkdir -p
<persia> It's a *good* name.  The command installs stuff.
<MTecknology> oh
<MTecknology> .... that makes much more sense when I read it now
<MTecknology> I didn't say it's a bad command - but it's a hard one to search for
<MTecknology> so   install -m 755 -D ${DESTDIR}/${PREFIX}/bin/ ./lal ${DESTDIR}/${PREFIX}/bin/lal
<MTecknology> or w/o the ./ probably
<MTecknology> I try that and I get install: target `/usr/bin/lal' is not a directory
<persia> MTecknology: Are you root?
<MTecknology> ya
<persia> And you had the -D?
<persia> Oh, I see the issue.
<persia> read the very first line of the summary in the manpage again.
<MTecknology> DOH!
<MTecknology> OK!
<MTecknology> -D takes no arguments
 * MTecknology facepalm at man page
<MTecknology> sorry for missing that
<MTecknology> alrighty - I'm guessing I should be able to start a new terminal session - make; sudo make install
<MTecknology> nope
<MTecknology> I thought lal and lal.1.gz after all had their own lines - I guess not
<persia> paste your Makefile again?
<MTecknology> http://paste.ubuntu.com/365006/
<MTecknology> little different now
<persia> Right.  all: typically wouldn't depend on lal.1.gz
<persia> install: needs to depend on the stuff it's copying.
<persia> Drop the export line from install, you want just "PREFIX ?= usr/local" at the top (above all:)
<MTecknology> oh.. does the user still needto do make before make install?
<persia> Right now, yes, but if you follow my advice above, no.
<MTecknology> ok; I always that that was the norm :P
<persia> It is, but that's for entirely different reasons.
<MTecknology> ok, should I just have all:    lal
<MTecknology> then install:   lal   lal.1.gz ?
<persia> You can leave all: alone or not, as you like, but if you don't specify the dependencies in install, you are prone to errors.
<MTecknology> ok
<persia> Also, you're installing by default to /usr/local/usr/bin : is that what you want?
<MTecknology> I dropped /usr from that
<persia> I can only critique what I see :)
<MTecknology> http://paste.ubuntu.com/365009/
<MTecknology> I meant because you said it - just letting yoy know I listened
<MTecknology> heh - 'make' doesn't want to do anything now
<MTecknology> and I see why :P
<persia> That's why you want a clean: rule :)
<MTecknology> just an rm command?
<MTecknology> and depend on clean?
<persia> No.
<persia> A clean: rule.  clean: rules typically contain lots of "-rm " lines.
<MTecknology> -rm ?
<MTecknology> I know "rm" but "-rm"..
<MTecknology> I just tossed this together now - http://paste.ubuntu.com/365013/
<MTecknology> apparently wrong :P
<MTecknology> persia: sorry for trying to jump into this with apparently very little knowledge - I thought I knew enough to be able to do better than this
<MTecknology> nice big learning curve that I'm hoping to overcome someday
<MTecknology> RAOF: hi - somebody was looking for you
<MTecknology> 23:00 < rhpot1991> hmmm no RAOF tonight
<persia> Two recommendations.  1) prefix any line you don't care about succeeding with '-'.  This is useful in case you want to, for example, run `make clean; make clean`.  2) don7t bother with all the ./ entries.  make knows where it is.
<rhpot1991> I hit up persia all good :)
<MTecknology> ok
<RAOF> rhpot1991: Hah.
<persia> But I'll leave the rest of it to either the make manual or someone else :)
<MTecknology> persia: thanks - I'll try out this sexxy beast now
<persia> Oh, one last bit: install depending on clean: means that the stuff will always be deleted before being installed.
<MTecknology> I'll not do that if that's bad
<RAOF> Well, generally you need to not delete the things that you're about to try to install :)
<MTecknology> err - I was thinking depend on uninstall
<MTecknology> which I guess isn't needed
<MTecknology> I thought -D created a directory if not exists
<MTecknology> It doesn't want to isntall lal.1.gz
<MTecknology> Is that something that shouldn't have ${PREFIX} in it?
<MTecknology> just ${DESTDIR}/usr/share/man/man1/lal.1.gz
<MTecknology> -D  create all leading components of DEST except the last, then  copy
<MTecknology> It should make that part - not complain
<MTecknology> persia: thats for putting up with me again - I have the ITP filed too - so it's probably figure out a few tiny things on my own - then take the peoples suggestions - then actually submit to debian and file RFS :D
<MTecknology> persia: I appreciate all the help and holding my hand
<MTecknology> RAOF: thanks for your help too :)
<alkisg> How can I allow 2 individuals full read/access to my bzr branch? (https://code.launchpad.net/sch-scripts)
<dholbach> good morning
<iulian> G'morning Daniel.
<dholbach> hiya iulian
<dupondje> this feels stupid :)
<dupondje> https://bugs.launchpad.net/ubuntu/+source/gnome-do/+bug/513802
<ubottu> Ubuntu bug 513802 in gnome-do "Please sync gnome-do 0.8.3.1+dfsg-1 from debian sid" [Undecided,Incomplete]
<dupondje> and 1 hour after it, the FTBFS got fixed :)
<Laney> crimsun: (re #227505) No, I don't see that any more, but (on a dist-upgraded system, not a live cd) I'm having to toggle mute to get any sound output
<om26er> I am having a problem with finding the copyrights of a tarrball I downloaded
<slytherin> om26er: isn't there any COPYING or LICENSE file?
<directhex> om26er, that's usually not a great sign. have you tried contacting the upstream developer?
<om26er> slytherin, yes copying file is there
<slytherin> om26er: then what is the issue?
<om26er> slytherin, what should I look for in there? copyrights change with time
<slytherin> om26er: Wait a minute, are you looking for license or copyright owners?
<slytherin> I mean copyright holders for the code.
<om26er> slytherin, copyright ownsers
<om26er> ya
<slytherin> is there AUTHORS file?
<om26er> slytherin, yess
<om26er> am looking
<slytherin> om26er: doesn't it list copyright holders?
<om26er> slytherin, no it dont
<slytherin> om26er: Another option. a bit manual and lengthy. Check headers of source files. grep for word Copyright in the source files.
<om26er> I got this error http://pastebin.org/83882 while building
<om26er> please help I am getting the error when building  dpkg-buildpackage: error: debian/rules build gave error exit status 2
<maxb> om26er: That is merely the consequence of an earlier error
<om26er> maxb, did I do something wrong?
<maxb> You'd need to pastebin more of your build log for people to help
<om26er> maxb, terminal log?
<maxb> yes
<xteejx> If a source comes in several different packages, i.e. 1..the source for a program, 2..the data, 3.....the sounds ... can these be packaged separately and depend on each other without any problems?
<om26er> here is the terminal log http://pastebin.org/83897
<xteejx> Hi om26er :) Congrats on your Bug Control application
<om26er> xteejx, thanx :)
<slytherin> xteejx: Sure why not. In fact the new source format 3.0 allows different upstream tar balls to be combined together.
<xteejx> Oh wow ok :)
<slytherin> xteejx: If you want to package it old way you will have to create 3 different source packages. Otherwise use 3.0 format - http://wiki.debian.org/Projects/DebSrc3.0
<xteejx> Cool, thanks slytherin
 * directhex wonders if he owes bddebian cake
<xteejx> FTBFS: https://launchpad.net/ubuntu/+source/ogre-contrib/1.6.4-1/+build/1350584  - builds fine locally on i386
<xteejx> The error seems to be the autobuilder did not install nvidia-cg-toolkit, whereas locally it was fine.
<xteejx> dholbach: ^
<dholbach> I have no idea
<dholbach> xteejx: but maybe somebody else can - I need to sort out a few other things
<xteejx> No probs Daniel
<xteejx> Anyway, I checked the control file and everything seems fine there, may have just been a quirk
<statik> hi! is there a standard way to rename a file in a debian/patches patch? If I use cdbs-edit-patch, then rename the file directly, the resulting patch I get shows a complete removal and add of a new file, which is way more noisy than I want
<dholbach> final day of https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in 22 minutes in #ubuntu-classroom on irc.freenode.net (first up: "Writing Beautiful Code")
<RoAkSoAx> james_w, Heya. Hey one quick question. While doing 'bzr builddeb' i get an error 'bzr: ERROR: [Errno 2] No such file or directory:' on a patch I deleted. How to override or what i can be doing wrong?
<geser> RoAkSoAx: did you tell bzr that the patch got removed? (bzr remove)
<RoAkSoAx> geser, nope, but indeed that was the problem :) thanks  :)
<highvoltage> hi, I'm reviewing zope.annotation (http://revu.ubuntuwire.com/p/zope.annotation) it says priority: extra
<highvoltage> it should be 'optional', right?
<randomaction> highvoltage: unless in conflicts with something or depends on "extra" package
 * jdong unamusingly glares at VMWare
<jdong> which just told me that a snapshot's size ranges anywhere from 768MB (RAM size) to 10.5GB (disk+RAM size)
<tim> hi, i am trying to build a deb of gcc-4.4.3 for karmic. the folder created by apt-get source does't contain the source directly, but a tarball ... when trying to build the package, dpkg-source complains, that the binary file content changed ... any idea, what i am doing wrong?
<daurnimator> hey all
<daurnimator> so this probbaly isn't the correct channel
<daurnimator> but I'm coding a daemon
<fabrice_sp> tim, how are you trying to build it?
<daurnimator> but I have no idea how to package/run/instlal/debainise it
<tim> fabrice_sp, with git buildpackage
<daurnimator> (eg, where to install, init.d scripts, how to make a pkg for it, etc)
<fabrice_sp> !packaging | daurnimator
<ubottu> daurnimator: The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
<fabrice_sp> tim, if you have the source locally, you should use debuild -b
<tim> fabrice_sp, i will give it a try
<segler> hi, i am searchin' for advocates for my rhythmbox plugin, please help me. http://revu.ubuntuwire.com/p/rhythmbox-radio-browser
<fabrice_sp> segler, version should be -0ubuntu1
<fabrice_sp> also, why do you need a dir file?
<fabrice_sp> otherwise, looks good. I'll have a deeper look later
<crimsun> Laney: which mixer element(s) do you need to unmute?
<ari-tczew> how can I close a few bugs in debian/changelog?
<ari-tczew> (LP: #bug, #bug2) ?
<Quintasan> ari-tczew: If one change closes multipe bugs shouldn't they be marked as duplicates?
<Quintasan> ari-tczew: if the bugs are related but not the same and are closed by the same fix I belive you can do as you said - (LP: #bug1, #bug2)
<ari-tczew> like so, but I want to know
<Quintasan> ari-tczew: if the bugs in question have exacly same problems I would mark one of them as duplicate and close only one
<directhex> sebner, how close to done is longomatch? all its build-deps are transitioned, so sponsorship is running at full speed again
<ari-tczew> quintasan, statistic mate ;)
<sebner> directhex: hmm, I wanted to wait for new upstream version but if you give me some minutes it's ready for now too
<directhex> sebner, well, it's RC you see... and stuff is being pulled into lucid by an eager seb128 too. we're almost done \o/
<sebner> directhex: heh, ok. then give me some minutes. I'll make it ready then
<ari-tczew> Quintasan, btw. would you like to take sponsor now?
<directhex> sebner, it seems to work fine against db4o 7.4, thankfully
<Quintasan> ari-tczew: uh sure, where I can get the diff?
<sebner> directhex: haven't tested that yet. Yesterday db4o was still untransitioned so I didn't bother doing testing
<ari-tczew> Quintasan, bug 255360
<directhex> sebner, a sexy ftpmaster (i guess bddebian) has been clearing things though NEW, which was running reasonably quickly anyway
<ubottu> Launchpad bug 255360 in liblo "[lucid] Please update liblo to 0.26 version" [Wishlist,New] https://launchpad.net/bugs/255360
<sebner> directhex: heh, yeah he's great :)
<Quintasan> ari-tczew: well, builds fine, let me check debian/ then :P
<ari-tczew> sure
<sebner> directhex: I'll give it a testbuild now, I'll tell you when ready for sponsoring
<Quintasan> ari-tczew: I like it, builds fine and I didn't find any problems :)
<ari-tczew> Quintasan, cool, would you like take sponsor on other bugs?
<ari-tczew> with debdiff now
<Quintasan> well I have time so no problem
<Quintasan> it would be good if someone else could review it too
<ari-tczew> Quintasan, go ahead bug 514453
<ubottu> Launchpad bug 514453 in pyalsaaudio "Merge pyalsaaudio 0.5+svn36-1 (universe) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/514453
<Quintasan> ari-tczew: this one is fine with me too
<highvoltage> if anyone's around for reviewing some zope packages so that we can get schooltool back in ubuntu, there's just two left that needs reviewing:
<highvoltage> http://revu.ubuntuwire.com/p/zope.server
<highvoltage> http://revu.ubuntuwire.com/p/zope.size
<kamalmostafa> ScottK: hi Scott -- reminder: we've been sitting on libtifiles/libticalcs for a couple weeks now.  :-)
<ScottK> kamalmostafa: It's pretty near the top of my Ubuntu TODO at this point.
<kamalmostafa> ScottK: sounds good.
<_stink_> anyone know of a way to have dpkg (or some other debian packaging magic thing) (1) check whether a .deb's dependencies are already installed, and (2) return an error to the shell if not?
<_stink_> --no-act doesn't seem to care about whether depends are installed.
<hakaishi> Hi everyone! Anyone up to advocate/review qt-shutdown-p? - I corrected the desktop file, the copyright file and the docs file as jcfp asked. http://revu.ubuntuwire.com/p/qt-shutdown-p
<ScottK> hakaishi: I know you've been asking a long time.  You might consider asking the Debian qt-kde team if they are interested and if they are, get it into Ubuntu via Debian.  See #debian-qt-kde on OFTC.
<geser> _stink_: you could use "gdebi --quiet --aptline $package.deb" and check if it lists something or not
<_stink_> geser: omg.  that is awesome.
<_stink_> i owe you a beverage should we cross paths.
<Quintasan> hakaishi: it's good, I think if you go to Debian they should be fine with it
<_stink_> crap, i didn't even know about gdebi.
<hakaishi> ScottK: I thought, I get advocations only if there are no issues with the package. And since there no longer are, I thought I'll ask for it now^^
<ScottK> hakaishi: I haven't been following the details of your package, I've just been noticing you've been asking for a while.
<hakaishi> ScottK: Everything should be okay with the new upload. The others weren't okay because of copyright and the rules file or such
<Quintasan> hakaishi: AFAIK it would be better to get it to debian, if you want to change it just get a newer version to Debian and request a sync, both projects will gain something :)
<hakaishi> On which server does #debian-qt-kde run? - I mean the exact address
<Quintasan> hakaishi: irc.oftc.net I belive
<hakaishi> okay, thanks
<hakaishi> Is there a website for debian-qt-kde like revu.ubuntuwire.com?
<Quintasan> hakaishi: hmm I think you can upload to mentors.debian.org
<hakaishi> Thank you, maybe I will try to get it into debian, maybe not. I'll see tomorrow. Bye bye
<wind-rider> hi
<geser> Hi
<wind-rider> on my kubuntu lucid installation the package soprano-daemon is installed
<wind-rider> it is made dependent on virtuoso-server today / yesterday to fix https://bugs.launchpad.net/bugs/505653
<ubottu> Ubuntu bug 505653 in soprano "make soprano depending on virtuoso-opensource" [Undecided,Fix released]
<wind-rider> kpackagekit shows that soprano-daemon is dependent on it, but still virtuoso-server is not installed automatically
<wind-rider> is that a bug?
<geser> Depends or Recommends like the changelog says?
<geser> Recommends: virtuoso-server (>= 5.0.12-0ubuntu3), ...
<wind-rider> geser: oh, then that's the problem
<wind-rider> geser: but that's wrong
<ScottK> wind-rider: Probably better to ask in #kubuntu-devel.
<wind-rider> ScottK: ok, I'll do that
<wind-rider> virtuoso should be installed by default and not as an option
<geser> usually Recommends are auto-installed like Depends
<geser> but I don't know how kpackagekit behaves at it
<ari-tczew> fabrice_sp: ping
<sebner> directhex: ready for sponsoring :)
<wind-rider> geser: thx, i discussed it at #kubuntu-devel
<wind-rider> and added a comment to the bug report
<MohammadRRR> Hi , How Gnome-do can shutdown without requesting passwird
<MohammadRRR> *password
<directhex> sebner, ta, i'll take a peek & upload once dinner is eaten
<sebner> directhex: great, thx. Just ask if you have any questions
<randomaction> fabrice_sp: could you check if zshdb builds for you? It FTBFS on buildd but builds fine in pbuilder. (bug 514359)
<ubottu> Launchpad bug 514359 in zshdb "zshdb-0.03+git20090920 FTBFS" [Undecided,New] https://launchpad.net/bugs/514359
<fabrice_sp> randomaction, sure
<randomaction> maybe it only manifests in sbuild
<ScottL_> would someone mind looking at zynjacku package in REVU ( http://revu.ubuntuwire.com/p/zynjacku ) ?
<fabrice_sp> randomaction, I also installed some 'checking' packages (don't remember the name), that are responsable of some FTBFS in hte buildd
<fabrice_sp> so let see what happens
<fabrice_sp> ScottK, you should update the Maintainer field
<randomaction> wrong nickname
<fabrice_sp_> ScottL, also some comments in copyright (# Please also look if there are files or directories which have a
<fabrice_sp_> # different copyright/license attached and list them here.
<fabrice_sp_> )
<fabrice_sp_> argh. got idsconnected
<directhex> sebner, seems to build fine
<sebner> directhex: sure, I (at least) fiXX0red the build :P
<fabrice_sp_> randomaction, FTBFS
<directhex> sebner, well, gotta check these things!
<fabrice_sp_> FAIL: test-tbreak
<dupondje> who can accept packages that are in queue ? :)
<fabrice_sp_> dupondje, do you mean NEW?
<directhex> source format 3.0? sod it, i'll upload anyway
<dupondje> https://launchpad.net/ubuntu/lucid/+queue here ...
<ScottL_> fabrice_sp_:  you said that ScottK should update the Maintainer field...did you mean ScottL (me) ?
<fabrice_sp_> yes. Sorry
<fabrice_sp_> your nicks are very close :-)
<fabrice_sp_> dupondje, archive admins
<ScottL_> yeah, it's been problematic sometimes
<fabrice_sp_> :-D
<randomaction> fabrice_sp_: ok, so reproducible in sbuild
<randomaction> fabrice_sp_: thank you
<fabrice_sp_> ScottL, you should also reviewyour copyright: you have sources with LGPL and different people
<fabrice_sp_> randomaction, yw ;-) Do you want me to do more tests?
<sebner> directhex: Yeah, I asked you 3 weeks ago (if you remember) and you didn't say to have a problem with it, else I just have to find someone else
<fabrice_sp_> Quintasan, did you check rdepends for liblo?
<fabrice_sp_> (just to see if we have a transition to do for the 26 rdepends)
<ari-tczew> fabrice_sp_: I think tht nobody have time for testing all rdepends
<fabrice_sp_> ari-tczew, so you prefer to have 26 packages that FTBFS?!
<ari-tczew> ahh, you mean check building?
<fabrice_sp_> yes. and test some of them.
<Quintasan> fabrice_sp_: urgh my fault, I only checked libol to build in lucid
<fabrice_sp_> this is a huge change (from liblo0 to liblo7), so I expect some ABI changes
<ScottL_> fabrice_sp_:  thank you for looking at zynjacku in REVU, i'm at work so I'll look at the maintainer field and copyright at home tonight :)
<fabrice_sp_> Quintasan, no problem ;-)
<fabrice_sp_> ScottL, I'm putting my comments in revu (discovered more stuff :-) )
<ScottL_> oh, excellent, thanks again :)
<fabrice_sp_> Quintasan, ari-tczew This is only that if there is a transition to do, it's easy to create a bug report and request some help (26 packages is not that huge). Just my 2 cents
<fabrice_sp_> ScottL, yw ;-)
<ScottL_> the whole REVU process is teaching me gobs of stuff :)
<fabrice_sp_> :-D
<fabrice_sp_> last time (less that one moth ago) I requested a package review I discovered a lot of thing I forget to check in my own package;-)
<Quintasan> fabrice_sp_: I wonder if I can somehow list all rdepends without searching on packages.ubuntu.org
<fabrice_sp_> apt-cache rdepends liblo0 ?
<directhex> sebner, you've closed yourself off from backports.org tho
<Quintasan> liblo0
<Quintasan> :/
<fabrice_sp_> Quintasan, it's not liblo0?
<Quintasan> I belive no, hmm'
 * fabrice_sp_ is beginning to be tierd :-D
<ari-tczew> fabrice_sp_: now please just tell me, do we need check only FBTFS or FTBFS + general work all rdepends?
<sebner> directhex: that's calculated because 1) there is not really a reason for backporting any app I maintain 2) git revert. no problem at all
<Quintasan> fabrice_sp_: it would be liblo0ldbl rather
<fabrice_sp_> Quintasan, right
<fabrice_sp_> ari-tczew, I would build and test some of them
<Quintasan> fabrice_sp_: and I'm supposed to grab sources of those from debian and thest them against lucid pbuilder as well?
<fabrice_sp_> Quintasan, I would build the lucid actual source
<fabrice_sp_> anyway, because the lib name change, we have to rebuild all of them
<randomaction> fabrice_sp_: I guess I'll just give a hint to DM of zshdb and leave it to the interested parties :)
<fabrice_sp_> as the lib is in Experimental, I expect some problems
<fabrice_sp_> randomaction, :-D
<Quintasan> so I need to setup a custom pool for pbuilder?
<fabrice_sp_> randomaction, when test fails, it's generally hard
<fabrice_sp_> Quintasan, or use a chroot for that, and manually install liblo or use a ppa :-)
<randomaction> fabrice_sp_: it fails because the script which contains the test cannot be found
<fabrice_sp_> Quintasan, I've done that with a ppa before
<fabrice_sp_> randomaction, oh. perhaps the script is not installed?
<Quintasan> oh well, night it long so I might build them all as well
<Quintasan> :P
<Quintasan> is*
<fabrice_sp_> lol
<ari-tczew> Quintasan, regards!
<randomaction> fabrice_sp_: maybe, but in this case it must be a really weird situation, as everything runs fine in pbuilder
<fabrice_sp_> I tried that with maven, some time ago, and uploaded more than 40 packages! :-)
<ari-tczew> btw. please mate upload pyalsaaudio :>
<Quintasan> ari-tczew: you're going to build some too, aren't you? :>
<fabrice_sp_> randomaction, right. I may check my build log
<ari-tczew> fabrice_sp_: I remember maven action :>
<fabrice_sp_> :-D
<fabrice_sp_> dooooomi, about bug your comment in bug 514491
<ubottu> Launchpad bug 514491 in liblo "Sync liblo 0.26~repack-1 (universe) from Debian experimental (main)" [Undecided,Confirmed] https://launchpad.net/bugs/514491
<ari-tczew> Quintasan, no tonight :( ... tomorrow I'm going on celebrations about my city Tczew (750 years)
<fabrice_sp_> dooooomi, the problem is that old lib becomes NBS, and that we should get rid of it as soon as the new one is uploaded
<fabrice_sp_> that's where transitions comes from
<ari-tczew> so if I right understand, sponsors have to upload debdiffs in versions e.g. 1build1 for rdepends?
<fabrice_sp_> randomaction, in which step does the script processor.sh built in pbuilder?
<fabrice_sp_> ari-tczew, yes
<fabrice_sp_> randomaction, I can't find any reference to it in my log
<randomaction> it gets installed late in the process, no evidence of running
<randomaction> fabrice_sp_: http://paste.ubuntu.com/365429/
<fabrice_sp_> very strange
<randomaction> probably tests run it and expect it to be there
<randomaction> they are silent it all is ok
<randomaction> s/it all/if all/
<dooooomi> fabrice_sp_: ok. anyway, the point is that most likely all rdepends can be rebuilt using the new version of the library with no problems. though i'm not quite sure what exactly would need to be done to achieve that
<fabrice_sp_> randomaction, but in your case, the tests are ok, so it seems it can actually  find it
<randomaction> yep
<fabrice_sp_> dooooomi, upload a new revision for each rdepends (as build1 if the package comes from Debian)
<fabrice_sp_> randomaction, weird
<fabrice_sp_> :-D
<fabrice_sp_> can you enter in your pbuilder (with login), and actually build the package? I'm getting curious when this file comes from :-D
<fabrice_sp_> dooooomi, anyway: this is good news that actually we won't have any FTBFS because of that ;-)
<dooooomi> fabrice_sp_: i'm at least 99.9% sure about that ;)
<fabrice_sp__> grrrr: got disconnected again :-/
<fabrice_sp__> dooooomi, cool! :-) That will be an easy transition the n;-)
<randomaction> fabrice_sp__: you grew an additional underscore :)
<fabrice_sp__> lol
<fabrice_sp__> I only can have 2 ;-)
<fabrice_sp_> randomaction, in a new chroot, the package builds fine
<fabrice_sp_> it may be because of .sh not being directly runnable
<fabrice_sp_> have to go now. Will check tomorrow. Bye
<randomaction> fabrice_sp_: bye
<Quintasan> randomaction: got a second?
<randomaction> Quintasan: yes
<Quintasan> randomaction: well, I want to sponsor ari-tczew package, I grab the debdiff from him, apply and testbuild and if everything is allight I can upload?
<Quintasan> allright even.
<randomaction> yes. If you use debuild, signing is done with -kKEYID
<Quintasan> randomaction: hmm I wonder now because the changelog will mention his name, won't debuild look for his key?
<randomaction> so you use -k with your keyid
<randomaction> and it uses it to sign
<crimsun> cat ~/.devscripts
<crimsun> DEBSIGN_KEYID=foo
<randomaction> crimsun: thanks, that's handy :)
<Quintasan> randomaction, crimsun: thanks
<ari-tczew> what about latest MOTU Council Meeting?
<ari-tczew> who has been joined to MOTU?
<randomaction> ari-tczew: no quorum: http://irclogs.ubuntu.com/2010/01/28/%23ubuntu-meeting.html
#ubuntu-motu 2010-01-30
<Quintasan> I'm going to bed. Good night Ladies and Gentleman
<ChogyDan> I'm trying to put a kernel into a ppa, and I'm getting ABI errors.  Do I have to pack the ABI files in with the source?  I know when building it locally, I could d/l the ABI files...
<jmarsden> ChogyDan: Buildd's have no Internet access during the build process.  By design.
<ChogyDan> fair enough, but I don't know what to do regardless
<jmarsden> ChogyDan: Look at how the official Ubuntu kernel packages do things, and do it that way.  I guarantee they do not go out and grab stuff from the Internet during package building.  So your kernel paclages should not need to do that either.
<wgrant> ChogyDan: IIRC there's a script that you run to grab the latest ABI files and put them in the source.
<wgrant> Or you enable PPA mode, which disables the ABI check and uses something different.
<wgrant> Although that might not exist any more; I haven't done it for 18 months.
<ChogyDan> wgrant: how do I enable ppa mode?  ok.  Well, I will try packing in the ABI files, see if that works
<doctormo> Hey everyone, I'm getting an error when I tried to include a postinst script into my package.
<doctormo>  dpkg (subprocess): unable to execute installed post-installation script: Exec format error
<doctormo> I thought the postinst was just a bash script, am I wrong?
<wgrant> doctormo: The postinst has to be an executable of some kind. Are you missing a #!/bin/sh?
<doctormo> I was
<ScottL_> anyone care to give some pointers for using debhelper 7 style format?
<zooko> ScottK: the last feature of Tahoe-LAFS is in trunk now. And it kicks ass! http://allmydata.org/pipermail/tahoe-dev/2010-January/003723.html
<zooko> But I must sleep...
<zooko> I'll be back on IRC tomorrow!
<kklimonda> can I merge packaging branch with a full branch somehow?
<kklimonda> anyone familiar with "distributed development" online? I have few questions
<geser> sort of familiar, I've done some successful merges with it
<kklimonda> geser, are there plans to drop debian/patches/ in favour of branches?
<geser> that I don't know
<randomaction> I think these are *very* remove plans
<kklimonda> geser, is there an easy way of working with both "full" branches and and branches that contain only debian/ directory or do I have to diff them by hand?
<kklimonda> also can I get branches for all packages uploaded to -proposed and -security?
<geser> I've only used the packaging branches from LP till now
<kklimonda> (I've tried lp:ubuntu/<package>/karmic-security and lp:ubuntu/karmic-security/[package] and neither works)
<geser> the second one should work
<geser> have you a package name with an upload to security at hand?
<kklimonda> transmission
<geser> hmm, apparently no -security branches (see https://code.edge.launchpad.net/ubuntu/+source/transmission)
<kklimonda> weird
<kklimonda> django have -security branches so it would seem that it's dependant on developer.. but aren't those branches created automatically?
<geser> yes, but I don't know how it's triggered as it runs "external" to LP itself
<geser> or not so external as I just found out
<wgrant> geser: "not so external"?
<geser> I found an loggerhead branch mentioning package-import.ubuntu.com but it was 2 years old
<geser> wgrant: do you know how bundled this package-import.ubuntu.com is with LP itself?
<wgrant> It is external. It checks LP regularly for new uploads.
<wgrant> It's not part of LP. It uses the public API and bzr to communicate.
<jetienne> q. im writing a /etc/init.d script..  where can i get info on the language between ### BEGIN INIT INFO and ### END INIT INFO
<jetienne> http://wiki.debian.org/LSBInitScripts got it
<Laney> what does that mean?
<Laney> oh, no channel ctcps I guess
<tsimpson> yeah, except for /me
<geser> Laney: http://freenode.net/using_the_network.shtml explains them
<Laney> got it
<kklimonda> can I append ubuntu version to the version string generated by bzr builder/dailydeb ?
<RainCT> norsetto: I'm running Sid here and it's really not that scary :)
<norsetto> RainCT, oh, I'm not afraid of that, just to screw up since what I'm running now is a kind of monster-patch system, loosely based on hardy
<kemmotar> hi all! what you do? can i join your team? (sorry for my bad english)
<randomaction> kemmotar: see links in the channel topic
<ari-tczew> randomaction, are you bored?
<randomaction> ari-tczew: not too much :)
<ari-tczew> want to sponsor?
<randomaction> I can ack a sync for gambas2 :)
<ari-tczew> are you sure?
<ari-tczew> yesterday I have checked patch  with upstream
<ari-tczew> code aren't the same
<randomaction> ok, let's look
<randomaction> snprintf(ctx, sizeof(ctx), "%.2g", THIS->doc->getPDFMajorVersion () + THIS->doc->getPDFMinorVersion() / 10.0);
<randomaction> %.2g prints a floating-point number. The floating-point number is supplied in the next argument.
<randomaction> snprintf(ctx, sizeof(ctx), "%d.%d", THIS->doc->getPDFMajorVersion () + THIS->doc->getPDFMinorVersion() / 10.0);
<randomaction> %d prints an integer, so two integers should be supplied
<randomaction> instead, one floating-point number is supplied
<ari-tczew> so what's the conclusion?
<randomaction> that replacing the first line with the second is not a good idea
<ari-tczew> ok, give me a moment, I'll convert request to sync
<ari-tczew> randomaction, bug 514755
<ubottu> Launchpad bug 514755 in gambas2 "Sync gambas2 2.19.0-2 (universe) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/514755
<ari-tczew> could lm-sensors backport from lucid to karmic?
<randomaction> ari-tczew: done gambas2
<ari-tczew> requestsync is bugged
<ari-tczew> lazr.restfulclient.errors.HTTPError: HTTP Error 412: Precondition Failed
<geser> argh, a 2nd occurance of this :(
<ari-tczew> randomaction, thanks
<geser> ari-tczew: the bug itself got filed, you just need to "finish" like subscribe the sponsoring team
<ari-tczew> huh? which bug is filed?
<ari-tczew> ahh, you mean by requestsync
<geser> your sync request
<ari-tczew> I know
<ari-tczew> randomaction just give an ACK, so no problem ;-)
<ari-tczew> btw. do you will fix this issue, geser?
<Quintasan> fabrice_sp: FYI, most of the rdepends of liblo built fine, didn't test all of them tough
<geser> I plan to. I only know a possible reason for this so I can only hope my fix will really fix it
<ari-tczew> is there any statistic (LP) who did upload the most packages? just like top10 or something
<geser> there was in the past
<randomaction> https://launchpad.net/ubuntu/+topcontributors gives some idea, especially soyuz karma
<ari-tczew> lol, stupid tool, e.g. Martin Mai has only 5 packages uploaded
<ari-tczew> ups, I'm looking on wrong field! sorry!
 * iulian wonders where emgent is.
<kklimonda> hmm, when I do bzr merge-package tags aren't merged (i.e. only tags from ubuntu branch are present in a working branch)
<kklimonda> works fine when I use normal merge
<ari-tczew> does MOTU have official logo?
<ari-tczew> like this: https://launchpadlibrarian.net/1516491/motu-image-2.png
<ari-tczew> anybody have bigger image than this?
<fabrice_sp> Quintasan, cool: we will just have to upload build1 versions after sync of liblo. Thanks for taking care of that check ;-)
<Quintasan> fabrice_sp: do you mind uploading it? My connection is pretty screwd now and I have lags even when typing :S
<ari-tczew> Quintasan: fabrice wrote after sync
<fabrice_sp> Quintasan, it's a sync, right?
<ari-tczew> so no this time
<Quintasan> urgh, looks like broken central heating affect my reading ability
<Quintasan> @_@
<fabrice_sp> too hot?
<Quintasan> too cold
<Quintasan> :/
<Quintasan> too hot wouldn't be a problem since I could open the door to garden :P
<fabrice_sp> right! If we begin to see repeated caracters, we will ping you to keep you awake :-D
<Quintasan> lol :D
<geser> fabrice_sp: lliikkee tthhiiss??
<fabrice_sp> geser, ping
<fabrice_sp> :-P
<geser> there is a bug in lucid which causes this?
<geser> s/?//
<geser> just set the delay to "repeat keys" to it's minimum value and this will happen
<fabrice_sp> oh, right: remember seing the discussion in ubuntu-devel
<geser> can someone access here https://edge.launchpad.net/ubuntu/+source/hypre
<hyperair> no permissions
 * geser files a bug then
<fabrice_sp> yes I can
<fabrice_sp> geser, ^
<geser> hmm, interesting
<fabrice_sp> only when unlogged
<fabrice_sp> when I log in, no permission
<geser> thanks, added that info to the bug
<ScottL> fabrice_sp, when you looked at zynjacku in REVU you mentioned some files were LGPL, how could you tell?
<fabrice_sp> click on the legal link
<fabrice_sp> ScottL, ^
<fabrice_sp> or use licensecheck
<geser> DktrKranz: do you know if we can get a newer gpsd into lucid? some other packages are in DEPWAIT on a newer libgps-dev
<DktrKranz> geser: I'll have a look with bzed
<fabrice_sp> geser,  bug 508013
<ubottu> Launchpad bug 508013 in gpsd "Sync gpsd 2.90.1~svn6819-1 (universe) from Debian testing (main)" [Undecided,Incomplete] https://launchpad.net/bugs/508013
<ScottL> thanks fabrice_sp...I'm learning more and more stuff :)
<fabrice_sp> :-D
<ari-tczew> geser, so what's the conclusion about gpsd? we can sync it from testing?
<geser> not unless DktrKranz or bzed give their OK
<ScottL> fabrice_sp, you also mentioned using debhelper 7 format, but I had trouble finding explicative information, can you suggest somewhere to learn more about it?
<Laney> man dh
<fabrice_sp> ScottL, /usr/share/doc/debhelper/examples/rules.tiny ?
<fabrice_sp> man dh is definitively better
<ScottL> yes, I found both of those fabrice_sp
<ScottL> but my understanding of makefiles, /debian/rules, et al is rather limited still and I'm not sure really how to convert
<ScottL> but thanks for your help nonetheless :)
<fabrice_sp> ScottL, well, you can try with the tiny rules file (#!/usr/bin/make -f
<fabrice_sp>                %:
<fabrice_sp>                        dh $@)
<fabrice_sp> arghh: bad paste
<ScottL> i know which one you are trying to show
<fabrice_sp> and if you ,iss something, uses override_<what you need>
<ScottL> I did try that last night with the zynjacku but it didn't work
<ScottL> I've been reading the FSF gnu make book and I need to devote the time to really understand a large percentage of the dh scripts
<fabrice_sp> ScottL, according to the actual rules files, it should work quite easily (it uses ./configure, make and make install )
<fabrice_sp> you miss perhaps some extra parameters
<ScottL> probably, i tried it very late last night and was a bit fuzzy in the head to dry to problem solve, i'll try again later
<ScottL> s/dry/try
<fabrice_sp> if you can try now,  we can help you looking after the errors
<ScottL_> okay, but I have very limited time (really should be cleaning up for daughter's 8th birthday/sleep over party)
<ScottL_> okay, i run debuild -S and:    debian/rules:3: *** missing separator.  Stop.
<ScottL_> hmmm, I guess I should revisit what i put into the rules file :/
<fabrice_sp> and uses tabs ;-)
<ScottL_> blimey, you beat me to it...yes, it was the tab
<ScottL_> i compared to /usr/share/doc/debhelper/tiny    but I thought that I had copied it from there last night, perhaps not
<ScottL_> so basically for all rules there are no targets and it runs dh clean, dh build, dh *  as called
<ScottL_> debuild -S works now again   :)
<ScottL_> and building again in pbuilder
<ScottL_> but fabrice_sp, how can I pass arguments?   directories and the like?
<ScottL_> nevermind, I think this page I found last night (told you it was late) probably has the information   http://kitenet.net/~joey/blog/entry/cdbs_killer___40__design_phase__41__/
<Quintasan> hmm, fabrice_sp, shouldn't pbzip2 provide some sort file for update-alternatives?
<fabrice_sp> Quintasan, not sure what is the context of the question :-D
<Quintasan> fabrice_sp: well pbzip2 is obviously faster with mulicore processors and it should be available to choose as an alternative to standard bzip2
<fabrice_sp> Quintasan, sounds logical, yes
<Quintasan> well, just a test case, pbzip2 took 7 seconds to zip a 234mb text file and normal bzip almost 20 :P
<cody-somerville> Quintasan, absolutely not
<fabrice_sp> wouah!
<Quintasan> oh
<fabrice_sp> cody-somerville, why?
<Quintasan> cody-somerville: why not?
<fabrice_sp> :-D
<cody-somerville> Thats not how alternatives are supposed to be used.
<Quintasan> cody-somerville: hm?
 * fabrice_sp is learning something new
<Quintasan> I though if we provide an alternative in kubuntu-artwork-usplash or unrar & unrar-nonfree we could do something like this for pbzip2
<cody-somerville> Yes and that would be wrong
<cody-somerville> and cause breakage
<Quintasan> why so?
<cody-somerville> They take different command line options
<Quintasan> uhh, right, I did not consider that
<Quintasan> -_-
 * Quintasan feels bit stupid now
<jmarsden> Quintasan: If you really want to, writing a wrapper script to map the bzip2 options to pbzip2 and using the wrapper as the alternative might be worth a look.
<Odd-rationale> Is using the CDBS the recommended way of packaging python modules? From what I've read on the wiki, there seems to be a couple other ways, but I cannot find much information about them.
<ScottK> Odd-rationale: For a python module that uses distutils it's an easy way to do it, but currently using debhelper is recommended.  WIth debhelper 7 rules.tiny it's just as easy and technically better.
<Odd-rationale> ScottK: ok thanks. I'm kind of new to ubuntu packaging. So I'm experimenting around...
<ScottK> Odd-rationale: If you are interested in packaging Python modules I recommend joining #debian-python on OFTC and working with that team (it has a lot of Ubuntu participation) to get your package into Debian (and sync'ed to Ubuntu from there)
<Odd-rationale> ok.
<ScottK> They are also willing to help people who are new and just learning.
<Odd-rationale> so if i want to use dh7, i should call dh_make without the -b option?
<hyperair> if you want to use dh7, you run without -b and then get rid of the debian/rules file and start afresh
<ScottK> Odd-rationale: I'd start with a working package as a template and use that.
<ScottK> Odd-rationale: I'll suggest my python-ipaddr package for one.
<fabrice_sp> how is that a package in testing since the 16th of January is not yet in Ubuntu? It's libmoosex-types-common-perl
<fabrice_sp> No 'autosync' since the 16th?
<ScottK> fabrice_sp: Normal autosync and new package sync are two different archive admin actions.
<fabrice_sp> ohh
<ScottK> Also new packages need to go through source and binary New in Ubuntu.
<fabrice_sp> I thought autosync was sync existing and new packages
<ScottK> So "How" is lots of possibilities.
<ScottK> Nope.
<fabrice_sp> ok
<Odd-rationale> hyperair, ScottK: thanks!
<Odd-rationale> ScottK: is your python-ipaddr in the repositories?
<Odd-rationale> so i can apt-get source it?
<ScottK> Odd-rationale: Yes.  In lucid
<Odd-rationale> ScottK: oh, ok...
<randomaction> fabrice_sp: are you planning to make any uploads of aqsis? If not I'll rebuild it for boost 1.40 (it's uninstallable in lucid now)
<fabrice_sp> randomaction, no: no new version in the short term.
<fabrice_sp> thanks for taking care of it ;-)
<Odd-rationale> ScottK: Thanks for all your help! Would you be willing to take a look at my package and offer some feedback? or is there a way to get someone to show me if I was doing it correctly? Thanks again!
<ockham> hi, i'd like to announce my first package: http://revu.ubuntuwire.com/p/pysolfc
<ockham> (and my second one: http://revu.ubuntuwire.com/p/pysolfc-cardsets :-)
<blueyed> Why am I getting conflicts with "bzr merge-upstream" in debian/* ? e.g. in debian/control.. where does "merge source" come from?
<blueyed> james_w: ^^
<Odd-rationale> What does it mean by "The changelog does not close a bug from Launchpad."?
<Quintasan> Odd-rationale: you are doing a new package?
<Odd-rationale> Quintasan: yes. I am learning how.
<Quintasan> Odd-rationale: okay, every new package should close a bug from Launchpad
<Quintasan> Odd-rationale: please file a bug on launchpad - [needs-packaging] <your package name> and assign yourself to it
<Quintasan> Odd-rationale: then in changelog you should add (Closes LP: #<your bug number>)
<Odd-rationale> Quintasan: ok. do i file it under ubuntu?
<Quintasan> Odd-rationale: yes
<Quintasan> Odd-rationale: https://wiki.ubuntu.com/PackagingGuide/Complete
<Quintasan> You will use it very often :)
<Odd-rationale> Quintasan: yes. i've been reading that. very helpful doc.
<Odd-rationale> Is there a way to search within all needs-packaging bugs for a string?
#ubuntu-motu 2010-01-31
<micahg> Odd-rationale: bughugger?, Adavanced search?
<jetienne> q. i would like to setup a small repository, it will be like 3-4 deb in there. easyness to setup is important. where should i look ?
<jmarsden> jetienne: http://wiki.debian.org/HowToSetupADebianRepository
<jetienne> jmarsden: any suggestion on a easy way ?
<jmarsden> jetienne: It all depends on what you mean by easy.  mini-dinstall, maybe?
<jetienne> jmarsden: ok thanks will look
<jmarsden> You're welcome.
<jetienne> jmarsden: additionnaly i got this script doing a .deb which im trying to port, do you have a good link on the meaning of all the files in debian/* ?
<jmarsden> The New Maintainers Guide, and man debhelper
<jetienne> htx
<jmarsden> You're welcome.
<jmarsden> jetienne: For basic packaging info for Ubuntu, see https://wiki.ubuntu.com/PackagingGuide/Complete   # but if you are here you probably already know this :)
<hakaishi> Hello everyone! Anyone up to advocate/review qt-shutdown-p? - I corrected the desktop file, the copyright file and the docs file as jcfp asked. I think there shouldn't be any more issues. http://revu.ubuntuwire.com/p/qt-shutdown-p
<gnomefreak> anyone wish ideas on what package i would file bug agsinst for my backspace not working correctly. You can no long hold down backspace you have to hit it one time pre letter/number
<gnomefreak> s/wish/with
<geser> gnomefreak: known bug, System -> Preferences -> Keyboard, re-enable "Repeat Keys" (and don't let the "Delay" slider on its minimum value if you don't want each key press twice)
<gnomefreak> geser: thanks ill take a look at that
<gnomefreak> geser under general  repeat keys with it enabled and slider about halfway it still doesnt let me use any key by holding it down am i in right place?
<gnomefreak> ah i got it
<gnomefreak> thanks geser
<dupondje> http://packages.ubuntu.com/lucid/sabnzbdplus => any idea why it needs python less then 2.6 ?
<dupondje> in control file there is nothing about that ...
<geser> look at debian/pyversions
<dupondje> hmz, there are the versions that are supported ?
<geser> yes
<fabrice_sp> dupondje, also look inside the .py files: sometime, some python2.5 is referenced
<dupondje> yep saw that already :)
<fabrice_sp> :-D
<dupondje> but in pyversions you can put for example 2.5 and 2.6 ?
<dupondje> but why does it conflicts 2.6, should it just allow existence of 2.6 ? and use 2.5 ?
<om26er> I am getting this error while building http://pastebin.org/84545
<randomaction> om26er: looks like your orig.tar.gz is broken
<om26er> randomaction, I tried it twice
<om26er> ahh I made a mistake.. randomaction thanx I found it
<geser> slytherin: are you working on merging libpdfbox-java? it could get moved to universe after the merge
<slytherin> geser: Not as of now. But I believe the Ubuntu changes should be merged in Debian.
<geser> ok, will look later at it in detail and either merge or sync
<shriekout> http://revu.ubuntuwire.com/p/happytimer
<shriekout> please, advice...
<om26er> sorry got disconnected. was I answered?
<slytherin> om26er: no
<om26er> slytherin, I don't have headers installed can that somehow be related?
<slytherin> om26er: I was not part of previous conversation. So I don't know what you are talking about.
<om26er> slytherin, http://pastebin.org/84550
<slytherin> om26er: what are you trying to do exactly?
<om26er> slytherin, I am building gparted from scratch and get the error
<om26er> *following the packaging guide
<slytherin> om26er: So did you create the source package form scratch?
<om26er> slytherin, yes
<slytherin> om26er: In that case looks like the build dependencies are not correct.
<om26er> sudo apt-get build-dep gparted?
<slytherin> om26er: You are using pbuilder. apt-get build-dep is for building package without pbuilder
<slytherin> om26er: check the build dependencies specified in debian/control file of your package
<om26er> slytherin, Build-Depends: debhelper (>= 7), autotools-dev
<slytherin> om26er: that is certainly not sufficient
<slytherin> take a look at current gparted source package.
<om26er> slytherin, also Depends: ${shlibs:Depends}, ${misc:Depends}
<om26er> slytherin, the one from universe?
<slytherin> I believe gparted is in main
<om26er> slytherin, everything is installed already
<slytherin> om26er: You are not getting. The build dependencies you have specified in debian/control file are not sufficient to build gparted. Compare it to the official package.
<om26er> slytherin, yes. I downloaded the source through sudo apt-get source gparted and the control file in it has many other dependencies and I tried to install all of them and they are already installed
<slytherin> and does the package you created have same build dependencies?
<slytherin> I mean the one you are trying to build from scratch.
<randomaction> om26er: the dependencies you installed don't matter, because you are using pbuilder
<randomaction> pbuilder examines debian/control and installs exactly what's listed there in a chroot
<randomaction> line 297 shows a missing dependency
<om26er> what is that?
<om26er> configure:21700: error: XML::Parser perl module is required for intltool
<dupondje> geser fabrice_sp: why does sabnzbplus refuse to install when python2.6 is installed? Shouldn't it just use 2.5 and ignore install of 2.6 ?
<geser> dupondje: because it depends on python << 2.6
<geser> python being the package installing the default python version
<dupondje> geser: in the depend list there is python >= 2.5
<geser> Depends: python (<< 2.6), python (>= 2.5), [...]
<dupondje> not in the control file ?!
<geser> but in the resulting deb
<dupondje> yep thats true, but what causes the python << 2.6 ?
<geser> the value in debian/pyversions
<geser> it tells that the package "works" only with python 2.5
<geser> so the builds sets the depends that this is ensured
<tim> hi, how can i used debuild to include the original source for a ppa upload?
<geser> debuild -S -sa
<tim> geser, thanks, that is, what i was looking for
<dupondje> geser: so if the application doesn't work with python2.6, its unable to make a package that works for 2.5 only ?
<om26er> is there any alternative to pbuilder?
<geser> dupondje: do you know that it doesn't work with python2.6?
<geser> om26er: there is also sbuild. what's wrong with pbuilder?
<om26er> geser, it dont build for me
<geser> then it's probably a bug in your package
<randomaction> om26er: it's not pbuilder's fault
<om26er> geser, two different packages
<dupondje> geser: asked the developpers of sabnzbdplus, and they confirm it doesn't work on 2.6
<monkeylibre> join ubuntu-devel
<monkeylibre> sorry
<geser> try asking in #debian-python on OFTC, as I'm not very uptodate on python packaging. Debian will have the same problem once they make python 2.6 default
<dupondje> geser: http://packages.debian.org/nl/squeeze/sabnzbdplus doesn't seem to conflict with 2.6 here :s
<geser> ah, right it has a dependency on python2.5
<geser> so you need to find out which part of our delta causes this different dependencies compared to Debian and if needs to be undone
<dupondje> http://launchpadlibrarian.net/38341487/sabnzbdplus_0.4.12-1_0.4.12-1ubuntu1.diff.gz
<dupondje> this is the diff :)
<dupondje> it should depend on python2.5 instead of python >= 2.5 ?
<ari-tczew> fabrice_sp: ping bug 428860
<ubottu> Launchpad bug 428860 in gnome-main-menu "Please sync gnome-main-menu 0.9.13-3 (universe) from Debian unstable (main)" [Undecided,Fix released] https://launchpad.net/bugs/428860
<bdrung> ari-tczew: do you take bug 428860?
<ubottu> Launchpad bug 428860 in gnome-main-menu "Please sync gnome-main-menu 0.9.13-3 (universe) from Debian unstable (main)" [Undecided,Fix released] https://launchpad.net/bugs/428860
<monkeylibre> necesitas: Xine Plugin
<dupondje> dh_pysupport -i -V2.5
<dupondje> dh_pysupport: Unknown python version 2.5
<dupondje> hmz :s
<ari-tczew> bdrung, what do you mean "take bug"?
<bdrung> ari-tczew: take for sponsoring
<ari-tczew> I'm not sponsor :>
<ari-tczew> bdrung, you can take bug 428860 if you want
<ubottu> Launchpad bug 428860 in gnome-main-menu "Please sync gnome-main-menu 0.9.13-3 (universe) from Debian unstable (main)" [Undecided,Fix released] https://launchpad.net/bugs/428860
<dupondje> dh_pysupport: Unknown python version 2.5 => really no idea why :(
<geser> I assume because pyversions doesn't list it anymore as supported
<aboSamoor> how can I ask for packaging sagemath for the latest version 3.4.1, while the one available is 3.0.5dfsg-4ubuntu1
<ari-tczew> aboSamoor, I think that the best way of new upstream release is request to Debian Maintainer
<ari-tczew> aboSamoor, please look at bug 510521
<ubottu> Launchpad bug 510521 in sagemath "Please remove sagemath source and binary from lucid" [Medium,Confirmed] https://launchpad.net/bugs/510521
<ari-tczew> Debian Maintainer is working on new upstream release for Debian, but if he don't do this before final release of lucid, sagemath is going to /dev/null
<directhex> you could help
<directhex> afaik it's a tough packaging job
<ari-tczew> directhex, who could help?
<directhex> ari-tczew, aboSamoor
<aboSamoor> directhex, I always wanter to help at least with smaller packages. I sent an email to motu mail list and none even replied
<fabrice_sp> ari-tczew, pong
<fabrice_sp> what do you want on bug 428860 ?
<ubottu> Launchpad bug 428860 in gnome-main-menu "Please sync gnome-main-menu 0.9.13-3 (universe) from Debian unstable (main)" [Undecided,Fix released] https://launchpad.net/bugs/428860
<ari-tczew> fabrice_sp: I want to have ACK for sync.
<fabrice_sp> ok. I'll check it
<fabrice_sp> why are you so interested in syncing this package? (just curiousity :-D )
<directhex> gnome-main-menu is "slab", right?
<ari-tczew> caprice
<fabrice_sp> ;-)
<ari-tczew> I'm contributting to Ubuntu, just only that.
<fabrice_sp> I thought it was becasue actual version is buggy
<ari-tczew> so do you not ACK this?
<fabrice_sp> no: I was trying ot understand your motivation
<fabrice_sp> (I'm com,paring the debian directory, and the patches are different, so I have to check source code :-/ )
<fabrice_sp> meaning: it will takes time
<ari-tczew> not only me want to get new upsteram version in Ubuntu
<ari-tczew> JAK too
<ari-tczew> 0.9.12 is too old
<ari-tczew> deprecated
<fabrice_sp> libslab is packaged indepently now, right?
<ari-tczew> right
<fabrice_sp> ok
<ari-tczew> https://launchpad.net/ubuntu/+source/libslab
<slytherin> any autotools experts here?
<slytherin> I need help to find root cause of this error - checking for working iconv... no
<ari-tczew> propably your package needs some depends in debian/control
<slytherin> No. This has nothing to do with packaging. I am trying fix windows build for my own application.
<DktrKranz> geser, ari-tczew: green light for gpsd sync (I commented on the bug to check rdeps too, as some could require some love)
<segler> hi, I am searching for a second advocate for my rhythmbox plugin, please. http://revu.ubuntuwire.com/p/rhythmbox-radio-browser
<segler> hi, I am searching for a second advocate for my rhythmbox plugin, please. http://revu.ubuntuwire.com/p/rhythmbox-radio-browser
<dupondje> somebody has experience on packaging python things ? :)
<fabrice_sp> dupondje, did you tried  #debian-python on OFTC ?
<dupondje> fabrice_sp: but the thing is that its quite ubuntu specific, as only ubuntu has 2.5 as oldversion ...
<fabrice_sp> dupondje, Debian is trying to make the transition to python 2.6, and a lot of people there are Ubuntu guys
<randomaction> dupondje: they actively encourage Ubuntu people to participate
<geser> dupondje: there are also ubuntu people in #debian-python and it would be good to have a solution that doesn't cause us problems later, so talk to them
<dupondje> is python2.5 going to be removed ?
<dupondje> or ?
<slytherin> dupondje: yes in lucid
<dupondje> oh ok :) then sabnzbdplus is broken in lucid :(
<dupondje> damn :)
<fabrice_sp> slytherin, removed from the archive? I thought it that packages will not be built, but python2.5 willstill be there
<slytherin> I think we have already gone through one cycle in that situation. So I believe 2.5 will be dropped completely.
<fabrice_sp> python2.4 is still there atm :-/
<dupondje> https://bugs.launchpad.net/ubuntu/+source/sabnzbdplus/+bug/515223
<ubottu> Ubuntu bug 515223 in sabnzbdplus "sabnzbdplus is broken in lucid as it needs python2.5" [Undecided,New]
<devfil> ascoltata?
<devfil> sorry wrong chan :P
<rbelem> hi everybody
<rbelem> what is the procedure to get the most recent version of a software in the repos?
<Quintasan> rbelem: for general support please go to #ubuntu -> as for your question
<Quintasan> sudo apt-get update
<Quintasan> sudo apt-get upgrade
<rbelem> Quintasan, i want to upgrade one package that is outdated in the ubuntu repos
<rbelem> :-)
<Quintasan> oh
<Quintasan> rbelem: you want source then
<Quintasan> rbelem: apt-get source <packagename>
<Quintasan> rbelem: https://wiki.kubuntu.org/PackagingGuide/Basic
<Odd-rationale> I've been working on my first package. I'm not sure I did everything correctly. If I would like some feedback, should I post the REVU link here? Thanks!
<Quintasan> rbelem: sorry, wrong link -> https://wiki.kubuntu.org/PackagingGuide/Complete#Updating%20an%20Ubuntu%20Package
<Quintasan> Odd-rationale: yes
<Quintasan> I have some time to spare so I can look at it now
<Odd-rationale> Here it is. http://revu.ubuntuwire.com/p/python-nltk thank you so much!
<rbelem> Quintasan, but what is the procedure to get it reviewed and uploaded to the repos? revu is the right place for that? the package is already in the repos http://packages.ubuntu.com/search?keywords=usb-modeswitch
<rbelem> and already in debian
<Quintasan> rbelem: newer version is in debian?
<rbelem> nope
<Quintasan> rbelem: oh, did you contact the package maintainer in Debian?
<Quintasan> rbelem: if he/she did release new package in Debain please file a sync
<rbelem> Quintasan, cool
<kklimonda> actually there is 1.1.0 in debian sid
<Quintasan> if not you can ask if she/he wants help
<rbelem> kklimonda, i think it is 1.0.7-1 in debian
<Odd-rationale> brb
<kklimonda> rbelem, depends on architecture - there is 1.1.0-2 for the popular ones
<Quintasan> Odd-rationale: did you test it with pbuilder?
<rbelem> Quintasan, it would be nice to have in the motu wiki a procedure to ask for a package upgrade if it is already in ubuntu and debian and both are outdated
<kklimonda> debian package isn't oudated though
<Quintasan> rbelem: well you can file a bug REQUESTING that or you can update it yourself
<kklimonda> rbelem, and you can always request a simple update
<rbelem> kklimonda, i'm just getting 1.0.7-1 http://packages.debian.org/sid/usb-modeswitch
<Quintasan> Odd-rationale: ./nltk/stem/porter.py is under GPL-2+
<Quintasan> Odd-rationale: you need to mention it in copyright, overall good :)
<kklimonda> rbelem, I get 1.1.0-2
<randomaction> rbelem: http://packages.qa.debian.org/u/usb-modeswitch.html
<rbelem> kklimonda, what do you mean by simple update?
<Quintasan> Odd-rationale: add the missing licesne entry, reupload and I will advocate your package
<Quintasan> Odd-rationale: You need at least two advocates to get it uploaded though
<rbelem> randomaction, ah! cool!
<kklimonda> rbelem, instead of merging or syncing with debian you can request a package update to the newer version.
<rbelem> kklimonda, just file a bug in launchpad asking for an update then?
<rbelem> thanks randomaction for the link
<kklimonda> rbelem, yes - and even better you can prepare update yourself and ask for motu to sponsor it
<rbelem> kklimonda, cool! and upload to revu?
<kklimonda> rbelem, no - you prepare a debdiff and attach it to the bugreport
<kklimonda> (a debdiff is just a diff of debian source package)
<rbelem> kklimonda, cool!
<rbelem> thanks kklimonda for the clarification :-)
<kklimonda> rbelem, you can read more about the process here: https://wiki.ubuntu.com/SponsorshipProcess
<Odd-rationale> Quintasan: Thanks! Do I add the other licence at the end of the copyright file?
<randomaction> rbelem: in case of usb-modeswitch 1.1.0, it *may* get into lucid automatically: it will move into testing in 10 days at the earliest, and automatic sync from testing end on Feb 11th
<Quintasan> Odd-rationale: I belive you can do it like
<Quintasan> ./nltk/stem/porter.py
<Quintasan> argh
<Quintasan> sorry
<Quintasan> ./nltk/stem/porter.py: GPL v2 or later
<Quintasan> under the main license
<randomaction> rbelem: it's really close, so see https://wiki.ubuntu.com/SyncRequestProcess for how to request a manual sync
<Odd-rationale> Quintasan: something like this? http://paste.ubuntu.com/366421/
<Odd-rationale> Quintasan: i added line 15 and 34
<Quintasan> Odd-rationale: http://paste.ubuntu.com/366422/
<Quintasan> Odd-rationale: that should do
<Odd-rationale> Quintasan: ok. should I also remove the last two lines as well?
<Quintasan> Odd-rationale: yes
<Quintasan> Odd-rationale: and PROTIP from me: as you do new packages you should go to source dir and do - licensecheck -r .
<Quintasan> Odd-rationale: remember the dot at the end of command
<Quintasan> Odd-rationale: it recursively scans through the source dir and looks for licenses :)
<Odd-rationale> OK. cool!
<Odd-rationale> also, what is the difference between 'dpkg-buildpackage -S -sa' and 'debuild -S -sa' ?
<Quintasan> can't really say, never used dpkg-buildpackage -S -sa
<randomaction> Odd-rationale: man debuild :)
<Odd-rationale> what do you use?
<Odd-rationale> randomaction: ok. so debuild runs dpkg-buildpackage.
<randomaction> and a couple of other things
<Odd-rationale> hmm. funny thing is, if i use debuild, i get "bad-ubuntu-distribution-in-changes-file lucid". but it works fine with dpkg-buildpackage...
<randomaction> because it's a message from lintian
<randomaction> which is run by debuild
<Odd-rationale> it is ok to ignore if i want to build for lucid?
<randomaction> lintian in karmic is a bit outdated, that's why you get it
<Odd-rationale> Quintasan: Alright. I reuploaded. Thanks for the help!
<Odd-rationale> Another question. This package is not in debian. Do I have to work to get it into debian? or is that automatically taken care of?
<Quintasan> Odd-rationale: well, you should make changes according to debian standards (probably not many changes from your ubuntu package) and ask in debian development channel what to do nex
<Quintasan> next*
<Quintasan> Odd-rationale: Debian channels are on irc.oftc.net
<rbelem> randomaction, cool! so i don't need to bothered about this :-)
<Odd-rationale> Quintasan: Is getting it into debian something that is required?
<Quintasan> Odd-rationale: no, but if someone in debian does the same package it will probably overwrite your work so you'd be better becoming Debian/Ubuntu maintainer of that package :)
<randomaction> Odd-rationale: https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers#Getting%20new%20software%20in%20Debian
<Odd-rationale> ok. i'll work on that. thanks for help.
<Odd-rationale> Sorry for asking so many questions, but what does it mean to "Create one symlink to pbuilder-dist-simple for  each  distribution"?
<kklimonda> Odd-rationale, you can use pbuilder-dist without it
<Odd-rationale> kklimonda: ok. but I don't even know what the above quote meant. I guess I don't need to? :)
<kklimonda> Odd-rationale, well - you have to check if package you are trying to upload to debian actually builds on debian system. pbuilder is one of the tools you can use to do it. but you don't really have to understand this single quote :)
<randomaction> it means create symlink "pbuilder-lucid" to "pbuilder-dist-simple", create symlink "pbuilder-karmic" to "pbuilder-dist-simple", and so on
<Odd-rationale> what does creating a symlink do?
<randomaction> you can use these symlinks to run pbuilder
<Odd-rationale> but if pbuilder-lucid and pbuilder-kamic are both symlinked to pbuilder-dist-simple, then how does it know to build for lucid or karmic?
<randomaction> I think it examines by which name you called it
<randomaction> in fact I wonder why a collection of symlinks is not supplied with the package
<Odd-rationale> so i just need to `ln -s /usr/bin/pbuilder-dist-simple /usr/bin/pbuilder-karmic` ?
<randomaction> I guess so (I don't use this feature)
<Odd-rationale> randomaction: oh, so how do you build for different ubuntu releases and debian?
<randomaction> or maybe better create this symlink in /usr/local/bin
<randomaction> pbuilder-dist lucid *.dsc; pbuilder-dist sid *.dsc
<Odd-rationale> is there any changes i need to make to my ~/.pbuilderrc file to do that?
<randomaction> I believe it's designed in such a way that you don't need to tune this config file
<Odd-rationale> randomaction: do you mind if i see your ~/.pbuilderrc?
<randomaction> I wouldn't recommend using mine, it's full of leftover stuff for jaunty and karmic
<Odd-rationale> ok. i just have one line: COMPONENTS="main restricted universe multiverse"
<Odd-rationale> is that ok?
<randomaction> it's ok if it works :)
<randomaction> in fact, I don't even know whether pbuilder-dist uses or overrides .pbuilderrc
<Odd-rationale> so 'sudo pbuilder' builds for my current distribution (karmic) and builds in /var/cache/pbuilder. and 'pbuilder-dist karmic' builds for karmic in ~/pbuilder. is that correct?
<randomaction> I believe that's their default behaviour
<Odd-rationale> to test building on debian, i should build for sid?
<randomaction> yes
<Odd-rationale> randomaction: how do you manage the different control and changelog files for different builds?
<randomaction> different branches in git-buildpackage
<Odd-rationale> I'm getting this strange error with pbuilder-dist: http://paste.ubuntu.com/366473/ However, it works fine with lucid.
<dupondje> I would recreate my pbuilder environment :)
<Odd-rationale> dupondje: you mean rerun pbuilder-dist <dist> create?
<dupondje> y
<Odd-rationale> k
<Quintasan> night
<james_w> kamalmostafa: you set https://code.launchpad.net/~kamalmostafa/ubuntu/lucid/inteltool/fix-508633-ftbfs/+merge/17535 to work in progress, does that mean I shouldn't review it yet?
<kamalmostafa> james_w: looking
<james_w> ah, I see you did it with a few
<james_w> hi btw
<kamalmostafa> james_w: okay I did it because of fabrice_sp's comment: https://bugs.launchpad.net/ubuntu/+source/inteltool/+bug/508633/comments/2
<ubottu> Ubuntu bug 508633 in inteltool "inteltool FTBFS on !x86 archs" [Undecided,Won't fix]
<james_w> oh
<james_w> how did I miss that?
<kamalmostafa> james_w: :-)  it still shows as FTBFS for the non x86 platforms I assume
<james_w> yah
<james_w> only a problem of filling up the ftbfs list really
<james_w> if the problem is filed in Debian then I'm not sure we should change it in Ubuntu directly
<kamalmostafa> james_w: well, you know me... always eager to clear some red boxes! ;-)
<james_w> :-)
<kamalmostafa> james_w: it has been filed in Debian for about 7 weeks (not long really) but that being said I don't know how actively the pkg is maintained upstream.  Whether you want to push my change just to clear the ftbfs's is up to you.
<james_w> hmm
<james_w> I'm not inclined to, though I haven't looked at the ftbfs list recently :-)
<kamalmostafa> oh, and yes, for other merge proposals that I've since "reverted" to work-in-progress -- they are likely similar situations -- merges that have been "put on hold" by MOTU's to see if Debian will take action first.  In general, I don't know how long we're inclined to wait -- but I'm glad to at least have those issues bug-reported here in Ubuntu.  Too bad we can't mark them as "ignore this" in the FTBFS list somehow.
#ubuntu-motu 2011-01-24
<ari-tczew> micahg, siretart: bug 706725
<ubottu> Launchpad bug 706725 in libgpg-error (Ubuntu) "Sync libgpg-error 1.10-0.2 (main) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/706725
<ari-tczew> mr_pouit: around?
<ari-tczew> if package has got changed binary package, is enough to change depends and b-d in rdepends? or replace/conflicts also is needed?
<persia> It depends entirely on what sort of binary package change happened.
<persia> Do you have an example?
<ari-tczew> hello persia
<ari-tczew> yes, example: http://paste.ubuntu.com/557454/
<ari-tczew> I'm reviewing one sync request which looks small, but it's require a lot of transitions due to some syncs from experimental.
<ari-tczew> looks like gigantic work
<persia> Ugh.
<persia> I generally dislike single source packages providing multiple libraries, and further dislike versioned -dev packages.
<persia> But if that's what you7re starting with, you'll also need to adjust the shlibs (and potentially symbols) files, so that things built against it end up with the right dependencies, and then probably rebuild (and likely port) all the rdepends.
 * micahg would suggest waiting for Debian to port the rdepends unless there's a pressing reason
<persia> Might be done.  Might be relatively easy to port (and Debian/Upstream would appreciate porting patches).
<persia> But, yeah, since we're past DIF, probably only worth it if there's some important change.
<ari-tczew> micahg, persia: mission failed. getting through the string to the ball, at the end I got: dh_makeshlibs: dpkg-gensymbols -plibgwengui-fox16-0 -Idebian/libgwengui-fox16-0.symbols -Pdebian/libgwengui-fox16-0 returned exit code 1
<ari-tczew> too much work
<persia> DId you update/change all the symbols files for all the libraries?
<ari-tczew> persia: I'm only building experimental packages on my pbuilder-natty.
<ari-tczew> FYI, bug 706645
<ubottu> Launchpad bug 706645 in gnucash (Ubuntu) "Sync gnucash 1:2.4.0-3 (universe) from Debian experimental (main)" [Undecided,Incomplete] https://launchpad.net/bugs/706645
<ari-tczew> I can imagine how much rebuilds and transitions will needs Ubuntu 11.10.
<ari-tczew> I guess that many libs and important software will be upgraded after Debian 6.0 release like perl 5.12, openssl 1.0
<ari-tczew> and viele viele mehr
<micahg> ari-tczew: if we can get stuff sync'd with unstable, most of it will happen automatically
<micahg> s/will/should/
<persia> Yeah.  Once Debian releases, we'll probably want to mostly cherrypick, rather than syncing for natty.
<micahg> yeah, I meant sync'd with pretransition versions :)
<ari-tczew> micahg: I wish that will be automatically. If it's true that Debian will be released in the 1st half of February, then they have a time to adjust archive since out next devel open - May - June.
<ari-tczew> s/out/our
<ari-tczew> does anybody know how long adjust toolchain is taking for Debian?
<ari-tczew> I;m asking due to curiosity.
<ari-tczew> micahg: btw. today reviewing libgpg-error is time-consuming for me. let alone about that much transitions as we've discussed some minutes ago!
<kklimonda> out of curiosity :)
 * kklimonda would love to have others point out his grammar mistakes more often.
<persia> "due to curiosity" is grammatical, if less common
 * micahg keeps that in mind :)
<kklimonda> persia: really?
<kklimonda> thanks, good to know
<ari-tczew> what's wrong?
<kklimonda> ari-tczew: nothing :)
<ari-tczew> ok
<kklimonda> persia: it can be used in the same context as "out of curiosity"?
<persia> I suppose.  It isn't usually.
<ari-tczew> out of curiosity = 0 curiosity
<ari-tczew> due to curiosity = a lot of curiosity :>
 * ari-tczew feels pretty sick. :-/
<micahg> ari-tczew: no, out of curiosity means that curiosity exists, basically the same thing as due to curiosity colloquially
<persia> kklimonda, "Colorless green ideas sleep furiously" is grammatical as well: don't fall into the trap that everything grammatical is good: usage is important.
<kklimonda> persia: I missed you :)
<persia> http://en.wikipedia.org/wiki/Colorless_green_ideas_sleep_furiously
<RAOF> persia: So, what we need is a language where only correct statements are grammatical :)
<ari-tczew> micahg: OK kklimonda explained me via PM about special case for "out of curiosity"
<ari-tczew> bdrung: why kubuntu.org is not supported by update-maintainer?
<persia> Because the packages *should* all have "Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>" as the maintainer, which doesn't include that string.  Anything else encourages separatism.
<ari-tczew> persia: maintainer with @ubuntu.com is wrong?
<persia> It's suboptimal.  Anything other than the string above implies that that package should only be modified by some subset team, rather than all developers.
<persia> This is an exclusionary statement, something we try to avoid.
<kklimonda> oh great, looks like libevent transition is going to be a pure joy
<kklimonda> the 2.0.10 version have a versioned library, but puts headers in the same location as 1.4.x..
<RAOF> That sounds pretty standard.
<kklimonda> RAOF: but now we can't really update libevent to 2.0.10 until all applications that are using 1.4.x aren't ported, right?
<RAOF> Yes.
<Rcart> Hello everyone. Which deb3 fields are more common used in a patch?
<kklimonda> RAOF: well, that doesn't sound standard to me.. and to think that just few months back I was asking why are gtk headers versioned.. :)
<paultag> Rcart: deb3 or dep3 ?
<Rcart> paultag: Sorry, dep3 (:
<RAOF> kklimonda: It's what often happens, which makes it fairly standard :)
<paultag> Rcart: :)
<paultag> Rcart: what ever feels right. There are some that make sense, others that really would only apply to stuff such as the linux project
<paultag> Rcart: I use different tags ( most the time ) then others because of my workflow
<paultag> Rcart: it's status upstream, description and author are usually common
<kklimonda> I use Description, Origin, Forwarded (if Origin != upstream) and Bug-(Debian|Ubuntu)
<paultag> +1
<paultag> today was a great day. I got rid of most of my patches :)
<paultag> God, I hate patches so much. They just fester and clot up the code base
<Rcart> Ok, thanks paultag and kklimonda :)
<paultag> good luck Rcart!
<ari-tczew> I know why Rcart is asking about DEP3 :)
<paultag> ari-tczew: yeah?
<Rcart> ari-tczew: o/
<ari-tczew> paultag: IIRC I suggested him to add to his patch.
<ari-tczew> Rcart: hello
<paultag> ari-tczew: ah. gotcha
<Rcart> ari-tczew: i'm working to update the branch, but found right now that there's a bug report and a patch upstream: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593653
<ari-tczew> Rcart: is it the same as yours?
<Rcart> No, looks better
<ari-tczew> Rcart: OK then it's fine. You can exchange patch and in Origin tag put link to comment where you found patch
<kklimonda> RAOF: assuming that libeven API hasn't changed (which is apparently the case) is it early enough to start the transition for natty? rdepends are http://paste.ubuntu.com/557486/
<ari-tczew> how can I delete package from REVU? I found asterisk since asterisk exists in our and Debian archive already.
 * ari-tczew has got an idea to clean up REVU after Debian release.
<RAOF> kklimonda: If the API hasn't changed then it's simply a rebuild for all rdepends; that list looks nicely leafy.
<Rcart> ari-tczew: You mean import the upstream patch, apply it and update the branch, right? Now i got about dep3 tag :)
<ari-tczew> Rcart: yes
<RAOF> kklimonda: I'd check if everything on that list builds correctly; if so, I'd consider it early enough for the upgrade.
<kklimonda> RAOF: yes, that's what I'm planning on doing :)
<persia> ari-tczew, The general practice is just to archive anything already in the archives.
<Rcart> ari-tczew: Thanks, working on it.
 * ari-tczew is off to bed.
<kklimonda> directhex: any idea why banshee uses twice as much cpu as rhythmbox?
<kklimonda> directhex: while playing music
<siretart> bdrung: thanks for noticing. Yes, your suggestion makes sense to me, feel free to adjust the recipie, it belongs to the motumedia team
<sagaci_> test
<Rcart> Hi!. I'm importing a patch from upstream and i'm gonna include a dep3 tag to the patch. If i include the Bug field, this most point to the launchpad bug report, and the Bug-Debian to, obviously, the debian bug report, right?
<broder> Rcart: no, Bug is the upstream bug tracker. Bug-Ubuntu would be for the launchpad bug
<broder> err, that is assuming that upstream isn't using launchpad for bugtracking itself...
<Rcart> broder: Great, thanks (;
<Rcart> broder: Would please give a look to the patch's tag? http://pastebin.com/0WHkwHS3
<broder> Rcart: the debian bts isn't upstream for bittornado, is it?
<broder> Rcart: also, there should be an empty line separating the dep-3 block and the actual patch
<Rcart> broder: No, is not. So the field mos be: Bug-Debian, right?
<broder> Rcart: right
<broder> Rcart: also, your origin tag isn't very specific - something like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593653#17 would be better (since it references the specific message - i assume that's the specific message)
<Rcart> broder: Your're right :)
<Rcart> broder: http://pastebin.com/BA1kgDQX
<broder> Rcart: that's fine, though it would be nice if you used some of the other optional tags that apply, like author and forwarded (even better is if you actually forward it)
<broder> Rcart: but i need to go to bed now. i'm sure anybody else would be happy to assist if you need any further help
<Rcart> broder: thanks a lot :)
<dholbach> good morning
<AnAnt> Hello
<AnAnt> why didn't I get this FTBFS http://launchpadlibrarian.net/62702256/buildlog_ubuntu-natty-i386.libgwenhywfar_4.0.3-1_FAILEDTOBUILD.txt.gz on maverick ?
<AnAnt> nor on Debian experimental
<RAOF> AnAnt: So, it's failing because one of the symbols in went away.  Being C++, that *could* be due to something changing elsewhere in the toolchain.
<AnAnt> gcc 4.5 ?
<AnAnt> RAOF: so, what should be fixed ?
<AnAnt> RAOF: shall I edit the symbols file & reupload , or the fix should actually be somewhere else ?
<tumbleweed> AnAnt: it's a destructor, probably not important, I'd guess you can make it optional and avoid a soname bump
<AnAnt> tumbleweed: what do you mean by "make it optional" ?
<tumbleweed> AnAnt: see dpkg-gensymbols(1). Btw c++filt is very handy for demangling C++ symbols
<AnAnt> thanks
<AnAnt> tumbleweed: but why did that symbols dissappear on natty, but not on maverick nor experimental ?
<kklimonda> hmm, when I prepare a full branch for a merge should I leave release as UNRELEASED or change it?
<tumbleweed> AnAnt: different gcc version, I'd assume
<tumbleweed> kklimonda: if it's a merge, you might as well change it. If it's a shared packaging branch, UNRELEASED seems sensible, as you don't want a confusing changelog after a rejected review
<AnAnt> tumbleweed: how about using the c++ tag ?
<kklimonda> tumbleweed: thanks
<tumbleweed> AnAnt: if you are the debian maintainer, it's useful, as you can use it instead of mangled symbols in the symbols file. But it doesn't help you here at all
<ari-tczew> wrrrrrrrrrrrrrrrrr
<ari-tczew> what da f**
<ari-tczew> https://launchpad.net/ubuntu/+source/gnucash/1:2.4.0-3
<ari-tczew> we have discussion in the night about that
<ari-tczew> AnAnt - facepalm!!! if you read this
<ari-tczew> this is gigantic transition
<ari-tczew> he uploaded packages from experimental without testing before - https://launchpad.net/ubuntu/+source/libgwenhywfar/+changelog
<ari-tczew> shameful
<ari-tczew> he should lost his upload access
<Laney> maybe he wants to handle the transition
<Rhonda> !language | ari-tczew
<ubottu> ari-tczew: Please watch your language and topic to help keep this channel family-friendly, polite, and professional.
<geser> ari-tczew: where did the discussion happen? I see only a discussion about the symbol issue in my scrollback for this channel
<ari-tczew> Laney: looking on his activities, I dount
<ari-tczew> doubt*
<jpds> Oh well, people should use homebank anyway.
<ari-tczew> geser: http://paste.ubuntu.com/557610/
<ari-tczew> sync gnucash requires sync 2 B-D from experimental and then do transitions. it's clear to understand in above log.
<kklimonda> argh, 4 packages ftbfs with libevent2, one of them being developed by the author of libevent himself..
<kklimonda> good morning
<ari-tczew> hello kklimonda
<geser> ari-tczew: so AnAnt wasn't involved in this discussion but missed reading the bug about the sync before using syncpackage?
<ari-tczew> geser: yes, he didn't read sync request for gnucash - again, shameful
<Rhonda> It looks like there might be a rush of new stuff into Debian testing in march/april going on. I fear that's too late for natty, is it?
<ari-tczew> I'm writing e-mail to DMB - Cc to TB since there is only bdrung in DMB
<kklimonda> Rhonda: yeah, the feature freeze is at the end of february
<ari-tczew> Rhonda: as clarified in log, we are after DIF and that big transitions are too hard to do
<Rhonda> kklimonda: hmm, that might enable at least a bit of flow
<soren> jpds: Some of us have *actual* accounting to do, you know :)
<jpds> soren: Yeah; me too.
<Rhonda> Ah, reminds me that I should do a syncrequest for pgadmin3 again, from experimental :)
<Rhonda> ari-tczew: Depends on point of view and what one is willing to invest. But we have been through the willingness of investment before, so â¦
<soren> jpds: No support for currencies (let alone multiple currencies), it doesn't seem to even have the concept of expense and income accounts..
<Rhonda> So I guess after I finished the job for the squeeze release I'll put special attention in good sync candidates.
<soren> jpds: Does it even do double-entry book keeping?
<ari-tczew> Rhonda: 1) Didn't check bug before use syncpackage.   2) Didn't test build before uploading - twice!   3) Guess that didn't consider about transitions needed.
<geser> ari-tczew: do you know how many packages are involved in this transition?
<Rhonda> ari-tczew: I can understand that. But your tone isn't really helpful nor in accordance with CoC, there's no need to swear, even if *ed out.
<ari-tczew> geser: I checked in the night - more than 10 IIRC.
<chrisccoulson_> how do you know he didn't consider the transition needed? it's not that many packages....
<chrisccoulson_> and not reading a comment on a bug against another package is hardly "shameful", as you put it
<chrisccoulson_> i think you're over-reacting a bit
<ari-tczew> chrisccoulson_: well, I guess as he didn't test build and didn't check difference between packages synced from experimental.
<ari-tczew> even if it's sync, developer should check debdiff between dscs
<bdrung> ari-tczew: how do you know that he didn't do a build test? sometimes a package builds locally, but fails in the archive.
<ari-tczew> bdrung: built not locally
<ari-tczew> because I was checking sync request
<bdrung> ari-tczew: i assumes it two times that someone didn't build the package before uploading, but in both cases they did and i worked for them for different reasons.
<bdrung> ari-tczew: that's why i prefer to ask the people before judging them.
<chrisccoulson_> indeed :-)
<bdrung> ari-tczew: the old rule of presumption of innocence
<ari-tczew> bdrung: I'm 90% sure that he didn't test build and he will tell you that he did test build, because won't admit to the error. naivete!
<bdrung> ari-tczew: did he lied before or why are you sure that he will lie?
<dholbach> ari-tczew, I think before you start complaining about somebody, you should take the time to get in touch with them and in a very calm way ask what their actual plan was
<dholbach> I agree with bdrung that it's a good idea to first assume some kind of misunderstanding or maybe hear more about the motives/plan behind some move
<tumbleweed> especially if you actually want to resolve the situation rather than getting everyone's backs up
<dholbach> ari-tczew, I'm a bit concerned that your first reaction is to "report the person to the TB/DMB/whoever" before having talked to them
<ari-tczew> wait, 10 minutes
<ari-tczew> I''ll have interesting log
<dholbach> ari-tczew, this is not about proving that you were right right from the start
<dholbach> I'm talking about calming down, assuming some kind of misunderstanding in the interest of keeping a good atmosphere AND solving the problem
<dholbach> I personally did many mistakes regarding Ubuntu development, but I'm glad they were pointed out to me in a calm way, so I could go and fix them
<dholbach> and keeping the atmosphere friendly and encouraging to me is the most important thing here
<AnAnt> Hello, is it required that I check for a syncrequest bug before I syncpackage ?
<ari-tczew> bingo ;D
<bdrung> AnAnt: at least recommended.
<dholbach> ari-tczew, give it a break!
<ari-tczew> ok folks, transcripts: http://paste.ubuntu.com/557621/
<dholbach> it's easy enough to duplicate a bug
<ari-tczew> dholbach: you didn't got it, there wasn't duplicate a bug
<ari-tczew> just ignore triaging bugs
<ari-tczew> he used syncpackage, not archive-admin way
<AnAnt> syncpackage shouldn't be used ?
<geser> ari-tczew: is this log from a private conversation of you with AnAnt?
<ari-tczew> geser: yes, it is
<ari-tczew> I know I shoulnd't
<ari-tczew> but this is the way to get feedback objective
<geser> ari-tczew: did you ask him if it's ok before you published it?
<AnAnt> may I know what is wrong ?
<ari-tczew> geser: sorry, no
<ari-tczew> I'm bad man
<Rhonda> ari-tczew: The log shows that you have a rather aggressive style in private queries, too.  And publishing private stuff isn't really helping.
<AnAnt> I built libgwenhywfar on maverick, and it built successfully, I didn't imagine that it would FTBFS (for a reason that I still not sure of) on natty
<Rhonda> AnAnt: Right, please testbuild in future on the distribution you will upload too
<geser> AnAnt: see http://irclogs.ubuntu.com/2011/01/24/%23ubuntu-motu.html#t11:37
<bdrung> AnAnt: always build the package which you are going to upload on the target release! change compiler, compiler flags, different libraries lead to build failures.
<Rhonda> AnAnt: cowbuilder or pbuild will help you, giving you chroots for that so you don't have to have a system with each distribution next to each other.
<AnAnt> what is "facepalm"
<Rhonda> AnAnt: http://deb.at/Ifacepalm
<ari-tczew> google it
<dholbach> AnAnt, it's safe to ignore it
<Rhonda> AnAnt: Feel free to ignore that
<bdrung> Rhonda, AnAnt: or pbuilder-dist ;)
<AnAnt> ok, I did a mistake, that I later fixed
<ari-tczew> how can build package for natty on maverick?
<AnAnt> but I have the impression, that there is something worse than an FTBFS going on
<ari-tczew> it's illogical
<bdrung> AnAnt: yes, a started transition.
<ari-tczew> you uploaded package with FTBFS - better and preffered way is add patch on package from experimental and upload fixed package
<AnAnt> bdrung: 5 packages ?
<AnAnt> ari-tczew: why fix it on experimental, if it builds fine there, we don't even know for sure what caused the FTBFS, that was just a workaround !
<dholbach> ari-tczew, can you try to calm down? I think AnAnt is fully aware of the mistake now and in addition to that there's still quite a bit of time to fix it - it's not like we're 5 minutes before natty release
<ari-tczew> I was overreacted with quantity of transition, yes, sorry. That was not gigantic. But other ways have been neglected.
<AnAnt> bdrung: transitions aren't allowed before feature freeze ?
<kklimonda> what's the point of this discussion? if it doesn't build, and we can't afford the transition, just downgrade it. It would already be done.
<AnAnt> ari-tczew: what other ways ?
<kklimonda> really, if we start calling technical board when people make mistakes then no one is going to do any work harder than simple syncs and merges
<Rhonda> kklimonda: From what I understood the FTBFS is already fixed.
<kklimonda> because something always may break
<kklimonda> I'm preparing a migration of libevent2 atm, over 30 packages to rebuild, 8 to change.
<kklimonda> should I be scared that someone will yell at me if something breaks?
<ari-tczew> AnAnt: no, it didn't build fine on natty. I was checking it some hours ago on pbuilder-NATTY, not maverick.
<bdrung> AnAnt: they are allowed, but ari-tczew claimed that you haven't checked that a transition is required for your upload.
<ari-tczew> and didn't check existing bug!
<AnAnt> I did
<ari-tczew> lie
<AnAnt> no, I didn't check a bug
<dholbach> ari-tczew, calm down
<ari-tczew> busted ^^
<AnAnt> I checked the transitions
<AnAnt> what is this ?
<ari-tczew> nevermind, continue
<ari-tczew> AnAnt and all: apologies, my reaction was bad. I have not bad intentions. Just making sure for technical quality.
<kunal> hello
<kunal> If we are reuploading a changed package (after receiving reviews), we need to change version and upload without source code?
<kunal> or same version and use -f option?
<ari-tczew> kunal: check patch system 0
<ari-tczew> https://wiki.ubuntu.com/PackagingGuide/PatchSystems
<kunal> ari-tczew: thanks
<ari-tczew> You're welcome.
<kunal> ari-tczew: is this also applicable for uploading on revu?
<ari-tczew> kunal: Yes. Do you want to upload a new package?
<kunal> ari-tczew: i already have a package there, i want to integrate review changes
<ari-tczew> kunal: aha ok
<Laney> kunal: keep the same version
<Laney> one version per /Ubuntu archive/ upload
<kunal> ok
<kunal> and changelog?
<ari-tczew> 0ubuntu1
<kunal> ok
<m4n1sh> a package zeitgeist does not have 0.7 version present in Maverick. So I built it in my PPA. Is the versioning 0.7-0ubuntu1~0ppa1~maverick alright? or it breaks it?
<ari-tczew> m4n1sh: 0.7-0ubuntu1~maverick1~ppa1
<m4n1sh> ara: I thought that maverick should come later?
<m4n1sh> ari-tczew: how is that different?
<ari-tczew> m4n1sh: backports have ~maverick1 so you should use ppa as a second
<m4n1sh> ari-tczew: i think a few people might be using that package
<m4n1sh> so I upload a package with this version
<m4n1sh> will it be overridden?
<ari-tczew> m4n1sh: what version do you have already in PPA?
<m4n1sh>  0.7-0ubuntu1~0ppa1~maverick
<ari-tczew> not good
<ari-tczew> I must  go away right now, I'm late
<m4n1sh> ari-tczew: so i should delete and start? or upload it and it will come as an update?
<tsimpson> m4n1sh: 0.7-0ubuntu1~maverick1~ppa1 would be better, as if the package is backported to maverick it would be 0.7-0ubuntu1~maverick1, so the backported version would be considered higher than the PPA version
<tsimpson> m4n1sh: however, because you put -0ppa1, 0.7-0ubuntu1~maverick1 would still be higher than the PPA version, so it's not going to cause any trouble
<micahg> bdrung: is there an option to not upload the .orig.tar.foo with backportpackage? ( I looked at the man page and didn't see one)
<Laney> what shall I do with the versioning of a package that was previously removed?
<Laney> Only consider the version that was in a release?
<Laney> s/removed\?/removed, and I want to bring back?/
<Laney> I'll just upload as if it were the next Ubuntu upload normally, that way there shouldn't be any problems.
<bdrung> micahg: no. bug #691897
<ubottu> Launchpad bug 691897 in ubuntu-dev-tools (Ubuntu) "[backportpackage] detect if orig.tar.gz upload needed" [Wishlist,New] https://launchpad.net/bugs/691897
<Laney> haskell rebuilds: good for ones karma
<m4n1sh> tsimpson: thanks a lot :)
<ari-tczew> how can I fix this FTBFS? http://paste.ubuntu.com/557741/
<ari-tczew> udienz: you know? ^^
<udienz> ari-tczew, adding -lQtCore
<ari-tczew> udienz: @QT_LIBS@ is not enough?
<udienz> ari-tczew, i guess enough. i look at nvclock maybe QT_LIBS should added after LIBS
<udienz> in nvclock_qt:: section
<ari-tczew> udienz: now I'm working on nvclock from Debian svn
<udienz> ari-tczew: great!  and patch from doko will usable and not useless anymore
<paultag> debfx: thanks for the patch against fluxbox, btw
<paultag> debfx: don't think I've messaged you directly
<paultag> debfx: we fixed it by correcting the underlying issue, but I'd not seen the ftbfs
<debfx> paultag: you're welcome :)
<paultag> and now, off to uni -- ciao!
<debfx> paultag: feel free to ping me once a new version is in debian so I can sync it to ubuntu
<paultag> debfx: will do, it's going to be in about two weeks, I got upstream to do a 1.1.3 release ( first release in 3 years! ), and it squashes most of our bugs :)
<paultag> debfx: upstream and myself are killing off the last issues before doing 1.1.3, should be nice and stable
<RainCT> bdmurray: So python-espeak is an important package?
<bdmurray> RainCT: can you remind me of the bug number?
<RainCT> bdmurray: bug #580781
<ubottu> Launchpad bug 580781 in python-espeak (Ubuntu) "python-espeak speaks words inconsistently" [High,Triaged] https://launchpad.net/bugs/580781
<bdmurray> since the "upstream" task was high it seemed reasonable to me that the ubuntu one would be too
<RainCT> bdmurray: Isn't "A bug that has a severe impact on a non-core application." -> Medium? Anyway, I'm not worried about it, just wondering whether I'd missed something about python-espeak being used (i'm upstream) :P
<broder> bdmurray: ubuntu bug priorities are evaluated in the context of ubuntu as a whole, which will almost always deflate the priority relative to how upstream views a bug
<bdmurray> Okay I've set it to Medium.
<micahg> bdrung: would it be hard to get a flag to not include the orig.tar.foo instead of it being dynamic
<bdrung> micahg: i would prefer to have it autodetecting the need of the orig file
<micahg> bdrung: that would require querying LP for the status of the package in the archive it'll be uploaded to
<bdrung> micahg: yes
<bdrung> tumbleweed: bug #707187
<ubottu> Launchpad bug 707187 in ubuntu-dev-tools (Ubuntu) "[syncpackage] fakesyncs if source tarball does not exist it Ubuntu" [High,New] https://launchpad.net/bugs/707187
<bdrung> ari-tczew: please unsubscribe ubuntu-sponsor if you sponsor an upload
#ubuntu-motu 2011-01-25
<ari-tczew> bdrung, tumbleweed: could you avoid in sponsors-overview last comment by  ?
<ari-tczew> janitor
<dholbach> good morning
<sagaci> afternoon dholbach
<dholbach> hi sagaci
<geser> good morning dholbach
<dholbach> hello geser
<AnAnt> Hello, anyone got a natty chroot ?
<persia> AnAnt, Sure.  What do you need?
<AnAnt> persia: thanks, I'll try something here first
<AnAnt> compiling this test code fails on natty: http://pastebin.com/0XGD4kXB , I compile as follows: gcc -Wl,-Bsymbolic-functions -lncursesw test.c
<AnAnt> I got libncursesw5-dev & libncurses5-dev installed
<AnAnt> persia: ^
<\sh> AnAnt: doesn't it mean: int main() { ... return(0); }? ,-)
<AnAnt> \sh: I don't understand
<AnAnt> the compile error was: undefined reference to addwstr
<AnAnt> anyone knows if there is something wrong with the compile command line ? linker flags ?
<persia> AnAnt, fails for me as well.  No idea why.
<AnAnt> it compiles on maverick btw
<geser> the usual "ls --as-needed" issue
<geser> exchange the order of -lncursesw and test.c -> test.c -lncursesw
<geser> order does matter with ld --as-needed which is default in natty
<persia> geser, So -lfoo needs to follow code that uses foo?
<geser> persia: exactly
<AnAnt> geser: aha, thanks
<persia> Ah!  That explains a few things I've seen.  Thanks.
<dapal> evaluate: ack :) -- I'm quite busy as well :/
<evaluate> dapal, ok :-)
<Laney> dholbach: forgot to reply to your mail re the announcement but no more comments from me :-)
<dholbach> Laney, thanks
<Laney> np
<Laney> your other mail reminded me ;)
<dholbach> I'll follow up in a bit
<AnAnt> geser: thanks, could you give me a link regarding the rationale of listing -lfoo before the source/object files using it ? I want to send a patch to upstream
<bdrung> dholbach: "The expectations of new developers are appropriate" - what we expect from them or what they expect?
<dholbach> the former
<Laney> oops
 * Laney ^H^H^H^H^H^H^H
<dholbach> alright... I'll head out into the cold for lunch - see you later
<geser> AnAnt: I can only point you to the manpage of "ld" and the "-l" option (perhaps also read about "--as-needed")
<AnAnt> geser: thanks
<ari-tczew> kklimonda: can we sync atkmm1.6 from experimental and clean up it from REVU?
<ari-tczew> kklimonda: btw. you have typo in d/changelog - forgot hash, (Closes: 604123)
<ari-tczew> and why svn :( git is better
<ari-tczew> bdrung: if you are free, you could sponsor merges from queue
<bdrung> ari-tczew: which?
<ari-tczew> bdrung: bug 695005 or bug 705383
<ubottu> Launchpad bug 695005 in python-numpy (Ubuntu) "Merge python-numpy 1.5.1 (main) from Debian experimental (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/695005
<ubottu> Launchpad bug 705383 in emacs23 (Ubuntu) "Please merge emacs 23.2+1-7 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/705383
 * ari-tczew is off for lunch.
<bdrung> ari-tczew: done python-numpy
<bdrung> ari-tczew: emacs is too big. find an emacs user for sponsoring.
<kklimonda> ari-tczew: we can clean it up from revu but there is no need to sync it. and missing # is not a typo, it closed bug just fine.
<ari-tczew> bdrung: I asked kees for emacs sponsoring
<tumbleweed> bdrung: thanks for numpy
<bdrung> tumbleweed: that was an easy one
<tumbleweed> IIRC that'll need a few rebuilds now, hopefully smorar will take care of it
<ari-tczew> RainCT: would be nice if REVU has a script to check whether package exist in Ubuntu or Debian
<RainCT> ari-tczew: Yeah. Send me a patch :)
<ari-tczew> RainCT: ha ha ha :P
<kklimonda> jdstrand: thanks for doing two upload for hamster-applet and not merging 2.32.1 in the meantime ;)
<jdstrand> that's slightly snarky :)
<jdstrand> I coded up a fix for one of those and noticed a patch was available for the other. it is all I had time for
<kklimonda> jdstrand: I just got confused when I saw 2.31.92-ubuntu4  :)
 * bdrung is poking ari-tczew for vlc.
<ari-tczew> bdrung: would you like me to review?
<shadeslayer> how can i specify a sshd port using debsign with -r option?
<bdrung> ari-tczew: yes
<tumbleweed> shadeslayer: don't know of any option except configuring the host in your .ssh/config (which is a good timesaver, anyway)
<shadeslayer> ok
<ari-tczew> bdrung: let me finish some things, some minutes
 * ari-tczew wishes that some day motu-swat will grant upload access to -security pocket.
<jdstrand> ari-tczew: why that would be helpful, I don't think there is a significant bottleneck atm
<jdstrand> the current process provides peer review and more or less timely sponsorship (we have a person dedicated to doing sponsoring each week)
<jdstrand> (ie, security sponsoring, beyond patch piloting)
<ari-tczew> jdstrand: that means that only Canonical can maintain that stuff, without community
<jdstrand> ari-tczew: no, Canonical sponsors for the greater community
<jdstrand> ari-tczew: yes, we are theoretically a bottleneck, but in practice we are not because the sponsorship volume is not high
<ari-tczew> jdstrand: sad to hear that not-payed community is worse
<jdstrand> ari-tczew: who said that? I certainly did not
<jdstrand> ari-tczew: the fact is that few from motu-swat are even acking patches to bugs where ubuntu-security-sponsors is subscribed
<ari-tczew> jdstrand:  [16:14] <jdstrand> ari-tczew: no, Canonical sponsors for the greater community
<ari-tczew> Canonical = cash
<jdstrand> ari-tczew: why would full access to the security pocket be given when there is little interest from the greater community to provide and test updates?
<ari-tczew> commercialism
<jdstrand> ari-tczew: that is a very odd interpretation of what I said
<dholbach> ari-tczew, I'm not sure where you are going right now - it should not exactly be a surprise that there are members of the community paid to work on Ubuntu
<jdstrand> ari-tczew: there are limitations in LP that don't allow this. I am merely saying that while it would be nice if that limitation was gone, practically speaking, there is no problem getting fixes from the greater community into -security
<jdstrand> if people just want to get the work done and contribute, there is no problem
<ari-tczew> jdstrand: so only LP is blocking give access to -security pocket?
<jdstrand> ari-tczew: that, processes surrounding handling of uploads to -security in stable releases, and people
<jdstrand> so there are technical and procedural things that need to be addressed. once the technical is resolved, I assume motu-swat can develop safe processes requiring peer review, etc
<ari-tczew> bdrung: thanks for sync review. could you have a look also on related bug 702765 ?
<ubottu> Launchpad bug 702765 in libgcrypt11 (Ubuntu) "Please sync libgcrypt11 1.4.6-4 (main) from Debian experimental (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/702765
<ari-tczew> jdstrand: I'm an admin of motu-swat so I can manage members properly, if you as ubuntu-security have concerns to any members in the team.
<bdrung> ari-tczew: ping me again once libgpg-error is synced
<jdstrand> ari-tczew: again, you are misinterpreting me. I am not saying anything against you are the members of the motu-swat team. I am saying there isn't a defined process for how motu-swat does peer review, testing, uploads and handling of regressions
<ari-tczew> bdrung: yea, I'm thinking when last syncs were done
<ari-tczew> (archive-admin)
<jdstrand> ari-tczew: right now, all that comes for free because the ubuntu-security team handles much of that on the larger community's behalf
<jdstrand> ari-tczew: if we are taken out of the picture (which is what you are suggesting), then processes need to be defined and followed
<jdstrand> this is all to ensure our users receive quality updates with the very best chance of being regression free
<ari-tczew> jdstrand: I'm only volunteer without cash so I can wait only for Canonical grace. I'll review vlc since bdrung asked me for that. Thanks.
<jdstrand> ari-tczew: where is this hostility coming from? I cleared the security sponsors queue last week (and there wasn't much there). mdeslaur is on community sponsoring this week, and iirc has already been looking at the queue
<mdeslaur> ari-tczew: I started looking at vlc this morning
<ari-tczew> jdstrand: I'm just guessing whether reviewing by motu-swat makes sense.
<jdstrand> ari-tczew: sure it does! if we get a qualified ACK from anyone from ubuntu-security-sponsors, we process it
<mdeslaur> ari-tczew: once I finished build testing it, I'll ack it and upload it
<ari-tczew> jdstrand: OK, good to hear. I just want to make Ubuntu more community-open in some areas like security.
<ari-tczew> So in future I imagine motu-swat as team with upload access to -security in universe.
<jdstrand> ari-tczew: we are striving to be open with the LP that is here now. https://wiki.ubuntu.com/SecurityTeam/SponsorsQueue discusses how the queue is processed. noticed there is a lot that ubuntu-security-sponosrs can do, of which motu-swat is a member
<mdeslaur> ari-tczew: could you please add the information that's missing to bug #539056 ?
<ubottu> Launchpad bug 539056 in drupal5 (Ubuntu Karmic) "backport security fixes from 6.19 and 5.23" [Undecided,In progress] https://launchpad.net/bugs/539056
<mdeslaur> ari-tczew: thanks
<ari-tczew> mdeslaur: I'll add when I'll have opportunities to test. or maybe you want to do it for me?
<mdeslaur> ari-tczew: you're supposed to test _before_ asking for debdiffs to be sponsored. See https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures
<ari-tczew> mdeslaur: I can don't preparing fixes if you want.
<mdeslaur> ari-tczew: I don't understand
<ari-tczew> mdeslaur: I dunno how explain it more, english is not my native.
<mdeslaur> ari-tczew: ok, I'll wait for your testing and updated debdiffs. Thanks.
<ari-tczew> mdeslaur: IIRC there is no need to add patch which jdstrand asked. I didn't check it yet.
<ari-tczew> because it was related to plugin for drupal, not for stricte drupal
<mdeslaur> ari-tczew: well, could you please update the bug with the info? thanks
<Rhonda> uh oh, requestsync did drop its pant infront of me
<Rhonda> Might it be that the version in debian testing isn't able to work with --lp anymore?
<tumbleweed> should work wit h--lp
<tumbleweed> Rhonda: traceback?
<Rhonda> The traceback somehow gives me the impression it might be related to --lp
<Rhonda> Let me paste it
 * tumbleweed always uses --lp. But I also haven't used the version that's in testing for a while... :P
<Rhonda> http://paste.debian.net/105662/
<tumbleweed> Rhonda: http://code.google.com/p/httplib2/issues/detail?id=62 <- basically it means connection failed
<tumbleweed> (as one could gess)
<geser> Rhonda: does the version in testing perhaps use edge.lp which is gone?
<tumbleweed> geser: edge.api still seems to exist
<tumbleweed> that was my first thought too
<Rhonda> Ah. Retry and it worked.
<Rhonda> I think it's related to my background uploading of wesnoth-1.9_1.9.4.orig.tar.gz which blocks a fair amount of my outgoing bandwidth ;)
<Rhonda> It's only at 18% so far .....
<tumbleweed> I'll bet :)
<Rhonda> Did I mention that I need betterbandwidth for such stuff?
<Rhonda> 'nuff done for now, see you around.
<MTecknology> if one line in debian/changelog fixes one launchpad bug and one debian bug, how should I mark that?  I've seen (Closed: #123123) and (LP: #123123) but never both put together
<MTecknology> there we go
<MTecknology> zul: howdy!
<ari-tczew> MTecknology: (LP: #XXXXXX, Closes: #XXXXXX)
<zul> MTecknology: hi
<MTecknology> ari-tczew: thanks :)
<MTecknology> zul: how's php been going for ya?
<zul> MTecknology: fine
<MTecknology> zul: how's everything else been?
<zul> MTecknology: fine..no php 5.3.5 yet if thats what you are leading to ;)
<ari-tczew> RainCT: are you going to take sponsorship on bug 707635 ?
<ubottu> Launchpad bug 707635 in Ubuntu "Sync zeitgeist-sharp 0.1.1.0-1 (universe) from Debian experimental (main)" [Undecided,New] https://launchpad.net/bugs/707635
<RainCT> ari-tczew: yep
<ari-tczew> RainCT: unsubscribe sponsors then
<ari-tczew> or mark In Progress
<RainCT> Yup. (Can't unsubscribe, team membership expired)
<persia> RainCT, I've extended your membership in ubuntu-sponsors, since you seem to need it, and do sponsoring.  Just ask if you expire again
<ari-tczew> persia: do you will be still in DMB?
<RainCT> persia: Thanks
<persia> ari-tczew, I have no idea.  I've been nominated for the selection process.  We'll see what happens when the developers express their preferences from the set of nominees.
<ari-tczew> persia: who is also nominated?
<persia> ari-tczew, The list of nominees is currently not disclosed.  It will be announced on Monday.
<persia> I will say that the DMB would appreciate more nominations, if folk have preferences.  It never hurts to have a wide selection of folks from whom to choose.
<ari-tczew> persia: then how do you know that you have been nominated?
<persia> ari-tczew, Because I am on the list that receives the nominations.
<ari-tczew> aha
#ubuntu-motu 2011-01-26
<pabelanger> What an exercise, finally have reprepro and rebuildd working together.  Yay, for local package repository
<MTecknology> ok... so... override_dh_fixperms:  if I place that in debian/rules it'll automatically be used, nothing special, just all magic?
<micahg> MTecknology: I thought with overrides you have to do something
<MTecknology> micahg: oh.. I'm only adding it to change the permissions of one directory, would it maybe make more sense to just put it right after dh_fixperms?
<micahg> MTecknology: hmm, I thought that you can the dh_foo, if appropriate, in the override along with whatever using the override for
<micahg> *call
<MTecknology> oh
<MTecknology> micahg: If a user installed the package, then upgraded the package but never changed that directory, could I make the permissions get updated on it?
<micahg> MTecknology: which directory?
<MTecknology> micahg: /var/log/nginx
<MTecknology> 750 instead of 755
<micahg> MTecknology: Yeah, that should be fine as long as you have a good reason :), you might want to add a news file so people aren't shocked
<MTecknology> micahg: I'll add it to the news file; i'd add the change to postinst but then every single update the permission will be reapplied; i'd rather just do it once for old updates and if the user changes it then leave it alone
<micahg> MTecknology: yes, that's best, cleaning up after oneself is fine, but sysadmins should have the final say
<micahg> MTecknology: check the version in the postinst
<MTecknology> oh... I was under the assumption that that postinst happened after the new package was installed
<micahg> MTecknology: hmm, you might have access to the old version, I'm not so clear, maybe someone else knows
<micahg> *version number
<micahg> MTecknology: yeah, you're right, http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
<micahg> MTecknology: you could check it in the preinst
<MTecknology> micahg: I had to run for a minute.. "new-preinst upgrade old-version
<MTecknology> micahg: I had to run for a minute.. "new-preinst upgrade old-version" does that mean there should be an old-version variable in there?
<micahg> MTecknology: I believe so :)
<MTecknology> $2 i assume?
<micahg> I think so
<MTecknology> :D
<MTecknology> heh.. so I'll just need to know how to compare the versions
<micahg> MTecknology: dpkg --compare-versions :)
<MTecknology> micahg: and to grab the new version?
<micahg> MTecknology: you shouldn't need to worry about the new version, right?
<MTecknology> what else would i be comparing against?
<micahg> MTecknology: the last bad version
<micahg> or the first good version depending on how you compare
<MTecknology> oh!
<MTecknology> I created a preisnt and didn't even need it :P
<MTecknology> except postinst doesn't seem to have that version for an upgrade
<micahg> MTecknology: whcih is why you should do it in preinst :)
<MTecknology> if dpkg --compare-versions "$most_recently_configured_version" lt "0.8.54-4"; then chmod 750 /var/log/nginx; fi
<MTecknology> micahg: thanks a bunch :D
<micahg> MTecknology: you're welcome
<MTecknology> micahg: now to test it out and see if things still build; I made a lot of changes (should close every open debian and launchpad bug against the package.) :D
<micahg> MTecknology: awesome
<MTecknology> even added a feature through a patch that it doesn't look like igor will accept
<micahg> MTecknology: is Igor upstream?, we'd want Debian to take that then
<MTecknology> :S ... debuild failed
<MTecknology> micahg: because of all the work i did with the package, the guys that manage it in debian asked me to help maintain; so what i do winds up right there
<micahg> MTecknology: that's great, work in one place and lots benefit
<MTecknology> by igor, I meant the guy that controls what winds up in nginx
<micahg> MTecknology: right, so if upstream rejects and Debian takes it that's fine for Ubuntu
<MTecknology> apparently i messed up debian/rules bad enough that debuild won't even complete
<MTecknology> oh.. it was only complaining about a little itty bitty thing....
<MTecknology> micahg: ya know.... I put a LOT of work into this thing; now I'm looking back and wondering where I'd be if this channel didn't exist.. I'd probably have given up entirely and got nowhere
<micahg> MTecknology: I'm sure that'll make a lot of people here smile :)
<MTecknology> micahg: I hope so; I wouldn't even want to /try/ to get a list of everyone that's helped me...
<jonathan> hi everyone
<jonathan> I'm interested in joining the prospective developers but I'm confused as to where to go to start
<jonathan> uh oh, guess my text got cut off
<jonathan> would anyone happen to know where one would start off in joining the perspective developers?
<MTecknology> jonathan: which developers?
<jonathan> I was looking at the ubuntu website and it said that prospective developers was a good place to start in joining the development team
<MTecknology> oh.. there's a lot of places developers can look to contribute; that's part of why it's such an easy place to jump into
<jonathan> I'm just confused on what I need to do in order to get started
<MTecknology> you could look into some bugs for a package you particularly like and try to fix them
<MTecknology> fix them, build a patch, and then add to the bug report
<jonathan> that's it?
<MTecknology> that's one place that's somewhat easy to jump into
<MTecknology> otherwise you could look through and try to triage all bugs in ubuntu :)
<jonathan> hehe
<jonathan> I'm sort of new to coding
<jonathan> I'll have to handle easy things
<MTecknology> there's no one language used; a lot packages produced for ubuntu are python driven though
<jmarsden> jonathan: You may find https://wiki.ubuntu.com/BeginnersTeam/FocusGroups/Development/Devbeginnings#Ubuntu%20Development%20Beginnings has a few things you can try out as you get started.
<evilvish> jonathan: bug triage is relatively easy and gives you a good idea about the packages.. and where to get involved..
<jonathan> and I can just come here if I happen to have questions?
<MTecknology> triage is where i started out at; i thought that if i just sat there and hammered away, i could be 'that guy' that got through everything :P
<MTecknology> jonathan: nope, questions are hated in here.... actually, some of the most amazing devs i know hang out in here
<evilvish> jonathan: depending on what you are doing, we have channels different channels..
<MTecknology> always eager to help new guys
<jonathan> where do I go if I have questions or happen to need to talk to someone?
<MTecknology> there's #ubuntu-packaging if you want to get into packaging
<MTecknology> jonathan: you can ask where the best place is to ask too :)
<jmarsden> jonathan: For questions that are definitely about triage, you may find #ubuntu-bugs is a good place to ask them.
<jonathan> by ubuntu packaging do you mean maintaining packages?
<MTecknology> ya
<jonathan> someone like me would be capable of doing that?
<MTecknology> that's what I'm working on right now actually
<MTecknology> and I'm very far from an expert
<jonathan> how much coding is involved in maintaining packages?
<MTecknology> depends.. ideally, not much
<jonathan> I guess that would be a good place to start then
<MTecknology> if you start though.. my best suggestion is 1) setup a dev system using debootstrap 2) create a user inside of that 3) do your dev in there
<MTecknology> if/when you start breaking things or installing php5-dev (i'm doing so now) you're not messing with your base system and it makes new environments incredibly easy to play with
<MTecknology> jonathan: https://wiki.ubuntu.com/PackagingGuide/Complete
<jonathan> I've never used debootstrap before
<jonathan> do you have a guide for that?
<MTecknology> aptitude install debootstrap; debootstrap natty natty; chroot natty
<MTecknology> debootstrap is so easy it's actually scary :P
<jonathan> ok, I think the first thing I'll work on is mastering all those packaging commands
<MTecknology> nah, then you'll never get anything done :P
<jonathan> which ones should I focus on?
<MTecknology> jonathan: up until a month ago I was always editing the timestamp line in debian/changelog by hand and screwed up a lot; then i found dch and life got easier
<jonathan> if I may ask, how long have you been a linux user?
<MTecknology> jonathan: there's a billion (or so) tools to make your life easier; best to just take a walk through that complete guide, and then start playing and figure out what you don't understand
<jonathan> I've used linux for a few months so far
<MTecknology> i started playing with linux when 5.04 came out (my senior year in HS)
<jonathan> that was last year for me
<jonathan> ok, I'll look through the guide then
<jonathan> thanks for the help
<MTecknology> jonathan: always feel free to ask questions; sounds like #ubuntu-packaging may be a good channel for you
<MTecknology> only 7min wait time estimated for amd64 ppa builders.... I'm about to skew that estimate...
<maco> upoading OOo?
<MTecknology> maco: not that bad, 13596k
<MTecknology> maco: providing a backport of php5 for lucid and maverick because it was such a huge request with nginx
<MTecknology> maco: at least i didn't trigger a complete rebuild of python :D
<MTecknology> dangit.....
<MTecknology> I have package nginx-full that depends on package nginx being already installed; package nginx depends on nginx-full | nginx-light.. so nginx needs to be installed before nginx-full is finished up; but installing nginx means you need to install one of the others
<MTecknology> any tips on making this work?
<jmarsden> MTecknology: install nginx-light first?  That will satisfy the dependency.  Then install nginx, then install nginx-full.  Sounds like it will do what you want??
<MTecknology> jmarsden: nginx-full and nginx-light are conflicting packages; they both require nginx to be installed first though; it's like apache-common
<jmarsden> Then you have a circular dependency, if nginx depends on -light or -full and they each depend on nginx.
<MTecknology> yup
<MTecknology> I'm not sure what the right way is to deal with it
<MTecknology> jmarsden: I'm sure it's my control file - lemme grab it
<jmarsden> Don't do that :)  Avoid recursive dependencies :)  apache-common doesn't depend on apache-mpm etc...
<MTecknology> jmarsden: oh......... that's making more sense now :)
<MTecknology> jmarsden: so instead of Depends: nginx-full; I'm looking at Reccomends: nginx-full ?
<MTecknology> or would I want Suggests?
<MTecknology> Recommends: nginx-full | nginx-light ?
<jmarsden> Suggests is less "forceful" to package managers, recommends will mean if you apt-get install nginx you *will* pull in nginx-full...  Eww, not sure you want the | stuf in Recommends.
<MTecknology> ok- that makes sense :)
<jmarsden> Are the names set in stone?  Maybe you should rename what i snow nginx to nginx-common and then rename nginx-full to nginx ???
<jmarsden> That way apt-get install nginx will do what most people expect.
<MTecknology> I considered different names like that; but the only thing held in nginx-full or nginx-light is a binary and one or two other tiny things; nginx has most everything; but to deal with the way things look now it made the most sense to have nginx instead of nginx-common
<jmarsden> OK.  If there is an existing "tradition" for that naming scheme, then it makes sense to keep it.
<MTecknology> jmarsden: uploaded again... we'll see if things get fixed :)
<jmarsden> OK.  You can sometimes avoid the upload/wait-for-builders/test/oops/edit... cycle delay by setting up your own local repository, incidentally.  But I need to go to bed, you'll need to google for info on how to do that yourself :)
<MTecknology> jmarsden: alrighty, i should do that too... I wanted to be sleeping 4hr ago :P    thanks :)
<jmarsden> Goodnight.
<dholbach> good morning
<MTecknology> !info php5-fpm
<ubottu> php5-fpm (source: php5): server-side, HTML-embedded scripting language (FPM-CGI binary). In component universe, is optional. Version 5.3.3-1ubuntu9.3 (maverick), package size 2875 kB, installed size 7628 kB
<MTecknology> !info php5-fpm natty
<ubottu> Package php5-fpm does not exist in natty
<MTecknology> zul: What happened? :(
<MTecknology> zul: I just bumped up to 11.04 and it seems to have gone buh-bye
<paultag> MTecknology: http://lists.debian.org/debian-devel/2009/09/msg00348.html  <-- related?
<paultag> php5 (5.3.3-2) unstable; urgency=low
<paultag>   * Don't build FPM SAPI now
<paultag>  -- Chuck Short <zulcss@ubuntu.com>   Fri, 07 Jan 2011 22:44:56 +0000
<paultag> MTecknology: might want to get in touch with that feller if it's a big deal
<ari-tczew> bdrung: bug 702765 is ready.
<ubottu> Launchpad bug 702765 in libgcrypt11 (Ubuntu) "Please sync libgcrypt11 1.4.6-4 (main) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/702765
<udienz> ari-tczew, about bash merging. You can take it i will merging firestarter
<ari-tczew> udienz: I doubt that there is anyone willing to sponsor.
<ari-tczew> cjwatson wouldn't touch it. doko is maintainer, but he delayed merge to next upstream release.
<ari-tczew> and I'm not suprised. bash is very impotant package.
<udienz> hm.. ok ok
<Rhonda> I still don't really understand why bash has the need for such a lengthy diff in the first place.
<cjwatson> the merge in question isn't even all that important; most of the important changes are already in Ubuntu
<cjwatson> so I don't understand the lengthy debate about it
 * Rhonda . o O ( especially since the maintainer on both sides is the same person, actually â¦ )
<BlackZ> I'm agreed with cjwatson; I said that in the bug report, though :)
<cjwatson> Rhonda: I can understand plenty of reasons for that from my own experience, THB
<cjwatson> TBH
<cjwatson> not all my packages are synced
<cjwatson> important> I mean, I don't mean to diss udienz, but it does seem reasonable to spend effort on merges with important changes first
<Rhonda> Like pgadmin3, thanks for ACKing it, cjwatson ;)
<Rhonda> Though no merge but sync, actually.
<cjwatson> I think I just processed it
<cjwatson> that's mostly scripted, no need to thank me :)
<Rhonda> Whatever, thanks anyway. :)
<ari-tczew> I hope that in next Debian cycle most packages will support Ubuntu changes in modern, parallel system
<cjwatson> I don't find it that simple
<ari-tczew> so maybe we will gain more syncs
<cjwatson> in particular I'm not convinced that that interacts brilliantly with revision control
<Rhonda> ari-tczew: Actually dpkg is ready for that and buxy did blog on how to do it.
<Rhonda> â¦ in source v3
<Laney> the implementation there isn't as good as it could have been, IMHO
<Laney> you need to maintain entire separate series files for each distro
<cjwatson> I know dpkg can do it, but think of what the unpacked trees look like and how you deal with that in revision control; you end up having diffs in the unpacked tree even though it's the same version, which is very confusing when you then come to modify it
<cjwatson> so I haven't implemented that for any of my packages
<Rhonda> There is a lot of things that aren't as good as they could have been and annoy people indeed, in source v3 in general, but it's definitely a step in the proper direction
<ari-tczew> +1 ^^
<Laney> I (and the cli teams) find that keeping VCS branches for Ubuntu is a good way to manage the delta
<Laney> git merging is excellent for this workflow
<cjwatson> right, I prefer that to the approach of multiple series files
<cjwatson> it's much easier to see what's happening
<Laney> I would probably use unapply-patches in the multiple-series workflow
<Rhonda> Laney: I also consider VCS branches proper.
<Rhonda> I just haven't anyone approach me to do an ubuntu branch for irssi yet.  %-/
<Rhonda> Hmm, actually I could do that myself me thinks.
<Laney> It's in main, so you will have to get upload rights for it
<Rhonda> And step on the toes of those who have worked without contacting me so far. :P
<Laney> (if you want to upload yourself)
<Rhonda> oh
<Laney> that should be a formality though
<Rhonda> I guess I will have to apply because of logcheck anyway.
<Laney> you can get per-package rights, and the Debian maintainer should be almost guaranteed to receive them
<Rhonda> So what else from me is in main that I'm not aware of? Any cheap way to find out?  :D
<Laney> UDD? :P
<Rhonda> nah, grep-dctrl!
<Laney> or g.. yes
<Rhonda> huhm
<cjwatson> the problem with unapply-patches (and traditional patch systems) is that you can't use $vcs blame coherently between upstream and patched source files
<Rhonda> Laney: I don't have the packages files at my hand, so I might need to ressort to udd.  %-/
<cjwatson> well, one of the problems
<Rhonda> â¦ or start adding deb-src for ubuntu onto my system. :)
<Laney> I want to figure out if topgit makes sense
<cjwatson> Rhonda: or chdist
<Rhonda> cjwatson: What's chdist?
<cjwatson> it's in devscripts
<Laney> and I also want a way to indicate to Ubuntu developers that the Debian maintainer is maintaining a branch for the package
<Laney> probably Vcs-foo
<cjwatson> http://manpages.ubuntu.com/manpages/maverick/en/man1/chdist.1.html
<cjwatson> I use it on an Ubuntu system so that I can do 'chdist apt-get unstable -d source <package>'
 * Rhonda goes to http://deb.at/Mchdist instead  :P
<Rhonda> huhm
<Rhonda> $ grep-dctrl -FMaintainer,Original-Maintainer,Uploaders 'Gerfried Fuchs' -sPackage,Section /var/lib/apt/lists/at.archive.ubuntu.com_ubuntu_dists_natty_* | grep-dctrl -v -FSection universe
<Rhonda> So it's beep, irssi and logcheck  \o/
<Rhonda> Laney: Thanks for pushing me to dig it up
<Laney> \o
<Laney> now get applying!
<Rhonda> hah
<Rhonda> If time permits I would. The irc meetings aren't quite working for me these days.  %-/
<geser> 19:00 UTC doesn't suite you either?
<Rhonda> That's around the time my young one goes to bed, and we have time to talk with each other, my SO and me
<bdrung> ari-tczew: done
<ari-tczew> bdrung: thanks
<Rhonda> Oh. Still had an intrepid chroot and wondered why it gave me errors.
<bdrung> all sync and merge requests processed
<al-maisan> hello, I am having trouble installing a package (python-scipy) on natty; the errors are as follows: http://pastebin.ubuntu.com/558620/
<al-maisan> what is puzzling is that the quoted dependency "Depends: python-numpy (< 1:1.5)" is not in the python-scipy package's debian/control file
<al-maisan> any ideas why this breaks?
<geser> al-maisan: http://packages.ubuntu.com/natty/python-scipy shows this versioned dependency too
 * al-maisan looks
<al-maisan> oh, I see.
<al-maisan> thanks geser !
<ScottK> Hopefully whoever uploaded the new numpy is also taking care of the transition.
<maco> ScottK: does your brain pronounce that package's name with the proper -py ending or do you keep rhyming with an adjective for mashed potatoes?
<ScottK> Depends.  That one rhymes with pie.  Scipy however sounds like the peanut butter.
<geser> not http://en.wikipedia.org/wiki/Skippy_the_Bush_Kangaroo ? :)
<al-maisan> re. the new numpy .. /me hopes the same .. I went back to rev. 1:1.4.1-5ubuntu4 for the time being
<tumbleweed> ScottK: he's supposed to (he's a mentoree of mine). I'll prod him again
<ScottK> tumbleweed: Thanks.
<ScottK> geser: No.  http://en.wikipedia.org/wiki/Skippy_(peanut_butter) - Also not http://skippyslist.com/list/
<ari-tczew> ScottK: around?
<ScottK> ari-tczew: Somewhat.
<ari-tczew> ScottK: could you try build gnome-power-manager on natty (armel) without that change: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/gnome-power-manager/natty/revision/123#debian/rules
<ScottK> ari-tczew: Link to a .dsc I can dget and build without change and I'll try it.
<ScottK> Link/Link me
<ari-tczew> ScottK: give me 5 minutes
<m4n1sh>  i had the trunk build of gaj in my PPA
<m4n1sh> now there is an official release
<m4n1sh> so for adding the entry in changelog
<m4n1sh> should I remove the changelog entry of the trunk build
<m4n1sh> or keep it there?
<ari-tczew> m4n1sh: remove
<ari-tczew> keep information only about ubuntu package
<m4n1sh> ari-tczew: yeah. Since I would ask a DD to upload it
<m4n1sh> so I think it needs to go
<m4n1sh> ari-tczew: thanks for help
<m4n1sh> just wanted to learn the best practices
<ari-tczew> m4n1sh: You're welcome.
<ari-tczew> ScottK: armel = ARM ?
<ScottK> ari-tczew: For our purposes yes.
<ScottK> arm is the processor and also the name of a now defunct architecture in Debian that was replaced by armel (IIRC little endian versus big endian is the difference)
<ari-tczew> ScottK: http://people.ubuntu.com/~ari-tczew/ScottK/ let me know when you will start build :)
<ScottK> ari-tczew: I have to update the natty chroot on that box first, so it'll be a few minutes.
<ari-tczew> ScottK: How it's going?
<ScottK> ari-tczew: Started the build and then had to leave.  Just got back.  I'll have a look and see.
<ScottK> ari-tczew: Successful build.  Do you need the build log?
<ari-tczew> ScottK: if you could upload somewhere?
<ScottK> Sure
<ScottK> ari-tczew: http://pastebin.com/QRrF9W0E
<ari-tczew> ScottK: thanks :)
<ScottK> ari-tczew: You're welcome.
#ubuntu-motu 2011-01-27
<doctormo> lfaraone: hey, you want me on linked-in?
<lfaraone> doctormo: yessir.
<doctormo> lfaraone: Done sir, how are you?
<lfaraone> doctormo: quite fine, thank you.
<lfaraone> doctormo: yourself?
<doctormo> lfaraone: Seemingly busy all the time, but not much to show for it. Must be background work.
<lfaraone> fair enough.
<doctormo> lfaraone: Any fine projects?
<lfaraone> doctormo: nothing "fine", per se. wrote a replacement for purity, ugly ugly code. wrote a tiny application for multifactor authentication via cellphones, but didn't yet have time to dos o securely.
<doctormo> lfaraone: Sounds fancy, for Debian?
<lfaraone> doctormo: for Science, actually. But I'll put it in Debian when I'm done with the project
<doctormo> lfaraone: http://www.youtube.com/watch?v=NgR3N8y4boQ
<dholbach> good morning
<bdrung> dholbach: you could put the harvest script in a separate branch (and add the license header). then everyone can improve it until it can go into ubuntu-dev-tools.
<bdrung> dholbach: 2) i made some changes to the sponsors-overview.
<geser> good morning
<bdrung> good morning
<dholbach> hi bdrung, hi geser
<dholbach> bdrung, maybe later - this week I'm pretty slammed with other stuff
<Laney> ScottK: If you have 2 minutes today, could you look at haskell-utf8-string in natty/binary NEW? Thanks.
<kklimonda> is it just me or is the test rebuild being done on ppa builders
<kklimonda> :
<Laney> what's wrong with that? That seems like a reasonable thing to do.
<kklimonda> are they being done with a lower score, or will I have to wait 4 days to build my stuff? :)
<kklimonda> Laney: sure, but I was surprised when I saw 16k jobs in the builders queue
<Laney> i would hope they are scored down
<kklimonda> yeah, they have to have lower score
<sebrock> can someone help me create a backport?
<kklimonda> sebrock: sure, just ask
<kklimonda> (the questions :))
<sebrock> kklimonda: its the package openswan. The current lucid package has a bug which makes it useless with L2TP. So basically my VPN service which utilizes IPSec/L2TP does not work. Err.. it works for one login thereafter it has to be restarted. version 2.6.26 in Maverick solves this. Oh and I have a AMD64 arch.
<sebrock> kklimonda: so the question is if someone can build openswan 2.6.26 for 10.04 amd64?
<sebrock> kklimonda: did that cover it?
 * persia idly wonders what was wrong with the answer in #ubuntu-packaging
<kklimonda> sebrock: sure
 * kklimonda wonders why there are no binaries for openswan 1:2.6.28+dfsg-1
<kklimonda> for maverick*
<persia> !backports
<ubottu> If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
<sebrock> sorry persia, I was suggested to post in both these channels on #ubuntu
<persia> sebrock, Quick overview: read the wiki page, file a bug, do a test (prevu tends to be good for this), and report your results to the bug.
<sebrock> kklimonda: would you be able to do it for me?
<persia> Doesn't suprise me.  The distinction between them isn't always clear.  This one is dedicated to work *on* Ubuntu, and the other is about Packaging with Ubuntu, Ubuntu derivatives, etc.
<sebrock> ok
<kklimonda> sebrock: I can see if package builds without changes, and if so upload it to ppa:kklimonda/backports
<sebrock> kklimonda: that would be great
<persia> Ought still work towards proper backports so people don't have to find arbitrary PPAs :)
<sebrock> kklimonda: 2.6.26 is the version I'm looking for
<sebrock> I've tried to contact the maintainer but he does not answer me
<kklimonda> persia: sebrock can request an official backport, but I can't upload to the backporters ppa anyway, and he has to test it somehow.
<kklimonda> sebrock: can it be 1:2.6.28+dfsg-1?
<persia> Makes sense :)
<sebrock> dunno, possibly there are more new dependencies on that one
<sebrock> but I can always try it
<sebrock> kklimonda I would suggest 2.6.26
<kklimonda> sebrock: 2.6.28 builds fine, but I can't do a one magic command trick for 2.6.26 :)
<sebrock> kklimonda you mean 2.6.26 does not build?
<kklimonda> there seems to be a problem with openswan in maverick
<sebrock> oh
<kklimonda> sebrock: well, it should build but I'd have to dig out source from LP
<sebrock> there is no source for it?
<kklimonda> persia: also, when backporting is there a rule to backport the newest version available in concurrent releases, or can we backport any version we choose?
<sebrock> 2.6.26 is the version in maverick right now no?
<sebrock> or am I missing somethig
<kklimonda> sebrock: yes - but there has been 2.6.28 upload, which didn't build for some reason
<sebrock> hmm.. I'm confused. You have built .26 or .28?
<persia> kklimonda, My understanding is that we're supposed to backport something current in the archives, but I'm not sure that blocks maverick->lucid backports during natty development.  That said, I'm not a backporter: if the backport policy on the wiki page posted above doesn't say, you'll want to ask someone on the backporters team.
<sebrock> kklimonda: which package did you manage to build?
<kklimonda> 2.6.28+dfsg-5 from natty
<sebrock> oh
<kklimonda> I think I can also build 2.6.28+dfsg-1 from maverick
<sebrock> but 2.6.26 from Maverick is a no go?
<kklimonda> well, it can be done, but it would have to wait a while. Plus, I'm not sure if we can backport it.
<persia> sebrock, The 2.6.26 in maverick doesn't have accompanying source, sadly.
<kklimonda> persia: well, it can be fetched from LP
<persia> kklimonda, Oh, good.  I was very worried for a bit there.
<sebrock> persia: ok
<kklimonda> it's actually an interesting problem
<sebrock> kklimonda so how shouls we proceed? In "wait for a while", is that weeks?
<kklimonda> I wonder what did happen with 2.6.28 for maverick
<kklimonda> ScottK: can we backport a package from maverick that got superseeded by a never version that was never published in maverick? the package is openswan
<sebrock> if you managed to backport 2.6.28 to 10.04 amd64 I can try it out
<sebrock> you got a link?
<sebrock> brb, telephone
<sebrock> there
<sebrock> kklimonda I can try out 2.6.28
<kklimonda> it has 3 dependencies, so they should also be checked if we are actually backporting it
<kklimonda> sebrock: can you make an official backport request for openswan from natty to lucid?
<kklimonda> sebrock: I've uploaded it to https://launchpad.net/~kklimonda/+archive/backports, it should build in an hour or so (depending on how busy builders are)
<kklimonda> (when you report it we can actually track testing somewhere - it should help a little)
<sebrock> kklimonda I can do that. LP handles that right?
<kklimonda> sebrock: yes - https://help.ubuntu.com/community/UbuntuBackports#How%20to%20request%20new%20packages outlines the process
<sebrock> ok great
<sebrock> in order to get your package I add it to my sources or is it possible to manually get the deb?
<sebrock> ah right I see now
<sebrock> I'll report back
<sebrock> kklimonda: are you able to also build 1.2.6 of xl2tpd for 10.04? Seems the current version does not cooperate with openswan 2.6.28 very well
<kklimonda> sebrock: I'll see
<kklimonda> sebrock: it built fine, I've uploaded it to the same location
<sebrock> thanks will check it out
<sebrock> kklimonda: do I have to do something special to get it into my sources, apt-get update does not do anything
<sebrock> ie, I already have your PPA in there
<sebrock> yeah its ignoring your repo
<kklimonda> sebrock: it shouldn't
<kklimonda> sebrock: what do you mean by ignoring?
<sebrock> it is, I guess the diff is null
<sebrock> [Ign]
<kklimonda> sebrock: xl2tpd hasn't yet built, so nothing has been published yet
<sebrock> oh I thought it had
<kklimonda> it may not yet have been published
<sebrock> no indication when it has?
<kklimonda> see the result of apt-cache policy openswan
<kklimonda> it should show that there are two versions available - one of them from ppa
<sebrock> kklimonda: got it. However I'm sad to say that it still has the same bugs
<sebrock> I should file a bug for that first :(
<kklimonda> sebrock: there is a newer version in natty, you can test it
<sebrock> Yeah, but I'm certain the actual bug is in openswan
<kklimonda> ah, I see
<sebrock> Thank you very much for your help
<kklimonda> no problem
 * kklimonda hugs backportpackage
<sebrock> Its people like you who makes this so great :D
<ari-tczew> bdrung, tumbleweed: could you have a look on http://paste.ubuntu.com/559009/
<tumbleweed> ari-tczew: so did you install debian-keyring?
<ari-tczew> tumbleweed: not yet
<ari-tczew> tumbleweed: but error message is ugly :)
<tumbleweed> ari-tczew: that's true :)
<ari-tczew> tumbleweed: report bug for it?
<tumbleweed> ari-tczew: sure
<ari-tczew> tumbleweed: with debian-keyring works fine. is it in depends or something?
<tumbleweed> ari-tczew: suggests, IIRC
 * ari-tczew is off to doctor.
<sebrock> so how do I remove a PPA from lucid?
<al-maisan> sebrock: remove ppa? look in /etc/apt/sources.list.d
<sebrock> yes I saw that, but will removing the file remove the PPA completely?
<kklimonda> there is also ppa-purge in lucid-backports
<sebrock> seems ppa-purge is not available on lucid
<sebrock> kklimonda: I could not find it
<kklimonda> sebrock: you still have to remove all packages (or downgrade them) manually
<al-maisan> sebrock: do a "apt-get upgrade" afterwards?
<sebrock> I've removed them
<kklimonda> sebrock: then you are all set
<sebrock> I mean I want to remove the source
<kklimonda> just delete the file, and do apt-get update
<kklimonda> source of what?
<al-maisan> sebrock: oh sorry yes s/upgrade/update/
<sebrock> I figured that out myself :P
<sebrock> alright it seems to have worked...
<sebrock> strange there is a command to do that small task
<kklimonda> well, there is a ppa-purge :)
<kklimonda> (you have to install it by hand in lucid though, or enable backports)
<sebrock> ok Im trying to build a package here. it says I should set: --disable-md5 --disable-sha1 --disable-sha2
<sebrock> where do I set that?
<sebrock> debian rules or whatever...
<Laney> what's 'it'?
<Rhonda> In the configure switches in debian/rules
<sebrock> so I invoke configure with them switches?
<Rhonda> Most probably, but that still depends on what "it" is and the likes. It's just a guess based on the minimum information that you offered us.
<Rhonda> You see, the more information, the mor accurate the answers could be. :)
<sebrock> it is a blog post
<sebrock> http://blog.coombabah.net/wiki/strongswan
<Rhonda> It is pretty explicit on what to change.
<Rhonda> "Now edit debian/rules and change â¦ to â¦"
<sebrock> explicit would be the name of the file to edit
<sebrock> this assumes knowledge of editing debian rules
<Rhonda> But it carrys the name of the file to change.
<Rhonda> No, it doesn't.
<sebrock> am I blind?
<sebrock> :D
<Rhonda> debian/rules is a filename.
<sebrock> ah I see
<sebrock> I thought it was a name
<AnAnt> Hello
<RainCT> bdrung: http://paste.debian.net/105852/
<udienz> ari-tczew, alive?
<udienz> about merge firestarter. i found that a desktop file contained errors
<ari-tczew> udienz: nope
<udienz> i'have checked with desktop-file-validate
<udienz> can i patching it?
<udienz> http://paste.ubuntu.com/559084/
<ari-tczew> udienz: if you have right fix, please patch and note in d/changelog in separate star *
<ari-tczew> under information about merge
<udienz> ari-tczew, bug 694413 ready to review
<ubottu> Launchpad bug 694413 in firestarter (Ubuntu) "Merge firestarter 1.0.3-9 (universe) from Debian unstable (main)" [Medium,Incomplete] https://launchpad.net/bugs/694413
<ari-tczew> udienz: News accepted.
<ari-tczew> will take a look when have a time
<udienz> ari-tczew, okay. i will wait
<ari-tczew> udienz: do you know how fix that FTBFS? [LD_ERROR] misc.c:229: undefined reference to `log10'
<ScottK> kklimonda: You want to backport 1:2.6.26+dfsg?
<udienz> ari-tczew, that must be a libs not placing after object
<udienz> or a needed libs placed to end
<ScottK> kklimonda: If nothing else it can be done as a direct upload.
<ari-tczew> udienz: I got similiar error during build erlang (main)
<ari-tczew> you can try to merge it from unstable and fix ftbfs
<udienz> ok, i'll loking
<kklimonda> ScottK: not anymore as it doesn't work as it should but the question remains - can I backport from any newer release, or should I backport from the most recent release/development one?
<kklimonda> ScottK: If I can backport from any more recent release what happens in situation when (for example) I want to backport to lucid package from maverick that enables feature A, and then someone else wants a release from natty that enables feature B, and disables a feature A? ;)
<cjwatson> undefined reference to `log10'> as the log10(3) man page explains, "Link with -lm"
<ari-tczew> udienz: ^^
<shadeslayer> hi
<shadeslayer> im a bit confused about : " usr/lib/mono/* debian/tmp/opt/project-neon/usr/lib/mono/* "
<shadeslayer> is that the right way to move files from usr/lib/mono to other dirs?
<ScottK> kklimonda: You can backport from any newer release.
<ari-tczew> udienz: if you like, try to link -lm as cjwatson suggested on package tstools
<udienz> ari-tczew, okay. still downloading :(
<ari-tczew> udienz: ah, right, king size
<udienz> and my connections is very bad tonight
<broder> ScottK: if you have a moment, could you glance at bug #708757? i think this should be an easy one
<ubottu> Launchpad bug 708757 in maverick-backports "Please backport libpipeline (1.1.0-1) from natty to lucid, maverick" [Undecided,Confirmed] https://launchpad.net/bugs/708757
<ScottK> Sure
<ScottK> broder: Approved.
<broder> thanks
<bdrung> RainCT: please pull the latest version of lp:ubuntu-dev-tools and test again.
<ari-tczew> udienz: new comment added on firestarter
<ari-tczew> needs fixing
<bdrung> ari-tczew: please file a bug requesting a nicer looking error message.
<ari-tczew> bdrung: ah yea, I forgot
<ari-tczew> bdrung: for this time while I'm reporting bug, you could take a quick work on bug 708695 :>
<ubottu> Launchpad bug 708695 in avogadro (Ubuntu) "rebuild with python-numpy 1.5.1" [Undecided,Confirmed] https://launchpad.net/bugs/708695
<bdrung> ari-tczew: in a few minutes after sqeezing the last performing bits out of my buddy implementation
<ari-tczew> :>
<ari-tczew> bdrung: bug 708862
<ubottu> Launchpad bug 708862 in ubuntu-dev-tools (Ubuntu) "[pull-debian-source] Ugly error" [Undecided,New] https://launchpad.net/bugs/708862
<ari-tczew> bdrung: I guess that there are more bad looking errors in scripts.
<bdrung> probably
<bcurtiswx> doctormo, what would you think of allowing ground control to work when you have nautilus open with another server.. i.e. I connect-to-server to my desktop which is where i store all the bzr gets, groundcontrol still works since i've got nautilus up... or would it if i have ground control on the desktop?
#ubuntu-motu 2011-01-28
<jfer> hi all i was wondering if there were plans to package acire for ubuntu 10.10?
<Bachstelze> jfer: if it isn't packaged yet, it will never be
<Bachstelze> in the official repos, at least
<persia> Why?
<RAOF> Well, that's not strictly true.  It could be packaged in Natty and then backported, or it could possibly go through the ARB.
<persia> Indeed.
<jfer> ok
<ari-tczew> jfer: do you want to pack it?
<Bachstelze> natty is past FF, do new packages generally get an exception?
<Bachstelze> er no, it's past import freeze
<Bachstelze> meh
<Bachstelze> I need to go to bed
<jfer> i think that jono is the maintainer of the package so i might contact him
<persia> Ubuntu doesn't really have maintainers, but he may be able to help, certainly.
<MTecknology> what section would a -common package belong in?
<RAOF> What section is the base package in?
<MTecknology> RAOF: they should be the same?
<RAOF> It's a pretty reasonable bet.
<RAOF> The if -common package is for a library, then it's essentially part of that library and lives in the same section.
<MTecknology> RAOF: not a library, the main package is in httpd
<MTecknology> is there a debug section?
<RAOF> If it's only useful in conjuction with $BASE_PACKAGE and doesn't obviously fit into any other sections, throw it in the same section.
<MTecknology> nvm- i see it now :)
<MTecknology> thanks :)
<Rhonda> Yes, there is a debug section, but how would a -common package qualitfy for debug?
<MTecknology> I was looking at the other packages provided
<MTecknology> the -dbg packages
<Rhonda> ah
<micahg> if I'm fixing a FTBFS error from a sync, do I need to use -v on upload?
<MTecknology> I have this .logrotate file (http://dpaste.com/361716/) and I need to add a command in there; can I just add that command to the bottom?
<MTecknology> It needs to be either   kill -USR1 `cat /var/run/nginx.pid`   or   nginx -s
<MTecknology> heh....... I feel really dumb now
<Rhonda> Either in the prerotate or postrotate part, but isn't that there already? :)
<RAOF> micahg: The sync has already been processed by the archive, so you only need to have the new changes in the changes file.
<MTecknology> Rhonda: ya, that was why i felt really dumb :P
<micahg> RAOF: k, that's what I thought, thanks
<dholbach> good morning
<MTecknology> dholbach: howdy
<MTecknology> I love being able to use the excuse.. I can't do anything, it's compiling.
<MTecknology> Is there any way to tell dh_installchangelogs to install the changelog to a different directory? to ./usr/share/doc/nginx/changelog.gz instead of ./usr/share/doc/nginx-common/changelog.gz
<MTecknology> I'd like to do it with two different packages and a could different things... I want things installed as nginx instead of nginx-common
<Rhonda> MTecknology: Put nginx-common as first binary package in debian/control
<Rhonda> And actually, man dh_installchangelogs has documentation on its options ;)
<MTecknology> Rhonda: there's an 'nginx' package too, a dummy one though; there's two packages that I want to install stuff into the one directory for too
<MTecknology> Rhonda: I was looking at the man page for that app, and then started looking through man debhelper, still looking
<MTecknology> maybe -ppackage is what I need?....
<MTecknology> no..
<geser> good morning
<MTecknology> geser: how ya been?
<MTecknology> geser: maybe you can help me... you've helped me out on a lot of toughies before... :)
<MTecknology> geser: http://dpaste.com/361974/   nginx is a dummy package that selects nginx-full; I don't really think it needs the changelog in it; I'd like the nginx-doc and nginx-common package to install things to ./usr/share/doc/nginx/ instead of what they do now..
<MTecknology> wow... 10min to ask a question.. punishment of 03:30 and booze
<geser> MTecknology: currently no idea, try to find other split packages and check how they do it
<MTecknology> geser: i tried but couldn't find much that didn't have files laid out the same way which means either a) they don't care or b) they don't knoe
<geser> and check what Debian policy allows
<MTecknology> or c) it's not allowed..
<MTecknology> I need to learn how to find what I want in that policy
<geser> for the -doc packages you could have a symlink in /usr/share/doc/nginx/html (or what ever) and point it to /usr/share/doc/nginx-doc/
<MTecknology> hm.. i remember something about symlinks.. i'll try to find where i saw that
<MTecknology> geser: does it look kinda ok from what you can see from that little bit?
<geser> "/usr/share/doc/package may be a symbolic link to another directory in /usr/share/doc only if the two packages both come from the same source and the first package Depends on the second."
<geser> and a footnote mentions that you need a strict dependency (= version)
<MTecknology> geser: where at is that?
<geser> http://www.debian.org/doc/debian-policy/ch-docs.html 12.3 Additional documentation, 5th paragraph
<MTecknology> thanks :D
<geser> if you would do this symlink (if it would work in your case), your -doc package would need to depend on nginx (or the other way around, depending how you symlink)
<geser> and if you depend on the -doc package, you don't gain anything by the package split
<MTecknology> Maybe I'm getting a little bit pedantic in my wants..
<MTecknology> !info svn-buildpackage
<ubottu> svn-buildpackage (source: svn-buildpackage): helper programs to maintain Debian packages with Subversion. In component universe, is extra. Version 0.8.1 (maverick), package size 142 kB, installed size 600 kB
<MTecknology> I've heard that people naturally adjust to a 25hr day; being unemployed for a long time, i'm starting to really believe it
<MTecknology> every day, I want to stay up an extra hour
<jderose> hello, i was wondering if someone debhelper savy could help me fix the problem i describe here - https://bugs.launchpad.net/pyskein/+bug/709247
<ubottu> Ubuntu bug 709247 in PySkein "[packaging] UnicodeDecodeError when LANG not set" [High,Triaged]
<jderose> basically i need to make sure setup.py is called with LANG=en_US.UTF-8, but i'm not debhelper/make savy enough to get it working :)
<doctormo> persia: ping
<persia> Yes?
<doctormo> persia: that's weird, my irc client says your not here. And yet here you are.
<cjwatson> jderose: I've commented with a suggested approach
<jderose> cjwatson: thanks so much, i've been totally stuck on this!
<jderose> cjwatson: quick question: how do I "make your other targets depend on debian/tmp-locale"? sorry, not very make savvy
<cjwatson> jderose: like this: override_dh_install: debian/tmp-locale
<jderose> cjwatson: okay, thanks again!
<cjwatson> (sorry, override_dh_auto_install in your case, but you get the idea)
<cjwatson> jderose: also, 'override_dh_python2:\n\tdh_python3 ...' is just weird ...
<cjwatson> why not just 'dh $@ --with=python3' in the '%' target at the top?
<jderose> cjwatson: agreed, i copied from some other python3 packages... how should i do it?
<cjwatson> possibly --with=python2,python3 if you want both dh_python2 and dh_python3, but I don't know whether you do
<cjwatson> I guess not, your control file is 3-only
<jderose> right now pyskein is python3 only
<cjwatson> you might also want --without=python-support
<jderose> so if i have --with=python3, i no longer need override_dh_python2?  do i still need    override_dh_auto_install?
<cjwatson> you don't need override_dh_python2
<jderose> what does --without=python-support change?
<cjwatson> turns off the default call to dh_pysupport
<cjwatson> I'm not sure how dh_python2 was being called for you at all in the first place, since dh_python2 is only used if you say --with=python2, unless something has changed
<jderose> is that needed because dh_pysupport is python2 only?
<cjwatson> I believe it to be
<cjwatson> it's being phased out anyway, eventually
<jderose> cjwatson: my adaptation from httplib2 might not be without serious misunderstanding on my part :)
<cjwatson> you still need override_dh_auto_install since you need to modify the call to setup.py
<cjwatson> I wouldn't know about that ...
<doctormo> jderose: I would, what would you need to make setup.py do?
<jderose> doctormo: well, i don't need to do anything special except make it work with python3.  i'll admit i don't understand that rules file, but looking at other python3 packages, they all seem to have rules kinda like that
<doctormo> jderose: I see, so your issue is with the debian dh side of things rather than distutils.
<jderose> doctormo: right, although there is a bug in distuils i'm also https://code.launchpad.net/~pyskein/pyskein/packaging
<jderose> i'm also working around
<jderose> cjwatson: i'm still getting the same build failure, would you mind looking at my rules to see if you spot any problems? http://bazaar.launchpad.net/~pyskein/pyskein/packaging/view/head:/debian/rules
<MTecknology> ok.. there was a way to see what package installed what file, right?   what was that?
<jderose> MTecknology: dpkg -S /usr/bin/inkscape
<ari-tczew> jderose: could you show us error message?
<jderose> http://launchpadlibrarian.net/63030182/buildlog_ubuntu-natty-amd64.pyskein_0.7.0-0ubuntu5_FAILEDTOBUILD.txt.gz
<MTecknology> thanks :D
<jderose> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 71: ordinal not in range(128)
<jderose> this is actually the result of an upstream Python bug when no locale is set, so a need to create a locale when it's built on build server, but i can't get it working
<ari-tczew> python 3.2? wow, natty bases on 2.7
<jderose> PySkein is python3 only ATM
<jderose> plus, python3 is the future :)
<bencer> hi all, i just uploaded a new version of libredis-perl to debian and filled this but to sync the package for natty, #709431. is there anything else i should do?
<geser> bug #709431
<ubottu> Launchpad bug 709431 in libredis-perl (Ubuntu) "Support redis 2.0" [Undecided,New] https://launchpad.net/bugs/709431
<micahg> bencer: best to use the requestsync tool
<micahg> it's in ubuntu-dev-tools
<geser> which is also in Debian
<bencer> going to have a look
<kklimonda> jderose: barry may be a better person to ask about it. He has reported bug on python tracker about gettext not supporting LOCPATH, it may be related.
<jderose> kklimonda: this is bug the the PySkein author pointing me to - http://bugs.python.org/issue9561
<jderose> barry: could your infinite Python wisdom offer any guidance on this build problem? https://bugs.launchpad.net/pyskein/+bug/709247   :)
<ubottu> Ubuntu bug 709247 in PySkein "[packaging] UnicodeDecodeError when LANG not set" [High,Triaged]
<micahg> is there a more proper way to make a comment like this in a patch: http://bazaar.launchpad.net/~mathieu-tl/ubuntu/natty/evolution-rss/688776.stan+debfixes/revision/22
<kklimonda> jderose: I don't think there is much that can be done, in bug http://bugs.python.org/issue10419 (which is linked in 9561, and which seems to describe exactly your situation) there is a patch that should be applied to distutils script to fix that.
<kklimonda> jderose: other than monkey patching build_scripts at the runtime (which is an awesome idea, the kind of mad men propose) the best bet would be to wait for the fix to get into python ;)
<jderose> kklimonda: shouldn't it be possible to create the necessary environment in debian/rules though?  i mean, it builds fine on my system, just not build servers
<kklimonda> jderose: http://bugs.python.org/issue8409 suggests that gettext doesn't honour LOCPATH, it may be related
<kklimonda> jderose: the fix may be to generat locales system-wide
<jderose> kklimonda: um, how would i do that?  :)  http://bazaar.launchpad.net/~pyskein/pyskein/packaging/view/head:/debian/rules
<kklimonda> jderose: remove $@/en_US.UTF-8 from the localegen invocation (actually you can remove whole debian/tmp-locale target and move localedef to override_dh_auto_install
<kklimonda> no, wait - don't remove whole $@/en_US.UTF-8
<kklimonda> just $@/
<kklimonda> and leave en_US.UTF-8
<jderose> if ! localedef -i en_US -c -f UTF-8 -A /usr/share/locale/locale.alias --quiet en_US.UTF-8; then \
<jderose> kklimonda: it should be like that? ^^^  and then do i remove LOCPATH=$(CURDIR)/debian/tmp-locale?
<kklimonda> jderose: try that http://paste.ubuntu.com/559670/
<kklimonda> well, you can remove the LOCPATH
<jderose> kklimonda: thank you! trying...
<jderose> kklimonda: so on the build servers will rules have sufficient permissions to modify system wide locale?
<kklimonda> jderose: each build is done in a chroot (or maybe vm), so they have all rights inside it
<jderose> kklimonda: ah, gotcha.  well, i just did a dput, maybe this got it. thanks again for the help!
<ari-tczew> kklimonda: maybe you should consider join to MOTU?
<kklimonda> ari-tczew: I did, now I just need some time to gather endorements.
<ari-tczew> kklimonda: create a wiki page and I'll comment
<kklimonda> I'd have to go through my bugs, and see who did sponsor them - which is taking me more then required. But then I've always been.. less motivated on winters ;)
<kklimonda> ari-tczew: https://wiki.ubuntu.com/KrzysztofKlimonda/MOTUApplication
<ari-tczew> kklimonda: from my documents mean that I've sponsored for you 1 bugfix.
<kklimonda> ari-tczew: no idea - my documentation is lacking :)
<ari-tczew> kklimonda: but I remember that I asked you for fix bug and you prepared a patch so quickly which is good asset for comment.
<kklimonda> ari-tczew: ah, the g-s-d
<ari-tczew> kklimonda: no, gwget, but right, g-s-d as well :)
<kklimonda> right
<ari-tczew> kklimonda: have you got more to sponsor ATM?
<kklimonda> ari-tczew: hamster-applet for natty, and same version as sru for maverick - bug 697667 and bug 654397
<ubottu> Launchpad bug 697667 in hamster-applet (Ubuntu) "Update hamster-applet to 2.32.1" [Wishlist,New] https://launchpad.net/bugs/697667
<ubottu> Launchpad bug 654397 in hamster-applet (Ubuntu Maverick) "Reports lack totals" [Wishlist,Triaged] https://launchpad.net/bugs/654397
<ari-tczew> kklimonda: OK, I'll get them. Do you consider sponsoring time when you be in MOTU? ;)
<kklimonda> ari-tczew: I don't know, I don't like to touch stuff that I don't use or at least care for as I can't be sure if I'm not breaking it. But I could sponsor stuff for things I care about, or general things like ftbfs, packaging fixes, or transitions.
<ari-tczew> kklimonda: yea, small patches like FTBFS fixing are welcome to sponsor. January is last month when I got time for Ubuntu.
<maco> kklimonda: you're not a motu?
<ari-tczew> kklimonda: I had a quick research of your uploaded packages and there are some sponsors which did for you single uploads (1-2, no more). dholbach, coolbhavi, quadrispro, chrisccoulson or seb128
<maco> hmm i feel like ogra now. thats what he said to me a month before i applied for motu
<micahg> maco: that's generally a sign it's time for someone to apply :), happened to me too
<ari-tczew> maco: If you feel that kklimonda should join MOTU, comment his application. ;)
<maco> ill take a look at his uploads. i just see him doing so much i assumed he was one already
<ari-tczew> maco: maybe you want these 2 things hamster-applet to sponsor to be sure?
<ari-tczew> My endorsement is so strong without them, so I can leave them for someone else who want to comment kklimonda's application.
<maco> i cant do any sponsoring til i get internet access at home
<maco> which ...assuming i get first paycheque monday...should be about a week
<maco> (tarballs + starbucks dont mix)
<micahg> maco: so you need the BW equivalent of the trente?
<maco> the what what?
<micahg> err, bandwidth equivalent of the trenta, http://www.starbucks.com/blog/653/-trenta-means-more-refreshment
<maco> well actually...i could ssh to my vps
<maco> 31oz? who use 31? that is not a multiple of 4!
<kklimonda> maco: well, I just see uploading rights more as a responsibility, and less as a privilege. But I guess it's time to grow up a little ;)
<micahg> kklimonda: in reality it's both
<kklimonda> hmm.. once again I got lost in my directory with various packages..
<kklimonda> can someone describe how he or she keeps his packaging environment organized? :)
<kklimonda> I've tried various ways but it all falls apart at some point, especially when I do some work on debian packages additionally.
<micahg> kklimonda: I have everything in /opt/source, then under that I have a folder for each release, then under that a folder for sync, merge, and each pocket (-proposed, -security)
<kklimonda> micahg: so you don't use bazaar for packaging?
<micahg> kklimonda: generally not, but I also have a bzr branch under each release as well
<micahg> s/branch/folder
<kklimonda> mhm
<micahg> actually, hmm, there's more, I have a bzr folder under /opt/source for stuff I manage outside the distro, I also have /opt/source/daily for the mozilla dailies :)
<kklimonda> I like the idea with creating new folders for -proposed and -security
<hakermania> Why revu has this sign of Christianity?
<micahg> kklimonda: for people that always track lp:ubuntu/foo, I guess you can have those in a separate folder as well
<Pici> hakermania: Um.  What are you referring to exactly?
<kklimonda> hakermania: it's the same logo as MOTU have on LP, I don't think it's meant to be a cross.
<kklimonda> at least not the christian one.
<hakermania> Pici, kklimonda: I'm just wondering if it means something...
<micahg> it's the ubuntu-dev badge on LP actually
 * micahg heads out for a bit
<kklimonda> good point :)
<ari-tczew> kklimonda: a piece of my packaging environment ;) http://people.ubuntu.com/~ari-tczew/environment/
<ari-tczew> I don't have that structure as micahg has, but I remember (yet) which package is for what.
<kklimonda> so I just done something funny
<kklimonda> I wrote find . -type f -delete instead of find . -maxdepth 1 -type f -delete
<kklimonda> good it wasn't in some important folder..
<maco> kklimonda: i keep source packages in ~/src/ and if its stuff-to-sponsor then in ~/src/sponsor/  -- code i write goes in ~/code/
<kklimonda> maco: and how do you keep package in ~/src ?
<kklimonda> packages*
<maco> one dir per source package, with its .orig, .dsc, and .diff.gz & unpackedness in there
<ari-tczew> it's very good topic for blog or something :)
<ari-tczew> bdrung: ping
<maco> kklimonda: all the versions i have of that src pkg are in that dir together. though if i also maintain it in debian, theres a debian dir in there to keep debian and ubuntu separate
<kklimonda> maco: ah, I end up with a mess when I do that really quick - like ls ~/code/maintainance/transmission |wc -l
<kklimonda> 100
<kklimonda>  ;)
<maco> occasionally i delete dirs from ~/src/ for stuff ive already uploaded
<maco> it tends to result in reclaiming several gigs of disk space
<kklimonda> yeah, this is really nice side effect :)
<kklimonda> I've actually started unpacking random pieces of software (like packages I'd like to take a quick look at) in /tmp so I don't have to remember about them.
<jderose> kklimonda: hmmm, still not working, seems like build servers didn't like creating the locale - http://launchpadlibrarian.net/63035122/buildlog_ubuntu-natty-amd64.pyskein_0.7.0-0ubuntu6_FAILEDTOBUILD.txt.gz
<kklimonda> hmm, builders may be dropping privileges after unpacking everything.
<kklimonda> jderose: now, there is one more thing you can try doing.
<kklimonda> jderose: adding langpack-all | language-pack-en-base to build-depends
<jderose> ah, okay
<kklimonda> jderose: but I'm not sure if it will work with official Ubuntu builders
<jderose> kklimonda: and keep rules as is?
<kklimonda> jderose: you can remove localedef call
<kklimonda> hmm
<kklimonda> jderose: but it may not build when you try to upload package to official ubuntu archives.
<kklimonda> for a reason I don't know yet
<kklimonda> (as it builds fine on ppa builders)
<jderose> well, getting building on ppa builders will be a good step  :)
<jderose> kklimonda: ug, still not working - http://launchpadlibrarian.net/63041366/buildlog_ubuntu-natty-amd64.pyskein_0.7.0-0ubuntu7_FAILEDTOBUILD.txt.gz
<jderose> kklimonda: but thanks so much for all the help!
<kklimonda> jderose: try LC_ALL instead of LANG
<jderose> so LC_ALL=en_US.UTF-8 ?
<kklimonda> yes
 * jderose dputs
<kklimonda> jderose: configuring local pbuilder would make it much faster :)
<jderose> by default pbuilder will have locale setup thought, wont it?  how to i make it like the ppa build servers in this way?
<kklimonda> jderose: no, pbuilder creates an empty chroot so it wouldn't have any locales set
<jderose> ah, okay, i'll play with that then...
<kklimonda> (empty of packages other than essential minimum)
<kklimonda> ari-tczew: heh, how can this folder that clean (speaking of http://people.ubuntu.com/~ari-tczew/environment/env.jpeg) ;)
<kklimonda> cjwatson: bah, looks like python ignores LOCPATH so I can't use localedef as an alternative to langpack-all | language-pack-en-base :/
<ari-tczew> kklimonda: as I said, in general I know which package is for. TODO file helps sort out ;)
#ubuntu-motu 2011-01-29
<bdrung> ari-tczew: pong
<jderose> kklimonda: with that last change you suggested, the build is finally working! https://launchpad.net/~novacut/+archive/stable/+buildjob/2229834
<jderose> kklimonda: thank you *so* much for all the help!  :)
<kklimonda> jderose: no problem :)
<jderose> i'm still kind of awed it actually worked... i was chasing some serious windmills for a while :)
<doctormo> I need some help with a dkms package, it's expecting files to have been stashed in /usr/src/$package-$version/ and possibly expects a tar.gz to have been there too. But the example code I'm working from doesn't seem to have any debian code to put any files there... I was wondering if there was magic.
<bdrung> ari-tczew: pong
<ari-tczew> bdrung: could you sponsor one new package in Debian?
<bdrung> ari-tczew: maybe later this day
<ari-tczew> bdrung: wanna link right now?
<bdrung> ari-tczew: yes
<ari-tczew> bdrung: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=rsplib
<ari-tczew> thanks
<ari-tczew> wgrant: what do you think if Canonical could adopt lucas' FTBFS script, dedicate one server and rebuild archive once a week?
<wgrant> ari-tczew: It requires a lot more than a single server.
<ari-tczew> wgrant: why? maybe more HDDs
<wgrant> We could do a rebuild on a single architecture on LP every week. But the efficiency of such a frequency is questionable.
<wgrant> ari-tczew: Package builds take a while.
<ari-tczew> wgrant: then i386 :)
<wgrant> The i386/amd64 rebuild should be finished in 3 or 4 days.
<wgrant> Why do you want everything rebuilt every week?
<wgrant> Archive rebuilds are not quite free.
<ari-tczew> wgrant: For fresh look on packages with FTBFS. However, I know that there are not many contributors which work on fix FTBFS.
<mok0> Is there a package containing the ubuntu logo?
<ari-tczew> kklimonda: there is DEPWAIT on transmission.
<kklimonda> ari-tczew: yeah, I've noticed but I didn't have time to check it further.
<grunthus> Hello, I have just tried my first debdiff patch for bug 706271!
<ubottu> Launchpad bug 706271 in synaptic (Ubuntu) "synaptic network proxy preferences doesn't capitalize "internet"" [Undecided,Confirmed] https://launchpad.net/bugs/706271
<ari-tczew> hello grunthus
<grunthus> hi
<grunthus> That was my second attempt. Realised I had forgotten the changelog first time around.
#ubuntu-motu 2011-01-30
<ari-tczew> grunthus: do you want to get your debdiff uploaded?
<ari-tczew> then you need to subscribe ubuntu-sponsors
<grunthus> aha.
<paultag> I hate to be a whiny one, but is there anyone who can review #703718 ?
<paultag> Oh wait, shoot
<grunthus> found the instructions for sponsorship
<paultag> looks like it was handled. Stupid cache
<paultag> ignore me, thanks
<paultag> Riddell: thanks for killing fluxconf :)
<ari-tczew> broder: can we finish bug 690927 ?
<ubottu> Launchpad bug 690927 in tpb (Ubuntu) "Sync tpb 0.6.4-6 (universe) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/690927
<grunthus> ari-tczew: given that my patch is for synaptic, should that be forwarded to debian?
<ari-tczew> grunthus: are you an author of patch or did you take it from upstream?
<grunthus> i produced the patch myself from apt-get source synaptic
<ari-tczew> grunthus: I'd prefer to see your patch approved upstream, so wait for mvo (Michael Vogt) response on bug.
<ari-tczew> grunthus: you have error in debdiff. target in debian/changelog should be natty (I guess) and bug #xxx is wrong, please use rather (LP: #706271)
<ari-tczew> s/error/errors
<grunthus> thank you for advice, will alter it
<ari-tczew> grunthus: also would be nice to delete obsolete files on the bug leaving only working debdiff
<grunthus> Hello ari-tczew, done all that and uploaded a new patch.
<grunthus> But, I've just noticed the bug report refers to synaptic 0.75~pre4, whereas of course, since my system is maverick, I have 0.63.1
<ari-tczew> !SRU | grunthus
<ubottu> grunthus: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<grunthus> OK ari-tczew, back to the start for me then, this doesn't warrant a SRU.
<ari-tczew> grunthus: no?
<grunthus> the link you posted says SRUs only issued for high impact bugs
<grunthus> I should presumably set up a Natty virtual machine with testdrive and then create the patch for synaptic 0.75
<ari-tczew> grunthus: heh, high? not always, trust me :)
<ari-tczew> sometimes we bring SRUs for very hard to reproduce bugs
<grunthus> Well, I have added a cautionary note under my latest patch, so can leave to the discretion of M. Vogt.
<grunthus> Thanks again for your help.
<ari-tczew> grunthus: You're welcome.
<c2tarun> I have a question related to grub. Where can i ask?
<paultag> hyperair: I just checked your package on mentors, sent mail to the list
<hyperair> paultag: yeah i saw. thanks.
<hyperair> paultag: i thought i fixed all those errors.
<paultag> hyperair: I saw the patch in debian/
<hyperair> yeah
<hyperair> if you notice, there's a Bug: link
<hyperair> which is an upstream bug link
<paultag> hyperair: yeah I saw
<hyperair> so i have forwarded the patch
<paultag> hyperair: but I did not want to pick on you on the list
<hyperair> hmm?
<paultag> hyperair: it looks a bit bad if you have a patch that does not do it's job, so I figued i'd just post the issue and avoid doing the usual "Why do you have a patch if it's not fixing anything" thing
<hyperair> paultag: either way, i don't usually bother about the pedantic tags. they're pedantic for a reason, and i can't translate the debconf template myself.
<paultag> hyperair: yeah, it's an upstream issue
<hyperair> paultag: did it not fix the issue?
<paultag> hyperair: but still good to know
<hyperair> paultag: it did for me, and lintian doesn't complain
<paultag> hyperair: lintian complains for me
<hyperair> lemme check
<hyperair> paultag: there's nothing!
<paultag> hyperair: what are you running lintian with?
<hyperair> with nothing?
<hyperair> oh geez, another pedantic tag?
<paultag> hyperair: http://pastebin.com/G3tdCzyM
<hyperair> thanks
<paultag> hyperair: cheers, good luck!
<hyperair> thanks
<hyperair> paultag: this is weird. i'm on a utf-8 locale, and and it's interpreted as a minus for me, rather than a hyphen
<paultag> hyperair: humm? Yeah, it's described in the extra info lintian included in that paste
<paultag> Oh wait, you said the other way around
<paultag> hyperair: odd. Is lintian whining?
<hyperair> paultag: the lintian info mentions that on utf-8 it gets interpreted as hyphen
<paultag> with -iIE ?
<paultag> hyperair: yes :)
<hyperair> paultag: use a utf-8 locale, and run man on the manpage
<paultag> hyperair: same issue is showing up
<paultag> I was already on UTF-8
<hyperair> paultag: and is the - U+2010 or U+002D?
<paultag> hyperair: the issue is that it's showing up as unicode hyph when it should be minus
<hyperair> but it's showing up as a minus on mine!
 * hyperair is bewildered
<micahg> does cgit have a blame mode?
<paultag> hyperair: /me shrugs
<paultag> hyperair: not sure
<hyperair> Char: - (45, #o55, #x2d) point=1 of 1 (0%) column=0
<paultag> micahg: cgit?
<hyperair> paultag: so emacs says
<paultag> oh a web front-end
<paultag> micahg: no clue :(
<paultag> hyperair: I'm not sure, man. All I know is it's an error here
<hyperair> paultag: what's your locale?
<paultag> hyperair: http://pastebin.com/aPwwkPR8
<paultag> anywho, about time to call it a night. about 2 AM here
<paultag> hyperair: good luck, send me a message if you figure it out, I'd be interested to know
<hyperair> paultag: sure, thanks
<hyperair> paultag: oh, how did you check what character it was using?
<paultag> hyperair: look at the source page
<hyperair> paultag: what?
<paultag> hyperair: the man page is fine because groff was patched, it's in the lintian issue report ;)
<paultag> The Debian groff
<paultag> N:    package currently forces "-" to be interpreted as a minus sign due to
<paultag> N:    the number of manual pages with this problem, but this is a
<paultag> N:    Debian-specific modification and hopefully eventually can be removed.
<hyperair> aaaah i see.
<paultag> hyperair: :)
<paultag> hyperair: have a great night, I'm off for real :)
<hyperair> heh it's afternoon here though
<hyperair> good night
<paultag> :)
<hakermania> When will REVU freeze?
<micahg> hakermania: REVU doesn't freeze
<hakermania> micahg: I remember that it does, 1-2 months before new Ubuntu release, in order to fix existing bugs. Am I wrong?
<micahg> hakermania: no, but after Feature Freeze (Feb 24), no new packages will be accepted in the release pocket
<micahg> err, without a really good reason
<hakermania> micahg: So, my package (wallch) must be advocated  before 24 Feb in order to be included to natty?
<micahg> hakermania: yes, what happened WRT Debian?
<hakermania> micahg: I don't know what WRT Debian is.
<micahg> hakermania: With Regard To
<hakermania> micahg: I don't know, I didn't search a lot about it... I find debian a little chaotic...
<micahg> hakermania: I can't advocate, but I could do another packaging review if you like
<hakermania> micahg: What is the "REVU of Debian"? If you know what I  mean...
<micahg> hakermania: mentors.debian.net
<hakermania> micahg: Thanks!
<hakermania> Can I delete my old uploads for a specific package and keeps the newest ones? In wallch i have 60 uploads, can i delete somehow the e.g. 30 first?
<coolbhavi> hakermania, are you referring to a ppa upload?
<hakermania> coolbhavi: No, to a normal upload to REVU...
<hakermania> http://revu.ubuntuwire.com/p/wallch
<ari-tczew> hakermania: You won't encourage developers to review your package through spamming.
<hakermania> ari-tczew: This isn't my purpose.
<hakermania> ari-tczew: Sorry for the multiple uploads, but we are trying to fix some "lackings" of a taken review from a site.
<ari-tczew> hakermania: I still don't understand. Patience is gold.
<hakermania> ari-tczew: We are fearing advocating before having finished what we have in mind.
<ari-tczew> micahg: why do you required UNRELEASED target in https://code.launchpad.net/~bratsche/ubuntu/natty/gnome-do/disable-resize-grips/+merge/46301 ?
<notgary> Hey. I was wondering if someone could clear something up for me.
<notgary> I'm attempting to fix a paper cut in pinta
<notgary> I have installed the package using sudo apt-get install pinta
<notgary> However,
<notgary> When I try to get the source or the build-debs
<notgary> *sorry, build-deps
<notgary> apt-get tells me it can't find any package called pinta
<notgary> I'm guessing it's something to do with the packaging, which is why I'm asking here.
<udienz> notgary, try to use pull-lp-source
<udienz> pull-lp-source pinta
<udienz> or pull-lp-source $srcpakacge $release
<notgary> Ok, that worked, but what about the build dependencies?
<stgraber> my guess is that pinta is a binary package, it's not the source package
<stgraber> hmm, nope, actually it's a binary package ...
<stgraber> can you try: apt-cache showsrc pinta
<stgraber> if it fails, then you have something wrong with your sources.list (like missing deb-src entries)
<notgary> Yeah, that failed, for both pinta and a few other packages I tested it with. How would I fix it?
<stgraber> make sure you have your deb-src lines in /etc/apt/sources.list
<notgary> They're there
<kklimonda> ScottK: Any idea how hard would that be to get dh_python2 to lucid-backports?
<ari-tczew> kklimonda: I have a proposition - you will merge mongodb in universe and I'll sponsor - what do you think?
<kklimonda> ari-tczew: I've been looking at it today but I have to ask micahg (or chrisccoulsons) ome questions about xulrunner dependency.
<kklimonda> micahg: can I build depend on xulrunner-1.9.2-dev or will it go away at some point making package unbuildable?
<chrisccoulson> kklimonda, please don't build-depend on xulrunner-1.9.2-dev ;)
<chrisccoulson> kklimonda, https://wiki.ubuntu.com/DesktopTeam/Specs/Natty/Firefox4/XULRunner20Transition
<kklimonda> chrisccoulson: right, so what can I do if the package doesn't build with xulrunner 2.0?
<chrisccoulson> any help is appreciated ;)
<chrisccoulson> kklimonda, fix it :)
<chrisccoulson> which package is it?
<kklimonda> mongodb
<chrisccoulson> oh, that's using spidermonkey, right?
<kklimonda> yes
<chrisccoulson> i'd suggest taking a look at my patch in couchdb
<chrisccoulson> that *should* cover most of the API changes
<kklimonda> brr, you've managed to patch couchdb?
<chrisccoulson> yes
<chrisccoulson> it was a bit of a pain ;)
<kklimonda> I see you didn't actually have to edit erlang files ;)
<chrisccoulson> no, that would be horrible
<chrisccoulson> ;==]
<chrisccoulson> oops
<chrisccoulson> daughter ;)
<chrisccoulson> kklimonda, the main API change is JSNative changed quite significantly (that is the prototype for all native calls callable from JS)
<chrisccoulson> https://developer.mozilla.org/en/JSNative
<chrisccoulson> i guess that's the main thing that will affect mongodb
<chrisccoulson> but there's lots of examples of that in couchdb :)
<kklimonda> thanks, I've started a build to see where it fails and will see what can I do about it
<chrisccoulson> the one thing to bear in mind is the old JSNative didn't mandate setting a return value, whereas with the new API, you *always* have to set a return value, even if it is JSVAL_VOID
<chrisccoulson> if you want any help though, just shout, although, i probably won't look at it until tomorrow ;)
<chrisccoulson> and you might hit a problem that i've not experienced too ;)
<chrisccoulson> getting things to work seems to be fairly hit-and-miss :/
<kklimonda> I love C++ error messages
<chrisccoulson> yes, me too :/
<chrisccoulson> what error do you get?
<kklimonda> http://pastebin.com/AB1sTquf
<chrisccoulson> error: invalid conversion from 'JSBool (*)(JSContext*, JSObject*, jsval, jsval*)' to 'JSBool (*)(JSContext*, JSObject*, jsid, jsval*)'
<chrisccoulson> are all due to JSNative ;)
<chrisccoulson> oh
<chrisccoulson> actually
<chrisccoulson> error: invalid conversion from 'JSBool (*)(JSContext*, JSObject*, uintN, jsval*, jsval*)' to 'JSBool (*)(JSContext*, uintN, jsval*)'
<chrisccoulson> those ones are ;)
<chrisccoulson> not sure where the first error comes from though
<chrisccoulson> i'm guessing there will be a lot of copying and pasting to fix it
<chrisccoulson> most of that is probably only 3 or 4 changes, but duplicated everywhere
<kklimonda> most likely, there is a lot of duplicated errors
<kklimonda> oh well, I'll see if I have time to work on that. I'm still trying to fix two packages that break with libevent2
<kklimonda> but I'd love to get it into natty..
<kklimonda> bah, I've fixed honeyd to compile with libevent2.. and I have no idea how to actually test it :(
<MTecknology> I need some help.. If 'nginx' was installed and you upgrade; 'nginx-full' will replace 'nginx'; 'nginx-full' requires 'nginx-common'; 'nginx-common' has a logrotate script which matches the script that was in 'nginx'; 'nginx' no longer has this script; however.. on upgrade, both scripts are installed.
<MTecknology> The only solution I've been able to think up is adding an 'rm' to nginx-common.postinst; this seems like a bad idea though and I'm working if there are any better options.
<micahg> hi cyphermox, I took a look at evolution-rss, but I'm not sure about the comment in the patch, I wanted to ask someone else if that was DEP-3 compliant
<cyphermox> micahg, ah
<cyphermox> micahg, according to my reading of dep-3 it is, when using Subject:
<cyphermox> e.g. short subject followed by a longer one... the only issue is with dpatch you need to comment that stuff
<ari-tczew> kklimonda: did you receive e-mail from dholbach about your development feedback on surveymonkey?
<kklimonda> ari-tczew: no, neither did I get the email with the link to voting. I wonder what's going on
<ari-tczew> kklimonda: voting for what?
<ari-tczew> kklimonda: come on polish :D
<nonix4> How could I get somebody to reproduce a dataloss bug & get it mentioned in releasenotes asap? Bug 710340 being it this time.
<ubottu> Launchpad bug 710340 in debian-installer (Ubuntu) "Maverick alternate installer corrupts existing data partitions when more than one cryptswap volume is enabled (/etc/crypttab should NOT refer to /dev/dm-*)" [Undecided,New] https://launchpad.net/bugs/710340
<micahg> nonix4: #ubuntu-bugs for triage, #ubuntu-devel for release notes (go with triage first)
<micahg> nonix4: actually, in this case, #ubuntu-installer might be best :-/
 * nonix4 wishes rsync --copy-devices --inplace existed in any stable form... restoring remote backup without that is annoyingly slow.
<highvoltage> tumbleweed: still awake?
#ubuntu-motu 2012-01-23
<dholbach> good morning
<dholbach> Laney, tumbleweed: if you still want to do the other session about "working in debian", could you please go and grab a slot soonish? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable - HUGS :)
<bkerensa> dholbach: Would be cool if Ubuntu Developer Week was a physical event... I surely could benefit from a week of development sessions :D
<dholbach> haha, yes, that'd be nice
<Laney> dholbach: yeah, sure
<Laney> sorry that it's harder work for you this time around :(
<dholbach> Laney, it's fine - I just want the schedule to be sorted out RSN, so I can still get in touch with some other Linux sites, so we get more participants this time - that's why I urge everyone a bit more than usual :)
 * Laney goes cross-eyed looking at wiki markup
<dholbach> Laney, I can help you with that if you tell me title and time :)
<Laney> got it
<dholbach> ok great
<dholbach> :)
 * dholbach hugs Laney and tumbleweed
<dholbach> thanks a bunch
<bkerensa> =o
 * tumbleweed supposes he should take on an extra session or two
<tumbleweed> dholbach: what were you thinking about for the pbuilder / sbuild session? advanced usage & hooks
<dholbach> maybe, yeah - maybe even some quick introduction about what the tools are, why they're useful, pros of each and how to generally use them
<dholbach> I'd leave it up to you :)
<tumbleweed> you do cover the basics in the intro, though?
<dholbach> tumbleweed, I'm not quite sure how much time I'll have - I'll sure mention it and ask folks to setup a pbuilder in the getting set up session - in the past I almost never had the time for them to actually build a package
<dholbach> but 2h in one sitting is probably as much as you can type non-stop :)
<tumbleweed> and there I thought you were copying-and-pasting :P
<dholbach> I did that the last time around and it helped a lot
<tumbleweed> well, I asked around here, and people thought that was the most useful from your list of suggestions, so I'll snag a 30min slot for it
<dholbach> but sometimes you can guess by the questions that you need to expand on a thought, etc
 * dholbach hugs tumbleweed
<dholbach> beers are on me next time we meet :)
<dholbach> oh and my friend showed me pictures of his trip trip Cape town yesterday - it was beautiful
<highvoltage> it still is :p
<dholbach> a shame he didn't read my mail in time to come to your LUG meeting
<tumbleweed> unfortunatly rather hot recently
<dholbach> highvoltage, ok, I meant the pics were beautiful :-P
 * highvoltage just wanted to chime in :)
<dholbach> highvoltage, hey, you could chime in with a session you're giving! :-)
<dholbach> highvoltage, how about a 30m demo of Edubuntu and what's cooking there? :)
<highvoltage> dholbach: tumbleweed has already been putting some pressure on me to do that. I guess I might just do that!
<tumbleweed> heh
<highvoltage> (and just last night I decided to say 'no' to more things)
<tumbleweed> dholbach: I can probably extend the pbuilder session to an hour if the schedule stays empty (going into sbuild if I run out of material)
<dholbach> highvoltage, sorry, I didn't mean to browbeat you into something
<dholbach> highvoltage, maybe some of your Edubuntu friends would be interested?
<highvoltage> dholbach: nah, not at all. I fullheartedly want to
 * dholbach hugs highvoltage
<highvoltage> *hugs*
<highvoltage> I just need to find ways to be more time-efficient (it's hard)
<dholbach> THAT's a session we should have at UDW :)
<dholbach> or two
<tumbleweed> highvoltage: I need a session on how to actually get a thesis done when there is so much fun OSS stuff to do
<highvoltage> yeah I bought a bunch of e-books on time management and how tobe more efficient when doing creative kind of work. but I haven't had the time to read them yet :)
<tumbleweed> :)
<highvoltage> tumbleweed: ah I thought you were very near to the end
<tumbleweed> time wise, that doesn't mean progress-wise
<Laney> th...e...sis?
<tumbleweed> the.... ooh, look, bugs!
<dholbach> Laney, nice work on LP!
<Laney> :-)
<Laney> was quite fun actually
<Laney> and to think it was all to make nigelb proud!
<dholbach> Laney, I guess there won't be a way to fix historic data, right?
<Laney> sadly not, as it wasn't stored anywhere
<dholbach> I thought so
<dholbach> but at least it's fixed from now on :)
<Laney> unless you want to trawl through bugs and do it manually :P
<dholbach> or well, when it landed
<dholbach> yeah, I great way to spend a lazy sunday afternoon
<dholbach> or 1500 lazy sunday afternoons
<Laney> heh
<dholbach> :)
<Laney> different definitions of 'great' possibly â¦
<dholbach> I guess it depends on how great your other lazy sunday afternoons are :)
<Laney> sunday afternoon is the afternoon for making soup
<nigelb> Laney: lol
<Laney> nigelb: do you know how often production is upgraded?
<nigelb> Laney: No, but this will help figuring out http://lpqateam.canonical.com/qa-reports/deployment-stable.html
<Laney> yeah I know that. It tells me what but not *when*
<nigelb> right now, nothing's blocking deployment
<nigelb> So, soon.
<Laney> like I don't know if it's a once a month thing or whatever
<Laney> dev.lp is hiding the goods somewhere, but I can't find out where
<Laney> ah well /me carries on being impatient ...
<nigelb> Laney: Its not once a month.
<nigelb> its several times a week.
<Laney> sweet
<Laney> 14700 was friday
<nigelb> When did everything get QA'd?
<nigelb> (I'm guessing some time today)
<Laney> dunno
<Laney> I don't mind waiting, was just wondering how frequent it is
<nigelb> Laney: except for db patches, which you have wait since there's only one window at a time, everything eelse is fairly fast after qa-ok.
<nigelb> the only trouble is, all revisions in the stack before yours need to be qa-ok as well.
<Laney> righto
<l3on> hey guys
<l3on> I have this unmetdep:
<l3on> Package: live-config-sysvinit
<l3on> Version: 3.0~a22-1ubuntu1
<l3on> Missing: sysvinit (>= 2.86)
<l3on> the problem is in ubuntu sysvinit does not exist, but we have:
<l3on> Binary: sysvinit-utils, sysv-rc, initscripts
<l3on> I'm going to change that, which package do you suggest ?
<l3on> I think initscripts should be fine, 'cause depends on the others two
<tumbleweed> seeing as Ubuntu uses upstart, why do we need that binary package?
<l3on> maybe someone would use sysvinit ?
<tumbleweed> if we don't have sysvinit, how could they? :)
<l3on> but we have : sysvinit-utils, sysv-rc, initscripts
<l3on> that come from sysvinit source
<Laney> we don't have sysvinit itself
<l3on> yes now I see
<l3on> ok.. so, drop that package ?
<l3on> I mean â Package: live-config-sysvinit
<tumbleweed> or just leave it as uninstallable (but we are already patching it, so might as well dropit)
 * l3on tries to drop it
<tumbleweed> we could use a better document for referring people to when they ask "what can I do for Ubuntu" (/me tries to avoid writing it)
<valterstr> :D
<valterstr> about me?
<tumbleweed> in general, but yes
<valterstr> so... the question, what can I start with?
<valterstr> bug tracker?
<tumbleweed> my usual suggestion is to pick a relatively obscure and un-cared-for package that you use, and tidy it up
<valterstr> will look into that...
<tumbleweed> (by tidy it up, I mean look through the bugtracker, see if we have applied patches that haven't been forwarded upstream, etc)
<valterstr> i understand
<valterstr> so, in general, look for older bugs that have fixes that have not been merged?
<valterstr> launchpad changed bug page interface recently?
<tumbleweed> review operation cleansweep patches? https://wiki.ubuntu.com/OperationCleansweep
<tumbleweed> yes
<l3on> since I'm going to propose a merge for live-config, someone would take a look to this ? bug 913874
<ubottu> Launchpad bug 913874 in live-config (Ubuntu) "live-config script is broken in ubuntu" [Undecided,New] https://launchpad.net/bugs/913874
<tumbleweed> valterstr: you can pretty much ask any questions in here and should get help (sometimes after several hours, if it's quiet)
<valterstr> ok.
<valterstr> thanks.
<valterstr> I will start looking through the bug tracker then.
<tumbleweed> harvest.ubuntu.com also aggregates things that should be looked at
<valterstr> also, the "pushing upstream through sponsor" thing. could you please explain it in more detail?
<tumbleweed> !sponsorship
<tumbleweed> err, maybe not
<tumbleweed> http://wiki.ubuntu.com/SponsorshipProcess
<valterstr> https://wiki.ubuntu.com/DistributedDevelopment/Documentation/SeekingSponsorship
<valterstr> but do I do it like that for the changes I do or is there another process I should do?
<tumbleweed> valterstr: that process works
<valterstr> ok
<valterstr> tumbleweed: big thanks for the help
<Laney> nigelb: oh, r14713 (Get the code!)
<Laney> !!!
<nigelb> \m/
<nigelb> omgomgomg
<Laney> ssssssssssssswwwwwwweeeeeeeeettttttttt
<tumbleweed> hah
<tumbleweed> Laney: will you sort out lp-udd.py ?
<Laney> yus
<Laney> sponsor something so i can test it :P
<nigelb> Laney's all charged up today. He can do *anything* you ask him to do.
<Laney> gotta submit this paper review
 * tumbleweed looks for a nice gnarly lp bug
<Laney> or ELSE
<Laney> tumbleweed: nah, next fix should be ui for this
<tumbleweed> yes, that'd be nice
<Laney> and not too hard
<Laney> want to do the python-markdown sync? could be ok but you'd know better
 * tumbleweed looks
<tumbleweed> probably safe, I'll do it
<Laney> sweet
<tumbleweed> can't be synced yte. importer is out of date
<Laney> bah
<l3on> hey guys... looking at bug 783568 mdeslaur suggests me to use a different notation for the version.. but I'm not clear a thing about oneiric ... also it need a ubuntu1.11.10.1 version ?
<ubottu> Launchpad bug 783568 in gdevilspie (Ubuntu Oneiric) "missing dependency" [Undecided,In progress] https://launchpad.net/bugs/783568
<l3on> sorry, ubuntu0.11.10.1 ?
<micahg> l3on: yes
<l3on_> mmm...
<l3on_> I mean, in oneiric should be ubuntu1 .. no ?
<l3on_> considering precise has a new version of gdevilspie
<micahg> l3on_: no
<micahg> ubuntu1 should only be used in the devel release
<l3on_> ah ok :) thanks micahg
<l3on_> ok, branches updated... micahg could you take a look ? :)
<micahg> l3on_: non-security stuff, sure, I'll take a look when I pilot a bit later if that's ok
<l3on_> thanks
<jtaylor> l3on: shogun was "fixed" can you update the merge? also check if the hdf5 stuff is ok
<jtaylor> btw is there interest in getting the hdf5 transition done in precise too?
<jtaylor> would be nice as it includes a couple new helper commands which would ease backporting, but the status does not look very good yet
<jtaylor> also updating science stuff always takes ages :/
<tumbleweed> science stuff tends to be big an dclunky
 * tumbleweed needs to set up something like this for the bugs I file http://blog.gerv.net/2012/01/outstanding-requests-in-bugzilla/
<Laney> hdf5 is having problems
<tumbleweed> otoh, opencv seems to be going well
<jtaylor> can I sync stuff that does not exist in ubuntu yet?
<jtaylor> I want to have dh_linktree :)
<tumbleweed> yes
<jtaylor> now review necessary?
<tumbleweed> it'll go to NEW, yes
<jtaylor> automacially if I use syncpackage?
<tumbleweed> yup
<jtaylor> nice
<bkerensa> https://bugs.launchpad.net/ubuntu/+source/snort/+bug/889721 <-- Upstream had a interesting response
<ubottu> Ubuntu bug 889721 in snort (Ubuntu) "Typo in the man page: runnong instead of running" [Low,Fix released]
<tumbleweed> bkerensa: yeah, upstreams don't understand how we work
<micahg> jtaylor: dh_linktree was already sync'd by cjwatson
<jtaylor> oh good
<bkerensa> tumbleweed: Yeah he also e-mailed me and thanked me but essentially also assigned blame to both Debian and Ubuntu for not keeping up with Upstream heh
<cjwatson> well, dh_linktree still needs binary NEW - I'll do that now
<Rhonda> interesting that someone files a sync request for wesnoth-1.9 when I am preparing wesnoth-1.10 :)
<micahg> that's why I subscribed you :)
<Rhonda> Ah, you subscribed me. I wonder why it appeared in my mailbox :)
<micahg> launchpad should tell you why you got it
<micahg> although I think that message is delayed a bit
<Rhonda> You have been subscribed to a public bug:
<jtaylor> anyone knowlegable about fonts?
<Rhonda> micahg: but it doesn't tell by whom.
<micahg> oh, it used to say by whom
<Rhonda> You received this bug notification because you are subscribed to wesnoth in Ubuntu.
<Rhonda> And that is in the footer.
<Rhonda> micahg: marked it as wontfix, guess thats acceptable with the reasoning I wrote :)
 * Rhonda . o O ( being able to do so on my own without having to ask someone else is the good thing about being a MOTU :) )
<micahg> yep
<micahg> well, it'll still need to be NEW processed, but as long as it's in Debian, that qualifies as the initial package review
<Rhonda> Sure
<Rhonda> One of the reason I keep 1.9 in my PPA is, the last 1.9.14 release is extremely close to the 1.10 release, thus I don't expect any FTBFS or similar issues with it. :)
<Rhonda> There are just bug fixes and translation updates in between, but 1.9.14 was string frozen and feature frozen (I think feature freeze was upstream at 1.9.10 or such already)
<jtaylor> the new launchpad is not working so great :(
<jtaylor> constantly oops not found errors
<l3on> hello there.. where I can find some statistic for precise ?
<jtaylor> what kind of statistics?
<l3on> packages, bugs closed, what else ?
<l3on> merges, syncs,
<tumbleweed> l3on: you can find some things here: http://qa.ubuntu.com/report-list/
<jtaylor> interesting blcr-dkms is in the top 10 most duplicates
<jtaylor> apparently many use it, but there is no patch for this issue since 3.0 kernels
<l3on> thanks :)
<tumbleweed> I also have graphs of ftbfs packages and upload counts, but that's about it
<l3on> tumbleweed, can I see that ? :)
<tumbleweed> http://people.ubuntuwire.org/~stefanor/
<Laney> what a day for the debian package importer to be broken >:(
<tumbleweed> :)
<l3on> beautiful tumbleweed
<l3on> .:D
<l3on> maybe some numbers could help :)
<tumbleweed> they're all there in the js :P
<l3on> can I checkout the code? :)
<tumbleweed> yes
<tumbleweed> and if you have access to alioth, you can mine that kind of thing yourself
<tumbleweed> l3on: do we know what's wrong with the importer?
<tumbleweed> err Laney
<l3on> tumbleweed, what do you think about some tooltip/popup ?
<Laney> something fell over with ftp.uk.debain.org
<Laney> ian
<l3on> something like â http://jqueryfordesigners.com/coda-popup-bubbles/
<Laney> which is where it pulls from
<tumbleweed> l3on: for what?
<l3on> for top 50 uploaders
<l3on> just to know how many packages for instance
<tumbleweed> one of the reports already has tooltips, it'd make sense to use the same library (unless it sucks)
<l3on> which one ?
<l3on> I mean, which one report ?
<tumbleweed> I can't remember, and I can't see it :)
<l3on> lol
<Laney> 23/01 15:57:04 <Sledge> themill: looks like mirroring is broken somewhere upstream of free
<Laney> 23/01 15:57:19 <Sledge> I'm getting that looked at now, and also doing a manual sync
<Laney> free = box with mirror
<Laney> 23/01 15:57:37 <Sledge> DNS will be updated shortly to point elsewhere in the meantime
<tumbleweed> l3on: aah, ftbfs
<l3on> :)
<tumbleweed> anyway, patches welcome. Shout if you want me to move one of those +junk branches into a lp project, for easier merge requests
<l3on> we'll see, I'm not sure that what I want is easly to do :)
<l3on> *easy
<tumbleweed> flot.js alreday has some hover support: http://people.iola.dk/olau/flot/examples/tracking.html
<tumbleweed> Laney: we appear to have imports
<Laney> good ones?
<tumbleweed> they'd better not be bad :)
<Laney> not sure i can see any syncs on precise-changes
 * tumbleweed just did one
<Laney> sponsored?
<tumbleweed> no, coming up now
<Laney> https://lists.ubuntu.com/archives/precise-changes/2012-January/007903.html ? seems all you
<tumbleweed> yes
<tumbleweed> barry: still intend to build pypy in a ppa that has arm, or should I just sync it?
<Laney> not sponsored then?
<Laney> sponsor it to someone if you do it :P
<tumbleweed> Laney: syncing python-markdown, sponsored
<Laney> oh, it woke up?
<Laney> good stuff
<barry> tumbleweed: ah, last week i was trying to build it on my arm box, but honestly, i probably won't get to it now.  sync it i guess ;)
<tumbleweed> commit myself to making it work before release :)
<Laney> In [2]: ubuntu_archive.getPublishedSources(source_name='python-markdown', distro_series=lp.distributions['ubuntu'].current_series, exact_match=True)[0].sponsor
<Laney> Out[2]: <person at https://api.launchpad.net/1.0/~stefanor>
<tumbleweed> oh, ScottK sorry, didn't seeyou assigned yourself to that
<ScottK> tumbleweed: As long as it's done.  I was just waiting for it to appear.
<Laney> tumbleweed: select source, version, changed_by, signed_by from ubuntu_upload_history where source = 'python-markdown' and version = '2.1.0-1';
<Laney> :-)
<tumbleweed> :)
<Laney> it is nice going end-to-end like that
#ubuntu-motu 2012-01-24
<toabctl> is there a command line tool to compare package versions in debian and ubuntu?
<tumbleweed> rmadison can tell you the versions in both
<tumbleweed> what sort of differences are you looking for?
<toabctl> tumbleweed, i want to compare package versions.
<tumbleweed> toabctl: across the entire archive?
<toabctl> tumbleweed, no. just for a given source package
<tumbleweed> rmadison is probably sufficient then
<toabctl> tumbleweed, maybe i should use requestsync
<dholbach> good morning
<ajmitch> hi
<toabctl> hi dholbach
<dholbach> hey toabctl
 * philipballew highfives dholbach 
<dholbach> hey philipballew :)
<philipballew> hey dholbach how goes the morning?
<dholbach> good good - how about you? :)
<philipballew> not bad. just got back from scale, gave a talk there. lots of canonical people there and a good ubuntu presence
<philipballew> but now its late and college work takes my time. its overrated :)
<Adri2000> hi
<dholbach> hey Adri2000
<Adri2000> how long are we going to support universe/multiverse in precise? 3 years?
<tumbleweed> it's best-effort
<tumbleweed> the community supports whatever it wants to, really
<Adri2000> right
<dholbach> hey Laney - do you know if there was some discussion about format of the -changes mails after the addition of the sponsored attribute?
<Laney> dholbach: no, but it comes up in Signed-By â is that not right?
<dholbach> so if A does a change in Debian, B asks for a sync and C sponsors it, what will be in Changed-By and Signed-By?
<Laney> https://lists.ubuntu.com/archives/precise-changes/2012-January/007904.html
<Laney> From: is the person being sponsored
<Laney> Signed-By: is the sponsor
<dholbach> and for an auto-sync from Debian?
<Laney> Changed-By: is the person who did the original change
<Laney> they don't get mailed
<dholbach> ah ok
<dholbach> great, thanks
<Laney> but you should be using our cool UDD table instead of the mailing lists :P
<dholbach> how can I use it? :)
<Laney> it's imported into ubuntuwire
<Laney> so you can query it there to do whatever you need, or get an official mirror setup
<dholbach> ok, let me have a look :)
<Laney> we don't keep the Debian creator though
 * dholbach nods
<dholbach> Laney, I guess I would need access to the machine to toy around with the database and try to write my own script?
<Laney> it's pretty easy to set up a local UDD instance
<Laney> but ajmitch can get you access to the ubuntuwire machine if you ask nicely :-)
<dholbach> ah I guess it's http://wiki.debian.org/UltimateDebianDatabase/CreateLocalReplica
<Laney> yep
<dholbach> alright, I'll let you know what I find in the next days :)
<dholbach> Laney, so the fix is in LP and everything's nice and dandy now?
<Laney> or if you have an alioth account then you can access it from wagner
<Laney> seems to work afaics
<dholbach> sweet
<dholbach> great work
<ajmitch> Laney: what's up?
<Laney> ajmitch: dholbach might be looking for an account on skylone to do some udd stuff
<dholbach> let me toy around with the local dump first and see how far I get :)
<Laney> ack
<ajmitch> ok
<dholbach> if I can put up some nice stuff on ubuntuwire I'll ping you again
<dholbach> thanks again :)
<ajmitch> dholbach: ping me when you have something to play with
<dholbach> will do :)
<ajmitch> dholbach: actually just try & log in to syklone.ubuntuwire.org, I added an account with your ssh key from LP
<dholbach> WOW
<Laney> customer service!
<ajmitch> easier than waiting ~12 hours for me to be awake again :)
<dholbach> I can't guarantee that I will have some ready to play with in ~12 hours though ;-)
<ajmitch> doesn't matter, you can do what you need when you're ready now
<dholbach> thanks muchly
<ajmitch> 'psql service=udd' should get you the udd data, if the cron job has been working properly it should only be a couple of days old
<dholbach> sweet
<dholbach> ajmitch, do you know how often it is updated?
<ajmitch> weekly
<ajmitch> last update was sunday
<dholbach> fantastico
<ajmitch> thank tumbleweed for poking me about it :)
<Laney> the UDD import?
<ajmitch> at least the cron job to resync it
<ajmitch> I know you asked a few times about it as well :P
<Laney> just didn't know how often you were running it
<ajmitch> afaik the source data is only dumped every few days
<dholbach> ajmitch, for udd.sql.gz, I get this:
<dholbach> In [14]: conn.headers.dict["last-modified"]
<dholbach> Out[14]: 'Mon, 23 Jan 2012 08:09:33 GMT'
<Laney> http://udd.debian.org/crontabs.txt
<Laney> 0 8 */2 * * /org/udd.debian.org/udd/scripts/dump-db.sh
<dholbach> maybe that'd be a good way to update it more regularly? save last-updated and check last-modified
<dholbach> ok, ignore me :)
<ajmitch> it's a possibility, do you need more frequent updates?
<dholbach> no, I just thought that it'd be good to automate it if it was done manually up until now and nobody knew when it was updated on udd.d.o
<dholbach> but Laney answered that question :)
<ajmitch> it's a weekly cron job on syklone, I can adjust that
 * dholbach nods
<dholbach> great :)
<ajmitch> not a manual reload, that'd be annoying
<dholbach> yeah :)
<MTecknology> This is interesting... Apparently the binary and debug packages built, but the common files and docs package didn't build... http://packages.ubuntu.com/search?keywords=nginx&searchon=names&suite=precise&section=all
<MTecknology> Any ideas what's going on there?
<MTecknology> Someone filed it as bug 920110 - not sure what I can do about it
<ubottu> Launchpad bug 920110 in nginx (Ubuntu) "nginx-common precise needs packaging or -depends on nginx-*" [Undecided,Confirmed] https://launchpad.net/bugs/920110
<Ampelbein> MTecknology: bug 915257, but I'm not sure why that happened.
<ubottu> Launchpad bug 915257 in nginx (Ubuntu) "FTBFS nginx 1.1.12-1 in ubuntu precise except amd64" [High,Confirmed] https://launchpad.net/bugs/915257
<Ampelbein> MTecknology: The arch-all packages are built on i386 only so 920110 is fallout from this failure.
<MTecknology> Ampelbein: so when that's fixed, both of those bugs should be resolved?
<Ampelbein> MTecknology: Yeah.
<MTecknology> Ampelbein: thanks! Any bug link for that issue?
<Ampelbein> See above, the 915257, but like I said I don't know WHY that happened.
<MTecknology> ooh- i thought you meant there was some general known error
<Rhonda> great, wesnoth-1.10 is in debian unstable  :)
<Zhenech> Rhonda, hint hint, while syncing wesnoth, please also sync pokerth 0.9.1-1 :)
<Rhonda> nope
<Rhonda> Will sync pokerth right now.  Can't sync wesnoth-1.10 yet (read: am too lazy to write the text myself and requestsync doesn't like to pick it up yet)
<Rhonda> Zhenech: Sync request filed as bug #921118: https://bugs.launchpad.net/bugs/921118
<ubottu> Ubuntu bug 921118 in pokerth (Ubuntu) "Sync pokerth 0.9.1-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed]
<Zhenech> *hug* thanks
<Rhonda> hmmm
<Rhonda> requestsync tells me to use syncpackage instead â¦
<Rhonda> where does requestsync/syncpackage check for the package? rmadison?
<tumbleweed> Rhonda: launchpad and rmadison
<Rhonda> then I need to wait for udd to pick up the upload â¦
<tumbleweed> Rhonda: which pkg?
<Rhonda> wesnoth-1.10.  Like said, I am lazy to write the bugreport myself if there is a tool doing all the boring job for me :)
<tumbleweed> Rhonda: when you see it here, you can sync: https://launchpad.net/debian/+source/wesnoth-1.10
<Rhonda> ah, good to know
<tumbleweed> no need for bugs any more: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-January/000923.html
<Rhonda> oh, nice.  Guess I should grab that new ubuntu-dev-tools then
<tumbleweed> if requestsync is telling you to use syncpackage, it's already new enough
<tumbleweed> (but a newer version can sponsor syncs)
<Rhonda> ah, don't need that part, thanks for the clearification
 * Rhonda . o O ( and I really should read more mails â¦ )
<tumbleweed> oh right, there's also the blacklisting bug that laney mentioned
<tumbleweed> that hits some packages
<Rhonda> shall I request blacklist for wesnoth-1.11 right ahead?
<Rhonda> â¦ speaking of  ;)
<technomancy> does the build environment for PPAs allow you to pull in dependencies through systems other than apt? say using bundler for ruby gems?
<technomancy> I know this is not allowed for official Debian packages, but it's not clear whether the same rules apply for PPAs
<tumbleweed> heh, no the bug here is that lp decides to blacklist some versions of some packages by itself. So we now ignore those
<ajmitch> technomancy: no, it's not possible, the ppa buildds also have no network access
<technomancy> ajmitch: ok, thanks.
<technomancy> so basically you can't use a PPA for something that doesn't already have all its dependencies in apt?
<ajmitch> if you need it at build time, it needs to be in a package, or in the source you upload
<ScottK> Yes.  This is a feature, not a bug.
<technomancy> sure, it just means PPAs are not intended for what I have in mind. that's fine.
<alkisg> Hi, I'm confused by this: $ apt-cache show mahara | grep ^Section
<alkisg> Section: universe/web
<alkisg> If I do put "universe/web" in my package's debian/control though, lintian complains about it being an unknown section.
<alkisg> What's the correct section to use in debian/control? Just "web", without "universe", right?
<tumbleweed> just web
<alkisg> Thank you
<tumbleweed> all new packages go into universe
#ubuntu-motu 2012-01-25
<benonsoftware> Hello
<achiang> can i write a manpage inside debian/ ? the package doesn't need any patches otherwise, and the only other way i know how to do it is to create a patch that adds a manpage
 * achiang experiments with: touch debian/foo.1 ; echo 'debian/foo.1' > debian/manpages
<achiang> neat, that seems to work
<achiang> another question: is it bad form if the upstream is BSD but debian/* is GPL-2 ?
<geser> achiang: not really "bad form" but it gets interesting if you add a patch in future (assuming it would be GPL-2 too).
<dholbach> good morning
<geser> good morning
<Rhonda> Alright, syncpackage for 1.10 done :)
<Rhonda> â¦ wesnoth.
<tumbleweed> Laney: when are we getting build failure e-mail for synced packages?
<Laney> now now, you know the answer to that :-)
 * micahg just keeps an eye on +synchronised-packages for that
 * tumbleweed keeps tabs open for the builds I'm interested in
<tumbleweed> but I'm getting pypy timeouts on amd64, and so wan tto keep track of which buildds it timed out on :/
<micahg> right now due to powerpc being behind, I have 2 build failures that are depwaits, once the dep builds I'll retry, but that could be next week :)
<tumbleweed> powerpc is badly behind :/
<Laney> where's that new buildd?
<ogra_> vacation ?
<tumbleweed> I suppose we should raise more concern about that at the release meeting (yay, something to mention :P )
<Laney> come back with a nice tan ready to sweat out some packages
<Laney> bug #862251
<ubottu> Launchpad bug 862251 in Launchpad itself "Sync requester doesn't receive build failure emails" [High,Triaged] https://launchpad.net/bugs/862251
<micahg> tumbleweed: re powerpc> don't bother, we've already done as much screaming as we can do about it, should be a few more weeks only hopefully
<Laney> it is already in the escalation queue
<tumbleweed> yeah
<tumbleweed> arm seems to be keeping up far too well now
<tumbleweed> time for new x86 buildds :P
<tumbleweed> gaar pypy timed out again
<tumbleweed> damn, and it went back to the same buildd
<cjwatson> there's a ticket open to refresh the buildd pool in general ...
<ogra_> see, as i said, vacation ... they all lie at the pool :)
<bullgard4> Ubuntu 10.04.3 Synaptic notices for the DEB program package Â»ntopÂ« version 1.4.3-4: "Canonical does not provide updates for sntop. Some updates may be provided by the Ubuntu community." Why does Ubuntu 11.10 not notice the same?
<bullgard4> s/ntop/sntop/
<tumbleweed> bullgard4: you are outside the normal support length and into LTS. That only covers a subset of the archive.
<tumbleweed> (I'm guessing that's the reason for that notice)
<bullgard4> Ah! Thank you tumbleweed.
<micahg> anyone free to update libav-extra to 4:0.8ubuntu1 (bug 921765)?
<ubottu> Launchpad bug 921765 in libav-extra (Ubuntu) "libav-extra needs rebuild to >=4:0.8 so dev packages can be installed" [Undecided,New] https://launchpad.net/bugs/921765
<micahg> siretart: are you planning an upload for this to Debian? ^^
<siretart> micahg: yeah, I actually have it more or less ready. but then I noticed that fabian's simplifications needed porting, and then I got distracted :-(
<micahg> woohoo, powerpc backlog is at 256 jobs, I wonder if we can get it up to 512 :)
<ajmitch> please don't let it get to 1024
<micahg> well, the i386 PPA queue is above that :)
<ajmitch> i386 builders are slightly faster, I hope
<ajmitch> though it can be annoying to have a backlog like that
<micahg> powerpc is pretty fast
<micahg> relative to arm* at least
<ajmitch> it probably doesn't take much to be faster than arm, still
<ScottK> It's a lot faster than arm.
<ScottK> It's only slightly slower than amd64, but there's fewer builders.
<Rhonda> micahg: hmmm, I could add some wesnoth to the delay â¦
#ubuntu-motu 2012-01-26
<dholbach> good morning
<bkerensa> good morning dholbach
<dholbach> hey bkerensa
<Rhonda> about Bug 921118, should I close it and run syncpackage instead?
<ubottu> Launchpad bug 921118 in pokerth (Ubuntu) "Sync pokerth 0.9.1-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/921118
<tumbleweed> Rhonda: syncpackage can close bugs
<Rhonda> ah, right
<Rhonda> hmm
<Rhonda> syncpackage: Launchpad bugs to be closed: 921118
<Rhonda> syncpackage: Please wait for the sync to be successful before closing bugs.
<Rhonda> Close bugs [Y|n]?
<tumbleweed> yeah, it's less than perfect :P
<Rhonda> Somehow that sounds like it doesnt want me to close bugs?
<tumbleweed> launchpad 's syncing api doesn't offer to close
<Rhonda> So will they get closed before the sync happens?
<dholbach> I usually wait for the mail to show up, then hit "Y"
<Rhonda> does backportpackage only work for uploading to PPAs?
<tumbleweed> Rhonda: you have to tell it to close the bug
<tumbleweed> Rhonda: it's up to you to say "ok close it now"
<Rhonda> dholbach: how long does that usually take?
<Rhonda> tumbleweed: so it wouldn't pick up LP: #1234 from the changelog automatically?
<dholbach> Rhonda, 2-3 minutes, I think
<tumbleweed> Rhonda: no
<tumbleweed> oh, sorry yes
<tumbleweed> Laney: thanks for taking this to the techboard
<Laney> absolutely
<highvoltage> Laney ftw.
<Laney> highvoltage: make sure you comment or turn up to the meeting :-)
<highvoltage> Laney: oh, I will
<Laney> rock
<highvoltage> Laney: backtracking on that there's no seperate 'business' release and that 'parner' is now somehow part of Ubuntu is just BS.
<highvoltage> (but that you know)
<Laney> the business thing is a proposed new product
<Laney> well I think it's more than proposed actually
<highvoltage> at least in the default sources.list it always said:
<highvoltage> ## Uncomment the following two lines to add software from Canonical's
<highvoltage> ## 'partner' repository.
<highvoltage> ## This software is not part of Ubuntu, but is offered by Canonical and the
<highvoltage> ## respective vendors as a service to Ubuntu users.
<Laney> heh heh
<highvoltage> Laney: actually I might even end up launching a campaign about it, I'm really worked up about it
<geser> I hope it's easier than to teach Debian users that Debian non-free isn't part of Debian
<tumbleweed> well yeah, from most users' point of view it is part of Ubuntu. They see Ubuntu as a Canonical product, so this is totally part of Ubuntu
<highvoltage> yeah
<Laney> Debian is easier, as SC#5 says that.
<tumbleweed> yup
<Laney> We should work with the TB in the first instance. I'm sure there's a sensible outcome to be had here (â¦)
<tumbleweed> sure, and we'd all like to not see Ubuntu internal bickering in the news :)
<highvoltage> Laney: I have a stong urge to blog about it, do you think that's ok?
<Laney> Depends how you write it :-)
<geser> Laney: true, but how many Debian users have really read the SC and know about #5?
<Laney> At least it is there to point people at, in a founding document
<Laney> i.e. it is unquestionable in that sense
<Q-FUNK> howdy.  I seem to get warnings from CDBS' list-missing since I split one library into foo2 and foo-common, yet debc shows that the files correctly installed in foo-dev as intended.
<Q-FUNK> would anyone happen to know what causes list-missing to complain, even though everything was correctly installed?
<jtaylor> yey the lp ppa build queue is so long my daily builds are starting to queue up :O
<ajmitch> you're at the point where you've got more than 1 day of builds in the queue?
<micahg> wow, PPA queue is longer than PowerPC now
<l3on> Hey.. someone can open bug 629246 for oneiric/maverick/natty ?
<ubottu> Launchpad bug 629246 in ntfs-config (Ubuntu) "ntfs-config crashed with OSError in __init__(): [Errno 2] No such file or directory: '/etc/hal/fdi/policy" [High,Triaged] https://launchpad.net/bugs/629246
<TiMiDo> hey guys
<TiMiDo> how is everyone doing. here
<roaksoax> 9/win 3
<koolhead17> hi all
<TiMiDo> hi koolhead17
<koolhead17> hi TiMiDo
<TiMiDo> hi koolhead17
 * koolhead17 reading up on merging
<TiMiDo> nice I'm uploading some patches to upload,
<TiMiDo> to see if that will get rid of the bug,,
<astraljava> Hey Masters! Are packages synced from unstable still? Do I need to file a request for one?
<ajmitch> they've been synced from testing up until a couple of weeks ago, so a sync request is needed for anything newer
<ajmitch> or merge if there are changes in ubuntu
<astraljava> ajmitch: Thanks! I just noticed there is an update to audacious in unstable, and we're seeding that. But it FTBFS on some archs, so I will wait a little while to see if there are fixes. Thanks!
<micahg> l3on: I don't know that dropping hal in the stable releases is a good SRU
<l3on> mmmmmmmmmmm
<l3on> well, in oneiric works great
<jtaylor> tumbleweed: you're in the motu relase team right?
<micahg> l3on: works, yes, but that might regress functionality
<l3on> not really, wait, there is a old debian bug ...
<micahg> l3on: it's perfect for precise though as hal needs to die, so syncing
<l3on> micahg, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=615210
<ubottu> Debian bug 615210 in ntfs-config "Uses deprecated HAL" [Important,Fixed]
<l3on> seems that hal is not necessary
<jtaylor> tumbleweed: ipython upstream is discussing bugfix release or new upstream mid march if it would still got into precise
<micahg> l3on: right, well, it's not used very much as all now, but in the stable releases, the further back you go, the more it's used
<jtaylor> is it still realistic to get a freeze exception based on this rational: core functionallty known from < 12.04 is not changed much, we don't want to keep 0.12 due to bugs and interface change in new parts of 0.13?
<l3on> micahg, so, what you suggest ? :)
<micahg> l3on: no rdeps, so adding hal as a dependency seems safest
<micahg> l3on: but feel free to discuss with an SRU team member, I"ll give you the bug tasks since you're working onthis
<l3on> ok, thanks micahg :)
#ubuntu-motu 2012-01-27
<tumbleweed> jtaylor: a bugfix release sounds worth taking
<dholbach> good morning
<benonsoftware> Hello dholbach
<dholbach> hey benonsoftware
<takamarou> Hi all - I'm looking to get started doing some dev/bug fixes for Ubuntu, and am getting a bit confused as I browse through triaged bugs..  I see quite a few bugs that are labeled triaged, but when you click into them you see a "Fix Commited" and a "Triaged" entry.  Does this mean that the fix is committed by the original package devs, or does that mean it is still open to fixing?  Example: https://bugs.launchpad.net/ubuntu/+s
<takamarou> P.S. Sorry for the dumb question :/
<dholbach> takamarou, there's no dumb questions :)
<dholbach> takamarou, can you paste the full link to the bug? it seems it was cut off
<takamarou> dholbach, hmm, not cut off on my screen..  let me try it on its own line
<takamarou> https://bugs.launchpad.net/ubuntu/+source/inkscape/+bug/807861
<ubottu> Ubuntu bug 807861 in inkscape (Ubuntu) "typo in ../src/widgets/toolbox.cpp:4685" [Low,Triaged]
<dholbach> ah, that was a good question! :)
<dholbach> can you see the two lines in the middle of the page, one "fix committed" and the other one "triaged"?
<takamarou> Yep
<dholbach> they are what we call 2 bug tasks
<dholbach> we identified that the problem is in "inkscape (Ubuntu)" and "inkscape"
<dholbach> which means as much as: we need to fix it in inkscape, the Ubuntu package
<dholbach> and also in inkscape the upstream project
<takamarou> Which is "inkscape" as in the original straight from inkscape, and "inkscape (Ubuntu)" as in the Ubuntu repo version... right?
<takamarou> oh
<takamarou> OK
<dholbach> so it seems like the fix is committed (but not in a release , which would be 'fix committed') upstream
<dholbach> and in Ubuntu the bug is triaged, which means that the problem is understood and has all necessary information
<dholbach> one possible solution would be to grab the fix from upstream and fix the ubuntu package this way
<dholbach> or wait until a new release is rolled upstream and we upgrade to the new upstream version
<takamarou> Gotcha.  And what is the usual procedure with that kind of thing?  Wait for the new release, or do it yourself?
<dholbach> as it's a typo, I would assume it's safe to wait for the next upstream release
<takamarou> OK
<dholbach> if it's something urgent like a common crasher, it might be better to just grab the fix, apply it and not block on upstream finding the time to roll a new release
<takamarou> So little things like typos are probably going to be a bad choice for getting my feet wet in bug fixing, as they will be fixed upstream
<dholbach> no, if you want to start out by fixing a typo, do it - but in a lot of cases it makes sense to submit the fix to the upstream authors
<takamarou> OK
<dholbach> unless it's something really visible and irritating :)
<takamarou> Gotcha
<dholbach> it's impossible to know all of this from the very beginning
<dholbach> so keep the questions coming
<dholbach> also if you haven't heard already, next week is Ubuntu Developer Week, which might interest you: https://wiki.ubuntu.com/UbuntuDeveloperWeek
<takamarou> I will - still in the process of upgrading to 11.10, so I don't know all the questions yet.  But I will soon!
<dholbach> :-)
<takamarou> Sweet.  All the classes are during my work hours, but perhaps I'll keep IRC open in the background
<takamarou> Thanks!
<takamarou> OK - got another question.  Looking at another bug (https://bugs.launchpad.net/ubuntu/+source/unity/+bug/723864) in Unity.  It's got 4 bug tasks, Unity (ubuntu), Unity, Unity Foundations, and Ayana Design.  I understand the first three, but what the heck is Ayana Design (and also, why is there more than one upstream?).  I've seen this Ayana in a couple places now.
<ubottu> Ubuntu bug 723864 in unity (Ubuntu) "The alignment of the â[number of minutes] minutesâ selector in the âUnlock Keyringâ window is wrong." [Wishlist,Triaged]
<dholbach> takamarou, also we'll put up logs later on
<dholbach> takamarou, I'm not 100% sure, but I could imagine that in this case it's a way to get multiple teams aware of the bug
<dholbach> not 100% sure though
<dholbach> sometimes you can have lots more than 2 tasks
<dholbach> ie: https://bugs.launchpad.net/ubuntu/+source/audiofile/+bug/922036
<ubottu> Ubuntu bug 922036 in glame (Ubuntu) "Audiofile 0.3.x transition" [Medium,Triaged]
<dholbach> in this case it's a matter of fixing the same problem in many different packages
<takamarou> OK
<TiMiDo> Hi people
<TiMiDo> if i want to help around the MoTU  i need to create my self, a PPA, so i can upload new bugs fixes and much more?
<micahg> TiMiDo: you can use a local sbuild or pbuilder instance to test
<TiMiDo> oh OK i was reading. online on the wikis
<TiMiDo> so i can package,
<TiMiDo> question do i need my GPG so be sign before uploading. the new changes?
<micahg> TiMiDo: upload rights are a different story, they come later (https://wiki.ubuntu.com/UbuntuDevelopers)
<TiMiDo> let's see
<micahg> TiMiDo: until then, you can get sponsored: https://wiki.ubuntu.com/SponsorshipProcess
<TiMiDo> nice.
<TiMiDo> I'll get a sponsor later on but anyways i can still upload to lp
<TiMiDo> so I'll do that with bzr
<micahg> TiMiDo: once you propose a merge into the lp:ubuntu/* branch, it lands in teh sponsorship queue, no sponsor hunting necessary
<TiMiDo> oh nice
<TiMiDo> i was fixing some bug
<TiMiDo> on php5
<TiMiDo> do you guys have any packages that need help to be packaging or to check the rules?
<TiMiDo> i meant if ubuntu has orphaned packages
<blair> ub https://bugs.launchpad.net/bugs/920284 a commenter wrote "Could you progress the ones that require merges, and check how precise
<blair> looks after all of this has built and published?"  what am i supposed to do?
<ubottu> Ubuntu bug 920284 in Ubuntu "Sync maven 3.0.4-1 (universe) from Debian unstable (main)" [Medium,Triaged]
<blair> s/ub/in/
<micahg> blair: check and see what's left to be done to sync maven (i.e. what other build/runtime dependencies need to be sync'd/merged)
<blair> micahg, i think the person who has done the syncs has listed it pretty well already
<blair> there's nothing for me to do on the ones that require merges from debian, is there?
<micahg> blair: propose the merge?
<blair> unless i need to open tickets requesting a merge/sync?
<micahg> blair: you should ask the person who touched it last first though
<blair> there's only really one package that debian has a newer upstream than ubuntu and it was synced, the rest are debian package updates, which i don't think are really needed
<blair> for maven working, that is
<blair> what does MIR mean here: "synced, but will require MIR of libcommons-parent-java"
<micahg> Main Inclusion Request
<blair> that means, move it from universe to main?
<micahg> yes
<blair> why does he say that, i dont' see a direct dependency from libcommons-logging-java onto libcommons-parent-java?
<blair> is there a tool to propose merges, like requestsync?
<blair> apport?
<micahg> sorry, I have to go, will be back UTC early sunday
<blair> micahg, ok, have a good one
#ubuntu-motu 2012-01-28
<trinikrono> hey guys did something go wrong with ubiquity with a update i am seeing lots of bugs with a resolv.conf error
<trinikrono> does anyone have any idea about this or a master bug so i can mark the rest as dupes
<ScottK> I don't know which bug is the master, but it's known and someone was working on it.
<alkisg> Hi, I'm probably blind, but what am I missing here?
<alkisg> $ dpkg --compare-versions '1f' '<' '10' && echo yes
<alkisg> yes
<alkisg> Ah it compares 1 to 10... :(
<alkisg> The ipxe package uses a weird numbering scheme, and got me a rejected upload... 1.0.0+git-2.149b50-1ubuntu4
<alkisg> 1.0.0+git-2.55f6c88-0~2~natty1 <= 1.0.0+git-2.149b50-0~1~natty1   :(
<alkisg> ..because 55 is less than 149
#ubuntu-motu 2012-01-29
<micahg> tumbleweed: do you remember why there was a diff for gnubiff s/libfam/libgamin/, this seems to build fine without the diff (it's no longer in the distro at the moment, but has been requested)
<tumbleweed> micahg: FTBFS, IIRC
<tumbleweed> micahg: seems ubuntu had a preference for gamin over fam, I don't know if that's still relevant
<micahg> tumbleweed: right, idk, and there's no paper trail
<tumbleweed> micahg: it was one of my first merges, so I did a bit of research into it at the time
<micahg> well, I went back and looked at the changelog history in LP and the closed bug merge history with nothing, I only came across a comment that you did a bit of research, hence the ping :)
<tumbleweed> hah
<rigved> hi everyone.
<rigved> i found a typo in the live-build package (in an example script) kept in /usr/share/...
<rigved> if i use the example script as-is, the build process does not work.
<rigved> but the package version in debian is different than the one used in precise.
<rigved> should i file a bug report (and fix that bug)?
<rigved> or should i wait for someone to sync the new package version from debian?
<jtaylor> is it fixed in debian?
<rigved> jtaylor: i checked in debian. this problem is not there.
<rigved> jtaylor: but the debian version of the package is different.
<jtaylor> I'd file a bug in ubuntu with the fix
<rigved> jtaylor: ok.
<rigved> just out of curiousity, why is the live-build package version not the same?
<rigved> the package is there in unstable, so it has been quite some time since it was put there.
<jtaylor> ubuntu and debian have different needs for their live builds
<rigved> the debian package is a few versions ahead of the precise one.
<rigved> jtaylor: ohh. ok
<rigved> jtaylor: thanks!
<rigved> jtaylor: i did a bzr branch and it downloaded the version, which already has the fix. but the version in precise is the old one. so, the new version has not landed in precise yet. is there a chance that i will land in precise soon? in other words, is the freeze in effect or is there still some time.
<jtaylor> what did you branch?
<rigved> jtaylor: i did: bzr branch lp:live-build live-build.dev
<jtaylor> that looks like the debian branch
<jtaylor> lp:ubuntu/live-build should get you the ubuntu one
<rigved> jtaylor: ohh. ok. thanks again. i'll test it.
<jtaylor> typo fixes in an example script should not be subject to any freeze, so there is still plenty of time to fix it
<rigved> jtaylor: no. lp:ubuntu/live-build is not a valid branch.
<rigved> jtaylor: lp:live-build and lp:live-build/trunk are valid branches.
<rigved> jtaylor: plus, i check the file in the trunk source, along with revision info. the typo was fixed some time back.
<jtaylor> weird, just create a debdiff and don't bother about bzr
<rigved> jtaylor: ohh. ok.
<jtaylor> its still present in the 2 day old ubuntu22 version?
<rigved> jtaylor: yes.
<rigved> jtaylor: but not in the latest code in trunk.
<jtaylor> you probably have to ask some core developer about this
<rigved> jtaylor: hmmm...
<rigved> jtaylor: i think i'll ask on the launchpad of the live-build project.
<jtaylor> I'd just file a bug with a debdiff
<rigved> jtaylor: i filed a bug report: 923355
<rigved> bug 923355
<ubottu> Launchpad bug 923355 in live-build (Ubuntu) "live-build example auto/config script has a typo" [Undecided,New] https://launchpad.net/bugs/923355
<rigved> jtaylor: i filed the bug report before you told me about the debdiff.
<rigved> jtaylor: is it possible to add the debdiff info now, after the bug has been filed?
<jtaylor> of course
<jtaylor> below the comment box there is a link t add attachements
<rigved> jtaylor: ok. so, i used debdiff to create a diff.txt. so, i'll attach it to the bug report. nothing else required, right?
<jtaylor> give it the extension .debdiff so people know what it is
<rigved> jtaylor: ok.
<rigved> even though i did not get to fix anything here, but good thing at least my dev environment is set-up now.
<rigved> so i can attend ubuntu dev week.
<rigved> jtaylor: launchpad is asking me if the uploaded file is a patch or not. what should i tick?
<jtaylor> its a patch
<rigved> jtaylor: ok. thanks for all your help!
<rigved> bye
<jtaylor> hm a 9.5 mb debdiff for a typo fix :O
<astraljava> Maybe the original author has dyslexia?
#ubuntu-motu 2013-01-21
<chilicuil> Rhonda: hi, good day, sorry to bother, I'm just wondering if the wesnothd bin was removed from debian/ubuntu?, I'm running ubuntu precise and there is no 'wesnoth-server' package
<chilicuil> Rhonda: wop, my bad, it seems now it's in wesnoth-1.10-server =P
<dholbach> good morning
<micahg> wow, NMU to bump standards, that's a new one...
<jtaylor> if a core-dev is bored imagemagick "needs" a no change rebuild to drop a 600kb dependency for a lot of installs
<jtaylor> in principle it could also be merged, but I don't want to have TIL ;)
#ubuntu-motu 2013-01-22
<micahg> jtaylor: I don't mind rebuilding imagemagick, what's being dropped?
<micahg> jtaylor: nevermind, I can use tools to figure it out
<micahg> jtaylor: only edubuntu and ubuntustudio seems to be affected (well, mythbuntu also, but they're not releasing ISOs)
<dholbach> good morning
<dholbach> debfx, directhex, DktrKranz: could one of you imagine teaming up with bdrung for the Developers Roundtable at UDW (Thu 31st Jan, 19:00 UTC), which will mostly be a Q&A session where everybody can ask their questions about Ubuntu Development in general?
<iulian> Morning dholbach.
<dholbach> hey iulian
<dholbach> iulian, ^ maybe you could be interested in joining bdrung? :)
<iulian> Nop, can't do that unfortunately. :(
<dholbach> no worries, I hope we find somebody else
<iulian> I'm sure there's someone out there with more free time than me. ;)
<dholbach> there's 18:30 UTC (30m session) on that day we still have to find a speaker for too - we were thinking of either a demo of fixing a small bug or a walk through a few places to check for stuff to work on
<Rhonda> *sigh*
<Rhonda> People mail me that the packages.ubuntu.com site uses the old favicon - but noone tells me where to get the new one.
<Rhonda> And strangely, chrome doesn't display it to me on the www.ubuntu.com neither.
<tumbleweed> I see it in FF
<Rhonda> Or on www.debian.org  *puzzled*
<tumbleweed> www.ubuntu.com/sites/all/themes/ubuntu10/favicon.ico according to the source
<Rhonda> Yep, found it in the source.
<Rhonda> But it's still a bit â¦ well.  *sigh* :)
<MCR1> notgary: Hi :) If you are still searching for bitesize Compiz bugs for papercutters, here is quite a bunch of those: https://bugs.launchpad.net/compiz/+bugs?field.tag=coverity
<MCR1> notgary: They seem to be ideal for newbies, because the whole sourcecode is Coverity commented and pretty self-explainatory, but ofc there might be false positives among those as well...
<MCR1> notgary: This was just FYI, if you want to concentrate on other projects first, then no problem either - but feel free to use those, if you are on papercutters-bug-shortage ;)
<MCR1> dholbach: Hi :) How many contributions to Ubuntu does one have to make until a packaging wish gets fulfilled for free ;) ?
<MCR1> dholbach: I am missing https://bugs.launchpad.net/ubuntu/+source/emerald/+bug/968112 :)
<ubottu> Ubuntu bug 968112 in emerald (Ubuntu) "Emerald (the original Compiz Window Decorator) not available in Precise and Quantal, while it was working on all Ubuntu versions before [needs-packaging]" [Wishlist,Confirmed]
<xnox> MCR1: made a comment on the bug. Please provide requested information (it's mostly treasure-hunt / google-foo) =)
<MCR1> xnox: This was not the solution I expected. Please read https://bugs.launchpad.net/ubuntu/+source/emerald/+bug/968112/comments/7
<ubottu> Ubuntu bug 968112 in emerald (Ubuntu) "Emerald (the original Compiz Window Decorator) not available in Precise and Quantal, while it was working on all Ubuntu versions before [needs-packaging]" [Wishlist,Incomplete]
<MCR1> xnox: I am running Emerald on Raring with latest Compiz/Unity and did so on Precise and Quantal as well
<ogra_> MCR1, the point is that there will be nobody fixing bugs, the code was put to death by its developers
<ogra_> so even if it builds and runs on all supported arches (which i highly doubt for arm or powerpc), it would just rot in the archive
<MCR1> ogra_: Has every program for Ubuntu now to run on the Ubuntu phone ?
<ogra_> ??
<MCR1> ogra_: Then you would have to remove a lot more packages from the repos...
<ogra_> no, the phoine wont run most apps, it doesnt run an X server afaik
<ogra_> what has the phone to do with it ?
<MCR1> ogra_: The point is: there is currently no replacement equal to or even better than Emerald and it still works, so why throw it out ?
<ogra_> because its developers consider it dead
<ogra_> and it diodnt build on all arches ... since there was no developer for fixing it, it had to be removed from the archive
<MCR1> well, I would fix potential problems...
<ogra_> so first make sure to have the FTBFS fixed then
<MCR1> the build log from the bug is from a wrong version of Emerald btw - seems to be the non C++ branch
<MCR1> well, as I told you: I can build it without problems
<ogra_> create a PPA, ask the launchpad team for powerpc and armhf support for it, make sure it builds in all arches
<ogra_> alternatively just convince debian to ship it and it will automatically be synced from there
<ogra_> but its very unlikely debian will allow it in if it is an abandoned project upstream
<tumbleweed> (and of course you'd get push-back in Ubuntu for that too)
 * ogra_ wouldnt push back if someone can actually proof he can take over upstream fixing and packaging for all arches and bugs 
<tumbleweed> in which case, it should totally be in Debian :)
<ogra_> but thats indeed a quite advanced and likely also time consuming full time job :)
<MCR1> okay, guess I'll try to chat with some of the Debian packagers then - thanks
<tumbleweed> if there were historically problems buildign it on other archs
<ogra_> i bet they will tell you the same, but good luck
<tumbleweed> I'd start by seeinf if those are still issues
<tumbleweed> it's easy enough to build for ARM with qemu
<ogra_> right, thats why i suggested a PPA
<MCR1> tumbleweed: The initial problem was just a linker error
<ogra_> now that you can have armhf ...
<MCR1> then it got removed
<ogra_> it didnt build and nobody wanted to fix it
<MCR1> it was working and available until 11.10 and first noone knew how to fix it
<ogra_> (note that between opening of the bug and removing the package there were 6 weeks)
<ogra_> nobody bothered to fix it and there was no upstream anymore ... we dont allow packages in the archive that dont build
<tumbleweed> we have hundreds of packages that fail to build, each release. The few people that care don't have time to fix them all
<ogra_> right
<MCR1> then someone found out how to fix it and I added this information, but later nothing happened
<ogra_> and what cant be fixed and has no chance to be fixed through upstreams will be removed
<tumbleweed> because if we bring it back - there's still no upstream, so it's just a matter of time before it breaks again, and we have to deal with it
<ogra_> MCR1, ?? i dont see any other comment in the bug
<MCR1> all I am asking you is helping me get this package back in as I am no packager and have no packaging skills
<ogra_> doko obviously opened it on 2011-08-22 ... there were no comments on it until the package was removed 6 weeks later
<ogra_> MCR1, well, that can only happen if someone fixes it
<MCR1> ogra_: You are right -> it took some time until we found out the fix for the failing compilation
<ogra_> MCR1, the last comment on the bug is from 2011-09-29
<ogra_> and there were no further ones until you commented a few mins ago
<MCR1> ogra_: I've now added detailed instructions - I did not know about this bug
<ogra_> detailed instructions ?
<ogra_> git checkout and make dont really help
<MCR1> ogra_: I made my own one here bug 968112
<ubottu> bug 968112 in emerald (Ubuntu) "Emerald (the original Compiz Window Decorator) not available in Precise and Quantal, while it was working on all Ubuntu versions before [needs-packaging]" [Wishlist,Incomplete] https://launchpad.net/bugs/968112
<ogra_> someone needs to make a new upstream release of emerald, someone else needs to package it
<ogra_> and it needs to build on all arches
<ogra_> thats not a trivial task
<MCR1> I have only x86
<MCR1> :(
<ogra_> use a PPA then
 * ogra_ thinks we talk in circles since a while 
<MCR1> ok, thx 4 the help
<ogra_> make it build and provide a debdiff, find an upstream dev or find a packager who is willing to take the heavylifting
<MCR1> thx
<MCR1> ogra_: Does it help to have a PPA for i386 and amd64 maintained builds for Precise and Quantal ?
<MCR1> lp user ~brainpower is maintaining such a PPA, here the Quantal builds: https://launchpad.net/~brainpower/+archive/testing/+sourcepub/2745472/+listing-archive-extra
<ogra_> well, make him build for armhf and ppc too
<MCR1> I do not think that this will be easily possible, is this support essential ?
<ogra_> well, you need to make sure it builds on all arches
<tumbleweed> ogra_: AFAIK nan-canonical people can't get ppc access
<tumbleweed> we don't have emulated ppc
<ogra_> oh, ibthought ppc builds in containers too now
<tumbleweed> maybe I haven't been following *that* closely
<MCR1> ogra_: In Compiz we have plugins that are only built for amd64/i386 and won't work and thus are not compiled and packaged for arm/GLES
<tumbleweed> but I certainly don't see ppc ppa builders
<ogra_> well, i'm probably ahead of time here... UDS smoking corner marketingvtalks ;)
<MCR1> ogra_: That is why I asked if all packages nowadays need to run on arm also ?
<ogra_> MCR1, yes
<MCR1> I bet there are a ton of exceptions for this rule
<ogra_> not really...
<MCR1> no more glscreensaver for example ?
<ogra_> on hw that has no gl thats moot
<MCR1> remove all OpenGL applications ?
<ogra_> why ?
<MCR1> You really must be joking now
<ogra_> sw rendering works on arm
<MCR1> OpenGL != GLES
<ogra_> just not fast
<ogra_> and ?
<xnox> MCR1: the replacements are the gtk & kde window decorator bridges + themes.
<ogra_> mesa = mesa ;)
<xnox> MCR1: with respect to "solution", it simply means that it's underlinked and those two libs need to be either added at configure.ac / Makefile.am level, or potentially they are in the wrong order and need to come later.
<ogra_> which is an upstream task
<xnox> MCR1: with a proper patch & autoreconf, it might go into universe or something like that.
<ogra_> right
<xnox> ogra_: we patch a lot of packages like that =)))))
<MCR1> xnox: that would be great news :)
<ogra_> as i said. provide a debdiff and make sure it builds
<ogra_> (on all arches indeed)
<MCR1> ogra_: This is no attack, I am just wondering: http://packages.ubuntu.com/raring/xscreensaver-gl
<MCR1> Where are the arm builds ?
<Laney> hmm?
<Laney> I don't think we have any hard and fast requirement about that
<MCR1> it would be quite ugly for the repos...
<Laney> ensuring ongoing maintenance is more interesting IME
<ogra_> MCR1, on launchpad
<ogra_> you use the wrong tool, packages.u.c is a third party service only listing x86 arches
<MCR1> ah, ok
<tumbleweed> erm, that's not entirely accurate. it's on ubuntu.com and hosted on canonical servers, we can't call it a third party service
<tumbleweed> but yes, it builds on armhf https://launchpad.net/ubuntu/precise/armhf/xscreensaver-gl
<ogra_> oh, ssince when ?
<ogra_> it used to be run by abdebian guy in the past, when wasbit moved ?
<MCR1> ogra_: I could find them on launchpad, thx 4 the info.
<tumbleweed> as long as I've know it... And yes, it is run by Rhonda, who is more a debian person
 * Rhonda hides
<MCR1> ogra_: I will try my best to meet Emerald requirements (might take a while though...)
<ogra_> hmm, i'm probably to long in this business
<Rhonda> MCR1, arm is not part of the official pool, is it.
<ogra_> iit is
<Rhonda> I don't see arm in http://archive.ubuntu.com/ubuntu/dists/raring/
<tumbleweed> and no, there is no requirement that every package build on every arch. But it's preferred.
<ogra_> since 5 releases
<Rhonda> ogra_, isn't
<tumbleweed> Rhonda: it's on ports.ubuntu.com
<Rhonda> tumbleweed: That's a seperate pool, thanks for proving my point.
<tumbleweed> internally to LP, they are the same pool
<Laney> can you get at an internal mirror from the packages.u.c box?
<tumbleweed> it gets split out before it hits the primary public mirror
<Laney> where they are in the same pool
<ogra_> Rhonda, it is officialnsince lucid
<Rhonda> ogra_, http://archive.ubuntu.com/ubuntu/dists/lucid/ doesn't have it neither.
<ogra_> but will never move to archive.u.c
<Rhonda> Thanks again for proving my point.
<Laney> it's to do with usage not officialdom
<ogra_> it is a 100% officially supported arch nontheless
<Rhonda> Why isn't it in the same pool then but in ports?
<ogra_> wejust dont move it to save mirrors from complaining,mits avtech reason we wont mobe itto archive.u.c
<Laney> parse error
<ogra_> sorry, typing on a nexus7 here
<Rhonda> Me too :)
<ogra_> we just dont move it to save mirror admins from complaining, its a tech reason we wont move it to archive.u.c
<Rhonda> Then it's the same tech reason it's not included in pkg.u.c
<ogra_> but itis a fully supported arch nontheless
<ogra_> with 5 years support etc yadda yadda
<ogra_> (LTS supported only since precise though)
<Rhonda> If someone would like to sponsor my efforts along that lines I would be willing to invest more time into the packages code.  Unfortunately my time is limited and I have to take care for my kid and pay back loan.
<ogra_> we all do .., sadly :/
<tumbleweed> knowing nothing about canonical infrastructure, is there a full mirror available to it?
<tumbleweed> full as in including ports
<ogra_> nope
<tumbleweed> because that would make it easy
<ogra_> persia knows a few unofficial asian ports mirrors iirc
<tumbleweed> yeah, it's not hard to reassemble one
<ogra_> but beyind that there arent any officilly
<Rhonda> tumbleweed: Well, taking everything from ports isn't something I fancy.  Are really all archs on ports officially supported ones?
<ogra_> ppc and armhf are
<tumbleweed> and armel went away
<Rhonda> Hm, and those are the only two I see for raring.
<ogra_> armel not
<Rhonda> Was armel official in lucid?  ia64?  sparc?
<Rhonda> Thing is, deciding which are officially supported and which are not from having all in the same pool is fishing for problems.
<ogra_> armel, no ppc and no sparc/ia64 iirc
<Rhonda> Would require load of additional complexity in the code.
<Rhonda> If the official ones could be moved to archive and the inofficial be kept on ports, there would be code to work with that.
<tumbleweed> presumably at some point, we'll have to move armhf to archive.u.c
<tumbleweed> (or arm64 by then...)
<ogra_> iirc there are some tools in ubuntu-dev-tools tobfind whatsnsupported
<Rhonda> And additional complexity only for the reason "to save mirror admins from complaining"
<Rhonda> I dislike such decisions.  They make things just unneeded complicated. :/
<tumbleweed> ogra_: not that I know of
<tumbleweed> (but that was supposed to happen as the next stage of reorg...)
 * ogra_ didnt make that decision, i would love to see my arm work on a.u.c
<tumbleweed> I assume at some point the traffic on ports will become unmanageable
<tumbleweed> (unless all vendors do their own thing)
<ogra_> but it has been discussed each release for the past 4 years
<ogra_> and hasnt moved til today
<tumbleweed> anyway, there is no requirement that every package build on every arch. But it's preferred. In Debain, I port my packages to all the archs I can
<ogra_> so i wouldnt expectthat to happen in the near future either
<Rhonda> The much I hate making you feel bad for your work because it doesn't receive the publicity it deserves, the much I go with the pragmatic approach here: Not working around that issue might increase the preassure on them to get it in.
<ogra_> tumbleweed, i wouldnt let a package in if it wouldnt buildon all arches
<ogra_> Rhonda, heh,i didnt mean to push you there :)
<tumbleweed> ogra_: in this case, I'd agree with you
<ogra_> i was just stating the fact that o.u.c only has x86
<ogra_> *p.u.c
<Rhonda> Yep.  And I've heard that before.  My plan is to activate the "debports" part for ports.u.c to include them that way.
<Rhonda> It would show the archs on the packages lists, but explicitly state them as "(unofficial port)"
<Rhonda> That's the best I can offer on more-or-less short term.
<tumbleweed> being accurate about the officialness and canonical-supportability isn't that important on packages.u.c
<tumbleweed> (to me)
<xnox> Rhonda: armhf is official, despite living on ports.
<xnox> Rhonda: the ports vs archive split is pure disk space management for mirrors.
<xnox> Rhonda: just list them all, without any labels =)
<tumbleweed> I assume that requires more work
<Rhonda> xnox: Do you say so with your canonical hat on?  :)
<xnox> Rhonda: yes =)
<xnox> Rhonda: also documented here: https://wiki.ubuntu.com/SecurityTeam/FAQ#Architectures
<xnox> Rhonda: "While ARMEL and ARMHF are listed in ports.ubuntu.com for this release, they should be considered supported architectures"
<Rhonda> AHAH!
<Rhonda> "maintenance is best-effort"
<tumbleweed> see footnote 4
<xnox> Rhonda: but i think footnote 4 overrides that =)
<ogra_> it does
<Rhonda> xnox: Yes, but that's a specific statement for those two archs, not a general one.
<Rhonda> And that's where it gets tricky.
<xnox> Rhonda: yeah, hence why I explicetly said "Rhonda: armhf is official, despite living on ports."
<xnox> since armel is dropped in raring now anyway.
<Rhonda> You also said "just list them all, without any labels =)"
<ogra_> erm, the release manifest linked is outdated
<xnox> Rhonda: list them all without goind down the path of labeling something offices vs unofficial. It gets tricky very quickly and not as clear cut as ports vs archive.
<xnox> since some ports at some point in time have or hasn't been "official"
<ogra_> yeah, powerpc was on and off
<xnox> Rhonda: anyway p.u.c is very useful =) and the more it lists the better.
<Rhonda> Well â¦   http://www.amazon.de/registry/wishlist/3UJMXUVWGN7Y9/   *whistlesinnocently*   ;)
<Rhonda> No, I'll look into (ab)using the debports port for getting the ports stuff in.  And I need to look why the package descriptions are NOT appearing anymore on the site.  %-/
<xnox> Rhonda: this seems appropriate "Getting Things Done. The Art of Stress-Free Productivity"
 * Rhonda nods
#ubuntu-motu 2013-01-23
<micahg> jtaylor: imagemagick uploaded, please let me know if that worked
<dholbach> good morning
<spyzer> hey everyone, I was making a program which uses libwebkitgtk-3.0, but when I compile the program i get this error http://paste.ubuntu.com/1562127/
<spyzer> i  have installed all dependencies through apt-get
<spyzer> and am using pkg-config
<spyzer> then why do i get this error
<spyzer> please tell
<geser> spyzer: move all those call to "pkgconfig --libs" to the end of the line (after the bridge.o)
<spyzer> geser, I am using autotools so what do i do there?
<spyzer> in Makefile.am
<geser> can you pastebin you Makefile.am
<spyzer> http://paste.ubuntu.com/1562158/
<geser> rename "bridge_LDFLAGS" to "bridge_LDADD" and autoconf should to the right thing
<spyzer> geser, it says linker flags such as `--libs' belong in `bridge_LDFLAGS
<geser> http://www.gnu.org/software/automake/manual/html_node/Linking.html
<geser> LDFLAGS puts those libs before the object file which doesn't work with "ld --as-needed". They have to be listed after the object file which uses them
<spyzer> geser, but then i loose the ability to use pkg-config auto lib generation
<spyzer> ?
<dholbach> geser, do you think you could join bdrung for a developer roundtable at Ubuntu developer Week and answer development questions from the audience? (Thu 31st Jan 19 UTC)
<geser> dholbach: should work
<geser> spyzer: why? you still call `pkg-config --libs ...` but put into bridge_LDADD instead of bridge_LDFLAGS
<dholbach> geser, you are a hero!
<dholbach> bdrung, ^ :)
<spyzer> geser, it throws this error inker flags such as `--libs' belong in `bridge_LDFLAGS when I replace bridge_LDFLAGS with bridge_LDADD
<spyzer> geser, but another doubt, why does this same code compile on fedora and not on this ubuntu machine?
<geser> because Ubuntu's ld has "--as-needed" as default flag while Fedora's most likely not (and with --as-needed the link order matters)
<spyzer> geser, so how do i change that? in my configure.ac?
<spyzer> geser, I tried ./configure LDFLAGS="-Wl,--no-as-needed"
<spyzer> but still didn;t work
<spyzer> :(
<spyzer> geser, GOT the solution it was to add LIBS in the Makefile.am, check this out http://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries
<spyzer> thanks for the help man
<spyzer> u rock
<geser> is Ubuntu considering a switch to rolling releases between LTS?
<Laney> what makes you think that?
<tumbleweed> yeah, apparently it was in the news today
<tumbleweed> people asking me at work
<geser> http://www.golem.de/news/linux-distribution-ubuntu-erwaegt-umstieg-auf-rolling-releases-1301-97086.html (sorry only in German)
 * Laney watches
<geser> is the discussion about it somewhere public?
<tumbleweed> http://arstechnica.com/information-technology/2013/01/ubuntu-considers-huge-change-that-would-end-traditional-release-cycle/ is in english
<tumbleweed> (now that arstechnica has finished being broken and showing moon sharks)
<Laney> perhaps we could call it 'unstable' ;-)
<tumbleweed> :P
<tumbleweed> wasn't it supposed to be grumpy groundhog?
<Laney> that was going to be a parallel branch wasn't it?
<tumbleweed> yeah, like fedora's thing
<Laney> dholbach: you're really quiet compared to ogasawara in that youtube video
<dholbach> Laney, yeah, I know - I tried a couple of times to fix the mic levels, but had to keep going at the same time
<dholbach> I don't know what happened
<Laney> fair enough
<Laney> good to see you're causing waves :P
<geser> I wonder how large-scale changes like updating gcc will work with rolling releases with all the FTBFS such changes cause
<ajmitch> geser: that might depend on whether such things can be caught by tests prior to migrating from -proposed
<tumbleweed> that sounds hard
<ajmitch> it does
<geser> and we expect to see such FTBFS with major gcc updates (or the multi-arched python) and do archive rebuild for testing, but that would block such updates probably till the next LTS given the amount of time need to fix most of them
<geser> and as we can see in archive rebuilds some packages stopped building (unnoticed) due to some other changes too
<ajmitch> unless they could migrate when all seeded packages work with them, rather than all packages
 * ajmitch hand-waves
<tumbleweed> rebuild-testing the archive for migrations seems expensive
<ajmitch> that's what's been proposed already, afaik
<tumbleweed> I only know of the plan to DEP-8 test
<ajmitch> I thought that also included rebuilding prior to testing in the case of library migrations, I'm likely wrong though :)
<geser> I hope there will be a public discussion about this change too (don't have the time to watch the hang out right now)
<bdrung> geser: thanks for joining the table :)
<xnox> geser: i love how jurnalists picked up on that. if you watch the hangout you will notice that in the context of kernel development they are thinking how to provide stability, quality and QA on ongoing basis. since even considering rolling releases that problem first needs to be solved.
<tumbleweed> xnox: but that's not a story in itself
<xnox> tumbleweed: SQUIRREL!
<jtaylor> micahg: thx for imagemagick, next time please replace the fftw3-dev dependency with libfftw3-dev
<jtaylor> oO debian depends in fftw-dev?
<jtaylor> that will give a big dip in fftw3's popcon when wheezy is release :), imagemagick probably makes out 95% of all its installs
<micahg> jtaylor: I doubt Debian will switch from fftw2 to fftw3 before jessie in imagemagick
<jtaylor> yes
<jtaylor> btw its nofftw to fftw3
<jtaylor> imagemagick does not detect fftw2
<jtaylor> which is long obsolete
#ubuntu-motu 2013-01-24
<dholbach> good morning
<Rhonda> rotfl @ wesnoth-editor "screenshot" â¦
<Laney> haha
<Rhonda> At least someone got a sense of humor. :)
 * Rhonda . o O ( I still consider it not really an appropriate screenshot â¦ )
<nigelb> Rhonda: where?
<Rhonda> nigelb, http://screenshots.debian.net/package/wesnoth-editor
<nigelb> oh. lol.
<Rhonda> (or in software center I would assume)
<nigelb> Heh, I see it in packages.debian.org :)
<Rhonda> Or packages.ubuntu.com :)
<Laney> wrote my first executable debhelper file
<Laney> not sure if it's great or awful
<Rhonda> I read awful as helpful.  You make it sound so pessimistic instead. :)
 * tumbleweed crosses himself and steps away from Laney
<xnox> Laney: congrats =) i'm scared of executable debhelper files a little..... it's on a path to non-deterministic builds.
<Laney> xnox: well, it's nothing you couldn't do in rules anyway if you wanted to
<Laney> if I didn't have this I would have written basically the same code in there
<xnox> true
<Laney> well, or enumerated the list of files :P
<Laney> might be /slight/ overkill ;-)
<Laney> that brownie was over too fast :(
<xnox> =))))
 * xnox wants brownie now
<Rhonda> erm, what the â¦  receiving mail that someone gets errors when they want to look up jaunty packages?
 * Rhonda nibbles on Laney.  Baaad idea for convincing me to put my mail address there.  %-/
<Laney> haha
<Laney> Take it away and redirect people to this channel instead?
<Laney> or the motu ML or so
<t4nk216> Hi, I have a question about packaging. I am trying to create packages with tracks and trains for openBVE (train simulator) (see https://launchpad.net/~kaero-ms/+archive/openbverat). These should be only data packages, no binary. For some trains, manuals in pdf should be attached. Where should be such pdf installed, so user can find them?
<jtaylor> usr/share/doc/<package-name> is the normal location
<t4nk216> Thanks for any help
<t4nk216> jtaylor: so the format pdf is not a problem?
<jtaylor> there is some doc-base registration to register them somewhere
<jtaylor> t4nk216: if the source is available no
<jtaylor> the pdf must be built from source
<t4nk216> the source of pdf is unavailable
<jtaylor> thats a problem
<t4nk216> ok, i found something how to make doc-base registration, I will try to dig more. thanks.
<blackz> micahg, jtaylor: xchat patch (bug #1090842) doesn't work for me on amd64. does it for you?
<ubottu> bug 1090842 in xchat (Ubuntu) "FTBFS: in raring pyconfig.h is in /usr/include/x86_64-linux-gnu/python2.7 or .. /i386-linux-gnu/.." [High,Triaged] https://launchpad.net/bugs/1090842
<jtaylor> it did when I wrote it
<jtaylor> lets try again
<jtaylor> hm no it does not work
<jtaylor> I guess the package does not autoreconf
<jtaylor> the patch is based for upstream, so it patches configure.in
<blackz> jtaylor: will you modify it? or do you want me to do it?
<jtaylor> you can do it if you like
<blackz> jtaylor: ok
#ubuntu-motu 2013-01-25
<ESphynx> hey guys
<ESphynx> micahg xnox ping
<micahg> hi ESphynx
<ESphynx> hi :) So, finally! I have some time !
<micahg> I'll have more Sat night :)
<ESphynx> cool... care to tell me real quick though
<ESphynx> basically, there are a few bugs that have been fixed... so I'm planning to just go over all commits and isolate everything that is a bug fix
<ESphynx> and then test the result... is that basically OK for the SRU?
<micahg> ESphynx: well, bug fix + test case in an LP bug
<ESphynx> hmm, so I'd have to go and create an LP bug for each?
<micahg> usually, it's one issue per bug to track if things go wrong
<ESphynx> I see that, but these are bugs that have been fixed upstream :P
<micahg> well, presumably if it's being SRUd and doesn't have a microrelease exception, the bug is an annoyance for someone
<micahg> they need test cases and must be verified on the packages built in proposed
<ESphynx> micahg: well the major bug, as you might recall, is that it doesn't install on 64 bit releases at all
<micahg> ESphynx: yeah, that can be cherry picked and should be easy enough to write a test case for :)
<ESphynx> but since we're bothering making an SRU, I thought I'd throw in fixes for all the bugs I've ran across since.
<ESphynx> (Some of which surely deserving to be fixed)
<micahg> sure, as long as it's a minimal fix with little risk and you're willing to do the paperwork, I don't see why not
<ESphynx> well, not so set a precedent, but Quantal was the first version including Ecere :P and I don't know how many users started using yet, especially that it wasn't installable on 64 bit and most people install on 64 bit these days :)
<ESphynx> and these fixes lower risk more than anything else... Paperwork -- I would like to have a clue what I'm getting into ... Is the size of the paperwork going to proportional to the number of bugfixes I include? ;)
<micahg> yes, https://wiki.ubuntu.com/StableReleaseUpdates#Procedure , see #3
<ESphynx> Can I pack these together into 1?
<micahg> ESphynx: you can keep https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions in mind if you think ecere upstream is worthy
<ESphynx> regression tests... hope to have these one day ;)
<xnox> ESphynx: so do you have the binary package name conflict fix?
<ESphynx> xnox: that's what I'm gonna hit first.
<ESphynx> xnox: We had determined that it would be up to ecere to be renamed I guess? ;) And not elliptic curves? ;)
<xnox> ESphynx: as soon as you have it, shout out. I'll review and sponsor it quickly =) as that's a bit urgent.
<ESphynx> I guess that stems from me being in experimental while elliptic curve is in unstable? ;)
<xnox> ESphynx: yes, unfortunately =)
<ESphynx> ok. xnox I'm starting on that right about now
<ESphynx> just wrestling a bit with micahg here to try to get a MRE for Quantal SRU :P
<xnox> nah, you won't get MRE that easy.
<ESphynx> micahg: a provisional (one-time) MRE really sounds like the best solution to me... Since the main reason is that it's uninstallable on 64 bit...
<xnox> SRU is easier. for MRE you need to show an existing string of SRU typically.
<micahg> right, and if upstream has no regression tests, that won;t fly
<xnox> ESphynx: being uninstallable is savere, just prepare the debdiff and file a regular SRU.
<ESphynx> I think I'll just forget about Quantal otherwise.
<ESphynx> better luck with Raring.
<xnox> fix the clash & I might help you do the SRU for quantal.
<ESphynx> I know you guys offer your help (and I greatly appreciate that)
<micahg> ESphynx: fair warning, attitudes like that don't encourage others to help...
<micahg> (MRE or else...)
<ESphynx> micahg: oh, it's not an attitude thing. sorry , didn't mean it that way
<micahg> ok :)
<ESphynx> micahg: it's just a matter of making the most of my very limited time
<ESphynx> micahg: e.g. I would like to get proper 64 bit support going
<ESphynx> and when Raring comes out this problem will have magically dissappeared :P
<micahg> ESphynx: that's quite understandable, I'd suggest focusing on the high priority bugs and backport a new feature version
<ESphynx> (not because of 64 bit suppor t( i hope to get that going too), but because it's already fixed in Raring...
<ESphynx> micahg: so, with that in mind, should I still bother with an SRU?
<ESphynx> and if so, should I just do the installability one? or should I do one for all the bugs I deem severe?
<micahg> yes, especially for the installability issue
<micahg> I'd suggest for anything severe
<micahg> but your time is yours
<micahg> paperwork isn't that bad if you understand the issue at hand
<ESphynx> yes... but I do want to try to fit in to the Ubuntu project
<ESphynx> but hmm, is that going to be just 1 SRU? or multiple?
<micahg> your choice
<ESphynx> if it fixes multiple bugs? And I should file multiple issues in LP?
<ESphynx> (all associated with the same SRU?)
<micahg> multiple bugs, one debdiff (choose which bug and note on the others)
<ESphynx> for the https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<ESphynx> debdiff which fixes this is attached to bug #xxxxxx" -- I see. I'll try to figure that out when I get there.
<ESphynx> so... for now, I'm going to create a special branch just for this 'sru' process here
<ESphynx> 1 commit per bug fix would be best?
<micahg> well, I always suggest that, but you'll want the commits as patches
<ESphynx> and I should create the bugs on LP with the information as specified there
<ESphynx> as patches?
<ESphynx> from?
<micahg> patches against the source
<ESphynx> meaning the original source?
<ESphynx> i.e. one bug fix can't depend over the other, is it?
<micahg> well, I mean quilt patches
<ESphynx> (that's where stuff gets tricky, I got tons of this already which is why I need to start over again already...)
<ESphynx> right the instability fixes I did depends on improvements to the build system
<ESphynx> right now*
<micahg> yeah, so you'll want a quilt patch for those build system fixes
<micahg> and one patch for each fix
<ESphynx> well yeah I'm going to try to isolates stuff and make it a single commit
<ESphynx> but I was going to do the other fixes as commits on that same branch as well... but you're saying it really should be on the original source?
<micahg> branch, sure, source, no, use patches against the source, the patches are stacked one on another
<ESphynx> so it's ok is all the bug fixes depends on the previous one?
<micahg> yeah, just note which are dependent in case they need to be yanked
<ESphynx> k, well I was just saying, but they really sohuld be independent...
<ESphynx> so how's that I'm going to isolate important bug fixes (starting with the uninstallability one), and I'll file LP bags for them
<ESphynx> and I'll reconvene with you on Saturday evening to see how we can get this moving :)
<micahg> depends on what files change in each patch, it might make sense in the way they are stacked
<ESphynx> (or just drop you a line so you can take a look at your earliest convenience :))
<micahg> sure
<ESphynx> well they are going to be stacked in the order of the branch anyways...
<ESphynx> k, thanks a lot
<ESphynx> xnox: is this going to be a new release for debian?
<ESphynx> micahg: Should I also include this package change for Quantal? the libec package needs to be renamed to libecerec or something similar
<ESphynx> due to a conflict with the elliptical curve library in debian/unstable :P
<micahg> ESphynx: I don't think that conflict exists in quantal
<ESphynx> micahg: It doesn't for quantal but will for raring or later?
<micahg> yeah
<ESphynx> but wouldn't it be best to fix it already?
<micahg> sure
<xnox> ESphynx: name-change for debian. no need for name-change in quantal. raring will just get a synced package from debian.
<micahg> but only raring needs the fix
<xnox> ESphynx: so just make a new debian - and i'll sponsor it into debian & sync it into raring.
<ESphynx> xnox: should this be a minimal fix or can I just release a mini version with latest?
<xnox> ESphynx: new debian can be anything you want =)
<xnox> ESphynx: but with name-change fix please ;-)
<ESphynx> 'fair enough. then I'll fix a couple things and test it a bit. yes name change fix of course :)
<ESphynx> I'll try to get both of these things done by tomorrow!
<micahg> ESphynx: don't forget a breaks/replaces on the older version # of libec0  when you do the rename, should make upgrades to raring work fine as well
<ESphynx> micahg: where does that go? control file?
<micahg> yeah
<ESphynx> k, thanks for mentioning ;)
<micahg> ESphynx: http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
<ESphynx> ah ok, great
<micahg> (that whole page is worth reading)
<ESphynx> micahg: the library is still going to be named the same though ... (except a symlink is going to dissappear)
<micahg> ESphynx: I thought you were renaming libec0 to not conflict with the otehr thing
<ESphynx> micahg: I am... so I'm getting rid of /usr/lib/libec.so*  , but keeping /usr/lib/ec/libec.so
<micahg> hrm, I was referring to the binary package
<ESphynx> yes , the package is going to get renamed... but the library .so file is going to keep the same name
<ESphynx> me and xnox already agreed on a lintian override to silence the warning :P
<micahg> that's fine, I was noting the breaks/replaces for the binary rename
<micahg> *package
<ESphynx> yeah ... will it 'break' though?
<ESphynx> (doesn't it just replace?)
<micahg> ESphynx: http://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks for reasoning
<ESphynx> k
<dholbach> good morning
<jackyalcine> morning dholbach
<dholbach> hi jackyalcine
<alo21> hi...
<alo21> if I download a source which has patches (via pull-debian-source), and I open a file which has a patch, Is the file patched yet when I open the file with gedit?
<Laney> alo21: that depends on the patch system in use
<Laney> is there a debian/source/format file?
<alo21> Laney, yea... 3.0.0
<Laney> 3.0 (quilt)?
<alo21> yes
<Laney> so yes, with that they should be applied
<Laney> you should have seen a message to that effect when pull-debian-source extracted the package for you
<alo21> Laney, and if there is a dpatch?
<alo21> in fact I got that message
<Laney> you wouldn't expect to see that in a 3.0 (quilt) package
<alo21> Laney, well
<alo21> thanks
<Laney> but: dpatch apply
<alo21> fine
<alo21> and during pbuilder --build, all patch are applied. Right?
<Laney> yes
<Laney> if they're correctly in the series file
<alo21> Laney, I have two build logs. One compiled with 'cc -lX11  yeahconsole.o   -o yeahconsole' and failed. another compiled with 'cc  yeahconsole.o   -o yeahconsole -lx11' and succeeded.
<alo21> how can I decide the order of the arguments
<alo21> hi... I am merging a package, and I would like to edit an existing patch and makes it work on Ubuntu. Can I edit it, or I have to create a new one?
<micahg> alo21: it depends, if the patch is pulled from an upstream commit, you'll want to add a new one, if it's Debian only and upstreamable to Debian, you could modify it, otherwise, add a new patch
<alo21> micahg, the patch comes from debian, and it edits a makefile. This patch works well on Debian, but not in Ubuntu
<alo21> micahg, what is the best thing to do?
<micahg> alo21: which package and patch?
<alo21> micahg, yeahconsole, patch 50-makefile.patch
<micahg> alo21: the patch is wrong, that's probably why it fails on Ubuntu :)
<micahg> +LDFLAGS += -lX11 should be LIBS, not LDFLAGS
<alo21> micahg, in fact it fails... and I know the solution (is the previous patch)
<alo21> micahg, or what you said is OK...
<alo21> micahg, Can I directly edit the existing patch?
<micahg> yeah, and send the fix to Debian after confirming it still builds there
<micahg> that stuff should probably ideally use pkg-config, but if this one change works, we can probably let it be
<alo21> micahg, why I should send the fix to debian?
<micahg> alo21: it's wrong there too :)
<alo21> micahg, so have I to fill in a new bug, or I can get in touch with the Debian Maintainer?
<micahg> alo21: file a bug with the fix
<alo21> and the fix should be a .patch or a .debdiff?
<micahg> after confirming it solves the problem of course :)
<micahg> debdiff fixing the .patch I guess
<alo21> micahg, Can I edit a patch just with gedit
<alo21> ?
<micahg> in this case, yes
<micahg> you'll want to quilt pop -a first
<alo21> micahg, what happens to wiki.ubuntu.com? A lot of pages seems no exist
<Laney> probably https://lists.ubuntu.com/archives/ubuntu-devel/2013-January/036384.html
<micahg> so he deprecated the whole wiki? :D
<alo21> ahahah
<alo21> micahg, thanks!
#ubuntu-motu 2013-01-26
<artfwo> what is the current preferred way for a sponsored package upgrade? udd or debdiff?
<cjohnston> artfwo: udd is what they are promoting, but I have done both in the last couple weeks
<artfwo> cjohnston, thanks, so debdiffs are still in use
<cjohnston> artfwo: yes
<lfaraone> If someone is entirely new to working on debian packages and wants to fix a Launchpad bug, what doc should I point them to?
<tumbleweed> the ubuntu packaging guide
<tumbleweed> !packaging guide
<ubottu> The packaging guide is at http://developer.ubuntu.com/packaging/html/  - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports and !sponsoring
<tumbleweed> by a "launchpad bug" I assume you mean something Ubuntu-related
<lfaraone> tumbleweed: Yes.
<lfaraone> Is UDS registration broken? Clicking on "Apply now" takes me to the same page on http://uds.ubuntu.com/about/
<lfaraone> hm, the correct URI is http://summit.ubuntu.com/uds-s/sponsorship/
<lfaraone> soooooo gratuitiously expensive sushi, or pizza?
<ESphynx> lfaraone: I'm going for pizza myself tonight.
<ESphynx> despite my utter love for sushi.
<lfaraone> oops, wrong iwndow.
<ESphynx> =)
<lfaraone> although it was food for an Ubuntu hackathon!
<TheLordOfTime> lol
<ESphynx> lfaraone: same here.
<ESphynx> let's both have pizzas for our Ubuntu hackathon =0
<ESphynx> it's totally on-topic.
<lfaraone> ESphynx: We ended up ordering from http://beautys-pizza.com/. I wonder if they deliver to you.
<ESphynx> lfaraone: Oh I doubt so, I'm in QuÃ©bec, Canada ... I'm all set with my Ristorante pizza in the freezer =) and a 2nd other brand as backup.
<ESphynx> however it's 6:37PM and i haven't eaten breakfast yet, so I was going to go for bacon & eggs & sausages & toasts first
<ESphynx> it's going to be an allnighter hackathon.
#ubuntu-motu 2013-01-27
<micahg> hi ESphynx, I should be ready in about 30 min or so
<ESphynx> micahg: hey... I'm working on this stuff here but sadly not as far along as I would have hoped :|
<ESphynx> Planning to be working through all these issues through the night however :P
<ESphynx> I got pizza & coke set aside.
<micahg> ESphynx: heh, I should be around for the next 3-4 hours if I can be of help
<ESphynx> great :) thanks!
<ESphynx> Hmm, now this is quite annoying... I had symlinks in /usr/lib/ec/ , but actual .so.0.44 were still all in /usr/lib/
<ESphynx> I'm assuming that libec should still be out of there not to conflict with lib elleptical curves, in case 2 versions are ever the same and to avoid overall confusion? :|
<micahg> ESphynx: you might need to change the install path in the Makefile or equivalent
<micahg> indeed
<ESphynx> OK I mostly took care of that :P
<ESphynx> How do I trick people into completing the missing translations for Ecere? :P
<ESphynx> xnox: going for libecc0 ...
<ESphynx> micahg think that should be fine?
<micahg> ESphynx: why not libecere0?
<ESphynx> micahgc: that is the runtime library package.
<ESphynx> micahg: This is the eC compiler library
<micahg> ah, libecc0 sounds good then
<ESphynx> (the actual compiler, not a runtime library...)
<ESphynx> micahg: question about this breaks/replaces stuff... I don't want to 'break' or 'replace' the elliptical curve library named libec0!
<micahg> ESphynx: that's why it's versioned :)
<ESphynx> micahg: yeah but what do the versions mean... do they refer to elliptical curve library or libec?
<micahg> libec
<ESphynx> in unstable, libec0 is the elliptical curve; in experimental, libec0 is the eC compiler
<ESphynx> i.e. http://packages.debian.org/experimental/libec0  vs  http://packages.debian.org/sid/libec0
<micahg> ESphynx: look at the versions the eC compiler version is lower, so breaks.replaces would be fine
<ESphynx> lower because 0.44 vs 2012?
<micahg> yes
<ESphynx> i'm very confused with the DPM's example on Replaces/Breaks  Replaces: foo (<< 1.2-3)
<ESphynx> The example is For example, if a package foo is split into foo and foo-data starting at version 1.2-3, foo-data would have the fields
<ESphynx> This is not the case here, we're talking about completely unrelated packages :|
<micahg> yes, so the package where the libec0 files move, breaks/replaces on the last version of libec0 that had them
<ESphynx> so I should not use <<
<micahg> yeah, << is right
<micahg> err... <=
<ESphynx> Replaces: libec0 (>> 0.44.02-1)
<micahg> no
<ESphynx> is it ?
<micahg> Breaks: (<= 0.44.02-1)
<micahg> same with Replaces
<ESphynx> k. thaks.
<micahg> or << if you want to use the new version there
<micahg> but in this case, I think <= makes more sense
<ESphynx> I do'nt understand all this << ... that's a left shift operator for me :P but if you say <= works, it's good with me :)
<micahg> << is less than, <= is less than or equal to
<ESphynx> ah ok :)
<micahg> ESphynx: see 7.1 : http://www.debian.org/doc/debian-policy/ch-relationships.html
<ESphynx> I see
<ESphynx> a case of annoying historical baggage :P
<ESphynx> What's "debarch_is_wildcard" is not exported by the Dpkg::Arch module  supposed to mean :|
<ESphynx> Somehow my dh-exec 0.3 on Precise got broken by some processs and I'm struggling to get it working agian :S
<micahg> no idea
<ESphynx> Well, look at that! got it working again somehow (though I seriously messed up my package DB :P)
<ESphynx> I wonder why i'm getting these now: W: libecc0: postinst-has-useless-call-to-ldconfig :S
<ESphynx> sounds like a case for an override :P
<ESphynx> micahg: Should update to the NEWS files be included in that SRU?
<ESphynx> I'm going through these 219 commits, and I'm thinking... well yes this bug should be fixed for at least 25% of them :|
<ESphynx> guidance? anyone? :)
<micahg> ESphynx: NEWS file should only be used for major changes in a package
<ESphynx> micahg: yeah but since this was the first versions, I was doing updates to the past history of the SDK :P
<ESphynx> good morning guys
<ESphynx> So, what can I do for these poor souls on Quantal who would like to use Ecere ?
<micahg> ESphynx: not sure what you mean about updates to past history, see http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-news-debian for what the NEWS file is for
<micahg> ESphynx: in the numerous uploads that I've done, I think I've only used a NEWS file entry twice
<ESphynx> micahg oh hi =)
<ESphynx> micahg: Well NEWS has its own meaning for me in the upstream package...
<micahg> ESphynx: that's fine, you should list changes in upstream stuff in the upstream NEWS file :)
<ESphynx> micahg: I made 'corrections' in the past entries of the NEWS file
<ESphynx> micahg: I've been talking about the upstream NEWS file the whole time.
<micahg> ah, heh, ok
<ESphynx> I don't have a separate 'NEWS' file for the package, I thought the 'changelog' handles that
<micahg> that's fine for new upstream versions, not for SRUs
<ESphynx> micahg: so this SRU... I'm at a loss, my friend
<micahg> ESphynx: well, if there's major breakage with a new upstream version, a package NEWS entry might make sense, but in general, no package NEWS is good NEWS :)
<ESphynx> I really don't care about the NEWS file
<ESphynx> my problem is there are ~220 commits between the current Ubuntu package (0.44.01-1) and the latest (0.44.03-1)
<ESphynx> most of which I consider important bug fixes
<micahg> ESphynx: maybe raise the bar to severe then?
<ESphynx> micahg: my other argument is that whichever 'patched up' 0.44.01 is going to be less tested/stable than 0.44.03  as it is
<ESphynx> since I essentially have to 'redo' the patch for the severe issues
<micahg> ESphynx: that's a classic problem with stable releases, we have backports for stuff that's not SRUable
<micahg> ESphynx: just pick the major stuff that's really broke that can't be worked around
<ESphynx> Is backport a possibility here? ah but that doesn't happen automatically, is it?
<micahg> ESphynx: sure, it's possible, but we should at least fix the installability issue in quantal
<ESphynx> Ok.
<micahg> backport isn't an end run around the SRU process, it's an option to get the latest upstream with all features/fixes
<ESphynx> So. 1. installability 2. arm/ppc issues 3.  GCC 4.7 issues
<micahg> sounds good to me :)
<ESphynx> let me give you an example
<ESphynx>     ecere/gfx/fonts: Fixed wrong kerning when using the same face with different sizes
<ESphynx> Should that make it or not?
<ESphynx> this can result in having the e show over the T in a 'Test' string
<micahg> gcc 4.7 issues shouldn't be fixed in an SRU unless they break the build
<ESphynx> they make loading a BMP image crash
<micahg> ah, sounds like a good fix then
<ESphynx> ide/Project: Fixed buffer overflows using DynamicString::concatf -- Should that make it?
<micahg> it's visually annoying, so, it's your call
<ESphynx> visually annoying? what do you mean?
<ESphynx> ah the Font one
<micahg> T over e
<micahg> yeah
<ESphynx> it sure is.
<ESphynx> but i'm just not up to document 200 bugs in Launchpad
<micahg> the buffer overflow might not be exploitable, if it's not, not worth fixing in an SRU
<ESphynx> how about buffer overflows?
<micahg> if it is, probably should go to -security
<ESphynx> hmm well I don't know if it'd be exploitable or not, I don't consider my SDK very secure in the first place.
<ESphynx> Ok then let me review these issues again, in light of our discussions. I'll be picking a minimal set.
<ESphynx> being of perfectionist nature, that's just so hard on my brain :P
<micahg> ESphynx: I can certainly relate
<micahg> ESphynx: here's the general criteria for SRU if that helps: https://wiki.ubuntu.com/StableReleaseUpdates/#When
<micahg> we have backports for the rest :)
<micahg> backports are visible by default in software center, but are opt-in
<ESphynx> oK i'm starting to feel this
<ESphynx> I've singled out 47 bugs
<ESphynx> or commits, rather :P
<ESphynx> https://gist.github.com/4650823
<ESphynx> I made some wine with the grapes in my backyard ;) threw in some stuff including some 100% cherry juice. i've had some comments that it tastes a bit too much of cherry / red licorice :P   This is the label  http://ecere.com/tmp/labelv8.png =)
<ESphynx> (Now on to cherry-picking :P)
<ESphynx> micahg: Any advice on how to proceed? I made a 'quantal-sru' branch and I'm going to cherry pick each of these 47 commits and verify them one-by-one and make sure the result is good.
<ESphynx> Should I be 'regrouping' some of these?
<micahg> dbaa493 eda: Put back include paths to fix Oneiric/amd64 build problems with libffi doesn't make sense
<micahg> db43e9b ide/Debugger: Improved support for GDB 6.3 on OS X also
<ESphynx> micahg: the first one is about adding -I/usr/include/i686-linux-gnu
<ESphynx> the latter is fixes to GDB protocol, and though I did this for OS X it would likely affect a user using GDB 6.3 on Ubuntu as well
<micahg> we have 7.4
<ESphynx> I know, but one might decide to use 6.3 :P (for reasons including the fact that GDB is completely and utterly broken these days)
<micahg> can you justify the reasoning and risk for all of these?
<ESphynx> it's also just 'improved' GDB communication
<micahg> ESphynx: we don't care about non-archive stuff in most cases for SRUs
<ESphynx> the first has no risk, it just adds an include path (reduces the risk of a build failing) ... besides I'm only going to add it if the build needs it :P
<ESphynx> the latter makes the integrated communication more stable
<micahg> I'm saying for the whole list, I don't need you to tell me the justifications, but the SRU team will want to see them as well as test cases (reproducers, not code) and regression risk
<ESphynx> yeah, sounds painful :P
<micahg> right, just focus on what you can justify :)
<ESphynx> a broken debugger is an annoyance
<ESphynx> so every bit of progress I make on integrating with GDB is golden :P
<micahg> sure, but it's not worth SRUing unless you can justify the regression risk
<micahg> and we've got backports for everything else
<ESphynx> I don't mean to sound like an ass, but regression risk -- seriously
<ESphynx> nothing and no one is using this yet :P
<ESphynx> I can understand regression risk to be critical for packages that used by the whole system... like X11, or the kernel, or even GTK, Qt... but for isolated packages?
<micahg> SRUs are meant to improve the existing versions in the archive, backports are there to bring the latest and greatest
<ESphynx> which is why I've singled out these 47 critical bug fixes out of the 220 commits
<ESphynx> but now are they going to expect me to spend 30 minutes for each of these to come up with a reproducing scenario?
<micahg> right, well, that's why xnox and I suggested a minimal set
<ESphynx> 51b6684 compiler/libec: Added missing null pointer check   -- This is a potential IDE crash (one could lose his work as a result)
<ESphynx> Should this make it in?
<micahg> if it was totally broke in quantal, you could push a new upstream, but AIUI, it's not the case on i386
<micahg> ESphynx: yeah, work loss is a good SRU criteria
<ESphynx> a lot of these are SIGSEGV fixes
<ESphynx> true, it's not fully broke on i386 :P
<micahg> ScottK: ^^ any suggestions?
<ESphynx> well I'll go through them again and may omit some ... that was just a first round.
<ESphynx> micahg: let me reiterate that I appreciate your help and especially your moral support in this difficult task :P
<ScottK> ESphynx: We promise no regressions post-release, so the regression concern is a potential issue for all SRUs (more some than others though).  For packages that don't have a micro-release exception approved by the tech board, it's unfortunately necessary to go through a test case for each issue.  It might be possible to have a combined test case that covers multiple bugs.  There's no need to be duplicative about it.
<ESphynx> ScottK: Can a test case be 'steps to reproduce' , or should it be an automated script?
<ScottK> ESphynx: It can be either.
<ESphynx> ScottK: What of a fix for something obviously wrong, but for which I never managed to reproduce the issue on Linux? I'm thinking about: 4750114 compiler/libec/lexer: Solved issue where isatty was called on an eC File object - Hopefully resolves parsing bus errors on OS X
<ScottK> Why would you include the fix for Linux then or are you making a bugfix release for multiple OS?
<ScottK> If so, there's nothing to verify since there's no issue.
<ESphynx> ScottK: I have newer versions which have the fix... this is still an issue on linux, isatty() expects a FILE * but I'm passing it my own struct... It never caused any problem out of sheer luck.
<ScottK> In that case, it's possible, if there's no other way to verify, to do it via code inspection and testing to ensure there's no regression, so mostly describe what you need to do to execute that functionality so it can be tested to still work.
<ESphynx> If I've fixed 5 buffer overflows in different locations, should I describe the 5 ways to reproduce each of them?
<ScottK> Yes.
 * ESphynx tremples in pain
<ESphynx> trembles*
<ESphynx> Something like e84d924 ide/CodeEditor: Fixed buffer overflow - Large strings such as the credits in the IDE's about.ec caused buffer overflows,   noticed as 'Stack smashing' on Ubuntu Quantal  -- surely deserves an SRU?
<ScottK> Yes and if it's noticed as stack smashing in a build log or something, the absence of the same is sufficient.
<ESphynx> that was noticed in the controlling when opening ide/src/about.ec in the IDE
#ubuntu-motu 2014-01-20
<mdeslaur> Unit193: sure we can, ask chad to do it, or file a bug perhaps
<Unit193> Alrighty, got a recommended room or PM OK?
<mdeslaur> Unit193: he's "qengho"...perhaps in #ubuntu-devel?
<Unit193> mdeslaur: OK, saw on LP, thanks.
<Unit193> Hopefully that's good. :)
<dholbach> good morning
<ngaio> Can someone please tell me what the deadline is for a package in Debian testing to be automatically included in Ubuntu Universe? Is it the date of the feature freeze?
<Zhenech> https://wiki.ubuntu.com/DebianImportFreeze
<Zhenech> https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule - 16th feb
<ogra_> you will always be able to request a sync though ... it just wont happen automatically after that freeze
<ngaio> Oh okay thanks! I have a package in Debian and I finally managed to fix an important bug and I want to be sure the fix will make it into trusty
<ngaio> I mean to say, I am the developer of an application which is packaged by someone else in Debian
<cjwatson> testing doesn't matter anyway
<cjwatson> we sync from unstable
<ngaio> I'll request the packager if he can have it into unstable before the 16th, thanks again!
<michagogo|cloud> 16:32:13 <cjwatson> we sync from unstable
<michagogo|cloud> Why is that?
<michagogo|cloud> I mean, why pull packages that are labelled unstable and updatable, and freeze that version, setting it in stone as part of the release?
<cjwatson> because that's not what unstable means.
<cjwatson> it basically just means "changing".  but so is testing - just at a slower rate and the extra gating there doesn't really help us because we do our own very similar version of the unstable->testing process.
<cjwatson> we tried syncing from testing and a large part of the effect was simply that it was more cumbersome and slower to get bug-fixes.
<cjwatson> and some of the benefits of testing in Debian didn't actually end up helping us because of effects caused by rebuilding.
<cjwatson> I am very supportive of Debian testing, but I also know exactly what that process consists of and how it does/doesn't help Ubuntu
<cjwatson> packages that are fundamentally not in a state that might be releaseable in practice normally go into experimental, not unstable
<michagogo|cloud> cjwatson: I wonder if it would be
<michagogo|cloud> Er
<michagogo|cloud> Meant to hit backspace, not enter
<michagogo|cloud> I wonder if it would make sense to only auto-pull from unstable if an older version of the package exists in stable or testing
<cjwatson> I don't think so.  New packages rarely do much harm.  (I realise that you care about a particular exception or two, but those are definitely the exception and not the rule.)
<cjwatson> The vast bulk of new packages are things like new libraries needed for other things to build.  Holding them back until they reach testing would be cumbersome for very little gain.
<michagogo|cloud> I know that some packages, e.g. Bitcoin, are unstable-only in Debian because it is/can be important to keep them updated
<cjwatson> And those we can handle as exceptions.
<cjwatson> It doesn't make sense to change the general rule for those very few cases.
<michagogo|cloud> New libraries that are only in unstable that things that are in testing or stable need to build?
<cjwatson> Varies.
<cjwatson> And it doesn't make sense to introduce extra multi-day delays when it doesn't buy us much.
<cjwatson> Honestly, we've gone over this a lot.
<cjwatson> bitcoind was an anomalous and unusual case, not representative.
<michagogo|cloud> Also, I haven't been able to find an answer to te question of what needs to be done to propose an update to the bitcoin packages that essentially disables them
<cjwatson> I guess I don't understand how to answer that question without restating it.
<michagogo|cloud> One thing that someone mentioned as a solution for the problem of the ancient versions being shipped in older releases was the possibility of an SRU (I think) that would essentially remove the functionality of the software
<michagogo|cloud> Making it inert
<cjwatson> Indeed.  But I don't understand what clarification to that might be useful to you.
<michagogo|cloud> What form such an upgrade might take
<michagogo|cloud> What the change would consist of
<cjwatson> Wouldn't it basically delete the substantive package contents and insert some documentation of why the package was removed and what its users should do instead?
<michagogo|cloud> That's my question.
<cjwatson> s/removed/disabled/
<cjwatson> Well, that's the best answer I can give.
<cjwatson> (Without actually doing the work.)
<michagogo|cloud> Do you know of any precedent, something that I could look at as a reference?
<cjwatson> owncloud was the last example I can think of that called for something similar, although I don't remember whether the disablement was actually executed.
<michagogo|cloud> Where would I find the relevant discussion?
<cjwatson> https://launchpad.net/ubuntu/+source/owncloud/1.1+git20110209-0ubuntu1.1 looks promising.
<teward> Is it safe for me to make the assertion that the version of PCRE in Precise is not going to be updated, and therefore I can mark this nginx bug as "Won't Fix" in precise because the required PRCE libraries aren't going to be updated to 8.20 or greater?
<teward> https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/915344
<ubottu> Ubuntu bug 915344 in nginx (Ubuntu) "enable PCRE JIT support in nginx 1.1 on precise" [Wishlist,Fix released]
<teward> related pcre bug: https://bugs.launchpad.net/ubuntu/+source/pcre3/+bug/909109  (fixed in quantal and later)
<ubottu> Ubuntu bug 909109 in pcre3 (Ubuntu) "upgrade to >= 8.20, enable JIT support" [Wishlist,Fix released]
#ubuntu-motu 2014-01-21
<dholbach> good morning
<jtaylor> I don't get the skiamge failure
<jtaylor> the package in the archive fails its tests, but if I rebuild it locally in a trusty chroot it works
<jtaylor> with an numerical error
<jtaylor> that should be impossible, its the same compiler
<jtaylor> the only thing I can think of is the compiler tuning to the local cpu?
<jtaylor> but doesn't it use generic tuning normally?
<jtaylor> time to do disassembling :(
<jtaylor> oh wait it could be compressed pngs
<jtaylor> indeed it is
#ubuntu-motu 2014-01-22
<dholbach> good morning
<jtaylor> hm we should just mass close the dozens of the blueman crash bugs from [567]xxxxxx bug era, nobody is going to triage them
#ubuntu-motu 2014-01-23
<dholbach> good morning
<zequence> Hi. We have a fix commited for ubuntustudio-default-settings. Would like a sponsor to help upload it. lp bug #1259525
<ubottu> Launchpad bug 1259525 in ubuntukylin-default-settings (Ubuntu) "Lubuntu & Xubuntu & Ubuntu Kylin lightdm session fails to start. user-session is not set" [Undecided,Confirmed] https://launchpad.net/bugs/1259525
<zequence> branch is lp:ubuntustudio-default-settings
<mitya57> zequence: please subscribe ubuntu-sponsors
<zequence> mitya57: Ah, thanks
<gg0> hi
<gg0> could anyone help me backporting a gnash patch?
<gg0> xnox already filed #1253468 a couple of months ago
<gg0> a couple of months ago
<teward> gg0: xnox assigned himself to the bug... I think you need to poke xnox about that
<jtaylor> how do I disable png optimization for a package?
<Laney> I think export NO_PNG_PACKAGE_MANGLE=1
<jtaylor> http://codesearch.debian.net/search?q=NO_PNG_PACKAGE_MANGLE
<jtaylor> mh no results = not right, or don't bother trying to forward to debian
<jtaylor> (or never used)
<Ampelbein> http://codesearch.debian.net/search?q=NO_PNG_PKG_MANGLE
<jtaylor> thx
<Ampelbein> But only 1 result, so maybe wrong as well ;)
<jtaylor> just started grebbing pkgbinarymangler
<Laney> (trusty-amd64)root@iota:/# grep NO_PNG /usr/bin/pkgstripfiles  if [ -n "$NO_PNG_PKG_MANGLE" ]; then
<gg0> teward: already poked, xnox assigned it to himself two months ago, no progress since then. i don't think he will complain if anyone else does the job
<gg0> xnox: right?
<gg0> anyone interested?
<teward> gg0: i want to clear it with him first, I poked -devel to see if xnox is around, the patch builds in amd64 for that bug in saucy, so I don't see a issue with it, but as most of what I do is CLI i can't test.
<teward> gg0: since it's typically good form NOT to do the work of others who're assigned to a bug if they have it on their to-do list (note the "low" priority on that bug though)
<teward> gg0: i know it'll build for Saucy, though, because I did so in a chroot successfully (aka, with sbuild) , but i still have to test the others, I had some nginx updates I had to push to PPAs, so it went on the backburner (it takes about 50 minutes per build in a chroot though, so i won't have build tests done for a while)
<gg0> i'm sure it does build on all versions given gnash version is the same. i'm less sure about reproducing the issue but that can be done even in a chroot
<teward> gg0: well, not within an sbuild chroot, but I can *maybe* push things to a private repository for testing later... brb dinner
<gg0> i don't know ubuntu process. you'll have to reproduce it on all version you want to backport to, right?
<gg0> teward: thanks for your time in advance
<gg0> you might be interested in applying and backporting these ones as well
<gg0> https://bugs.launchpad.net/bugs/1266088
<gg0> https://bugs.launchpad.net/bugs/1266089
<ubottu> Ubuntu bug 1266088 in gnash (Ubuntu) "Please fix alternatives system" [Undecided,Confirmed]
<ubottu> Ubuntu bug 1266089 in lightspark (Ubuntu) "Please fix alternatives system" [Undecided,Confirmed]
<teward> gg0: yeah, i've got enough on my plate right now, I was just doing xnox a favor by peeking at whether it builds for Saucy and such :)
<teward> gg0: but given that the first one you linked was "low" priority, me helping SRU those is at the bottom of my to do list.
<teward> gg0: but, those bugs there, the two you just linked, are missing information I'd need as a triager to test/fix/etc.  You need to point at which versions of Ubuntu are affected
<teward> therefore stating which versions need fixing ;)
<gg0> teward: all gnash versions on all ubuntu versions. about gnash one #1266088 alternatives has been renamed to adobe player one by ubuntu uploaders, i guess on all ubuntu versions. about the latter #1266089, on lightspark alternatives should be renamed to adobe one too for consistency, always been wrong i guess
<teward> I'd suggest adding that information to the bugs.  :)
<gg0> you would do the right thing: ubuntu broke it, ubuntu fixes it :p
<teward> ... and another schroot failure on my sbuild >.>
 * teward goes to destroy and rebuild his schroots
#ubuntu-motu 2014-01-24
<gg0> shouldn't it be backported to precise LTS too?
<gg0> don't know how to add an Affects line
<teward> gg0: as a normal user you can't, if you tell me what's affected I'll nominate it for those series' of Ubuntu, but you have to confirm that those versions are affected
<gg0> ok
<gg0> teward: ok i confirm that both #1266088 and #1266089 affect all releases since precise _included_ (all prerm and postinst scripts in question have same md5checksum)
<teward> gg0: nominated both bugs for P, Q, R, S, and T.  it wouldn't hurt to mark that you tested the bugs and found that all those releases are affected by it
<gg0> done
<gg0> about bug #1253468, it's harder
<ubottu> bug 1253468 in gnash (Ubuntu Saucy) "gnash: youtube play with ffmpeg media handler broken on wheezy" [Low,Triaged] https://launchpad.net/bugs/1253468
<teward> gg0: as i said you have to test each version of the software there to determine whether it's affected, Q, R, S, and T are listed as affected, but I suspect xnox did that, they may know something you and I don't.
<gg0> i'm doing that from chroots. and it behaves a bit differently than debian ones
<gg0> i mean that it seems affected on all included P but when i workaround it as described in bug description i can't see any video, everything black, though movie seems stating because progress bar moves
<gg0> plus, on P seems even gstreamer handler is broken, would need further debug
<gg0> btw easy to test and workaround if you take a look at bug description
<gg0> i'd like to know how it behaves on your ubuntu machine
<teward> well mine's 12.04 so probably the same :P
<gg0> give it a try, it doesn't bite
<teward> nah, too busy dealing with spambots in other channels
<gg0> exactly what i meant, machine that hosts chroots
<teward> gg0: this is why I like CLI output - http://paste.ubuntu.com/6806038/
<teward> gg0: however, the workaround they propose does work in 12.04
<teward> but this isn't a chroot test :P
 * teward doesn't test bugs in chroots, he tests in VMs normally :P
<teward> fortunately my computer is 12.04 so i don't need a VM :)
<gg0> might be i had a temporary network problem
<gg0> nice
<gg0> but i don't think you also have a Q R S T machine :p
<teward> that's what the VMs are for :P
 * teward has a Q, R, S, and T VM
<teward> s/a Q/Q/
<teward> s/VM/VMs/
<gg0> good. time to fire them up and test it again them :)
<gg0> s/them/then/
<teward> no need, Triaged usually means confirmed / ready for work on it :p
<gg0> btw test in question worked great on debian chroots on a debian machine, just such black screen on ubuntu chroots
 * teward shrugs
<teward> I'll leave our comments for xnox, they'll probably see them when they unlurk and be able to provide additional comments
 * teward tends to his sbuild chroots which're still failing
<gg0> builds cannot fail, patch is tiny and all changes are ifdef'ed depending on libav versions
<teward> well, "builds" can fail
<teward> which is why part of SRUing is build testing
<teward> either in a PPA or in sbuild or pbuilder
<teward> but apparently I broke my sbuild chroots
<teward> again
<teward> s
<teward> so i'm just gonna nuke em and rebuild them from scratch
<teward> and NOT modify them :P
<gg0> *builds with patch in question
<teward> gg0: i'm too thorough a triager, i ALWAYS build-test :P
<teward> downside is it takes almost an hour to build in sbuild on my system, but meh
<teward> gg0: I'd rather not intrude on xnox's assigned bugs, though, outside of testing, so you can suggest things all you want, I'm still going to wait for xnox :)
<gg0> i don't think it did anything else than what he wrote/we can see
<gg0> s/it/he/
 * teward shrugs, and goes back to rebuilding schroots
<gg0> ok thanks for now
<gg0> we'll see whemever he'll come back from vacation in a couple of months :p
<gg0> *whenever
<gg0> anyway #1266088 and #1266089 are not assigned, you wouldn't hijack anything
<gg0> thanks for yout time
<gg0> bbl
<dholbach> good morning
<xnox> teward: gg0: please fix bugs assigned to me =)
<xnox> that would be lovely
<Laney> he'll split his salary with you if you do
<TheLordOfTime> xnox: ack.  i'll prep debdiffs.
<TheLordOfTime> can someone approve the precise nomination on https://bugs.launchpad.net/ubuntu/+source/gnash/+bug/1253468 ?
<ubottu> Ubuntu bug 1253468 in gnash (Ubuntu Saucy) "gnash: youtube play with ffmpeg media handler broken on wheezy" [Low,Triaged]
<TheLordOfTime> (since xnox said we can all fix his bugs)
<xnox> TheLordOfTime: that's easy, nomination approved.
<TheLordOfTime> xnox: thanks :)
<TheLordOfTime> xnox: this is gonna be a long day for my sbuild chroots, though, I always test-build before putting debdiffs up :P
<TheLordOfTime> and that took about an hour to build for saucy
<TheLordOfTime> xnox: been a little bit since I did an SRU, I target it for RELEASE-proposed right?
<TheLordOfTime> nevermind, question answered
<xnox> TheLordOfTime: you can just target: RELEASE these days, it gets auto-redirected.
<TheLordOfTime> xnox: ah, the SRU guidelines suggest to target RELEASE-proposed and i already did that on the changelogs for quantal, raring, and saucy
<TheLordOfTime> xnox: i take it that even though it's autoredirected targeted debdiffs for RELEASE-proposed are still accepted?
<xnox> yeah, either is fine.
<TheLordOfTime> also, one question, should each of these get a .1 at the end of the version, or a whole number bump at the end?  I ask that because the procedures say:
<TheLordOfTime> "he version number does not conflict with any later and future version in other Ubuntu releases (the security policy document has a well-working scheme which can be used for SRUs.)"
<TheLordOfTime> s/he/the/
<TheLordOfTime> and because a number bump in quantal will conflict with raring, and raring will conflict with saucy
<cjwatson> if you follow the link to the security doc it has an algorithm you can follow
<TheLordOfTime> or is that irrelevant in each individual release?
<cjwatson> or at any rate a pretty comprehensive list of examples
<TheLordOfTime> cjwatson: that suggests the .1 to the end of the version number (dch also does that, adds the .1)
<TheLordOfTime> cjwatson: i've provided debdiffs with .1 at the end of version numbers as dch and that guide had said, and it's been changed to a full number bump, but I assume that'll be corrected before it's uploaded
<TheLordOfTime> (if such corrections are needed)
<cjwatson> .1 would be correct here, as you say a straight increment would conflict
<TheLordOfTime> right
<TheLordOfTime> cjwatson: a straight increment on precise wouldn't conflict, though, the base version is higher than precise in later releases
<TheLordOfTime> but i'll just do whatever dch does :P
<TheLordOfTime> sponsors can change it if necessary later :)
<TheLordOfTime> xnox: cjwatson: can either of you assist me in figuring out why sbuild failed here?  I can see it says its because of a dependent package not going to be installed, but that's kinda an ambiguous error.  http://paste.ubuntu.com/6809646/
<TheLordOfTime> (that failure looks to be in precise)
<cjwatson> TheLordOfTime: sorry, buried in grub
<TheLordOfTime> cjwatson: no problem.
<cjwatson> one of these weeks I will actually nail down enough regressions to be able to put this in trusty with a clear conscience ...
<Ampelbein> teward: You don't seem to have precise-updates enabled in your sbuild chroot
<Ampelbein> teward: Maybe that screws up the dependencies
<teward> Ampelbein: probably, i'll update the chrotos
<teward> chroots*
<teward> Ampelbein: um... question, how does one go enabling precise-updates in the sbuild chroot
 * teward hasn't fussed with the chroots much yet
<Ampelbein> teward: I always login to the source chroot and add to /etc/apt/sources.list
<Ampelbein> I don't know if there is an easier way.
 * teward shrugs
<teward> Ampelbein: i'll do that for the source chroots then
<teward> good news is the others all build without incident :P
<teward> Ampelbein: looks like that resolved the apt failure, lets see if it builds
<teward> Ampelbein: yeah, adding in precise-updates has resolved the initial issue I was having, the build's going now.  (it's a LONG build though >.>)
<teward> well, now that that builds, all's good.  now i wait for a sponsor to see it.  :)
<gg0> teward: thanks
<gg0> what about bug #1266088 and bug #1266089?
<ubottu> bug 1266088 in gnash (Ubuntu) "Please fix alternatives system" [Undecided,Confirmed] https://launchpad.net/bugs/1266088
<ubottu> bug 1266089 in lightspark (Ubuntu) "Please fix alternatives system" [Undecided,Confirmed] https://launchpad.net/bugs/1266089
 * gg0 should then invent something otherwise he'd be out of bugs to nag about
#ubuntu-motu 2014-01-25
<Unit193> Logan_: Howdy, what's the likelihood of an update getting in that really diverges from Debian, if Debian has a fairly active maintainer?
<Logan_> Unit193: It really depends on the package. I'm actually about to go to sleep.
<Unit193> Logan_: I'd hope, at 0319.  Sleep well.
<Unit193> Thanks
<Logan_> :)
<geser> Unit193: what kind of update and which package?
<Unit193> dropbear, split out a dropbear-initramfs, updated to dh7, updated to latest upstream, updated init script, added building of the scp module and in the initramfs hook to install it as bin/scp, and maybe smaller things or something I'm missing...
<Unit193> I'm guessing a big no, but may as well ask.
<cjwatson> why wouldn't most of those be done in Debian?
 * ogra_ wonders how they make sure you have properly working networking inside the initrd for that 
<cjwatson> the thing people usually choose not to think about is that large divergences are an *ongoing* cost, and need corresponding benefit - fiddling about with the packaging system (dh7, init script, etc.) rarely have anywhere near the benefit required
<cjwatson> work with the Debian maintainer instead
<ogra_> ++
<cjwatson> there's a reason I ended up being (effectively) the Debian grub2 maintainer rather than just doing all the work in Ubuntu, for instance :)
<cjwatson> this way I have to do much less scutwork with merges
<Unit193> cjwatson: Sure, and I understand and get that, just figured I'd ask since I already did it for myself.
<Unit193> ogra_: And the initramfs stuff was already there, I just made it more of an option.  It uses a function to bring it up, or can use the ip= boot option.
<geser> isn't the dropbear Debian maintainer looking for help with initramfs support?
<ogra_> Unit193, yeah, i was just curious
<Unit193> I didn't do much with that though, outside of the package I have .profile so when you ssh in it'll ask you for the password.  Biggest thing I changed in there is used pidof dropbear to forably close ssh connections out of the initrd when the system resumes booting.
<geser> Unit193: https://lists.debian.org/debian-devel/2014/01/msg00289.html , so I'd propose to work with the Debian maintainer to improve the initramfs support for both Debian and Ubuntu
<Unit193> geser: Again, not the part I did, or likely can, do much with. :/
<Unit193> Thanks for responding!  Got the answer(s)  :)
#ubuntu-motu 2014-01-26
<teward> gg0, if someone approves the nominations on bug #1266088 and bug #1266089 I'll maybe take a stab at it, but I have more important stuff on my list of things to do, like find a source of income since I don't have a job anymore :/
<ubottu> bug 1266088 in gnash (Ubuntu) "Please fix alternatives system" [Undecided,Confirmed] https://launchpad.net/bugs/1266088
<ubottu> bug 1266089 in lightspark (Ubuntu) "Please fix alternatives system" [Undecided,Confirmed] https://launchpad.net/bugs/1266089
<teward> gg0, I'm going to be ignoring my nginx bug triaging too for a few days.
<gg0> teward: no problem
<gg0> could anyone please fix them on T at least?
<gg0> (supposing backporting requires more time/priviledges)
#ubuntu-motu 2015-01-19
<dholbach> good morning
<ngaio> good morning dholbach! how are you?
<dholbach> hi ngaio
<dholbach> doing well, thanks - how about you?
<ngaio> good thanks dholbach - I'm an infrequent visitor to IRC but it's always nice to see your "good morning" messages!
<dholbach> :)
<ngaio> is this the correct channel to ask if Ubuntu vivid will contain QT 5.4?
<dholbach> ngaio, yes, you could try #ubuntu-devel as well
<ngaio> dholbach, thanks :)
#ubuntu-motu 2015-01-20
<dholbach> good morning
#ubuntu-motu 2015-01-21
<dholbach> good morning
<mitya57> dholbach: pushed updated index.html to lp:~ubuntu-packaging-guide-team/+junk/update-packaging-guide
<mitya57> I am not a web designer, so it's far from perfect, but definitely better than what we have now
<mitya57> hm, run script should be updated to copy more stuff
<mitya57> pushed that as well
<dholbach> mitya57, wow - let me take a look
<dholbach> mitya57, that's looking great already!
<dholbach> thanks a lot!
<dholbach> mitya57, I guess some changes also need to go into the ubuntu theme in lp:ubuntu-packaging-guide
<dholbach> but I'm no expert either
<mitya57> dholbach: that would be more difficult
<dholbach> I guess so
<mitya57> dholbach: actually, I like the current style of guide itself more than the index.html I wrote :)
<dholbach> mitya57, you mean of articles on developer.u.c or articles on packaging.u.c?
<mitya57> I mean articles on packaging.u.c
<dholbach> ok
<mitya57> If you want, I can make the header bar orange
<dholbach> maybe we should ask others how they feel about it....
<mitya57> Hmm, closing the message about cookies doesn't work
<dholbach> just comparing https://developer.ubuntu.com/en/apps/qml/tutorials/building-your-first-qml-app/ to http://packaging.ubuntu.com/html/auto-pkg-test.html I like how the article on developer.u.c has more space and is more readable
<dholbach> but that's just my opinion
<dholbach> others might feel differently
<dholbach> developer.u.c is also more readable from a device with smaller screen
<dholbach> we would sort of get that for free
<mitya57> dholbach: are non-minified versions of developer.u.c CSS files available somewhere?
<dholbach> I'll ask around
<mitya57> Well, in any case, we can't just use the CSS files from there, we need to write a Sphinx theme simulating them
<mitya57> I will be able to look at that only if I somehow have lots of free time :)
<dholbach> ok... I just wasn't sure if we could do some simple fixes :)
<dholbach> right
<dholbach> in any case I'll follow up on the bug
<dholbach> and thanks a lot for your help already!
<mitya57> You are welcome :)
<dholbach> mitya57, I was just told:
<dholbach> <ant> dholbach, the scss is available at http://bazaar.launchpad.net/~canonical-webmonkeys/ubuntu-web-style-guide/trunk/files/head:/sass/responsive/latest/
<dholbach> not sure if that's all we need?
<mitya57> dholbach: Is this really the same code as on developer.u.c?
<mitya57> File names are different
<dholbach> I'll ask
#ubuntu-motu 2015-01-22
<dholbach> good morning
#ubuntu-motu 2015-01-23
<dholbach> good morning
#ubuntu-motu 2015-01-25
<Unit193> lfaraone: Heya, did you happen to see my pithos ping?
#ubuntu-motu 2016-01-25
<oxide94> Hi all
<oxide94> I'd like to add a new package to Ubuntu
<oxide94> I'm reading https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<oxide94> and the 1st point is to post here, so I'm posting :)
<oxide94> I am a member of MooseFS Team, and we'd love to add MooseFS to Ubuntu
<oxide94> we already have our own repository with packages
<oxide94> could somebody help me?
<oxide94> anybody?
<Rhonda> oxide94: Do you have started with it in a PPA already, or on your own site?
<Rhonda> oxide94: And even better option would be to upload it to Debian and not Ubuntu, to make it available to even more people.  Ubuntu will sync from there then.
<oxide94> Hi @Rhonda, now we don't have Launchpad PPA, but it is on roadmap to add
<oxide94> about Debian - I know
<oxide94> but there's a problem with adding MooseFS to Debian, 'cause there's  LizardFS available in Debian (a fork of MooseFS)
<oxide94> and the LizardFS' maintainer objected to adding MooseFS, so probably it will be a long way
<Rhonda> You can do a personal PPA, not a project PPA for a start.
<Rhonda> They can object to it, but if you maintain it there's little they can do.
<oxide94> http://ppa.moosefs.com/stable/
<Rhonda> Debian is a do-ocracy -- who does stuff decides what's done.
<Rhonda> Were the reasons to keep moosefs out valid?
<oxide94> there were some things we're working on now, like public bugtracker
<oxide94> or source code repository different than this https://moosefs.com/download/sources.html (e.g. GitHub)
<oxide94> and we're working on it
<oxide94> but our, let's say, goal
<oxide94> is to add MooseFS before FeatureFreeze / DebianImportFreeze
<Rhonda> Well, that's nice reasons, but no show-stoppers, there are other packages that don't have that neither.
<oxide94> and problably it may be simple, like marking MooseFS' and LizardFS' packages conflicting to each other
<Rhonda> You should work on that then rather earlier than later
<oxide94> We're working on it, probably we'll be uploading sources into GitHub
<oxide94> yes, we're doing it now ;)
<Rhonda> You think they need to conflict?  Can't they co-exist (don't know anything about either, just wondering)?
<oxide94> You know, both are filesystems
<Rhonda> So?
<Rhonda> ext4 doesn't conflict with brtfs neither.
<oxide94> yes, yes
<oxide94> let me eplain :)
<Rhonda> cat /proc/filesystems.  There is no reason for them to conflict? :)
<oxide94> they're both distributed filesytem, LizardsFS is a fork of an old, outdated and unsupported MooseFS version (1.6.x)
<oxide94> they actively develop LizardFS, and we actively develop MooseFS
<oxide94> in the mean time
<oxide94> there were made some changes, like metadata format
<oxide94> and it may be a security risk, to try to install them both on the same machines
<Rhonda> Do they register as the same fs?
<oxide94> I'm not sure what you're asking about
<Rhonda> Ok, if they really conflict on that level then it's some kinda bad fork approach they took, not nice.  But seemingly nothing you can do.
<Rhonda> If they go by the same fs name underneath, or are recognized as the same fs by the kernel.
<oxide94> you know, LizardFS didn't changed their binaries' names
<oxide94> like mfsmaster, mfschunkserver, mfsmount
<oxide94> etc
<oxide94> we have mfs(xxx), which is obvious, they should have lfs(xxx), which is also obvious
<oxide94> but they don't want to change it
<Rhonda> *sigh*
<Rhonda> Well, yeah, I can see the pain/difficulty to get that resolved.
<oxide94> exactly
<oxide94> @Rhonda: if you have some time, please take a look at this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810822 [Debian ITP for MooseFS] and this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810853 [Debian RFS for MooseFS]
<ubottu> Debian bug 810822 in wnpp "ITP: MooseFS -- fault tolerant, highly available, highly performing, scaling-out, network distributed file system" [Wishlist,Open]
<ubottu> Debian bug 810853 in sponsorship-requests "RFS: moosefs/2.0.83-1 [ITP] -- fault tolerant, reliable, highly available, highly performing, scaling-out network distributed file system" [Wishlist,Open]
<oxide94> I posted them some time ago
<Rhonda> oxide94: The "undesirable overhead from having two similar software products" is a bit of moot.  As long as there are people willing to maintain the things there's nothing wrong with it.  There are lots of similar packages, mail clients/browsers, but especially libraries which are very much more similar in what they provide than different mail clients, so â¦  that can be safely ignored.
<oxide94> exactly :)
<oxide94> but you know
<Rhonda> But if the transparency and following open source is a valid critic, you should work on that.
<oxide94> Rhonda: I'm of course aware of the advantages of putting the package to Debian at first
<oxide94> yes, we are
<oxide94> ok, could you tell me more about this "transparency"?
<oxide94> I'm not sure what does it mean exactly
<oxide94> Rhonda: ok, let's assume, that we'll improve some things like public bug tracker, packages (lintian checks etc.), sources on GitHub
<oxide94> what should we do next?
<oxide94> I'd like to put packages into Ubu before FeatureFreeze date
<Rhonda> When is that?
<Rhonda> Given that for Ubuntu it's much earlier than for Debian, I'm uncertain on that grounds.  I've always got my packages through Debian into Ubuntu (and it's also the suggested way).  About time difficulties I'm not the right person to suggest you something, sorry.
<rbasak> oxide94: interesting. Your situation is similar to MySQL/MariaDB, but not the same.
<rbasak> MySQL and MariaDB work together within the same maintenance team in Debian and work to make sure their packages interact on Debian well.
<rbasak> oxide94: on the other hand you've been accused of not having Debian packaging in shape.
<rbasak> oxide94: your difficulty I think is that you aren't already a Debian or Ubuntu developer able to handle any needed packaging fixes. Unfortunately that takes a ton of time and experience, especially in the forked situation you have.
<rbasak> oxide94: it seems to me that volunteer sponsors aren't going to be able to spare the time you need to make your deadline.
<rbasak> oxide94: you could engage an existing Debian developer or Ubuntu developer to help you. Even then it's tight.
<rbasak> That's how it looks to me, anyway. I hope that's helpful.
<oxide94> rbasak: yes, it is, thanks
<oxide94> @Rhonda: I mean Ubuntu FeatureFreeze, Feb 18th
<oxide94> rbasak: about debian packaging "in shape" - I checked our packages using lintian and it issued, let's say, minor warnings which are easy to fix (like outdated Free Software Foundation postal address ;)
<rbasak> oxide94: there are plenty of things that lintian is not capable of picking up.
<oxide94> of course there are many more things, and some of them are more important
<oxide94> Ok, I see
<oxide94> So... should we try to do everything to go through Debian and be imported automatically to Ubuntu?
<rbasak> I haven't looked at your packaging, so I cannot judge. But I do deal with packaging created by non-Debian developers quite often, and I have very rarely seen any that isn't somehow flawed.
<oxide94> ok
<rbasak> I'm biased. I work for Canonical. I'd say that the only chance you have is to engage Canonical. I should point out that this isn't a requirement; for Ubuntu all you need is competent packaging, consensus amongst Ubuntu devs (not Canonical) that it is good, an existing Ubuntu developer to upload, and an Ubuntu archive admin to accept. None of this requires Canonical.
<rbasak> But for you to achieve that is potentially a very tall order.
<rbasak> I have undertaken this kind of work before, and it has taken months and multiple cycles.
<rbasak> In time you can become an Ubuntu developer and handle most of this yourself.
<rbasak> The issue is your deadline.
<oxide94> Yes...
<oxide94> and especially that this is LTS release...
<rbasak> OTOH, you can seek to get it into Debian, and in that case it'll automatically get synced to Ubuntu if it's in before Ubuntu's feature freeze. But that seems even more unlikely to happen in time.
<oxide94> exactly.
<rbasak> (to your deadline)
<oxide94> at the moment I managed to add MooseFS to FreeBSD :)
<oxide94> of course, there were some problems etc.
<Rhonda> oxide94: Putting it into a personal PPA (doesn't need a group PPA) would be a big start.  That way you can already ask people to look at it.
<oxide94> Ok, great, I'll start with that
<oxide94> and then... post here one more time, or maybe there's something like ITPs or RFSes like in Debian?
<rbasak> You can file a [needs-packaging] against Ubuntu (no particular package) and tag it needs-packaging, Wishlist. That's the equivalent of an ITP, but isn't a requirement. It's also a place to track an RFS.
<rbasak> If you do create one, please make sure to link to the Debian bugs, as the first question any sponsor will ask is "why can this not be done in Debian?"
<rbasak> If you want to put a proposed upload into the sponsorship queue, see https://wiki.ubuntu.com/SponsorshipProcess
<oxide94> ok, many thanks!
<Punkoivan> guys, I moving to devops engineer, can anyone give me good book or maybe online resource to learn about it?
<Punkoivan> Which config manager easy to learn for novice? I read that it's ansible, doesn't?
<thebwt> ... this is probably not the right channel for that
#ubuntu-motu 2016-01-27
<lukesoft> Hi Guys, Really trying to get going with contributing to ubuntu......but iam getting some bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/tomboy/".
<lukesoft> can you pliz point me in the right direction, i believe i set up my dev env correcly
<Rhonda> Hmm.  If I update the trusty-backports package of wesnoth-1.12 with a version from xenial, I will have to also propose a backport for vivid and wily, right?
<lukemadzedze> guys which languages are used mostly if i want to contribute to ubuntu-motu
<lukemadzedze> programming languages
<Laney> lukemadzedze: any, it depends on what the program is written in
<lukemadzedze> Laney: thank you very much
<lukesoft> guys is there a way to find out which language a package is developed in, before i start trying to fixing its bug...or even downloading the sorces
<lukesoft> is there a way of know the language used in a package, before downloading the sources....i want to try out fixing a bug or 2 but only if its a java application...but i dont seem to see any other way to know its a java programm before downloading the sources
<rbasak> lukesoft: if you have deb-src lines in sources.list, use apt-cache showsrc and examine its build dependencies, maybe?
<rbasak> You will need to understand how those map to languages, and a C compiler won't be explicit in there as it's build-essential.
<rbasak> (maybe C++ too, I'm not sure)
<rbasak> lukesoft: it's hard to categories because source packages could use multiple languages. Most distro engineers handle many languages, so there's there's never been a need to classify them.
<lukesoft> rbasak: Thanks a lot ey, i am a java developer with very limmited understanding of c++ and c, iam really desperate to start working on my first bug or 2, so naturally i would love to work on a java project for practice .......but i cant find any package written in java, to use for practice, and iam getting a bit demotivated as all the other languages a really looking like greek to me
<lukesoft>  all the other languages *are really looking like greek to me
<lukesoft> :(
<rbasak> lukesoft: Ubuntu has a ton of Java work that needs doing, but unfortunately it may be too much in the deep end for you right now.
<rbasak> lukesoft: I don't know much about the Java side of things, but you might be able to use "reverse-depends -b" to find things that require some named java package to build. That would maybe give you a helpful list.
<rbasak> lukesoft: perhaps look at bugs against tomcat7 and tomcat8?
<lukesoft> rbasak:Thanks a lot, let me try that for now, if i fail, i can always try my level best with everything else........after all i mainly want to do this to learn :)
#ubuntu-motu 2016-01-28
<sidi> I need to port a lib (libzeitgeist-1) to multiarch support. Anyone here got a good tutorial on what needs to be done?
<Rhonda> :~$ requestbackport -d trusty wesnoth-1.12
<Rhonda> requestbackport: Error: Source release xenial does not exist
<Rhonda> Oo
<Rhonda> What may I be doing wrong?
<Laney> distro-info-data out of date maybe?
<Rhonda> Does it need a deb-src entry?
<Laney> J    if source not in ubuntu_info.all:
<Laney>         raise DestinationException("Source release %s does not exist" % source)
<Rhonda> Laney: Ah, that might be, upgrading to the backports version.
 * Laney nods
<Rhonda> Yes, found that part, but no clue about the rest. :)
<Rhonda> I mean, found that line in the source but no clue how to look further from there. :)
<Rhonda> Anyone of you at FOSDEM btw.?
 * Laney 
<Rhonda> yay :)
<Rhonda> Comments on https://bugs.launchpad.net/bugs/1539085 and how to process here very welcome.
<ubottu> Launchpad bug 1539085 in trusty-backports "Please backport wesnoth-1.12 1:1.12.5-1 (universe) from xenial" [Undecided,New]
<Rhonda> meh
<Rhonda> service mysql start failed, how can I diebug further (sorry, not used to upstart at all)
 * Rhonda redirects herself to #ubuntu
#ubuntu-motu 2016-01-29
<dholbach> good morning
<ioan> hi
<ioan> my game is finally done, and I was wondering do you accept launchpad builds?
#ubuntu-motu 2016-01-30
<Fantu> hi, why nemo 2.8 is still in proposed?
#ubuntu-motu 2017-01-24
<dude_> hello
<sladen> helo
<dude_> why is "contribuiting in the developpement of ubuntu" equivalent to "maintaining packages". What exactly is Ubuntu ? a collection of packages ?
<ogra_> it is way more, but development typicall yhappens in source packages, so yeah, thats equivalent in most cases
#ubuntu-motu 2017-01-25
<ehoover> wgrant: would love to bend your ear re: wine packages when you have a moment
#ubuntu-motu 2017-01-27
<zerous> hi :)
#ubuntu-motu 2018-01-23
<hawa7> hi, is there any reason why the eclipse package is still in version 3.8 and accordingly 6 years old?
<Rhonda> You mean besides noone investing the time to work on it?
<hawa7> exactly
<hawa7> seems like a very long time. so there could be a another reason apart from the usual
<Rhonda> From what I understood there were changes to it that made it harder to package, and it's java.  But I never digged deeper into it, and when I asked only frustration came back from the people that tried to work on it.
<hawa7> i understand, java indeed is ugly
<hawa7> this is the first package i came across in ubuntu, which is really that old
<hawa7> is there a list of packages with their respective age in universe?
<Unit193> Perhaps Debian 681726.
<ubottu> Debian bug 681726 in src:eclipse "eclipse: Upgrade to latest upstream release (HELP WANTED)" [Serious,Open] http://bugs.debian.org/681726
#ubuntu-motu 2018-01-24
<tsimonq2> handsome_feng: Hi
<tsimonq2> handsome_feng: So if you noticed I only uploaded that one package, it's because I think there's other packages that depend on it
<tsimonq2> handsome_feng: So I wanted to get that processed first, but as you can tell, builders have been down so there's a backlog :)
<handsome_feng> tsimonq2: hi, sorry for the late reply. Thank you! And by the way, in my new package list, there is no package depends on ukui-menus, the only dependency is ukui-window-display depending on ukwm. :)
<tsimonq2> handsome_feng: oh ok :)
<tsimonq2> handsome_feng: I'm also curious to see what your reply to jbicha is in #ubuntu-release ;)
<handsome_feng> I have replied. Check it out :)
<tsimonq2> Ok :)
<tsimonq2> Worst case scenario, I can just poke one of the archive admins myself.
<tsimonq2> I'm looking at ukwm now, although I'll be to bed shortly :)
<handsome_feng> That would be great, thank you very much!
<handsome_feng> You can do it tomorrow, thanks ! :)
<tsimonq2> (I'm waiting on the clothes dryer ;) )
<tsimonq2> handsome_feng: One thing I did notice though is that I had to add "Wed, " before "17" in the date line of ukwm. It's trivial enough I can fix myself, but I think that was my problem compiling with sbuild :)
<handsome_feng> emmm, I make a mistake , thank you!
<tsimonq2> It's all good, I'll upload a fixed package when ready ;)
<handsome_feng> \o/
<tsimonq2> handsome_feng: Er, except for one thing. https://paste.ubuntu.com/26449337/
<tsimonq2> no-symbols-control-file is the major thing I think should be fixed.
<tsimonq2> Fixing any of the other warnings would be good as well, but I'll only block on that one, I think.
<handsome_feng> I will fix this soon and then update the PPA
<tsimonq2> Awesome :)
<tsimonq2> I went to review ukui-panel but I'm depwait: libukui-menu-dev:amd64 (>= 1.0.0)
<tsimonq2> Anyways, I'll go to sleep now, have a good day :)
<handsome_feng> Good night!
#ubuntu-motu 2019-01-27
<JackFrost> I have http://paste.openstack.org/show/UGto7TYyd7A1roF5hn7i/ for xscreensaver, unless someone really thinks 60_sequential_glslideshow.patch is worth keeping (and if so, then forward it upstream already)
#ubuntu-motu 2020-01-23
<alkisg> Hi guys. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792687 recommends NOT regenerating the .pot file on each build, yet python's DistUtilsExtra/command/build_i18n.py does that unconditionally
<ubottu> Debian bug 792687 in src:gettext "gettext: please support timestamps from environment" [Wishlist,Fixed]
<alkisg> Any ways around it, or any other advice?
 * alkisg asks that in #ubuntu-devel instead, in case pitti is around and can take a look... ty
