#ubuntu-motu 2006-02-27
<sistpoty> andrewski: what is the last message you get from inside pbuilder?
<andrewski> pbuilder: debootstrap failed
<andrewski>  -> Aborting with an error
<andrewski>  -> cleaning the build env
<andrewski>     -> removing directory /var/cache/pbuilder/build//5987 and its subdirectories
<andrewski> that's right after the warning.
<sistpoty> andrewski: the interesting stuff is just before deboostrap failed, what's there?
<andrewski> ok... pastebinning... brb. :-P
<sistpoty> :)
<andrewski> http://paste.ubuntu-nl.org/9078
<sistpoty> andrewski: oh nice... my first guess is, that you did everything right
<andrewski> that's good to hear. :)
<sistpoty> andrewski: yep... archive.ubuntu.com seems to have problems atm
<andrewski> hm.  so i could change my mirror and probably be good to go?
<sistpoty> andrewski: you could try that, or just wait until a.u.c is fixed
<andrewski> i'll try changing my mirror.
<andrewski> sistpoty: and you said that dapper is usable now?  i'm tempted to go ahead and upgrade, but this is on my laptop, which i want to work.
<sistpoty> andrewski: I've been using it for quite some time, and I didn't notice any big problems recently
<andrewski> sistpoty: this close to release, it's only likely to be small updates, right?
<TheMuso> I must say I have found GNOME a little sluggish on my P4, whereas Breezy runs fine.
<sistpoty> andrewski: we're almost at feature-freeze, so mostly bugfixing
* sistpoty is afk now... dinner is ready
<andrewski> hmm... and i could justify upgrading so that i could help find and squash bugs too. :)
<andrewski> TheMuso: hmm, odd.  i wonder why?
<ajmitch> andrewski: some of us have run dapper since it opened :)
<ajmitch> so it's obviously not too bad
<trappist> it's had its moments
<mae> i can vouch that the "alpha" experience with dapper was much nicer than it was with breezy
<mae> lol
<jahraztah> hello i was wondering whether the version of gtk-gnutella in dapper willbe upgraded to the latest stable version since the verison in dapper is expired and will not function
<jahraztah> this also goes for breezy backport
<jahraztah> current stable working version is 0.96 and version in repository is 0.96b b for beta
<TheMuso> jahraztah: We are currently in upstream version freeze, but a request may have been made to update it, I don't know.
<jahraztah> but this is very important
<jahraztah> a new version of dapper comming with an expired version of a software
<jahraztah> and the version was expired many days ahead of upstream version freeze
<jahraztah> 24 January 2006, Version 0.96 Released
<lfittl> jahraztah: do you know which version is in debian?
<jahraztah> 0.96
<TheMuso> The debian version is 0.96cvs200602040801-2
<jahraztah> ok
<lfittl> we should wait for debian to get the final, and then request an UVF exception
<TheMuso> c/
<TheMuso> Note that feature freeze is only days away.
<lfittl> days? just ~20 hours
<jahraztah> normally i wouldn't request like this, but this upgrade is important, because the software doesn't function if not upgraded, do you know what i mean?
<LaserJock> we can get a UVF  exception after FF can't we?
<ajmitch> LaserJock: yes
<jahraztah> the offical website does provide a deb, and the deb is fully working so far on my ubuntu
<jahraztah> will dapper include software to allow easy installation of debs without opening a terminal. like a gui front using dpkg
<ajmitch> like synaptic?
<lfittl> jahraztah: yes, we have got gdebi for that now
<ajmitch> or do you mean gdebi for the single packages?
<tseng> or gdebi
<jahraztah> yes, like when u download a deb file from the net you u just double click it and the applicaton launches and installs for you
<jahraztah> and show all the things that are happening, like where it'll install and package info, and also dependencies
<jahraztah> because dpkg does nothing about dependency. and you have to manually downlaod tha packages and then re-install the deb
<tseng> not really
<tseng> apt-get -f install resolves dependancies on partially installed debs
<jahraztah> oh i did not know that
* mode/#ubuntu-motu [-o fbond]  by fbond
* mode/#ubuntu-motu [+o fbond]  by ChanServ
<fbond> crud
<LaserJock> fbond: man, that thing loves you ;-)
<fbond> i know jesus i already got the authorities involved
<LaserJock> I don't know if Jesus had anything to do with it, but ok. ;-)
<fbond> i should hope he wouldn't be getting involved here
* mode/#ubuntu-motu [-o fbond]  by fbond
<TheMuso> From a glance, gtk-gnutella is probably just a straight sync.
<TheMuso> Going by the changelogs. Haven't looked any deeper though.
<sistpoty> TheMuso: debdiff (and filterdiff) or diff for the debian-dir is your friend ;)
<mr-russ> When packaging, how do you get different file ownership than the default, do you have to adjust postinst?
<TheMuso> sistpoty: I know.
<sistpoty> :)
<sistpoty> mr-russ: afaik yes.
<mr-russ> okay.
<sistpoty> mr-russ: just look in the debian-policy, I bet there is s.th. about file ownership in there ;)
<sistpoty> wow, s.o. is working on the new-queue :)
<mr-russ> sistpoty: thanks.  10.9 :)
<sistpoty> hehe
<TheMuso> Gee. The changelog has had a lot of editing done to it since universe got 0.96b.
<ajmitch> sistpoty: good, so a few things should work again - hopefully syncs get handled also
<sistpoty> ajmitch: yes... hopefully I will be more successful in getting an answer right now than with my previous tries ;)
<ajmitch> hehe
<ajmitch> sounds like it was more fun with soyuz
<sistpoty> definitely ;)
<fbond> hmm...pbuilder is failing to update with md5 errors
<fbond> anyone seen this?
<ajmitch> wouldn't surprise me
<ajmitch> archive.u.c is having issues today
* TheMuso was able to update his 3 builders, one of which is on powerpc with no problems.
<fbond> is there a mirror?
<sistpoty> fbond: sure... iirc there was a list of mirrors in the wiki
<TheMuso> Although now I am not having such luck, even though there is a good chance there is nothing to update.
<hub> w00t. exifprobe is in
<TheMuso> heh. Just to show you how bad the issues are, one ofo my i386 builders completed successfully, whereas the other one failed.
<dolson> fbond: hey... sorry, I thought you went on vacation so I did qsampler. I started doing linuxsampler, but I can't get that gcc crap to go away. I read the FAQ, but that didn't work for me
<sistpoty> hub: congrats :)
<hub> hugin will wait because of the license
<hub> but they'll fix the problem upstream
<hub> by using vigra 1.4 that is MIT licensed
<dolson> fbond: so thanks :)
<fbond> i just finished linuxsampler
<fbond> qsampler is done
<fbond> ?
<fbond> sistpoty: do all ubuntu package repos also contain current dapper?
<fbond> dolson: yeah i was sick for a few days, needed sleep more than anything
<dolson> sleep? what's that? ;)
<dolson> fbond: yeah, I did qsampler yesterday
<dolson> I think... or maybe earlier today? geez, I don't even know now
<sistpoty> fbond: no idea... if these are complete mirrors, they do
<fbond> ah
<fbond> dolson: ok, then that should be good to go
<sistpoty> dolson: btw.: vcf-plugins uploaded... I guess my concern wasn't really justified... :)
<fbond> where can I monitor status of dssi sync from debian?
<sistpoty> fbond: is the sync requested already?
<dolson> fbond: it didn't rely on linuxsampler, so I was able to do it first. and I think the dapper-changes list
<dolson> sistpoty: cool deal! please upload anything with fbond's name on it ;)
<fbond> sistpoty: i am in revu as forest@alittletooquiet.ent
<sistpoty> dolson: I'm already reviewing like a mad man ;)
<fbond> sistpoty: siretart had said it was on his todo list
<dolson> fbond: if we do get all these music apps in, we'll be my heroes!
<TheMuso> hehehe
<sistpoty> fbond: ah... good, but I think it will be a few days until syncs will be progressed again (due to the statement on -dev some minutes ago)
<fbond> dolson: just like i'd always dreamed...
<dolson> fbond: I am not sure I am comfortable knowing that you dream of me.
<sistpoty> fbond: you could always subscribe to the changes-mailing list, and check for dssi-accepted message
<fbond> sistpoty: ok.  there are some packages in revu that depend on dssi
<dolson> some important packages!
<fbond> dolson: don't get too uncomfortable.  i was mostly being polite.
<dolson> lol
<sistpoty> I guess I will build dssi locally for reviewing pending packages...
<fbond> that, of course, would be appreciated.  don't kill yourself, though.
<fbond> dolson, sistpoty: i'd like to get dssi-vst in, but wondered if anyone had thoughts on the licensing issues
<TheMuso> fbond: That is a curly one.
<fbond> yes, it would have to be an automated download
<fbond> during build
<TheMuso> I think it has been discussed a lot of linux audio dev and user, but I am not aware of what the conclusion was.
<fbond> or create a separate package called vstsdk
<fbond> right
<fbond> i had created a vstsdk package that downloaded the SDK at install time
<dolson> fbond: I did om and omins too. wasnt hard at all...  firstly, the libs were already in dapper, and the FlowCanvass thing I guess is distributed in the source, not a separate lib to package
<TheMuso> I know it would be nice to ship, but the license is a tough one.
<fbond> dolson: terrific
<fbond> TheMuso: not really
<fbond> it's this simple: you can not distribute source of VST SDK in any form
<fbond> dssi-vst makes an exception from the GPL in its license that allows distribution of dssi-vst without VST SDK source
<fbond> at least for dssi-vst, licensing is pretty cut-and-dry
<TheMuso> Right.
<fbond> it's just a simple matter of making dssi-vst buildable by an automated build machine
<sistpoty> fbond: is dssi-vst on revu? can't find it there
<fbond> i.e.
<fbond> sistpoty: no, not ATM
<fbond> i've not uploaded my previous
<fbond> package
<sistpoty> fbond: can you point me to the licence / upstream tarball?
<fbond> cause Steinberg, in the meantime, released a new version of the SDK
<fbond> sure
<fbond> http://www.steinberg.net/sdk_downloads/vst_29468/index.php
<dolson> dssi-vst is a very important thing for musicians, especially anyone coming from Win32 who invested any money or time into certain VSTs.. I sure hope something can be worked out
<fbond> the new version of the SDK does not compile cleanly with dssi-vst
<fbond> will probably require some tweaking
<fbond> and Steinberg doesn't make old versions available after new releases
<fbond> and old versions are not redistributable
<fbond> so some work is in order
<TheMuso> fbond: There is also the chance that they completely change the URL.
<dolson> is there a CVS of dssi-vst?
<fbond> TheMuso: yes, we had considered this
<fbond> the URL looks very phony
<sistpoty> fbond: I get a file not found
<fbond> dolson: yes, i haven't checked it yet
<fbond> sistpoty: might've moved, or maybe that's an old link
<fbond> sistpoty: hang on a sec...
<sistpoty> thx
<fbond> dssi-vst is on sourceforge as a part of dssi package
<fbond> use soruceforge CVS if necessary
<dolson> cvs hasn't been updated for over a year
<fbond> to download VST SDK, Steinberg makes you agree to a license, and then send you an email with a link to the goods
<fbond> so i suspect the actual location does change from time to time
<TheMuso> They are trying to prevent the very thing you want to implement I guess.
<fbond> http://www.steinberg.de/sdk_downloads/vst_29468/index.php
<fbond> TheMuso: yes, they are trying to thwart my noble efforts
<fbond> sistpoty: crap
<fbond> i think i just pasted the same link
<fbond> it is
<fbond> ha!
<fbond> they are watching IP addresses
<sistpoty> fbond: found it already on sourceforge
* ajmitch waits for the black helicopters
<fbond> sistpoty: you found VST SDK?
<fbond> just license?
<sistpoty> fbond: no, dssi-vst... is this s.th. different?
<fbond> sistpoty: probably not
<fbond> can't just diff it cause the Steinberg version is a .rtf
<sistpoty> fbond: http://dssi.sourceforge.net/download.html
<dolson> fbond: that link works for me
<fbond> sistpoty, dolson: yes, i've been there before.  where is the VST SDK license on that page?  are you sure it is there?
<fbond> sistpoty: or did you just want the dssi-vst license?
<sistpoty> fbond: I'm looking through the tarball actually
<fbond> yes, the README in the tarball has the dssi-vst licensing info
<fbond> dolson: oh, BTW, don't get too down on yourself over linuxsampler package.  it wouldn't compile with anything except gcc-3.3 for me.  <3.3 = bad; >3.3 = bad; =3.3 = good
<fbond> i had to force gcc-3.3 in debian/rules with environment vars to configure step
<fbond> and adding appropriate build-depends
<dolson> fbond: cuse told me it is "known to work with gcc 4.0"
<fbond> dolson: not from what I can tell
<LaserJock> ajmitch: I saw a black helicopter land in the middle of nowhere in Montana once. But I don't think that had anything to do with Linux ;-)
<dolson> I think it has similar asm issues as Mx44, which Willem van Engen patched
<sistpoty> fbond: oh... that licensing is a real pita... I guess the only way to do it might be to have a package vst-headers that downloads the header-files in postinst and have dssi-vst depend on that
<dolson> fbond: by the way: http://rivironline.com/ubuntu-6.10.png
<fbond> LaserJock: but it might've been related to VST!  You know how those Germans get...
<fbond> jk
<ajmitch> LaserJock: they're out to get you, you know
<sistpoty> fbond: however it's not even guaranteed to work, since you cannot assume to have networking on the buildds (inside the build-environment)
<fbond> sistpoty: ouch.
<LaserJock> but in Montana? there is nothing but crazy bombers and cowboys out there. ;-)
<TheMuso> That crossed my mind earlier.
<fbond> sistpoty: well, without downloads, it's definately not feasible...
<fbond> maybe just a source package...
<sistpoty> fbond: we can't make a sourcepackage, if these files are not redistributable :(
<sistpoty> fbond: I'm not sure about downloading though... maybe infinity or lamont could give a hint there
<fbond> i mean dssi-vst source, and require user to manually download VST SDK
<fbond> apt-get install dssi-vst-source
<sistpoty> fbond: ah, sure... that would work
<fbond> wget vstsdk.zip
<ajmitch> still sounds nasty
<fbond> fancy-debian-build-command make-my-dssi-vst
<fbond> yes
<fbond> nasty
<ajmitch> I doubt the buildds have external net access
<fbond> how lonely!
<ajmitch> so the user would need to build this
<fbond> dolson: yeah, i tried to rebuild linuxsampler with gcc-4.0.  no such luck...
<fbond> gcc-3.3 is the only one that works for me
<dolson> that's weird..
<sistpoty> fbond: gcc-3.3 is a nogo unfortunately... it needs to built at least with 3.4 (and c++ stuff depending on c++ with >4.0)
<dolson> oh crap
<fbond> um
<fbond> gcc-3.3 is in current dapper repos.  this will change?
<fbond> 3.4 is likely ok.
<fbond> hmm just a sec
<fbond> dolson, sistpoty: i might've been wrong about gcc-4.0 failing...
<fbond> oops, no i was right
<sistpoty> fbond: yes, that will change, maybe for dapper +1... but new packages mustn't use 3.3 any longer
<fbond> ok
<lfittl> gn8 everybody
<dolson> fbond: we should figure out how to patch that code I guess.. I don't know where to start, really
<fbond> well, let's give 3.4 a shot first
<fbond> so, g++-3.4 is not okay?
<sistpoty> fbond: if it's c++ depending on c only, it's ok... but as soon as you've got a dependency on c++ it won't work since c++-abi was changed between 3.4 and 4.0
<fbond> "depending on" = "links against" ?
<sistpoty> exactly
<fbond> never really understood this abi stuff :)
<sistpoty> fbond: it will just segfault, if you try to link these together
<fbond> ok
<fbond> sistpoty: is it okay to compile C with gcc-3.4 and C++ with g++-4.0 and then link them?
<sistpoty> fbond: c abi didn't change, so you can mix up c-code from 3.4 and 4.0
<fbond> and mixing 4.0 C++ with 3.4 C is okay?  just not to familiar with these kinds of compiler issues...
<sistpoty> fbond: yes... c++ linking with c can see only c-interfaces (as there are only c-interfaces) and thus is ok
<fbond> okay, thanks!
<sistpoty> np
<fbond> crud.  g++-4.0 is the problem
<fbond> dolson: linuxsampler will not compile with g++-4.0, and links against libgig, which has C++.  as a result, g++-4.0 must be used.  Where is the info on patching?
<dolson> fbond: you mean on patching in debs or patching this specific code problem?
<fbond> patching this problem.  did you have some info?
<dolson> I don't... all I know is that whatever changed between g++ 3 and g++ 4 surely broken ASM stuff, because I had similar issues in Mx44
<dolson> fbond: I will try building the latest CVS
<sistpoty> dolson: congrats, qamix is in
<fbond> dolson: ok
<dolson> sistpoty: cool :)
<sistpoty> dolson: next thing to do is also check the build-logs (as soon as there are any)
<TheMuso> Any others motus around that could have a look at My few packages? :)
<sistpoty> dolson: know where you can find these?
<TheMuso> Sorry dolson, I just feel that a11y is just as important as audio. :)
<dolson> sistpoty: not as of yet, but you are surely going to tell me :)
<dolson> TheMuso: indeed it is
<TheMuso> dolson: But you were there first. :)
<LaserJock> can I get somebody to look at the debian/copyright file at http://tiber.tauware.de/~laserjock/copyright ?
<sistpoty> dolson: https://launchpad.net/people/adolson/+packages, then just click on the version-link and then on the link under release to get to the buildlogs
<dolson> sistpoty: sweet.
<LaserJock> dolson: yeah, I just found out about the +packages today. very cool.
<TheMuso> Ah! Finally got all pbuilders updated.
<sistpoty> LaserJock: I would put the "you should have received a copy of the gpl..." paragraph in the copyright... but it's also good the way it is (imo)
<dolson> LaserJock: I saw it before, didn't know it would be so integrated though. pretty awesome
<dolson> wb apacheLAGger
<dolson> wb poningru
<dolson> wb j^
<marcin`> hi guys
<dolson> wb Fuddl
<dolson> wb everyone else
<marcin`> got a problem
<marcin`> I got an webapplication and this webapp has /cache directory
<marcin`> and this directory has to be writable to webserver users
<marcin`> to put uploads there and cache files
<marcin`> where should I install this directory?
<marcin`> in /usr/share/mywebapp/cache or maybe in /var/cache/mywebapp and symlink to /usr/share/mywebapp?
<fbond> dolson: i gotta run for a bit.  let me know how things go with linuxsampler CVS?
<sistpoty> marcin`: did you take a look at fhs for this (in package debian-policy)?
<dolson> fbond: k, thanks for reminding me, lol
<fbond> later
* dolson got distracted by TV
<marcin`> sistpoty: kind of...
<marcin`> sistpoty: it's pretty unusual situation so there is no simple answer..
<marcin`> sistpoty: I think that user files should go to /var/cache...
<marcin`> sistpoty: but I'm not sure so I ask here...
<sistpoty> marcin`: not really sure... if you delete one of these files, what happens then?
<marcin`> sistpoty: well there is no files currently
<marcin`> sistpoty: this webapp creates only directory structure
<marcin`> sistpoty: to keep user files there in future
<marcin`> sistpoty: it's for user uploads
<sistpoty> marcin`: so if a user uploads a file, it will end up there? what if these file is deleted afterwards... will you get data-loss, broken links or s.th.?
<marcin`> sistpoty: propably not
<marcin`> sistpoty: it's: /cache/images /cache/import /cache/upload
<marcin`> sistpoty: with 'fake' index.html files in each directory
<sistpoty> marcin`: if a manual deletion of a file there is fully recoverable, /var/cache/mywebapp is the place to go
<marcin`> sistpoty: and these html files contains only 'This directory must be writable by the webserver user.'
<sistpoty> marcin`: if not, probably /var/lib/mywebapp
<marcin`> ok - and symlink to /usr/share/mywebapp ?
<sistpoty> marcin`: if you really need these, yes
<sistpoty> (if you can change the path directly, please avoid putting symlinks in there)
<marcin`> well I need this unfortunately
<marcin`> this path is hardcoded in php code
<marcin`> to /$webappdir/cache
<sistpoty> then either patch the code or use symlinks ;)
<marcin`> so if I keep webapp files in /usr/share/webapp then cache has to be there
<marcin`> yup
<LaserJock> do all files in the source need to be covered under debian/copyright or just the ones installed?
<sistpoty> phew... no idea really... if these aren't installed, you wouldn't need to have info on the copyright about them. and if you use the sourcepackage you'll have the copyright information anyway... but OTOH it's convenient to have them all in debian/copyright, thus you can easily install another file w.o. having a messed up copyright
<sistpoty> brb
<dolson> fbond|away: no luck.. I fear this is going to be a no-go
<shelagh> Hello, dolson; how can I help? I don't know how to start.
<dolson> help what
<TheMuso> shelagh: What do you want to help with?
<LaserJock> hi minghua
<shelagh> I wrote to you the other day (e-mail) to say I would help if I could
<dolson> shelagh: ah, I was thinking your name looked familiar
<shelagh> with learning how to make packages or testing or whatever.
<minghua> evening LaserJock
<dolson> shelagh: do you know how to progran at all?
<odla> hey i no longer need espresso or casper installed if i have dapper installed to my harddrive do i?
<shelagh> in theory, but not in practice yet.
<odla> shelagh: oh...so if i purge them...that's bad?
<shelagh> odla, sorry iwas replyting to something else.
<odla> ok
<shelagh> Where do I find out about using the packaging utilities? the documentation seems a little sparce on my harddrive.
<dolson> shelagh: check the links in the topic
<dolson> shelagh: right now I'm not really doing anything... I'm just waiting with baited breath to see if there are any fixes I need to make to my packages before feature freeze which is on the 23rd. but I am looking up stuff about trying to get LinuxSampler's compilation errors resolved so forest can fix his package in time
<zakame> hi all
<dolson> zakame! :)
<zakame> heya dolson! :D
<shelagh> dolson: got it. I'll do some reading and practicing.
<dolson> shelagh: are you familiar with any music software yet? if so, could you write some quick tutorials, like a quick-start guide? for instance, if you did one for Audacity, just show how to record multiple tracks, mute tracks, solo, volume levels, time shift, envelope editor, and plugins. just real quick, to the point, intros. not real advanced stuff
<shelagh> dolson: hmm... my experience has been struggling with midi and rosegarden, lilypond stuff. They have pretty good documentation. If I could work out how to get midi going reliably in ubuntu, I would happily do a tute on that!
<LaserJock> what is the state of lilypond? do you guys use it much?
* dolson can't read a note 
<fbond> dolson: I'm not seeing much useful info
<fbond> one guarranteed fix is to disable MMX/SSE asm optimizations
<fbond> is it worth dropping to get the package in, for now?
<dolson> hmm... sounds good to me
<fbond> ok
<fbond> i'll get it rolling
<dolson> actually, Mx44 has MMX disabled, I think
<fbond> ah
<fbond> well that solves things pretty easily, although it is less than ideal
<fbond> i will see if i can work with upstream to get the problem resolved
<fbond> but for now, no asm optimizations
<dolson> thanks man
<dolson> I appreciate your work
<fbond> not a problem :)  and you've done well yourself
<dolson> thanks :)   we should look at building a 2.6.15-ck
<TheMuso> dolson: That will very likely break a lot of other stuff that depends on particular kernel patches/drivers in the distro if the user chooses to install that kernel.
<dolson> TheMuso: it is required for realtime audio... so there is not really any option. this is outside of ubuntu anyhow
<TheMuso> dolson: I know. But what about the extra drivers that have been patched into the current kernel. Users just might need them.
<fbond> TheMuso: my package is based on ubuntu's.  those drivers are there.
<fbond> the config is nearly identical, insomuch as it can be
<dolson> until Ingo's patch is accepted into mainline, there's not a lot we can do
<fbond> i just modified the patch list
<fbond> took out incompatible patches, added -ck6
<fbond> (to my 2.6.12-ck6 package)
<TheMuso> Righto then.
<TheMuso> You will be lucky if you can get it in, or are you not trying to get it in?
<marcin`> I have been asking about this today here but I'll try again
<fbond> i don't anticipate that a non-MOTU will be submitting a kernel package, no
<TheMuso> Fair enough.
<marcin`> does anyone here know if are there any plans to implement conditional dependencies in dpkg/apt?
<fbond> besides, there are loose strings WRT patched PAM, bash, etc, no?
<fbond> marcin: I doubt it
<dolson> fbond: I haven't heard anything back from Mark about a -rt kernel ever since the last thing I sent you
<fbond> you would have to check with Debian to know for sure though
<TheMuso> fbond: Yeah. IIRC dolson asked about that in #ubuntu-devel and kamion said he would have a look.
<TheMuso> the pam stuff that is.
<dolson> that's right.. he assigned the bug to himself
<marcin`> fbond: ok I'll try on debian channel
<fbond> this is not very useful info to me... I'm a bit out of the loop
<fbond> marcin: good luck...sorry couldn't be more help
<marcin`> fbond: but it's really strange that there is no such feature in dpkg yet..
<dolson> I sure hope that it gets into dapper in time.. the PAM patch at least. it's very small, even I understand what happens in the patch, and that's saying something
<fbond> marcin: i would guess that it is not useful that often. most packaging scenarios are pretty straight-forward
<marcin`> fbond: so I hope there is a chance to make at least feature request
<TheMuso> Cnditional deps?
<marcin`> fbond: most - yes...
<fbond> dolson: me too.  linuxsampler is done-and-done
<marcin`> fbond: but there are more complicated packages
<dolson> nice. I'll dl it and try it out here, along with my qsampler
<fbond> okay gotta run to grocery store before... sorry to take off in such a flash
<marcin`> TheMuso: yes - related with debconf
<fbond> marcin: hmmm, i'd have to think about it.  maybe there is an alt. solution.
<fbond> i'll be back, anyhow
<marcin`> TheMuso: for example you got webapp that can use mysql or postgresql database or remote database
<TheMuso> marcin`: A bit more explanation please. Not really up on what you are talking about.
<TheMuso> marcin`: Right.
<marcin`> TheMuso: then you could make a choice in debconf dialog and it could install dependency of your choice
<TheMuso> Yep I am wiwth you.
<marcin`> TheMuso: currently you have to do weird things with packages to provide this functionality
<TheMuso> Right.
<marcin`> TheMuso: I know that could be complicated but pretty usefull too
<marcin`> TheMuso: I think that this straight forward is just something from pre-debconf era...
<dolson> fbond|away: big diff.. I'd recommend adding in libjack0.100.0-dev as well
<LaserJock> hi bmonty
<bmonty> hey LaserJock
<zakame> heya LaserJock bmonty
<LaserJock> hi zakame
<TheMuso> dolson, fbond|away, do you use pbuilder to test packages?
<dolson> TheMuso: I do
<bmonty> hows it going zakame?
<zakame> doing great, still adjusting a bit to dapper (and xchat-gnome ;)
<bmonty> I don't think I'll be using xchat-gnome for much longer
<zakame> heya sistpoty
<bmonty> the only thing I like about it is the popups if someone sends me a message
<TheMuso> Go Irssi!
<sistpoty> hi zakame
<sistpoty> hehe, I just though, why is it so quiet, until I noticed that I got disconnected ;)
<LaserJock> bmonty: yeah, I'm using this cool OSX chat app that has a nice notify bubble.
<TheMuso> Hey guys. I have just been reading a bit about soyuz, and noticed something about RSS feeds. Anybody know where to find them?
<LaserJock> TheMuso: where were you reading about soyuz?
<TheMuso> On the launchpad wiki.
<TheMuso> They probably ahven't implemented it yet.
<TheMuso> I like the sound of it though.
<odla> is there something funk with mp3 support in dapper with rhyhmbox?  i have all the proper packages installed but i can't seem to get mp3s to play
<LaserJock> grrr I wish I could figure out a way to make a dapper chroot in OSX
<zakame> huh? you can't?
<crimsun> odla: dpkg -l gstreamer0.10-plugins-ugly |grep ^ii
<LaserJock> zakame: how could I?
<minghua> LaserJock: vmware, I suppose :-P
<odla> crimsun: nothing
<minghua> if vmware works in OS X, that is...
<crimsun> odla: so install it.
<LaserJock> minghua: oh my gosh, I never thought of that
<zakame> LaserJock: there you go
<odla> crimsun: the multiverse package or the regular one?
<LaserJock> minghua: there isn't anything OSX specific but do you think the linux vmware-player would work?
<crimsun> odla: the exact package I named.
<minghua> LaserJock: I seriously doubt it, considering it's most likely i386
<minghua> LaserJock: oh did you have an intel mac?
<LaserJock> I'm running i386 ;-)
<minghua> ok, slightly higher change, but still very close to zero in my opinion
<odla> crimsun: thanks
<crimsun> odla: np
<odla> crimsun: maybe that should be added to the unofficial dapper guide?
<crimsun> odla: sure?
<crimsun> (don't know what the unofficial guide is)
<odla> http://easylinux.info/wiki/Ubuntu_dapper
<odla> someone in #ubuntu+1 showed that to me
<whiprush> there's an #ubuntu+1?
<whiprush> heh
<fbond> dolson: libjack0.100.0-dev for which package?
<dolson> fbond: linuxsampler?
<fbond> TheMuso: yes, I use pbuilder
<fbond> dolson: hmm...
<fbond> does it depend on libjack-dev?
<crimsun> it should _not_ build-depend on libjack-dev
<dolson> no, it doesn't.. and the diff > orig
<crimsun> always use the versioned build-dep for apps that require jackd
<fbond> right, i was saving keys
<fbond> saving have now been lost
<crimsun> (libjack0.100.0-dev explicitly)
<fbond> dolson: i'm not following
<fbond> (yes i get it...thanks)
<dolson> fbond: the diff file is larger than the orig source tarball.. did you do that on purpose?
<fbond> um
<fbond> hang on
<dolson> k
<fbond> oh, i ran the autotools stuff so that it wouldn't build-depend on autotools-dev
<fbond> hmm this is not ideal
<fbond> but the tarball would've contained configure
<fbond> i just had to grab from CVS instead, since downloads are gone
<fbond> can I fake the tarball?
<fbond> that should be okay...
<crimsun> just make sure you clearly denote in the source version that it's a snapshot. Don't generate configure before debuild -S ; instead build-depend on automake1.{8,9} and libtool
<fbond> crimsun: the only reason I'm using CVS is because the source tarball is temporariliy unavailable
<fbond> you recommend I do not reconstruct source tarball as it would've existed?
<fbond> i've exported the CVS revision that corresponds to that release
<crimsun> fbond: no, because the release tarball may differ in md5sum, which will throw off any sync attempts from Debian (if the package is in Debian, which I presume it isn't?)
<fbond> (correct it is not) so I should treat this as a CVS snapshot, then?
<fbond> dolson: what version of qsampler did you package
<crimsun> if you checked it out from cvs, yes
<dolson> fbond: one sec
<fbond> dolson: CVS HEAD?
<dolson> fbond: I used the latest stable qsampler
<fbond> was it available on site?
<dolson> fbond: you can generate the last release tarball of linuxsampler from CVS
<dolson> yeah, qsampler has its own sf.net page
<fbond> i exported from CVS because downloads had been unavail for about two months due to outage
<dolson> fbond: Christian sent me the instructions to make the .orig.tar.gz file, I'll fwd to you
<fbond> dolson: who?  what instructions?
<dolson> fbond: you've got male
<fbond> i should hope not
<dolson> hehe
<fbond> okay i gotta run real quick, i'll deal with this in a bit
<dolson> Christian is the project lead.. I figured there was a way to generate their official release from the CVS, and I was right, he sent the instructions
<fbond|away> ok
<fbond|away> i'll be back
<dolson> k cool
<sistpoty> dolson, fbond|away: please only "fake" the release, if it really is bit-identical to the official tarball (caveats e.g. timestamp of files), otherwise just use a version-number for a cvs-checkout instead
<sistpoty> s/checkout/export/ ;)
<dolson> sistpoty: well, there is no way to ever know because their server failed and has been down since December 3rd
<sistpoty> dolson: then I guess it's better to tag the version as CVS-version
<dolson> so co -r  release0_3_3 linuxsampler, make dist, and then give it a CVS version (0.3.3-cvs?) in debian/control
<dolson> btw, fbond|away, the way it is now, I try to install and it doesn't go. libgig is not installable. for whatever reason, it's libgig3c2 that it has to depend on
<sistpoty> dolson: yes
<dolson> I shouldn't have deleted my packaging work from earlier
<crimsun> the beauty of maintaining packaging in svn/bzr/$yadda
<dolson> I just deleted it because forest put his on revu
<dolson> but my diff was really a lot smaller
<sistpoty> dolson: (you must ensure that version numbers can always be increased for higher version, where 0.3.3-cvs is higher than 0.3.3 and you usually name the version differently... but in this special case 0.3.3-cvs is good as well)
<dolson> I'd like to know what the proper way is
<sistpoty> dolson: listed in https://wiki.ubuntu.com/MOTU/Packages/Reviewing
<LaserJock> hmm, this might be a stupid question but does anybody know if the new Intel macs are 64bit?
<TheMuso> LaserJock: I don't *think* so, but don't hold me to that.
<LaserJock> hmm, I think somewhere I saw that they "secretly" are but Intel doesn't market them as 64bit or something stupid like that
<crimsun> they're core duos afaik, which are 32-bit
<dolson> sistpoty: so "0.3.2.99+0.3.3-cvs" is proper
<sistpoty> dolson: probably 0.3.2.99+cvs-20062202 for usual checkouts, I would use 0.3.2.99+0.3.3-cvs only if it's tagged in cvs
<sistpoty> dolson: so that you can easily verify which checkout the one for the tarball was
<dolson> it is tagged. the latest cvs will require the latest cvs of qsampler, libgig, liblscp, etc, which we don't want at this time
<sistpoty> dolson: sounds sane to me then ;)
<dolson> cool deal
<fbond> dolson: no worries, it will just take me a second
<dolson> fbond: did you base your package on the release checkout, or did you get the source elsewhere?
<dolson> like.. mentors?
<fbond> mine was based on release checkout
<fbond> i have followed instructions as per your email
<dolson> cool.
<dolson> I am not impressed with a lot of the stuff I've looked at in mentors
<fbond> i haven't really checked it out
<dolson> I assume that removing libgig from the depends list will allow the magic stuff to pick the correct libgig
<fbond> that's what i did
<dolson> I wonder why they don't use sourceforge instead of relying on their own servers
<fbond> sourceforge goes down too
<fbond> but not for two months, generally
<fbond> :)
<dolson> hehe, I know, but qsampler is downloadable thanks to sourceforge :)
<fbond> sistpoty, dolson: the tarball is usually distributed as a .tar.bz2, not a .tar.gz, does MD5 even matter then?
<dolson> I'm pretty sure sf does backups of some kind
<fbond> oh, nm
<fbond> it does
<dolson> they're both there heh
<fbond> sorry, stupid q
<sistpoty> dolson: just looking at qsampler... you should link to config.guess/config.sub in the config.status-target instead of the clean target (and remove them in the clean-target) to get these files out of the .diff.gz
<dolson> sistpoty: I'm opening up the rules now
<sistpoty> (and ask upstream to provide a tarball w.o. debian-directory ;)
<TheMuso> Rhythmbox in GNOME 2.14 is going to be really cool!
<TheMuso> Using it now.
<dolson> sistpoty: what the? I didn't put those in the diff on purpose, I don't even know what they are for lol
<sistpoty> dolson: they sometimes are more up to date on the buildds (e.g. for porting to new architectures), but afaik aren't that much useful for ubuntu
<sistpoty> at least I that's what I think they are for ;)
<TheMuso> I remember reading something about them in the autoconf documentation, I think in the README.Debian file.
<TheMuso> When I first started putting a package together a few months ago.
<minghua> the README.Debian.gz file in autotools-dev
<dolson> I have it installed in 3 places, /usr/share/{misc,libtool,automake-1.7}/config.guess
<dolson> same with the .sub
<minghua> I suppose dolson used dh-make and didn't touch the debian/rules it generated
<TheMuso> minghua: That sounds like the one.
<fbond> dolson, sistpoty: linuxsampler should be looking quite a bit better at this point
<fbond> (updated)
<fbond> minghua, TheMuso: actually, dolson's package included a debian dir
<fbond> from upstream
<fbond> and upstream could use a few tweaks
<TheMuso> fbond: Was it useful
<fbond> well, yes
<fbond> still needed tweaking
<sistpoty> sorry, but I really need to go to bed now... will try to do some reviews tomorrow
<dolson> I tried to make the least amount of changes as possible
<fbond> night sistpoty!
<fbond> thanks!
<sistpoty> you're welcome ;)
<dolson> sistpoty: sleep tight :)
<TheMuso> sistpoty: Night, and thanks.
<sistpoty> good night
<fbond> i gotta run, too
<fbond> dolson: if you want, give linuxsampler a shot
<fbond> i have not tried to install under dapper, but it does build
<dolson> I will for sure, going to sort qsampler and try them both
<fbond> great
<fbond> send me an email if something looks fishy, but I believe it shouldbe good to go now
<fbond> diff is quite small
<fbond> i'll talk to you tomorrow, probably
<fbond> night :)
<dolson> will do
<dolson> cya man
<zakame> afternoon MOTUs
<dolson> hi zakame
<zakame> ei dolson :D
<dolson> don't make fun
<Hobbsee> hi zakame
<dolson> I didn't choose to get laid off :(
<zakame> hi Hobbsee! :D
<Hobbsee> :)
<zakame> dolson: ???
<Kyral> Okay. Deskbar Applet owns
<Kyral> -ERANDOM
<dolson> zakame: ei = imployment insurance :)
<zakame> dolson: ah :) didn't know that
<dolson> ok, I just fixed the complaint about qsampler. should be good to go
<dolson> zakame: got laid off as a Christmas gift, thanks to off-shoring jobs from Canada to Pakistan
<dolson> ok, I think I will fix linuxsampler now and send a patch to forest
<zakame> dolson: awww :(
<dolson> zakame: I think it was a blessing.. I have learned a bit about packaging now
<zakame> dolson: good for you! :D at least there's a positive side in that :)
<dolson> there's a positive side in everything
<dolson> except perhaps hemorroids
<zakame> gaah
<dholbach> good morning everybody
<dolson> hi dholbach
<dolson> my alarm instantly wakes me when you sign on
<dholbach> hey dolson
<dholbach> :-)))
<dholbach> ROCK ON
<dolson> dholbach: qsampler is good to go I think. linuxsampler needs a bit of work..
<dholbach> NIce one!
* minghua has just finished a flight-4 test install
<dholbach> ROCK'N'ROLL - how did it go? :)
* dolson is ready to kill someone
<minghua> quite well, the installation is smooth, the result system is nice
<dholbach> super!
<minghua> the Chinese font is still far from satisfactory though, but that's my only complaint
<sladen> minghua: we'd like to deal with that one compliant and get it sorted :)
<sladen> minghua: have you used any other Linux distros/installs (eg. a previous version) that had better looking fonts
<sladen> minghua: maybe we can track down a better font from there if it's free enough to ship
<minghua> sladen: sure, I know exactly what font I need
<minghua> I even sort of know how to configure it to the desired effect
<minghua> the package in ubuntu is unfortunately very crappy
<minghua> I am refering to bug 31149
<Ubugtu> malone bug 31149 in ttf-arphic-uming "Bold fonts smudged" [Normal,Unconfirmed]  http://launchpad.net/bugs/31149
<minghua> and I am opening a new one in a second
<dholbach> minghua: do you know where and how to configure those default fonts?
<minghua> dholbach: more or less yes
<dholbach> minghua: where? because I'd like to change the arabic fonts too, they suck too.
<minghua> dholbach: and I think I can always ask (on fontconfig upstream mailing list, for example) in case I don't know
<minghua> dholbach: almost everything can be configured by fontconfig
<minghua> dholbach: I don't know which TTF font is best for arabic though
<dholbach> I'd try some different ones
<dholbach> I'll have a look.
<minghua> dholbach: and it depends if you want to map it to sans/serif/monospace or not
<dholbach> i see
<minghua> dholbach: the file to look at is /etc/fonts/fonts.conf, but the best way is not to modify it
<minghua> dholbach: put a file in /etc/fonts/conf.d instead, using a filename starting with two digits
<dholbach> ah cool
<dholbach> I'll have a look at those
<minghua> dholbach: and fontconfig will pick it up automatically
<dholbach> Nice.
<minghua> dholbach: man fontconfig and that's probably all (and so much more) you need to know
<dholbach> Some bug report complained about arabic fonts and when I tried an arabic installation, I saw what he meant. :-)
<minghua> sladen: back to your first question, though - as I've only used Debian and Ubuntu, I haven't seen a distro with nice looking out-of-box Chinese fonts, although I've heard of a lot
<dolson> I remember when all fonts in general sucked
<lfittl> dholbach: ping
<dholbach> lfittl: pong
<tepsipakki> slomo: thanks for making gstreamer0.10-plugins-bad* like you promised :)
<slomo> tepsipakki: np :) but please file bugs whenever something doesn't work so we get at least some of these plugins ready for good/ugly...
<tepsipakki> sure. they even managed to get 0.10.1 out just in time. I'm still running my own version of -bad but as soon as your packages hit the servers I'll try them
<slomo> tepsipakki: they're already on archive.ubuntu.com... at least the universe variant, multiverse should be there in some minutes
<tepsipakki> great
<tepsipakki> if someone could take a final look at gtkpod-aac, it already got one advocate ;) http://revu.tauware.de/details.py?upid=1908
<tepsipakki> and it's naturally meant for multiverse
<slomo> it will get to multiverse anyway because it b-d on faad or faac ;) but sure, i'll take a look now
<tepsipakki> thanks!
<slomo> it is based on gtkpod?
<tepsipakki> yes
<slomo> ok... hm, can you keep care that all new changes to gtkpod are also applied to your package? :)
<tepsipakki> sure
<tepsipakki> it would be easier if they all used the same patch-system, but it's pretty simple as it is
<slomo> tepsipakki: when it's based on that package please include all changelog entries in there, not only your own
<tepsipakki> hmm, read the comments above ;)
<tepsipakki> it has it's own source-tarball, so it was suggested to start from a clean table
<slomo> tepsipakki: ok, fine with me... but i would've included the old changelog :)
<slomo> either you made changes outside of debian or there were any before and you reverted them... why? it will make your life harder when you try to stay in sync with debian
<slomo> and apparently you missed some bits that were changed before... for example in src/prefs.c
<slomo> or in scripts/
<tepsipakki> in gtkpod there is debian/ubuntu_patch.diff which patches the path /mnt/ -> /media in various places. When you run 'rules clean' the patch is not reverted, so it results in a bigger diff.gz, so I made it to use dpatch.
<slomo> ok fine with me but when doing a debdiff between gtkpod and gtkpod-aac there were changes in the mountpath in src/prefs.c and in the scripts directory that are not in your package anymore
<tepsipakki> hmm, I'll check
<tepsipakki> true..
<tepsipakki> duh
<slomo> and in gtkpod the ubuntu.diff is only for reference... it was applied to the sources to not invent a new patch system over the debian package
<slomo> so just do the same please to keep the delte between gtkpod and gtkpod-aac as low as possible
<tepsipakki> I need to pach configure to change PACKAGE=gtkpod -> gtkpod-aac, so if I just add a patch for that?
<tepsipakki> and keep the rest as in upstream?
<tepsipakki> it's just confusing to have different kind of comments on revu ;)
<tepsipakki> I mean, someone told to clean up the diff etc
<slomo> yes i know... i'll talk to dholbach and sistpoty :)
<slomo> dholbach: ping?
<tepsipakki> but I can talk to the debian maintainer and give patches to make it cleaner, and be happy if he accepts them?
<dholbach> slomo: pong?
<slomo> dholbach: see http://revu.tauware.de/details.py?upid=1908
<slomo> dholbach: you said that it would be better to use a patch system instead of having the changes in diff.gz
<slomo> dholbach: but as this package is derived from one in debian i think it's better to make as less changes as possible
<dholbach> ok makes sense
<dholbach> maybe include the diff in   debian/applied-patches
<dholbach> so it's easier to extract and to re-apply, for a new version
<slomo> yes... that's how it was before :)
<dholbach> ok
<dholbach> sounds good
<slomo> ok, tepsipakki so just do it this way and you get my vote... and maybe dholbach's too :)
<tepsipakki> ok, will do :)
<slomo> tepsipakki: ok, ping me when you're ready and it's uploaded :)
<tepsipakki> yeah
<lionelp> slomo: can you have a look on http://revu.tauware.de/details.py?upid=1899
<tepsipakki> a question: I'd like to get libgssapi1 in dapper, but it contains /usr/lib/libgssapi.so.1 and it apparently conflicts with heimdal-dev which has /usr/lib/libgssapi.so. They both should be installable at the same time, says upstream. This conflict is the reason why the library is not yet in debian and upstream does not know how to resolve it..
* monzie says namaste to all
<minghua> tepsipakki: does libgssapi1 ships /usr/lib/libgssapi.so as well (usually a symlink)?
<tepsipakki> minghua: no..
<minghua> tepsipakki: I am pretty sure the /usr/lib/libgssapi.so in heimdal-dev is a symlink to /usr/lib/libgssapi.so.4 in libgssapi4-heimdal
<minghua> (at least in Debian, don't know how to check ubuntu as they say packages.u.c is outdated)
<tepsipakki> hmm, I'll try
<minghua> tepsipakki: then I see no reason why libgssapi1 conflicts with heimdal-dev
<minghua> tepsipakki: Debian apparently doesn't have libgssapi1 in sid
<tepsipakki> yes, heimdal-dev pulls in libgssapi4-heimdal..
<minghua> tepsipakki: while in sarge they have libgssapi1-heimdal which provides /usr/lib/libgssapi.so.1
<minghua> tepsipakki: that's all I can get from the dependencies, I don't know about libgssapi at all though
<tepsipakki> hmm, if I install heimdal-dev, it links libgssapi.so -> libgssapi.so.4.0.0 which is from libgssapi4-heimdal, but libgssapi1 wanted to link /usr/lib/libgssapi.so -> libgssapi.so.1.0.0
<tepsipakki> so there's the conflict
<tepsipakki> they install ok, but I'm not sure that the applications that expect to have a specific libgssapi.so are happy
<minghua> tepsipakki: looking at the practice of Debian maintainer it seems the API is compatible, which means if you compile your program against the heimdal-dev in dapper it should work with the libgssapi.so.4.0.0 provided by libgssapi4-heimdal
<minghua> tepsipakki: you need to ask someone who know libgssapi about this though
<tepsipakki> I'll ask upstream..
<TheMuso> Hey all MOTUs and MOTU hopefuls. :)
<monzie> hi all
<dolson> hey again TheMuso
<dolson> hey monzie
<TheMuso> dolson: SOmething I was meaning to ask you earlier today. Did you ever manage to download the titanicsf soundfont? Whenever I try to get that file recently I got a 404.
<dolson> TheMuso: someone sent it to me over AIM. they have bandwidth issues or something... I asked them if we could get permission to redistribute in Ubuntu because Mark said he wanted sound samples and such included in Ubuntu, but no reply. that was a while back.
<TheMuso> Ah right.
<TheMuso> Is it worth it?
<TheMuso> As in, attempting to get a copy from somewhere?
<dolson> no idea yet.. I don't have enough RAM to load it at this point
<dolson> it is highly recommended by others though
<dolson> did you listen to the three demo files there?
<TheMuso> Actually, I don't think I have.
<TheMuso> Must grab them and listen to them.
<dolson> they sound near movie-quality, to me...
<TheMuso> Right.
<dolson> there are 4 demos actually
<TheMuso> The demo page is a 404.
<dolson> TheMuso: the links in the wiki work: http://www.ubuntustudio.com/wiki/index.php/SoundFonts
<TheMuso> Thanks.
<dolson> the only thing I don't really like are the drums.. but I've heard a couple nice snares. just not enough variety between each sample playback. I imagine this can be fixed with a good software soundfont synth that allows randomization
<atie> minghua, ping
<minghua> hi, atie, just got your mail about 10 mins ago
<minghua> atie: please have a read about my comments in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=335426 first
<Ubugtu> debian bug 335426 in scim-pinyin "should add im-switch support for zh_CN" [Wishlist,Open] 
<minghua> atie: I am all for adding im-switch support in scim-hangul, but I am against your (actually scim-anthy's) approach
<atie> minghua, so scim-anthy is bad example?
<minghua> atie: I need to go sleep soon and can't really think clearly right now :-P  will give you a detailed reply tomorrow
<atie> minghua, ok.
<minghua> atie: not really "bad", but not good enough, in my opinion
<minghua> it's a maintainer's burden thing
<minghua> adding such a patch is probably 10 min's work, but later I probably need 5 hours to keep supporting it
<atie> I wanted to keep all scim packages in same. :)
<minghua> atie: well, my debian packages won't use that approach, which are scim-uim, scim-pinyin, scim-tables
<minghua> for scim-hangul I am just co-maintainer, so it's kind of in the middle
<TheMuso> dolson: That orchestral demo has MIDI written all over it :)
<TheMuso> Dont like either the band mix or the orchestral demo.
<TheMuso> Got the others to try yet.
<atie> minghua, do you remember I sent you and Mr. Yang a mail to check current scim-hangul?
<minghua> atie: yes
* minghua forgot what it's about though
<atie> minghua, go to bed, talk later. I am feeling sorry. :)
<minghua> atie: sure, good night
<atie> minghua, it's too early to me saying "good night". bye.
<minghua> :-)
<dholbach> TheMuso: I packaged dogtail :)
<TheMuso> dholbach: What is that package again?
<dholbach> automated a11y testing
<TheMuso> Thats right.
<TheMuso> I have just replied to Henrik's email on the list to see whether we can get something moving re the speech implementation. I suggested he come onto IRC so we can bug Kamion about it.
<TheMuso> I know it is close to feature freeze, but we need either a yes or no.
<dholbach> yeah
<TheMuso> Ok he has just joined.
<tepsipakki> slomo: ok, new version of gtkpod-aac is now in REVU
<slomo> tepsipakki: url? :)
<tepsipakki> http://revu.tauware.de/details.py?upid=1944
<slomo> tepsipakki: fine with me :)
<tepsipakki> yeehaw! :)
<slomo> when it builds ;)
<tepsipakki> cosmetic..
<slomo> dholbach: do you have some time to review this one too? just do an debdiff to the gtkpod package... the changes are really small
<dholbach> slomo: not at the moment, later
<dholbach> or somebody else can review it
<slomo> dholbach: ok :)
<slomo> tepsipakki: search for another vote :) maybe ask sistpoty again
<tepsipakki> slomo: ok, np
<tepsipakki> how should I handle a package which has it's own debian-hierarchy, and the latest version is not in debian/dapper?
<tepsipakki> I mean, which version should I use
<tepsipakki> upstream has -1, do I use -1ubuntu1 or -0ubuntu1?
<Yagisan> tepsipakki: I suggest -1ubuntu1
<slomo> dito
<slomo> but you can keep the -0ubuntuX version as well
<slomo> your decision... debian will never get this package so you could use a -X version too
<tepsipakki> oh, and I believe that the libgssapi/heimdal-conflict is easy to solve.. since libgssapi build-depends on libkrb5-dev which conflicts with heimdal-dev, so libgssapi1 should Conflicts with libgssapi4-heimdal?
<Yagisan> yes, but if someone adds upstreams repo, the -1 will be higer then the -0ubuntu
<tepsipakki> slomo: yes, I believe they'll release a new version before it hits debian :)
<lfittl> slomo: do you have time to look at http://revu.tauware.de/details.py?upid=1945?
<slomo> lfittl: yay a game :) i'll review it now
<lfittl> :)
<Yagisan> slomo: I'll get you more games - hopefully by dapper +1 ;)
<slomo> lfittl: upstream is insane, yes? ;) "-funroll-loops -fomit-frame-pointer -pipe -O9"
<Yagisan> slomo: the -O9 actually does not work - heh
<slomo> Yagisan: it should work... but it does the same as -O3
<lfittl> slomo: yep, will send him a mail about my changes
<Yagisan> IIRC it was ignored, as it wasn't int the accepted range
<slomo> lfittl: in debian/control... you have 3 times "Section: games" in there... one time for the source package is sufficient :)
<lfittl> oh, did not know that, will re-upload after you have finished reviewing :)
<slomo> lfittl: anagramarama-data should not have shlibs:depends as it's a) arch: all and b) doesn't contain binaries anyway
<slomo> lfittl: just delete the Depends line for -data
<lfittl> copy and paste is sometimes really bad ;)
<lfittl> anything else?
<slomo> lfittl: and add ${misc:Depends} to the other package just to be on the safe side :)
<dolson> I packaged orbital eunuchs sniper, but it crashes and deploys an SDL parachute... segmentation fault
<lfittl> slomo: what would be added by misc:Depends?
<slomo> lfittl: standards-version... 3.6.2 is enough, 3.6.2.X only adds cosmetic changes
<slomo> lfittl: most probably nothing yet... but when you use gconf for example gconf would be added there
<lfittl> k
<slomo> looks sane... what about a .desktop file for it? :)
<lfittl> right, I forgot that one, will re-upload after adding it
<Yagisan> lfittl: please, please include a .desktop file. It is such a pain in the arse to not have one. You could probally copy one out of another game on revu
<lfittl> Yagisan: I hate games without .desktop files too ;)
<slomo> lfittl: the game is fun :)
<lfittl> :)
<Yagisan> lfittl: I have so many installed with a .desktop file, I can't remember which ones to file bugs on!
<Yagisan> s/with/without
<slomo> lfittl: ping me when you uploaded a new version :)
<lfittl> yep
<slomo> hmm... wordlists in other languages would be nice :)
<Yagisan> slomo: what sort of wordlists >:) ?
<slomo> Yagisan: just random words with lenghts from 1 to 7
<slomo> Yagisan: no names
<Yagisan> slomo: I'm sure I have something that fits in my massive passwords collection. What do you need it for
<Yagisan> ?
<slomo> lfittl's game ;)
<slomo> you get 7 letters and have to find all possible words you can build with these letters
<Yagisan> hmm, I'm not sure he needs a 300MB compressed data file
<Yagisan> english letters only ?
<slomo> yes
<slomo> A-Z,a-z
<slomo> well... other national letters would work too i guess
<slomo> but i guess there are names in your password collection
<Yagisan> yes, all sorts, not just english characters either
<Yagisan> you really need just random characters ? that could probally hacked up in a script
<slomo> Yagisan: no... words :P you get 7 random chars in that game and need to find all words you can build with them
<Yagisan> slomo: script it. cycle from a-z then overflow. actually better idea is to have the game do it in code. probally can get some code to do that from john the ripper
<slomo> Yagisan: you don't understand me :) the game has a wordlist with real words from lenght 1 to 7
<Yagisan> ah - so typical of me.
<Yagisan> as usual it has gone over my head
<marcin`> raphink: vtigercrm and vtigercrm-mysql-local are in REVU now please review them if you will have time
<lfittl> dholbach: ping
<dholbach> lfittl: pong
<atie> Can someone here bring a new version of ttf-fonts package from Debian to Dapper directly? I could build them with source files in Debian.
<atie> s/them/it/
<freeflying> atie: hi
<atie> freeflying, hi.
<atie> freeflying, thanks for fixing the xim issue.
<freeflying> atie: it's my horour , hehe
<segfault> i have a slapd module which i got from openldap2.3, and compiled for openldap2.2 and packaged it. how am i supposed to upload to revu, since there's no .orig source?
<dolzzzon> fbond|away: good job
<dolzzzon> fbond|away: ohhh, except the address for the FSF is outdated in the copyright file
<zakame> evening MOTUs!
<dolzzzon> zakame: WAZZZZUPP!!?
<Gloubiboulga> heya zakame
<dolzzzon> argh. ok, I will sleep now, as my left eye hurts a lot :( bbl
<zakame> heya dolzzzon Gloubiboulga :D
<tepsipakki> guys, the libgssapi.so conflict I was talking about earlier is ancient history, doesn't apply to sid/dapper anymore
<tepsipakki> upstream cannot reproduce it anymore
<phanatic> hi people
<zakame> hello phanatic
<Tonio_> Gloubiboulga ping ?
<Tonio_> hi everyone
<Gloubiboulga> Tonio_, pong
<Tonio_> Gloubiboulga, netswitch and knetswitch have a chance to be uploaded
<Gloubiboulga> cool :)
<Tonio_> Gloubiboulga, Riddell tested gnetswitch and got a big error "segmentation fault" while launching it
<Tonio_> works for me.......
<Gloubiboulga> hum...
<Tonio_> can, you eventually test ?
<Gloubiboulga> yes, I do it now
<Tonio_> okay
<Tonio_> take the package on revu
<Tonio_> even there are still problems, upstream have worked hard last week to clean toe package for ubuntu
<Tonio_> it would be a pain not to get them in universe :)
<Tonio_> Gloubiboulga, what is important is to test gnetswitch with the svn version of netswitch that is on revu too
<Tonio_> not version 0.3 of course :)
<Gloubiboulga> of course :)
<Tonio_> Gloubiboulga thanks ;)
<Gloubiboulga> I had an issue too with 0.3
<Gloubiboulga> The default debhelper Cflags were not ok
<freeflying> looking for review http://revu.tauware.de/details.py?upid=1957
<Kyral> Morning
<phanatic> hi Kyral
<tepsipakki> ok, any main-uploaders available for a package-review? I have a new version of libnfsidmap packaged, should I upload it to REVU?
<allee> Hi, there a new rsibreak release that fixes major bug/annoyance. I've uploaded to REVU http://revu.tauware.de/details.py?upid=1930 and added a comment there.
<allee> The release is not a minimal bug fix, as is rsibreak will sooner or later turned of because it gets the timer wrong
<allee> Anyone to ping here for ask for an UVF, or better post to -motu ml?
<jpatrick> allee: https://lists.ubuntu.com/archives/ubuntu-motu/2006-January/000177.html
<raphink> dholbach: if I want to ask for a sync exception request, what shall I attach to the mail?
* jpatrick sees some mails from himself in dapper-changes
<jpatrick> wb allee
<allee> jpatrick: uhm, konversatoin was suddenly frozen :(  didn't like you URL? ;)
<jpatrick> odd
<allee> jpatrick: yeah. First time that this happend.
<raphink> anyone knows what I shall put in my mail for a sync request?
<jpatrick> allee: have you thought of joining the Debian Collaboration Team? https://launchpad.net/people/dct (for what you discussed at #ubuntu-meeting)
<tseng> raphink: Please sync foo, uvf approved by {mdz,kamion}. Thanks.
<raphink> tseng: in english?
<allee> jpatrick: no, did now about it.  I only watch the alioth counterpart ;)  I'll look at it.
<tseng> raphink: what
<raphink> tseng: can you explain to me again, using sentences with subjects and verbs ?
<tseng> "what shall I put in my mail for a sync request"
<raphink> I know how to make a UVF request
<tseng> Please sync package foo from Debian
<raphink> but this is a sync request
<raphink> hmm
<tseng> ...
<raphink> I mean
<raphink> for UVF exceptions request, we have to join a diffstat and the upstream changelog
<raphink> is it the same for a sync request?
<tseng> no
<raphink> that is my question
<tseng> if your sync changes upstream version
<tseng> you should point out to elmo that it was approved by $approver
<tseng> and give him a link to the motu list mail even
<raphink> my question is how do I ask for approval ...
<raphink> what do I have to put in my mail to ubuntu-motu
<tseng> of the uvf change, or the sync?
<tseng> oh jeez
<raphink> instead of the diffstat+changelog
<raphink> sync
<raphink> it's a sync from Debian that I request
<tseng> sync of debian version, not new upstream?
<tseng> please start from the begining
<raphink> oook let's start from the beginning
<raphink> I want to request a sync from Debian of Wesnoth 1.1.1
<raphink> since we have 1.1
<raphink> which doesn't work anymore on the official server
<tseng> so, that is not requesting a sync
<raphink> for gaming
<raphink> huh?
<tseng> which is what you asked an I answered
<tseng> you are requesting a UVF exception
<tseng> if you get it, you can request a sync
<raphink> a UVF exception for a sync
<tseng> sure
<tseng> but a sync request is totally seperate
<tseng> so please dont call it the same thing :)
<raphink> as you wish
<raphink> my point is
<raphink> for a UVF exception, we have to join a diffstat and the upstream changelog
<raphink> is it the same if I request a UVF exception for a sync from Debian?
<tseng> yes, its still a uvf exception
<tseng> just note that the version is alreayd in debian
<raphink> ok
<tseng> and its a clean sync
<tseng> no ubuntu changes
<raphink> so I run the diffstat on the package?
<tseng> on the orig tarballs
<raphink> ah
<raphink> I have yet to see if it's a merge actually
<raphink> dholbach: could you approve my message to the list please?
<dholbach> sure
<raphink> :)
<raphink> thanks
<raphink> it says it's too big a body
<raphink> cause there are lots of attachment, although i've tried to make them as small as possible ;)
<dholbach> 322K? HOLY COW!
<raphink> heh
<jpatrick> must go to india then
<raphink> this is a new version of wesnoth
<raphink> with lots of changes
<dholbach> I feel we have to find a new process for this.
<raphink> dholbach: and I've even run diffstat on it
<raphink> otherwise the debdiff was 50MB lol
<jpatrick> ok that's huge
<raphink> indeed
<raphink> that's as big as the orig
<raphink> which I guess explains why the 1.1.1 official server requires to use wesnoth 1.1.1 and not 1.1
<raphink> dholbach: did you approve it though?
<dholbach> yes i did
<raphink> dholbach: thanks
<raphink> siretart: do you think it would be possible to have a local repo on tiber that can be used to test packages that depend on one another in REVU?
<siretart> raphink: in principle, yes. But I'd rather spend time on revu2
<raphink> siretart: well for REVU2 too of course
<raphink> siretart: if I can work on REVU2, I'd be happy to do it
<raphink> siretart: if there is something that is needed now
<siretart> raphink: well, the svn is open, and I guess you can already commit to it ;)
<raphink> yes
<raphink> but I don't really know what is the plan
<raphink> who is working on what
<raphink> where there is a need for more work
<hub> http://geekz.co.uk/lovesraymond/archive/cancomical-lynchpad
<hub> LOL !
<apachelogger> re
<jpatrick> hello
<jpatrick> Tonio_: you around?
<jpatrick> apachelogger: libqt3-compat-headers (>= 3:3.2.3) and libqt3-mt-dev (>= 3:3.2.3) ?
<apachelogger> jpatrick: later has been removed
<apachelogger> compat is needed for building
<jpatrick> odd, I'm build 1903
<jpatrick> building*
<apachelogger> 1903 still includes mt-dev
<apachelogger> next revision will not ;-)
<jpatrick> well, where is it? ;-)
<apachelogger> shell I really upload for that little depend?
<jpatrick> yep
<apachelogger> ok
<jpatrick> otherwise I can't upload
<apachelogger> the package is _that_ perfect? O.o
<jpatrick> we'll see
<apachelogger> up it is
* jpatrick is off for some tea
<sistpoty> hi folks
<Gloubiboulga> hey sistpoty
<sistpoty> hi Gloubiboulga
<jpatrick> hello sistpoty
<sistpoty> hi jpatrick
<sistpoty> time for another reviewing round... /me looks at gnome-orca
* jpatrick is currently looking at contactmenus
<atie> bye all
<jpatrick> apachelogger: this is going to take forever
<apachelogger> jpatrick: the building?
<jpatrick> yep
<jpatrick> it's still unpacking dep
<apachelogger> hasn't took that long here
<apachelogger> O.o
<apachelogger> lame server :P
<sistpoty> TheMuso: for gnome-orca, it might be prudent to split the binary package to an arch:all (python-stuff) and arch:any (the library) pacakge
<marcin`> raphink: ping
<slomo> sistpoty: would be nice, yes... btw, for gtkpod-aac... your suggestions were all correct for a new package but keep in mind that this package is derived from one we already have and has to be kept in sync with that one... so minimal changes
<slomo> TheMuso: for gnome-orca... copyright is wrong... i find at least "Copyright 2005 Sun Microsystems Inc." und "Copyright 2005 Google Inc." und "Copyright 2001, 2002 BAUM Retec, A.G." but you mention two names in debian/copyright
<sistpoty> slomo: so gtkpod-aac will always be merged from gtkpod-versions? Had the impression that it was a fork here... ;)
<sistpoty> slomo: hehe, you just wrote "und" ;)
<slomo> sistpoty: it's only changed packaging :) one new build-dependency from multiverse... so it should be kept in sync with the default package, yes
<sistpoty> slomo: ah... thx for clarifying
<sistpoty> slomo: did you upload gnome-orca right now?
<slomo> sistpoty: nope... i aborted the upload ;)
<slomo> sistpoty: copyright is wrong
<sistpoty> slomo: ah... just saw your comment... I removed your advocacy ;)
<slomo> sistpoty: thanks :) but i think the splitting would be overkill in this case
<slomo> sistpoty: it's only a 6544 bytes library... it doesn't deserve an own package ;)
<sistpoty> slomo, TheMuso: I could live with the package in the current shape (maybe I should have commented that), splitting would be a nice extra imo :)
<sistpoty> slomo: but the python-stuff will be around 4 instead of only 1 times on the ftp-servers
<hub> what can't I reupload to REVU a package
<sistpoty> hub: .upload file left lying around?
<hub> the version hasn't changed but the package did
<hub> ah right
<jpatrick> dput -f *.changes
<hub> works now
<hub> .upload
<slomo> sistpoty: but it would make our Packages files bigger too... twice as big
<hub> dholbach: that pandora package I fixed it. I did the mistake  :-/
<dholbach> hub: ah ok
<hub> I don't know how it didn't go thru
<hub> I always check the binary package
<sistpoty> slomo: yep... and a *library* package would be total overkill, but imo I still think the split to a -base (or s.th.) package might be good
<apachelogger> jpatrick: still building?
<slomo> sistpoty: it would be cleaner... yes... but the tradeoff doesn't justify it imho :)
<jpatrick> apachelogger: now it's going though ./configure
<apachelogger> oioi :|
<sistpoty> slomo: hehe... well I'm still learning some lessons... last lesson was "misc:depends" is good ;)
<slomo> sistpoty, TheMuso: i'll change the copyright for gnome-orca and upload it then
<sistpoty> slomo: go ahead ;)
<dholbach> hub: still no love on amd64
<hub> mmm
* sistpoty looks at omins
<dholbach> let me doublecheck
<hub> there was a problem on i386
<dholbach> maybe i did something wrong
<dholbach> it's building and i'll be off cooking for some time
<hub> the uid changed :-0
<hub> http://revu.tauware.de/details.py?upid=1966
<dholbach> hub: better
<lucas> is it me, or a spam went through on ubuntu-announce@ ?
<stratus> lucas: check the headers
<dholbach> lucas: yes, it was a mistake
<lucas> stratus: I did
<lucas> stratus: but I can easily send you an email with the good List-Id header :-)
<sistpoty> dolzzzon: you'll need to update debian/copyright for omins, since there are files that contain copyright info (authors) not listed copyright
<slomo> hub: copyright is wrong in pandora
<stratus> lucas: sure, but spammers don't give a fuck about them, so if they look coming from ubuntu.com smtp, wee..
<slomo> hub: "Copyright (C) 1995 Spencer Kimball and Peter Mattis" is missing
<hub> ah well, yeah
<slomo> hub: shall i fix it? and "Software is licensed under GPL version 2 (see COPYING file)." can be left out imho
<slomo> hub: it's only confusing
<hub> slomo: I'll do it
<slomo> hub: ok, ping me when you uploaded a new version :)
<stratus> is it just me that sometimes look at slomo nick and read elmo ?
<hub> stratus: just you
<stratus> damn, i need to upgrade something in my eyes
<hub> stratus: yeah, new firmware"
<slomo> stratus: lol... no i'm not elmo ;P why? because i'm so picky about copyright?
<stratus> hub: the same thing with you switch, err i mean hub. :-)
<stratus> slomo: heh i really know that you're not elmo. There's just something funny about slomo and elmo that my eyes mess up sometimes.
<slomo> hub: pandora is fine except copyright... good work :)
<stratus> hub: yes, i need a new firmare that fix keratoconus. :-|
<hub> slomo: http://revu.tauware.de/details.py?upid=1967
<slomo> hub: ok, fine with me :)
<jpatrick> apachelogger: done
<apachelogger> hoooray :)
<slomo> hub: uploaded
<hub> slomo: thanks.
<hub> slomo: I could have too :-)
<slomo> oh, yes... sorry :)
<hub> np
<stratus> dholbach: news about UVFStatus processing?
<dholbach> stratus: matt asked me to change the process, we're still discussing, I'll give an update, once we're done
<stratus> dholbach: oh, ok let me know. :-)
* sistpoty looks at speechd-up
<dholbach> sistpoty: go, make the a11y happy! :)
<sistpoty> hehe
<pef> hello
<slomo> does someone know where one could subscribe to the motu-reviewers mailing list? :)
<fbond|away> http://tauware.de/cgi-bin/mailman/listinfo/motu-reviewers
* fbond|away didn't see that, because he is away...
<slomo> thanks :)
<fbond|away> np
<sistpoty> TheMuso: please look at speechd-up comments
<fbond|away> sistpoty: linuxsampler?
<fbond|away> qsampler has been ok'ed, and is useless without linuxsampler...
<sistpoty> fbond|away: will take a look
<lfittl> sistpoty: ping
<fbond|away> thanks!
<sistpoty> lfittl: pong
<lfittl> dholbach: ping
<slomo> wb lfittl :)
<lfittl> hi slomo :)
<slomo> lfittl: anagramarama built fine everywhere... good work :)
<fbond|away> sispoty: actually, can you hold up 5 minutes on linuxsampler?
<lfittl> slomo: saw that, I really like the launchpad way to manage builds :)
<Gloubiboulga> Riddell, ping
<slomo> fbond|away: a question for linuxsampler...
<fbond|away> sistpoty: had to make a quck change
<fbond|away> slomo: yes?
<slomo> fbond|away: why do you install the libs to /usr/lib/linuxsampler
<fbond|away> oy, you had to ask
<fbond|away> i didn't make that decision, that is the default for the package
<slomo> fbond|away: put them in /usr/lib... make an liblinuxsampler0 and liblinuxsampler-dev package
<fbond|away> should i change it?
<slomo> imho yes
<Riddell> Gloubiboulga: hi
<Gloubiboulga> hi Riddell
<Gloubiboulga> Riddell, I've tested gnetswitch, it segfaults in a chroot, but not on my dapper box
<Riddell> spooky
<Gloubiboulga> did you test it in a chroot too ?
<Riddell> no
<Gloubiboulga> Riddell, I've changed some little things, could you test my package ?
<Gloubiboulga> I can upload it to REVU
<sistpoty> fbond: yes, please change that and also remove the postrm, postinst (dh_makeshlibdeps will care for that)
<Riddell> Gloubiboulga: yes, but not just now
<Gloubiboulga> ok, I'll upload it, test it when you want Riddell :)
<sistpoty> fbond: wait a minute plz, I want to take a look at what exactly is in the linuxsampler package
<jpatrick> can someone advocate http://revu.tauware.de/details.py?upid=1964 so I can upload?
<sistpoty> jpatrick: /me looks
<jpatrick> sistpoty: pbuilds and all and lintian's happy with it
<sistpoty> jpatrick: ok, will take just a few minutes
<jpatrick> all problems are on apachelogger
<sistpoty> apachelogger: please just bunzip2 and gzip -9 tar.bz2 you downloaded, but don't repackage it
<marcin`> sistpoty: hello
<sistpoty> hi marcin`:
<marcin`> sistpoty: could you tell me how can I remove some package from REVU?
<sistpoty> marcin`: you can't... only revu-admins can do that
<sistpoty> marcin`: you can tell me, I'll remove them
<jpatrick> I think thats planned for revu2
<marcin`> sistpoty: are you one of them?
<sistpoty> marcin`: yes
<marcin`> sistpoty: ok then please remove vtiger-crm and vtiger-crm-mysql-local
<marcin`> sistpoty: we changes naming convention and now package name is vtigercrm
<marcin`> sistpoty: you can also remove vtigercrm-mysql-local
<sistpoty> marcin`: will take a few clicks ;)
<marcin`> sistpoty: because now vtigercrm-mysql-local will be integrated in vtigercrm source
<sistpoty> ok
<marcin`> so keep only vtigercrm
<marcin`> thanks and sorry about this mess ;)
<sistpoty> no problem
<sistpoty> fbond: for linuxsampler - it's a little bit tricky if you want to build a library and a binary from the same sourcepackage
<sistpoty> fbond: are the shared-objects used/usefule for anything but linuxsampler binary?
<apachelogger> sistpoty: what's changed in my orig?
<sistpoty> fbond: if not, I would suggest you remove them and the static library and do static linking
<sistpoty> apachelogger: mom
<jpatrick> :/
<sistpoty> apachelogger: if I gunzip your orig.tar.gz and bunzip2 what I can download, the tar's should be bit-identical (unless there is a really, really good reason to change the upstream tar)
<sistpoty> apachelogger: and unless I downloaded the wrong file, the md5sums of the tar's don
<fbond> sistpoty: I don't believe the libraries are useful for anything else, but I could be wrong
<sistpoty> +'t match
<fbond> and I guess you never really know
<apachelogger> sistpoty: I'll check
<fbond> is it a good idea to deviate so drastically from a package's standard install?
<fbond> I don't know if doing static linking is the best way to go...
<sistpoty> fbond: still another possibility is to make linuxsampler load the shared objects from /usr/lib/linuxsampler, but then you can't change ld.so in postrm/postinst
<sistpoty> fbond: but I wouldn't really know how to do that right for myself ;)
<fbond> why not just put libs in /usr/lib, and pretend they may be useful for other binaries, even if they actually aren't?
<sistpoty> fbond: if you put them into /usr/lib, you'll need build a complete library-package (with -dev package)
<fbond> hmpf, -dev is not currently installed by 'make install'
<fbond> (no headers are installed)
<apachelogger> sistpoty: that's really odd, as there is actually no diff according to diff ;-)
<apachelogger> anyway I'll re gzip the orig
<sistpoty> apachelogger: than it should be the same, right?... if that's the only problem, you don't need to reupload, I can exchange the orig then for uploading... (but I'm not completely done with reviewing)
<fbond> sistpoty: so going the static-link route, all I need to do is CFLAGS += "-static"; CXXFLAGS += "-static" ?
<sistpoty> fbond: and it's a little bit tricky, since you build a binary package and a library package from the same sourcepackage (see the debian library packaging guide for hints about how to do it)
<apachelogger> sistpoty: ok, I'll check md5 for future packages :-)
<sistpoty> fbond: just try it out... maybe there is some configure-flag there as well, like --disable-shared?
<fbond> hmm...
<sistpoty> apachelogger: :)
<sistpoty> apachelogger: is /usr/share/apps/kicker/menuext the right place for the desktop file? (ha, i use kde... but my knowledge is rather limited on it *g*)
<apachelogger> yup
<apachelogger> menuext is for menu buttons
<apachelogger> like the system or remote button
<apachelogger> contactsmenu is such a button ;-)
<sistpoty> apachelogger: ok, then I'll retry building with exchanged tarball and upload if it's still working ;)
<apachelogger> hooray :-D
<sistpoty> apachelogger: args... your debian/copyright is wrong... you'll need to change this
<sistpoty> apachelogger: there is at least one file with a different license: contactsmenu/librss/article.h
<jpatrick> just one....
<sistpoty> apachelogger: and the COPYING file is LGPL while the sourcecode says it is GPL, please check all source-code files what license applies
<sistpoty> jpatrick: doesn't matter if it's one or a dozen... if debian/copyright doesn't match the license of the files, it usually results in a reject from the new-queue
<jpatrick> I know
<apacheLAGger> well
<apacheLAGger> unghost ;-)
<apachelogger> better
<sistpoty> apachelogger: did you read the issues? or were already off?
<jpatrick> I think he did
<apachelogger> the license?
<sistpoty> apachelogger: yep
<apachelogger> I checked that
<apachelogger> it's lgpl
<apachelogger> though
<apachelogger> the packages includes librss from akregator
<apachelogger> and that's gpl2 and later
<apachelogger> dunno which one I should use
<sistpoty> apachelogger: both ;)
<apachelogger> ah :-D
<apachelogger> sistpoty: reupload?
<sistpoty> apachelogger: either explicitely state which files fall under which license (or if it's all files in one dir with a different license, you can also list this)
<sistpoty> apachelogger: please do
<apachelogger> k
<sistpoty> apachelogger: actually it appears to be even 3 licenses: LGPL (for most files), GPL for librss and BSD-like for parts of librss by Frerich Raabe
* apachelogger wonders why people think we have too much oss licenses
<sistpoty> hehe
<apachelogger> sistpoty: shell I call it lesser?
<apachelogger> library is kinda outdated, isn't it?
<sistpoty> apachelogger: call it the way it's referred to in the sourcecode... that's never wrong
<apachelogger> ok
<sistpoty> jpatrick: just in case you review contactsmenu again, if the two points I mentioned are fixed (and there is no dramatic change in the debdiff) feel free to take this as advocacy from me
<jpatrick> sistpoty: okay
<jpatrick> apachelogger: fix it
<sistpoty> jpatrick: (you can always do this if I write s.th. like "fix these things and you have my vote")
<apachelogger> anyone knows a copyright file I can use as example for the super-multi-licensing?
<jpatrick> apachelogger: I'll get one
<sistpoty> apachelogger: quake3 on revu does it pretty good...
<apachelogger> ok, thx
* sistpoty is out for a cigarette now
<fbond> sistpoty: hope you enjoyed your smoke.  i have just uploaded reworked linuxsampler.
<fbond> the new source package generates one binary package that installs a statically linked binary
<fbond> seems to work well...i stripped some garbage out of upstream's debian dir
<fbond> gave me "ignoring deletion of XXX" messages when running debuild -sa -S
<fbond> i think i want those changes to stay in diff.gz, though...thoughts?
<sistpoty> fbond: you'll need to make sure files you deleted are gone during build time as well (so you'll need to delete them in the clean-rule)
<sistpoty> fbond: the best way to handle this, is to talk to upstream and ask if they can make a release w.o. a debian-directory
<dolson> fbond: I have the same issue with qsampler
<fbond> yeah, it's not as helpful as it might seem :)
<sistpoty> fbond: you could also repack the orig-tarball for one release, but I don't like this as a permanent solution
<fbond> ok
<fbond> can i repack and then chat with upstream?
<sistpoty> fbond: yes... you needed to repack linuxsampler anyway didn't you?
<fbond> yeah, i already did ... i will do it again
<fbond> stay posted
<sistpoty> fbond: then please delete the complete debian-dir for repacking, makes the diff.gz more readable ;)
<fbond> sistpoty: done, uploading momentarily
<sistpoty> fbond: ok, will take a look once it's there
<fbond> please note that I also had to remove references to debian dir from e.g. Makefile.in
<dolson> what are the chances any packages in REVU that rely on dssi being sync'd will be successfully reviewed and uploaded in time?
<sistpoty> dolson: no idea really... maybe we could ask for exceptions
<sistpoty> dolson: I locally built dssi last night, so I can do reviewing, but I can't upload yet, because of the dependency
* apacheLAGger checks if the readme got it's own license
<apacheLAGger> wooh
<apacheLAGger> unghost
<dolson> ah
<dolson> sistpoty: you need an exception to upload, even if they are marked as ready for upload prior to FF. correct?
<apachelogger> sistpoty, jpatrick: http://paste.ubuntu-nl.org/9134 usable?
<jpatrick> apachelogger: you scared him away
<sistpoty> bah... always these disconnects *G*
* apachelogger scared him self way
<jpatrick> ah! wb sistpoty
<sistpoty> re ;)
<apachelogger> wb I say
<jpatrick> apachelogger: looks good
* jpatrick is now at kubuntu meeting
<apachelogger> that has to be sarcastic
<apachelogger> oh
<apachelogger> again meeting?
<fbond> sistpoty: new linuxsampler just uploaded, may take a min to appear
<sistpoty> fbond: k
<jpatrick> sistpoty: did you get apachelogger's copyright thing?
<sistpoty> jpatrick: no
<apachelogger> http://paste.ubuntu-nl.org/9134
* apachelogger thanks klipper
* dolson tries for the 3rd time to purchase Hacks DVD
<sistpoty> apachelogger: nice
<apachelogger> woot
<apachelogger> I'll upload
<sistpoty> anybody else having problems with the revu page?
<sistpoty> oh, works again :)
<fbond> sistpoty: why is dssi not currently sync-able?
<sistpoty> fbond: because nothing is syncable atm
<dolson> hmm, my omins pkg was based on someone else's work, so that's why it's fuxxored
<sistpoty> fbond: there seem to be problems with soyuz (our new build-system) and syncs...
<sistpoty> fbond: but the last comments I got look promising... maybe we have syncing back online in a few days
* apachelogger sings lift me up ;-)
<fbond> sistpoty: the timing is less than convenient, no?
<Se7h> hi
<sistpoty> fbond: the only appropriate timing would have been right after a release... when everybody is on holidays ;)
<sistpoty> hi Se7h
<fbond> sistpoty: :)
<fbond> okay, time to get back to what i'm paid to do
<sistpoty> Gloubi_Aw: I'm not entirely happy with new netswitch world order... did you get any comments from other motu's about package layout yet?
<fbond> sistpoty, i'll check back in on linuxsampler in a bit
<sistpoty> fbond|away: ok, I'll be looking at it now
<apachelogger> sistpoty: http://revu.tauware.de/details.py?upid=1974
<sistpoty> apachelogger: queued ;)
<apachelogger> aye, thx :-)
<jpatrick> should I upload?
<sistpoty> jpatrick: if you're happy with it, go ahead
<jpatrick> :)
<jpatrick> apachelogger: one second
* apachelogger trys a backport of compiz to breezy
<jpatrick> apachelogger: done: https://launchpad.net/people/apachelogger/+packages
<apachelogger> arrr :D
<apachelogger> jpatrick: thanks a lot
<jpatrick> no problem
<sistpoty> Tonio_: I just glimpsed over new netswitch... I'm not entirely happy with everything being in one package
<jpatrick> sistpoty: I don't think Tonio_'s actually..... here
<sistpoty> ah, k
<marcin`> raphink: ping
<jpatrick> marcin`: he's in a meeting
<marcin`> jpatrick: ok
<sistpoty> marcin`: vtigercrm-mysql-local should stay on revu or go as well?
<marcin`> sistpoty: remove this one too
<marcin`> sistpoty: there will be package vtigercrm-mysql-local but only 'binary'
<marcin`> sistpoty: this package will be created from vrigercrm source
<sistpoty> marcin`: ok, just a sec and it's gone as well
<marcin`> I'll upload new vtigercrm soon and I hope it will go to dapper..
<sistpoty> ok... only vtigercrm left :)
<marcin`> thanks
<marcin`> btw got a question - how to resolve this problem...
<marcin`> vtigercrm is collaborative work
<TheMuso> sistpoty: Thanks... I will have a look.
<TheMuso> slomo: thanks.
<marcin`> and there is a guy that wants to maintain this package in debian
<marcin`> and vtiger is also ubuntu bounty
<marcin`> and we did this package together - let's say it's 50% his job and 50% mine
<marcin`> then problem is that Maintainer field in control can contain only 1 name
<marcin`> and I would like to maintain this package in ubuntu and he wants to in debian...
<marcin`> how to resolve this problem and what should I put into control/copyright and changelogs?
<fbond|away> sistpoty: saw your comments, uploaded new linuxsampler package with very slight changes
<sistpoty> marcin`: you did the package together, so why not collaborate in the future?
<sistpoty> marcin`: are there changes that need to be done for the ubuntu-version only?
<sistpoty> fbond|away: ok
<sistpoty> fbond|away: the debdiff is ok, so unless it suddenly FTBFS you still have my vote ;)
<marcin`> sistpoty: I don't think so
<marcin`> sistpoty: it's webapp so there is nothing 'distrospecific'
<sistpoty> marcin`: then I guess it might be a good idea to work together on *one* package instead of having two ppl. caring for two distinct packages
<marcin`> sure - we work together
<marcin`> question is who should be mentioned in Maintainer field
<sistpoty> marcin`: you could then use e.g. alioth and set the maintainer to vtigercrm-devs (mailing list)
<sistpoty> marcin`: and changelog entries: whoever does a specific change should be listed there
<marcin`> sistpoty: pretty nice idea
<sistpoty> marcin`: imo there is also the possibility of a co-maintainer field, can't find a reference for it now though
<sistpoty> marcin`: at leasts that's the way it's done for collaborative maintenance projects in debian (using list as maintainer-field=
<sistpoty> ususally ;)
<marcin`> ok and what about this: different maintainer or ubuntu and different for debian?
<marcin`> is this possible?
<sistpoty> marcin`: it is... but that would imply to care for two different sourcepackages
<sistpoty> marcin`: so I wouldn't recommend it
<dholbach> sistpoty: fancy another look at linuxsampler?
<sistpoty> dholbach: just at it... and I think it compiled well
<dholbach> *highfive sistpoty*
<sistpoty> dholbach, fbond|away: no, still going... the automake issue isn't solved, but since it didn't FTBFS last time with the issue, I'm fine with it (but I just like to see the package being built though)
* sistpoty hugs dholbach
* sistpoty needs a faster box *g*
<fbond|away> sistpoty: yes, I did 'touch configure' in my package dir, rather than in my faked tarball
<fbond|away> i just realized it, and a new upload is on its way
<fbond|away> i am a bit of a perfectionist
<sistpoty> fbond|away: hehe... ok, if you want to be perfectionistic, I'll try another build with that upload. If it builds, I'm more than happy with it
<fbond|away> alrighty
<dolson> MOTUs++
<sistpoty> as in we need more motus for reviewing? *g+
<dolson> lol
<dolson> no, you guys are kicking royal rump
<sistpoty> thx
<dolson> I'm trying to fix omins now
<dolson> I really do need sleep soon though :\ 4pm here
<sistpoty> dholbach: did you just review an old version of linuxsampler or just made your comment to the wrong version? *g*
<dholbach> erm
<dholbach> there were so many versions now :)
<sistpoty> hehe
* dholbach is a good boy and reloads
<sistpoty> dholbach: if it builds (and I'm 99.9% sure it does) my vote still counts ;)
<dholbach> ok i test-build again and see
<dholbach> gphotofs has two silly changes waiting, i'd nearly do them myself and get it up :)
<dholbach> gopersist looks good too
<dholbach> (to poke hub's packages a bit)
<dholbach> (let's see if etl builds this time)
<TheMuso> dholbach: Has speech-dispatcher 0.6 gone through yet?
<TheMuso> If so, I have the grounds to upgrad speechd-up as well.
<dholbach> TheMuso: should have
<TheMuso> Righto.
<dholbach> TheMuso: i uploaded it some hours ago
<TheMuso> right
<TheMuso> btw what is the variable used in the control file to represent the source package version?
<sistpoty> TheMuso: version in changelog entry
<Gloubiboulga> sistpoty, have you tested gnetswitch ?
<TheMuso> sistpoty: Yes.
<Gloubiboulga> btw Tonio_ has made the *netswitch packages :)
<sistpoty> Gloubiboulga: no, I just built it and looked at the results
<sistpoty> Gloubiboulga: yes, found that out later ;)
<sistpoty> TheMuso: that's the field ;)
<Gloubiboulga> sistpoty, could you test it ?
<Gloubiboulga> gnetswitch segfault on Riddell's box, but not on mine
<sistpoty> Gloubiboulga: I'd like to review some more packages right now if you don't mind
<Gloubiboulga> sistpoty, np
<TheMuso> sistpoty: Ok let me explain. I want to take the package version and use it in the debian/control file as a version for a dependancy. What s the variable that I use?
<marcin`> well guys.. ArmeBosse and me are working on vtigercrm package
<marcin`> and we still don't know for 100% what to do with 'maintainer issue'
<sistpoty> TheMuso: ah, got it now... it's ${Source-Version}
<stratus> marcin`: why?
<TheMuso> Thanks.
<stratus> marcin`: you're free to use "foo maintainers <groupemail@...>" and list the two in uploaders field.
<marcin`> hmmm but what if we would like to have different maintainers for debian and ubuntu?
<TheMuso> sistpoty: BTW, I originally didn't upgrade speechd-up because it was incompatible with one of it's dependancies, but now that has been updated, we are all clear.
<sistpoty> dholbach: what's wrong with the maintainer field/config.log in gphotofs?
<stratus> marcin`: is there anyone working on the same package for debian?
<ArmeBosse> hoyes me
<ArmeBosse> -ho
<stratus> ArmeBosse: i would like to suggest you request a project in alioth, you can include marcin`in the project there.
<dholbach> sistpoty: .et -> .net
<stratus> ArmeBosse: you can use the same approach as pkg-zope group
<dholbach> sistpoty: config.log is a generated file, but a very minor nuisance
<sistpoty> TheMuso: the version is alright for me... if you have the time you can go for a newer version, but that's just an additional bonus
<dholbach> sistpoty: talked to hub about it
<stratus> apt-cache show zope3, do you see the maintainer field?
* marcin` wonders what it alioth ;>
<hub> config.log is in the upstream tarball
<stratus> marcin`: alioth.debian.org, it's gforge' debian installation
<sistpoty> dholbach: lol, I looked half a minute at it and didn't see that it's written wrong ;)
<hub> I remove ti in clean
<sistpoty> hub: and you might want to set the section to s.th. else than unknown ;)
<stratus> marcin`: you're free to not use alioth, but you should cooperate in the maintainership thing as pkg-zope (they're using alioth) guys are doing.
<hub> sistpoty: yep, was doing that oo
<stratus> marcin`: apt-cache show zope3
<marcin`> stratus: well but what if I don't want to be debian maintainer ;) ?
<ArmeBosse> stratus: i'm ok for this, and know the procedure
<ArmeBosse> stratus: the problem is that marcin don't want to be involved in debian
<marcin`> stratus: another funny part is that why to hell there is 'This package was debianized... ' in copyright file in ubuntu package :) ?
<stratus> marcin`: you don't need to be a debian maintainer to be listed in a project there (alioth) and you don't need to be a debian maintainer to share the "debian/ubuntu ..." thing in the maintainer field, really!
<stratus> marcin`: deb is the package format too, see man 5 deb
<marcin`> ok forget it.. but it's pretty weird that ubuntu looks like subdebian distro...
<ArmeBosse> stratus: another problem is claiming debian/ubuntu package :) as you can see marcin is only interested by ubuntu part
<marcin`> not like something independent
<stratus> ArmeBosse: He won't be involved directly, it's just a cooperative issue, he's not forced to be a debian maintainer, as you know. If he has a problem with the Debian name he should move away from FLOSS, because he can't stop anybody merge his packages back to any deb based distribution.
<stratus> ArmeBosse: there are some pkg-zope members that are only interested in Ubuntu part, i still fail to see the point.
<sistpoty> hub: did you repack the orig-tarball?
<dholbach> sistpoty: linuxsampler ready to go, sir!
<marcin`> stratus: I don't have any problem with Debian - the thing is that I don't use Debian and I don't want to
<dholbach> sistpoty: it was in the upstream tarball :)
<sistpoty> dholbach: what was in the upstream tarball?
<dholbach> config.log
<marcin`> stratus: and this particular package is not something that will be different in debian and ubuntu
<stratus> marcin`: great, you won't be involved with Debian just sharing the maintainer field with "them"
<dholbach> if you refer to that
<sistpoty> dholbach: will you upload linuxsampler, or shall i
<dholbach> sistpoty: i don't mind either way
<sistpoty> dholbach: but that's no reason to modify the orig-tarball
<sistpoty> dholbach: ok, I'll go for it
<dholbach> sistpoty: i upload, you comment and archive
<sistpoty> dholbach: fine for me as well ;)
<dholbach> ROCK :)
<dholbach> hub: you got etl building! NICE!
<marcin`> stratus: but I would like to make few new packages and then for example I don't want to get 'debianspecific' question etc.
<tepsipakki> hi, I sent an email on u-d and asked if someone could review some packages (libgssapi, librpcsecgss, libnfsidmap). they should be an easy task, because upstream has already made packages of them, so the changes are minimal...
<marcin`> stratus: I think that currently we will leave debian maintainer credentials but I just wonder how these debian/ubuntu relations work
<stratus> marcin`: you'll get questions and bug reports through ubuntu malone.
<stratus> marcin`: you can setup a list to discuss general deb (debian, ubuntu, ...) specifics stuff about that package and point "debian/ubuntu foo maintainers <put the list mail here>", if you want
<hub> dholbach: I have the rest waiting
<stratus> marcin`: so it will be safe to you treat that list as low priority, because the bug reports will go through malone.
<hub> dholbach: like synfig
<hub> dholbach: but I held on it I don't remember why
<TheMuso> When one links config.guess/config.sub, where does one link them from?
<dholbach> hub: i tried it too
<stratus> marcin`: i'm sure that a user here and there will send bug reports to the list, but the list itself will ask the guys to use malone or debian BTS when necessary. Do you see?
<hub> sistpoty: no I didn't tocuh the orig tarball
<hub> dholbach: and it didn't work?
<dholbach> hub: no, world breakage
<dholbach> hub: but that was a while ago
<hub> uh oh
<sistpoty> hub: hm... where did you get it from? (found only .tar.bz2 on on page)
<marcin`> stratus: ok but what if we have ArmeBosse as debian maintainer and his package
<stratus> marcin`: if you're in doubt just take a look how the pkg-zope and some other teams are doing it, i think ArmeBosse can guide you through these part of Debian internals, but alioth.debian.org is a good start point
<hub> sistpoty: ah maybe I did bunzip -c | gzip -9c
<marcin`> stratus: and then I would like to create some improvements or changes that ArmeBosse will not want to implement in debian package?
<hub> sistpoty: but not more than that
<sistpoty> hub: the md5sums of the bz2 didn't match (and the size didn't as well)... maybe I dl'd the wrong thing again ;)
<hub> sistpoty: :-/
<ArmeBosse> marcin`: you keep it in your branch/patch of the debian package
<stratus> marcin`: if the package will be the same (no ubuntuX revisions), it's sane let the MoM do its work automatically and get rid of differences, even in the maintainer field, IMHO. It's how i handled gdebi package with mvo, until UVF.
* Kyral wonders if it would be a good idea to ask Jeff to add his blog to Planet.Ubuntu.com
<marcin`> stratus: too many abbreviations :)
<stratus> marcin`: heh you described exactly what's going on with gdebi right now.
<stratus> marcin`: they're all in wiki.ubuntu.com, i think.
<marcin`> ArmeBosse: btw my questions are not vtigercrm related now.. I'm just curious
<Gloubiboulga> sistpoty, when you got time, could you tell me what's the problem with the *switch packages ?
<sistpoty> Gloubiboulga: give me 5 mins, ok?
<Gloubiboulga> sistpoty, ok
<stratus> marcin`: once you decide to diverge from debian package you can keep that stuff in a different branch than ArmeBosse, as he said.
<stratus> marcin`: I'm using bazaar-ng to keep the gdebi' debian tree and mvo has the main repository that is the same for Ubuntu.
<ArmeBosse> marcin`: you can look pkg-kde and Riddell related work on alioth
<sistpoty> hub: isn't the universe-part of the section usually set by the ftpmaster? (actually I only heard rumors about it, though I'm really curious)
<stratus> marcin`: We used to have the same trees almost in sync, but once Ubuntu started the Upstream Version Freeze (UVF), he started to add some changes to his repository that i don't need yet.
<stratus> marcin`: before the UVF, we uploaded gdebi for Debian and waited Ubuntu sync that automagically. :-)
<hub> sistpoty: I took the one from fuse-utils
<marcin`> stratus: ok and then what do you have in Maintainer field?
<hub> sistpoty: but if that is wrong, well.
<hub> sistpoty: is there any documentation about that?
<stratus> marcin`: i think actually we've my name in the maintainer field and mvo in uploaders field, since we don't need that mailing list for discussion. :-)
<sistpoty> hub: I guess it's wrong... imo that's part of that override-file-thingy, but actually I don't have a real clue about it ;)
<marcin`> ok
<hub> sistpoty: okay
<sistpoty> hub: and no idea where to find documentation
<stratus> marcin`: i never received a bug report related with ubuntu in my own email or through debian bts
<hub> what do you think is best I put on this one?
<marcin`> stratus: ok thanks.. now we need to finish this package and put it in dapper :)
<stratus> marcin`: np, good luck.
<hub> sistpoty: I'll just put utils
<sistpoty> hub: yes... I'll just take a look at the result... you won't need to upload again only for that change (imo)
<sistpoty> hub: we could ask elmo (I saw him chatting in LP), but I guess he'll kill us cause he's busy with getting syncs back online ;)
<hub> sistpoty: I just put "utils"
<sistpoty> ok
<hub> sistpoty: if it is OK I cna upload to the archive
<sistpoty> hub: looks good... just a smal moment and I'm through it
<hub> ok
<sistpoty> hub: +1 from me
<siretart> n'evening
<siretart> hi sistpoty!
<sistpoty> hi siretart
<siretart> sistpoty: how are you? long time no see :)
<hub> dholbach: so shall I upload gphotofs?
* dolson realizes sistpoty != siretart
<hub> allo siretart
<siretart> huhu hub!
<dholbach> hub: you got two votes? then go for it
<dholbach> hub: nice one
<dholbach> hey siretart
<siretart> dolson: we are at the same university. our nicknames are our loginnames at uni
<sistpoty> siretart: fine, what about you?
<siretart> huhu dholbach
<siretart> sistpoty: lerning stress, getting into the hot phase. but in general, fine :)
<hub> dholbach: i would be #2 :-)
<sistpoty> siretart: oh, good luck then!
<hub> dholbach: sistopy gave his
<dolson> siretart: ah. I just have a hard time with things... see, I never learned to read
<hub> sistpoty I meant
<dholbach> i gave mine too
<hub> ah ok
<hub> done
<sistpoty> hub: btw.: there seems to be s.th. strange with libfuse... there is no versioned dependency on it in the gphotofs-binary-db
<sistpoty> s/db/deb/
<hub> sistpoty: oh
<sistpoty> hub: but it's from shlibs:depends, so gphotofs is not at fault
<hub> sistpoty: a bug shall be filed
<hub> :-)
<sistpoty> hub: I'm not sure if it's a bug even... it's just strange ;)
<hub> yeah
<cyberserver> Hi people. Anyone is facing strange behaviour from mysql+apache with dapper? It seems mysql places the shared pipe inside a directory which apache cannot read....
<cyberserver> .. the result is that apache+php+mysql apps cannot bind to dabatase
<Gloubiboulga> cyberserver, it's a known bug iirc
<sistpoty> cyberserver: known bug, will be resolved soon
<cyberserver> Oh, ok. I have come around it chmodding /var/whatever..   ok, thx, no need to fill a bug report then :-)
<TheMuso> slomo: Around?
<slomo> TheMuso: yes
<TheMuso> Is it possible for me to accesss the changed copyright file for the uploaded orca pacage?
<TheMuso> btw sistpoty I have split the package into two, what should I do with it if orca is already waiting for upload?
<sistpoty> cyberserver: 755 are the intendended rights, if you want to fix it locally ;)
<cyberserver> sistpoty: ok, but the fix is not persistent... I need to reapply after a reboot...
<slomo> TheMuso: nope... i deleted it already :/ wait for it to leave NEW
<sistpoty> cyberserver: then just wait for updated packages ;)
<sistpoty> TheMuso: I'd suggest waiting till it hit the archives... it's easier to update it then
<cyberserver> sistpoty: maybe I should turn that "lock" bit on? I dont remember exactly how, but I know there is a way... "immutable bit" is the name, IIRC .....
<sistpoty> cyberserver: never heard of that one
<TheMuso> Ok.
<Kyral> the Sticky bit?
<cyberserver> chattr +i , IIRC
<sistpoty> Gloubiboulga: for the netswitch package
<sistpoty> Gloubiboulga: it's all going into one big package
<cyberserver> Kyral: no... IIRC, the sticky bit is one thing, the immutable bit is another thing
<sistpoty> Gloubiboulga: I don't really see, where the shell-script makes use of the shared objects
<cyberserver> http://linuxhelp.blogspot.com/2005/11/make-your-files-immutable-which-even.html
<Kyral> Ah I remember reading about chatter in my copy of Linux in a Nutshell
<Gloubiboulga> sistpoty, yep, that's why my package was split
<TheMuso> Ok guys, new speechd-up is uploaded.
<sistpoty> Gloubiboulga: and since there is stuff installed into /usr/lib, the package needs to conform to library packages (package matching soname, distinct -dev and lib package)
<sistpoty> Gloubiboulga: yes, and imo the way you did it, is the way to go
<Gloubiboulga> Tonio_ has certainly a good reason for it
<cyberserver> Anyway we can propose the change of adept's behaviour so it does not stands in the traybar stating "there is 1 updated package available" when that package is in state "will be kept" ?
<sistpoty> Gloubiboulga: but imo it's plain wrong to put shared objects into /usr/lib (or /lib) and not to follow the library packaging policy...
<cyberserver> That notifiers irritates... cause one will click on it to do the update ... and then adept will say "nothing to do"
<TheMuso> /c/
<sistpoty> cyberserver: please file a wishlist bug about that
<cyberserver> .. and keeps in the traybar stating there is 1 package to upgrade
<cyberserver> sistpoty: ok
<cyberserver> Well guys, I'm rebooting into the new kernel....
<cyberserver> ... be back in a sec... or a minute...
<TheMuso> time for some breakfast... finally. :)
<sistpoty> time for a cigarette *g*
<tepsipakki> is there now someone available for reviews? =)
<tepsipakki> utter silence.. :/
<Pygi> hehe :)
<cyberserver> :-( chattr is not working with directories :-(
<phanatic> hi people
<cyberserver> Strange.... about this chattr problem : http://seclists.org/lists/linux-kernel/2001/Jul/2804.html
<cyberserver> This should be fixed by now... unless it showed up again in 2.6
<tepsipakki> it's a pity I'm possibly the only Finn here.. so offering a pint won't help getting reviews :)
<sistpoty> tepsipakki: what package?
<tepsipakki> sistpoty: i love you :)
<sistpoty> hehe
<tepsipakki> sistpoty: http://revu.tauware.de/details.py?upid=1959 http://revu.tauware.de/details.py?upid=1956
<sistpoty> tepsipakki: queued... may take a little bit ;)
<tepsipakki> those are the ones I'd like to see in universe
<tepsipakki> thanks
<tepsipakki> they are basically unchanged
<hub> tepsipakki: first, there are config.sub and config.log in the digff
<tepsipakki> hub: yes, how to get rid of them? note that the current libnfsidmap_0.8 also has them
<tepsipakki> I mean, upstream has packaged them already, but they are not in debian yet
<Gloubiboulga> sistpoty, I'll see discuss the netswitch issue tomorrow avec Tonio_
<Gloubiboulga> I hope we'll find a great solution
<sistpoty> Gloubiboulga: ok, thanks... though it seems to have been uploaded already
<hub> tepsipakki: what I do is moving the rule where they are copied that are in clean:: to conf.status:
<hub> tepsipakki: and delete them in clean::
<Gloubiboulga> sistpoty, didn't know that...
<LaserJock> hub: do you have an example debian/rules on that? I'm also interested in  how to get rid of config.{sub,log}
<Gloubiboulga> good night :)
<hub> LaserJock: not really, I do cdbs usually
<hub> but what I said should work
<sistpoty> hub: two things to fix for gopersist: debian/copyright should have the reference to GPL
<sistpoty> hub: and W: libgopersist-1-0: package-name-doesnt-match-sonames libgopersist-1-1 (typo?)
<hub> sistpoty: ah uh. will look into it
<tepsipakki> hub: but wouldn't that leave the directory without those files, so the diff would still be big?
<hub> tepsipakki: no. removal is ignored
<tepsipakki> ack
<hub> sistpoty: right, the package-soname is incorrect. damn
<hub> sistpoty: will fix and update
<sistpoty> hub: if you want, you can fix that locally and upload, since everything else is ok
<hub> sistpoty: okay, thx
<hub> sistpoty: raphink did comment
<hub> sistpoty: I'll check that too
<raphink> hub: if you can correct your package tonight, I'll upload it
<SEJeff> How do I rebuild a source package after editing compile options in debian/rules ?
<hub> raphink: I can upload too :-)
<hub> raphink: just tell me :-)
<hub> raphink: but yes, I'll fix it
<raphink> sure
<raphink> hub: j'ai upload etl
<hub> later tonight
<hub> raphink: vu
<sistpoty> raphink: the library name is fine, it just doesn't match the soname ;)
<raphink> mhm
<sistpoty> raphink: or what's your concern especially?
* hub didn't read in depth
* hub need to put more work at the real-job-work
<hub> raphink: rejected
<hub> etl is already in the archive
<raphink> etl?
<ajmitch> morning all
<raphink> ben j'ai rien reu moi
<hub> libetl-dev
<sistpoty> hi ajmitch
<hub> etl-dev it is named
<hub> synced from debian
<hub> *sigh*
<sistpoty> raphink: congrats for root on tiber
<raphink> sistpoty: hmm I'm not root... I'm REVU admin only...
<siretart> raphink: please read /etc/motd
<siretart> :)
<sistpoty> raphink: that's unrestricted root access ;)
<LaserJock> that reminds me, I was glad to see revu-tools float by on dapper-changes, twice ;-)
<sistpoty> hm... but I didn't see an UVF-exc. request :P
<siretart> sistpoty: pssst. that s3cr1t ;)
<sistpoty> h3h3
<raphink> sistpoty: ooh nice :)
<siretart> raphink: -> query
* sistpoty is afk for a while... will continue reviewing l8er
<hub> raphink: that etl-dev package is a violation of the debian policy IMHO
<hub> raphink: I'll file a bug in BTS
<raphink> hub: why?
<hub> raphink: it is library and is not named libetl-dev but etl-dev
<hub> raphink: that is why the upload got rejected and we didn't notice
<hub> binary package is improperly named
<raphink> oh yes
<dholbach> good night revu-ers :)
<dholbach> and everybody else of coues
<LaserJock> cya dholbach
<dholbach> course
<hub> 'night dholbach
<dholbach> night guys
<hub> and thank you for the fish
<hub> :-)
<dholbach> haha :)
<tseng> dholbach: hugs
* dholbach hugs tseng
<dholbach> *wave*
#ubuntu-motu 2006-02-28
<tepsipakki> hub: thanks, I've now fixed the rules' from the packages, new versions are on the way to REVU
<tepsipakki> and there they are: http://revu.tauware.de/details.py?upid=1980  http://revu.tauware.de/details.py?upid=1981 http://revu.tauware.de/details.py?upid=1982
<siretart> gn8 folks
<tepsipakki> night.. no more ice hockey from telly :)
<marcin`> raphink: piiiing
<raphink> marcin`: let's go to #vtiger-bounty ok?
<sistpoty> time for another reviewing round...
<ajmitch> sistpoty: do you ever sleep?
<sistpoty> ajmitch: as soon as dawn breaks ;)
<TheMuso> ajmitch: sivang said that in -devel to kamion. :)
<Toadstool> re MOTUs
<sistpoty> tepsipakki: still there?
<Kyral> lol
<sistpoty> tepsipakki: just took a glimpse over librpcsecgss... see coments (I will first do a proper review of libgssapi though)
<sistpoty> tepsipakki: and one more thing not listed: the -dev package should depend on all -dev packages needed to satisfy headers in this -dev package (not sure if any of the build-dependencies are needed though)
<marcin`> sistpoty: hello
<sistpoty> hi marcin`
<marcin`> sistpoty: got a question... could you please review vtigercrm package in REVU?
<sistpoty> marcin`: give me a few minutes, then I'll do it ;)
<marcin`> sistpoty: we just uploaded package that we think that is ready for dapper
<marcin`> sistpoty: and raphink already said yes to this package but we need another MOTU to do the same :)
<sistpoty> marcin`: sure... just a few minutes and I'll be over it ;)
<marcin`> sistpoty: ok
<Toadstool> hum... just a dumb question, feature freeze just freezes new uploads or we have to file something like a UVF for package updates ?
<Toadstool> s/new/NEW/
<sistpoty> Toadstool: we don't need exceptions existing packages... I have no clue though, if we can push in new packages after feature freeze with an exception
<sistpoty> exceptions for existing packages even
<Toadstool> ok
<sistpoty> marcin`: on it... will take some time ;)
<marcin`> ok I'm here
<Toadstool> this is mandatory but the templates in my wide-dhcpv6 package are not debian devel-reference, and therefore Ubuntu, I think, compliant... moreover I've got some translations for my templates...
<Toadstool> *isn't mandatory
<Toadstool> gn8 MOTUs
<sistpoty> marcin`: why does vtigercrm-core depend on vtigercrm-theme-blue (but only recommend the other themes)?
<marcin`> because vtigercrm needs at least one theme to work
<marcin`> sistpoty: and this theme is hardcoded as default in original config.inc.php
<marcin`> sistpoty: so I use this as default and recommend other themes as optional
<sistpoty> marcin`: so it won't work if would have only aqua-theme?
<marcin`> sistpoty: it could but to make this possible user has to change config file manually
<ajmitch> sounds broken to me
<marcin`> sistpoty: /etc/vtigercrm/config.inc.php contains $default_theme = 'blue';
<ajmitch> you're still forcing them to always have the blue theme installed, no matter what their config says
<marcin`> I also force them to use english language as default...
<sistpoty> hm... if the default config would be broken otherwise, I guess I can live with the dependencies as they are right now
<marcin`> there has to be at least one theme and at least one language
<sistpoty> marcin`: you can do this with provides: vtigercrm-theme and depending on that virtual package
<marcin`> I could keep blue in vtigercrm-core package
<sistpoty> marcin`: but I guess this can be addressed for future releases
<marcin`> sistpoty: propably yes but then I need to do some magic to change default theme in config.inc.php
* ajmitch disagrees
<sistpoty> ajmitch: as in cannot wait for future releases? or as in dependencies should be fixed, even if the config would be broken?
<marcin`> ajmitch: you disagree to what?
<ajmitch> sistpoty: disagree that it should be put off for future releases
<marcin`> ajmitch: ok then tell me how it should work?
<ajmitch> depend on real | virtual package
<ajmitch> or you depend on the blue theme first
<ajmitch> so blue | aqua | whatever
<ajmitch> they'd need to explicitly select another theme in the deps to get it
<marcin`> ajmitch: it's not 'whatever' because then you need to set at least one as default
<ajmitch> and is it so very hard for someone to change their config?
<marcin`> ajmitch: and then they should choose which one should be default
<ajmitch> the default would still be blue
<ajmitch> since if you did apt-get install vtiger-crm, it would get the blue theme
<sistpoty> ha, gained some of ajmitch's deep insight :)
<ajmitch> :P
<sistpoty> insights even
<marcin`> I don't get it...
* ajmitch can do without the mockery
<marcin`> it works like this right now - so what's the problem?
<ajmitch> the problem is that there's no way to remove the blue theme without removing the whole app
<ajmitch> if you have blue | pink | black
<sistpoty> marcin`: it's the way apt-get install handles dependencies... the blue-theme would be drawn in by default.
<ajmitch> then blue will get picked by default
<marcin`> ajmitch: ok but in the same way there is no way to remove english
<ajmitch> unless one of the others is selected
<ajmitch> marcin`: so you could change that too :)
<marcin`> ok then tell me one thing...
<marcin`> I got few theme packages right?
<marcin`> and core package...
<marcin`> and this config.inc.php is created with postinst script...
<marcin`> if I remove theme blue as default dependency then user won't be able to use application
<marcin`> I cannot install theme _after_ core package
<marcin`> and there is another problem - user can install package in this way:
<ajmitch> dependencies will be installed (and configured, iirc) before the package that depends on them
<marcin`> apt-get install vt-core vt-theme-1 vt-theme-2 vt-theme-3
<marcin`> tell me now which one should be default?
<ajmitch> whichever you like
<marcin`> so which package should be installed first?
<ajmitch> I'm sure you can come up with a good way to choose, whether it be random choice or a preferred option
<marcin`> with theme or core?
<ajmitch> ?
<Kyral> Is anyone working on scribes?
<sistpoty> no
<ajmitch> Depends
<sistpoty> at least I'm not
<ajmitch>     This declares an absolute dependency. A package will not be configured unless all of the packages listed in its Depends field have been correctly configured.
<Kyral> and how long do we have before the Freeze?
<ajmitch> so when at least 1 theme is configured, the core can be configured
<ajmitch> Kyral: a few hours
<Kyral> .....damnit
<Kyral> I could get it ready tomorrow. But not tonight...
<marcin`> know what... I don't see any way to make this as you want to
<LaserJock> Kyral: dapper+1?
<Kyral> LaserJock: yah...
<Kyral> I'll ITP it for Debian
<marcin`> and I think that there is a lot of apps that has some theme as dependency and everything is ok
<LaserJock> that is why I think it is nice to get a sponsor in Debian. I can upload packages to unstable anytime and then sync to Ubuntu when I can.
<Kyral> I thought Sponsors were on a per package basis
<ajmitch> LaserJock: until debian has freezes, that is
<marcin`> ajmitch: tell me one thing - is this possible to install for example gnome without at least one default theme?
<LaserJock> Kyral: well, often times you develop a relationship with a particular DD,  I think. So you often have the same person sponsoring your uploads.
<marcin`> ajmitch: and I really don't see any way to make this possible while dpkg doesn't provide conditional dependencies
<LaserJock> ajmitch: do you thing that Debian will have freezes in unstable?
<ajmitch> marcin`: different comparison, gnome has a single themes packages
<Kyral> I have a couple ITPs to file then
<ajmitch> LaserJock: not as such
<marcin`> ajmitch: please show me at least one package which has something you expect in vtigercrm
<marcin`> ajmitch: I just need to see it because I don't understand what is the problem for you there
* ajmitch doesn't have time right now to go digging through packages for an example
<marcin`> ok then try to talk for a while about this logic...
* ajmitch doesn't have time to talk for awhile either :)
<marcin`> let's imagine that I'm user - and want to install vtiger
<Kyral> ITPs are still filed as bugs right...
<marcin`> so I do: apt-get install vtiger-mysql
<sistpoty> marcin`: freedoom and it's dependency on doom-engine
<marcin`> ajmitch: and how should I set default theme here?
<marcin`> sistpoty: apt-getting
<tseng> Nafallo_away: talk to me
<sistpoty> marcin`: looking at the dependencies would be more helpful ;)
<marcin`> sistpoty: will freedoom work without doom-engine?
<sistpoty> marcin`: the other way round is true actually (so maybe this is not a really good example)
<LaserJock> Kyral: yeah, I used reportbug. it has an option for ITPs if I remember right.
<sistpoty> marcin`: a package providing doom-engine needs some data-files (which are in doom-engine for example, but could also be directly installed)
<marcin`> sistpoty: ok I see this - and then how I can choose different engine>
<marcin`> sistpoty: dpkg gets first from list?
<sistpoty> marcin`: it's prboom | doom-engine... so prboom should get drawn in
<marcin`> sistpoty: because it says that freedoom depends on prboom
<sistpoty> marcin`: but you can install lxdoom and remove prboom
<marcin`> but I have to install prboom first?
<sistpoty> marcin`: afaik no... apt-get install doom-legacy lxdoom-x11 should do what you want
<marcin`> we are talking about apt-get install freedoom
<marcin`> do I have a choice then?
<sistpoty> sorry... go it wrong
<marcin`> can I apt-get install freedoom without prboom?
<sistpoty> apt-get install freedoom lxdoom-x11 should do that trick
<marcin`> apt-get install freedoom doom-engine or apt-get install freedoom prboom?
<sistpoty> marcin`: sudo apt-get --simulate install lxdoom-x11 freedoom does exactly what you want
<sistpoty> marcin`: freedoom lxdoom-x11 *will* draw in prboom
<minghua> sistpoty: I believe apt-get install freedom prboom- is another option
<sistpoty> minghua: no, just tried it, it does draw in prboom
<marcin`> sistpoty: ok then how can I switch between engines?
<sistpoty> marcin`: by installing another engine and removing the previous enging
<sistpoty> ah... my typing is horrible today
<marcin`> but what if I want to have both?
<sistpoty> you install them both
<marcin`> ok and which one is default then?
<ajmitch> whichever freedoom decides to use
<marcin`> imagine now - I got vtiger and for example 10 themes
<sistpoty> marcin`: prboom, because it gets drawn in automatically
<ajmitch> it's up to the program to decide what files it uses
<sistpoty> marcin`: but otoh there is no real default
<marcin`> each can be default but at least one _has_ to be default
<ajmitch> so choose one as default
<marcin`> I already did - blue is default
<sistpoty> ajmitch: the example is stupid, since freedoom (the datafiles) shouldn't depend on a doom-engine at all... but that's a different issue
<ajmitch> I mean without forcing users to always have it
<marcin`> I need to force users because there has to be at least one
<ajmitch> sistpoty: you're right, programs should depend on data, otherwise you can end up with circular dependencies
<marcin`> and there is another thing - blue is let's say 'system' default
<sistpoty> ajmitch: yes, and the tricky part is that you have all combinations of doom-engine and data-files here (as you could install the original doom-datafiles) but let's get back to vtiger
<marcin`> then each vtiger user can set different one as default
<minghua> sistpoty: in my system "apt-get install freedoom prboom-" works (note the minus sigh after prboom), it installs doomlegacy-x11 instead
<ajmitch> sistpoty: I'll let you handle it, I don't have the stamina to discuss this for the next 4 hours
<sistpoty> minghua: ah... I thought it was a typo *g*... learned just another thing
<sistpoty> ajmitch: phew... and this is just one of the issues I see w.o. even having built vtiger...
<minghua> sistpoty: a handy but less-known feature of apt-get :-)
<sistpoty> :)
<sistpoty> marcin`: so it might break if you install all themes, user sets a different theme and this theme get's removed?
<marcin`> ok guys let's do something
<marcin`> sistpoty: yes
<marcin`> sistpoty: but it's usual
<sistpoty> hm... don't have a (nice) solution at hand for this
<marcin`> sistpoty: in the same way I can set some theme in gnome on my desktop then remove this theme...
<marcin`> sistpoty: and gnome will propably switch to default right>
<marcin`> ?
<sistpoty> marcin`: no idea, I use kde ;) (and I'm not eager in testing this right now)
<minghua> gnome behaves strangely last time I tried that :-)
<sistpoty> marcin`: imo if you set a hard dependency on all themes, it will not make vtigercrm break, until you figured a better solution
<marcin`> anyway how it should be done to make you happy?
<marcin`> sistpoty: but I don't need hard dependency on all themes
<sistpoty> marcin`: I guess some postinst/postrm magic of the themes would be the way to go
<marcin`> sistpoty: I need hard dependency on one single theme
<marcin`> sistpoty: and default theme is set to blue in original config file
<marcin`> sistpoty: so I use this theme as default and then user can add optional themes if wants to
<sistpoty> marcin`: if you can live with the breakage, if a theme gets removed afterwards, you could depend on blue | theme and have all the themes provide theme
<marcin`> sistpoty: please install vtiger and try this at least once
<hub> I have an app whose version is R6 -BETA
<sistpoty> marcin`: what exactly do you want me to try?
<hub> how shall I version it
<marcin`> sistpoty: then you will see that it has login dialog
<hub> 0.0+R6BETA ?
<marcin`> sistpoty: and there user can choose theme
<marcin`> sistpoty: this is dropdown and it has to have at least one entry on it's list
<marcin`> so there always will be blue
<sistpoty> marcin`: I will do that... but first I'd like to review a little bit more
<marcin`> or more...
<marcin`> ok
<marcin`> but I'll be online for about 30 minutes...
<marcin`> it's 3:37 am here
<marcin`> and I need to go to bed soon
<sistpoty> hub: good question... 0.0+R6beta is at least not wrong
<hub> yeah
<sistpoty> marcin`: same here... but there are still some (really serious issues)
<hub> I'll start with that
<marcin`> sistpoty: go on then...
<sistpoty> marcin`: you should actually put everything from copyright.txt into debian/copyright
<sistpoty> marcin`: because the copyright information need to be available uncompressed
<sistpoty> marcin`: license_agreement should also be in debian/copyright
<marcin`> ehh it's ArmeBosse issue
<sistpoty> marcin`: but that's a pretty serious issue imo
<sistpoty> marcin`: another thing: vtigercrm-mysql-local: does it need php4 or libapache[2] -mod-php4?
<marcin`> libapache
<sistpoty> marcin`: and the conflicts to php5 is wrong, unless it contains the same files as php5 does
<marcin`> but it won't work if there is php5 in system
<minghua> marcin`: that doesn't mean it needs to Confilct with php5
<sistpoty> marcin`: but conflicts *only* states: cannot be installed at the same time (due to the same files being in the package)
<sistpoty> marcin`: there is no method of describing app foo will break app bar in debian/control
<marcin`> ok I'll remove this but it sucks because php5 is now in main...
<sistpoty> marcin`: mom, I'll look for a lengthy rant^Wexplanation from keybuk
<marcin`> and it will make vtigercrm propably unusable
<marcin`> and what about these licenses - it's not enough that they are mentioned in copyright?
<sistpoty> marcin`: https://launchpad.net/distros/ubuntu/+source/ubuntu-meta/+bug/22335 for conflicts
<Ubugtu> malone bug 22335 in ubuntu-meta ubuntu-desktop "gnome-screensaver conflicts with ubuntu-desktop" [Normal,Fix released] 
<sistpoty> marcin`: no, if you look at the debs, copyright.txt is compressed, and that's the point about it
<sistpoty> marcin`: you should simply copy all the contents of copyright.txt to debian/copyright (as well as license_agreement)
<marcin`> sistpoty: is there a way to keep these files uncompressed in /doc ?
<marcin`> sistpoty: they are not compressed in *.orig.tar.gz
<minghua> someone should put keybuk's explanation in a more apparent place :-)
<TheMuso> If any MOTUs have time, there is a new speechd-up package available for review.
<sistpoty> marcin`: yes, but imo you should put that into debian/copyright
<marcin`> ok just a moment
<marcin`> so remove this php5 conflict?
<vivid> how exactly do i sign up for motu?
<sistpoty> marcin`: yes, please remove the conflict
<TheMuso> vivid: YOu can either find a package that is not yet in the archive to upload, or start helping to fix bugs.
<marcin`> sistpoty: ok then is there any way to ensure that some other dependency will not broke my package?
<marcin`> break...
<vivid> thats it, ive got an app of mine that im trying to get in...but i cant figure out how, ive uploaded to revu, i think
<sistpoty> marcin`: no.
<vivid> i already have the changes, dsc, amd64 and x86 packages of the libs and binary
<sistpoty> marcin`: at least no automatic way
<marcin`> sistpoty: well it sucks...
<sistpoty> marcin`: why does it break if you have php5 installed?
<TheMuso> vivid: Have you emailed to submit your GPG key?
<marcin`> sistpoty: because by default apache will use php5 (if it is installed then it overrides php4)
<zakame> hi all
<vivid> TheMuso: no im not having much luck with finding this type of information on the site
<marcin`> sistpoty: and vtigercrm php code is not compatible with php5
<vivid> TheMuso: but i have my private and pub key here
<vivid> TheMuso: and my dsc, changes is signed
<TheMuso> vivid: I don't have much time right now, but give me a sec and I will find the link.
<vivid> sweet, thanks
<sistpoty> marcin`: you ship some apache-config-fragment... couldn't you put s.th. in there that prevents usage of php5?
<vivid> do i submit to REVU, or MOTU?
<marcin`> sistpoty: don't know that
<TheMuso> https://wiki.ubuntu.com/REVU
<marcin`> sistpoty: btw this package is broken...
<TheMuso> vivid: Thats the link with the info you need.
<sistpoty> marcin`: oh, that's bad
<marcin`> sistpoty: need to fix that.. ArmeBosse removed my postinst code and replaced with his that is broken
<marcin`> sistpoty: not big issue but this package is not installable at the moment
<sistpoty> marcin`: should I post all comments I found up till now? or do you want to wait until I finished reviewing
<ajmitch> sounds like a big enough issue
<marcin`> yes post all you got
<marcin`> ajmitch: right... I had no time to test it - he said that this is only regression to what he had before and it was workable...
<zakame> hi MOTUs!
<marcin`> ajmitch: but now I see that he was wrong
<sistpoty> hey zakame
<zakame> hello sistpoty
<sistpoty> marcin`: posted to revu... I mentioned most of them here already
<vivid> apparently ive already got it uploaded, but i cant sign in, and the rocover link provides nothing for me to paste and decrpyt
<marcin`> sistpoty: there is lintian override with missing-debconf-dependency
<marcin`> sistpoty: is that ok?
<marcin`> sistpoty: another question - we need some template file - config.template.php to use this file as input for dbconfig-common
<marcin`> sistpoty: and then we get config.inc.php as output
<marcin`> sistpoty: it goes to /etc/vtigercrm/
<marcin`> sistpoty: is this ok to have template there too?
<sistpoty> marcin`: no... lintian overrides are (if ever) only good if you know for certain that lintian is wrong
<marcin`> sistpoty: or maybe template should go to /tmp and then should be removed after config.inc.php is already generated by postinst?
<marcin`> sistpoty: so I should add debconf dependency>
<sistpoty> marcin`: templates shouldn't be in /etc... I
<sistpoty> marcin`: yes, please do
<sistpoty> marcin`: you can't install a file to /tmp
<sistpoty> marcin`: (i.e. a package can't have a file in /tmp)
<marcin`> sistpoty: I don't want to install file there I had a piece of code that generated file
<marcin`> sistpoty: with mktemp in /tmp
<jsgotangco> hrmm it seems libpng12-0 broke pngcrush
<sistpoty> marcin`: if it's temporary then it should be tmp, shouldn't it?
<marcin`> sistpoty: and then this file was used as template to generate /etc/vtigercrm/config.inc.php
<marcin`> sistpoty: and removed from /tmp after postinst
<marcin`> sistpoty: so anyway if I want to use template that should be temporary
<vivid> siretart: im having trouble logging into REVU, are you here?
<marcin`> sistpoty: I should install/generate this file from postinst
<sistpoty> vivid: just a sec, I'll take a look (soon)
<marcin`> sistpoty: then do something with this file in postinst and remove from tmp on the end - right?
<sistpoty> marcin`: sounds good
<sistpoty> vivid: what's your email-address for revu?
<vivid> sistpoty: jaugustine@vivnet.net
* sistpoty looks
<vivid> i cant seem to get my encrypted password..
<marcin`> sistpoty: so the thing now is that ArneBosse wants to use template file which he expects to be in /etc/vtigercrm
<marcin`> sistpoty: but he doesn't provide any script to put this file there - and this is why currently this package is broken
<sistpoty> marcin`: then unbreak it ;)
<marcin`> sistpoty: so I could add script that will install template file
<marcin`> sistpoty: but it definetly shouldn't go to /etc/
<sistpoty> marcin`: if it's temporary, it shouldn't go to /etc... (or just a template that's no config-file)
<marcin`> sistpoty: ok he will be angry but I don't care - my code is ok - his code is broken ;)
<marcin`> sistpoty: just a moment :)
<sistpoty> vivid: did you upload a package to revu yet?
<vivid> yes, two, and when i try to re-upload, it says theyre already there
<sistpoty> vivid: give me another sec please ;)
<vivid> they are libpar2 0.2-0ubuntu1 and gpar2 0.3.1-0ubuntu1
<sistpoty> vivid: yes, both have been moved to the rejected queue... only question remains is why
<vivid> if there is no license file will that happen? i think its named copying
<sistpoty> vivid: no, they are rejected in the revu-queue by some script... so there is either s.th. wrong with the signature or your key not yet imported or the scripts fault (once again)
<vivid> well, i didnt send my key to the keyserver until after i uploaded, so thats probably why
<sistpoty> vivid: what's your keyid?
<ajmitch> vivid: sending to the keyserver is just 1 part, it needs to be imported by a revu admin (like sistpoty)
<vivid> 2A70ADF9
<sistpoty> vivid: no that key isn't in revu's keyring... where did you actually send your key to?
<sistpoty> (since I didn't get a mail from you)
<sistpoty> vivid: but anyways, please send a signed mail to keyring@tiber.tauware.de, then I'll import your key
<vivid> the site says to send it to keyserver.ubuntu.com
<vivid> ok one sec
<marcin`> sistpoty: what is po-debconf ?
<marcin`> sistpoty: can it be set as dependency - debconf?
<sistpoty> vivid: hehe, that's only one step
<vivid> i must be in too much of a hurry
<sistpoty> marcin`: po-debconf is afaik the thing for debconf-translations
<sistpoty> marcin`: what do you mean about the dependency?
<marcin`> sistpoty: Pre-Depends: debconf | debconf-2.0 something like this?
<vivid> err, how do i sign an email heh
<sistpoty> marcin`: urm... why not just a dependency on debconf?
<marcin`> sistpoty: there was another issue in lintian then AFAIR
<sistpoty> vivid: what email-client are you using?
<vivid> i found the how-to thingy in the wiki
<sistpoty> vivid: :)
<sistpoty> marcin`: imo debconf as pre-depends should suffice, since debconf-2.0 is provided by debconf... (but I'm not sure wether that's true for debian/testing as well)
<sistpoty> marcin`: but it looks sane
<vivid> what should the subject be?
<sistpoty> vivid: a nice one... I like recieving mails with nice subjects (just kidding)
<sistpoty> vivid: s.th. like key for revu
<vivid> and you just want the public key block in it right?
<sistpoty> vivid: no, I want the mail to be signed by you... I can figure the keyid from that
<vivid> ok, well i put the keyblock it, but its signed anyway so it should be good
<sistpoty> vivid: doesn't really matter ;)
<marcin`> sistpoty: you said that I should put Cpyright.txt to debian/copyright?
<marcin`> sistpoty: have you sean it's content?
<sistpoty> marcin`: I browsed through it... probably append it to the bottom of debian/copyright
<marcin`> sistpoty: there is GPL license 2.1 there PHP License..
<marcin`> sistpoty: mysql and few more....
<sistpoty> marcin`: you can strip the GPL from it... but you need to mention what's covered in by gpl
<sistpoty> marcin`: you can strip only licences that are under /usr/share/common-licenses
<ajmitch> marcin`: what's covered by thte php license?
<marcin`> ajmitch: propably nothing
<ajmitch> I hope so
<ajmitch> otherwise ftp-master will probably reject it
<ajmitch> http://ftp-master.debian.org/REJECT-FAQ.html
<marcin`> ajmitch: aaaah I know why its there
<marcin`> ajmitch: it's because installation package for windows containst php and apache bundled in single package
<ajmitch> and are you shipping any of that source?
<marcin`> ajmitch: no
<marcin`> you know in windows they wanted to provide 'single click' installation
<marcin`> so they bundled apache/php/mysqlserver+vtiger
<sistpoty> marcin`: if nothing is covered by the source or binary by a license, you can of course remove that one as well
<marcin`> this license definetly needs more work
<marcin`> this guy ArneBosse is vtiger developer
<sistpoty> oh, nice
<marcin`> and he stripped everything he could
<fbond|away> dolson: here?
<dolson> fbond: always
<marcin`> from license - he propably wanted to hmm hide sugarcrm license somewhere deep under
<fbond> no kidding...i think you just may be here always
<ajmitch> marcin`: filed an ITP/RFP for it in debian?
<marcin`> ajmitch: unfortunately he filed ITP
<ajmitch> he?
<marcin`> ArneBosse
<marcin`> (icr nick)
<ajmitch> ok
<ajmitch> and does he have packages also?
<marcin`> http://fboudra.free.fr
<marcin`> his web page
<marcin`> what do you mean - 'does he have' ?
<ajmitch> just that
<ajmitch> he filed an ITP, has he worked on packages?
<marcin`> no we work together on this package
<ajmitch> then why is it unfortunate that he has filed the ITP?
<marcin`> we started independent - there is bounty in launchpad
<marcin`> because he was first :)
<ajmitch> yes I saw the package & even though about packaging it myself
<marcin`> and afaik debian packages are more important than these in ubuntu
<marcin`> while I didn't want to make package for debian - I don't use debian - just ubuntu
<fbond> dolson: eh, i was looking at packaging freecycle
<marcin`> and I didn't know about ITP and things like that
<ViViD> if debian updated a little more..
<fbond> there is an ITP, however
<fbond> I will get in touch with the ITP creator
<fbond> he already has packages made...I wonder why they aren't in Debian yet
<fbond> nm
<fbond> night
<marcin`> anyway this package is collaborative work
<dolson> fbond: oh yeah? cool..
<marcin`> fbond: where are these packages?
<fbond> http://piem.org/debian/
<fbond> i actually already did all the modifications necessary for dapper
<fbond> i was almost done when I decided I should probably check for an ITP
<fbond> :)
<sistpoty> ViViD: sorry, my universities mailserver seems to do weird things atm... didn't get your mail yet (but you sent it to the right place, I just went through the logs)
<marcin`> fbond: are you talking about vtiger packages?
<fbond> marcin: nope, we got our wires crossed
<marcin`> :)
<fbond> eh, happens :)
<fbond> later, y'all
<marcin`> sorry :)
<TheMuso> c
<TheMuso> wrong window sorry
<dolson> cya fbond|away
<dolson> fbond|away: whoa... ldrum looks sweeeet
<TheMuso> ldrum?
<ViViD> sistpoty: any luck with that email yet?
<sistpoty> ViViD: not really... give me a sec pls.
<sistpoty> ViViD: seems like it finally made tiber's MTA... so it should be here in a few seconds ;)
<sistpoty> made it past tiber's mta even
<ajmitch> sistpoty: want me to import it?
<ajmitch> I got it awhile ago
<sistpoty> ajmitch: go for it ;)
* ajmitch has to install gpg on the box first :)
<sistpoty> hehe
<ajmitch> gpg: key 2A70ADF9: public key "John Augustine <jaugustine@vivnet.net>" imported
<sistpoty> ViViD: congrats... you can upload to revu now ;)
<LaserJock> hi minghua
<minghua> hello LaserJock
<ViViD> sistpoty: am i able to upload .deb packages, or just sources
<sistpoty> ViViD: only sourcepackage with orig.tar.gz
<sistpoty> (i.e. dpkg-buildpackage -rfakeroot -S -sa)
<ViViD> thats what i sent, the changes file like it said
<ajmitch> before or after your key was imported?
<sistpoty> ViViD: revu runs over the incoming queue every */10, maybe it isn't processed yet
<sistpoty> (minutes)
<ajmitch> no, it is there
<ajmitch> http://revu.tauware.de/details.py?upid=1990
<ajmitch> it's done as a native package though
<ajmitch> plenty of comments for sistpoty to make on this one ;)
<sistpoty> hehe, it's in my queue ;)
<ViViD> sistpoty: one of them is up, the other isnt, maybe you can tell me if it was rejected?
<ajmitch> ViViD: not rejected, retry with dput -f
<ViViD> at least the required libraries got on
<ViViD> so now after two people review it, it gets put into universe?
<ajmitch> after 2 people check that everything is ok
<ajmitch> it looks like there'll be a bit of fixing to do
<ajmitch> firstly I can see that it isn't versioned properly, it ought to be 0.2-0ubuntu1
<ViViD> ive never seen a source versioned that way
<ajmitch> and that there are still a lot of unneeded .ex files in debian/
<ViViD> thats what dh_make put in
<ajmitch> yes
<ajmitch> and you can't just use dh_make as-is
<ajmitch> you need to clean up after it & only use the things you need
<ViViD> the actual program has no bugs, and this is my first source package
<ViViD> i updated the files, didnt know i was supposed to delete stuff
<ajmitch> yes, and you also need to cleanup debian/rules to take out rules you don't need
<ViViD> so i need to delete all the unneeded stuff, and change the version, anything else?
<ajmitch> plenty else
<ajmitch> this is just a quick overview :)
<ViViD> like i said this is my first time making source packages, i have a million binary debs on my server
<ViViD> so can i edit from the site, or do i need to change and re-upload
<sistpoty> ViViD: you'll need to change and reupload
<ajmitch> when I say that it should be 0.2-0ubuntu1, I mean that you have a libpar_0.2.orig.tar.gz
<ajmitch> and then you add on the debian directory, and put that version in the changelog
<ViViD> i have the libpar2_0.2.orig.tar.gz
<ViViD> so i put that inside the package? parrallel to the debian dir?
<ViViD> and then change the version to comply
<ajmitch> outside the package
<ajmitch> why is the package source named libpar2?
<ViViD> because its a library for par2's
<ajmitch> ok
<ViViD> hence gpar2
<ajmitch> so that's not part of the SONAME
<ViViD> par1 is deprecated yet it will work
<ajmitch> which will make naming the binary package fun
<ajmitch> what is a par2?
<ViViD> binary should be libpar2_0.2-0ubuntu1_arch.deb
<ViViD> its a recovery volume set
<ViViD> for repairing files, or groups of files that have become corrupted, or checking that they are not corrupted
<ajmitch> no, binary should have the SOVERSION in the name as well
<ViViD> ?
<sistpoty> ViViD: check the debian library packaging guide, it explains it better than I could (but ajmitch can explain it even better I guess *g*)
<ajmitch> reading that is probably best, before I try & explain
<sistpoty> hehe
<minghua> defoma is a monster :-(
<minghua> and a monster few people understand for that
<ajmitch> minghua: 'here be dragons;
* sistpoty doesn't understand unix+fonts stuff at all
<ViViD> k, the so is libpar2.so
<ViViD> and its version is 0.2, same as the package
<ajmitch> SONAME is different
<sistpoty> ViViD: the soname is *inside* libpar2.so (objdump -p libpar2.so | grep -i soname)
<ajmitch> it's a name for binary compatibility
<ViViD> that gives me no output
<sistpoty> ViViD: the soname describes compatibility... e.g. if version 2 and version 3 share the same soname, it means that you can exchange these two (because every public function has the same signature and the same semantics, but might be implemented differently)
<sistpoty> ViViD: probably -P, don't know it by heart ;)
<ViViD> must not be set, guess ill release a v0.2.1
<ajmitch> all this complex library stuff needs to be right, and it's one of the reasons why maintaining library packages isn't simple
<ViViD> and i need to reference the soname in the binary source?
<ajmitch> the binary package name has it
<minghua> we have a packager whose first package is a shared library here?
<sistpoty> ViViD: yes... otherwise all packages that depend on a specific shared object would cease to work, if you update that shared object to a newer (incompatible) version
<sistpoty> minghua: iirc lfittl also did a library quite early, and he did it quite well afaikt
<ajmitch> minghua: yep
<minghua> sistpoty: my first package is a package with both program and shared library :-)
<sistpoty> minghua: nice :)
<minghua> and I didn't get it correct the first time, actually far from correct
<minghua> s/is/was/
<ViViD> ok soname is libpar2.so.0
<ajmitch> so the binary package name might be libpar2-0
<ViViD> so the package would be libpar20_v_arch right?
<minghua> ViViD: you need libpar2-0 as package name then
<ViViD> ok -0
<ajmitch> and you'd still have something like 0.2-0ubuntu1 in the changelog
<ViViD> now, i just set the dependency of gpar2 to libpar2-0 instead of libpar2?
<minghua> ViViD: read http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html, it will help :-)
<ViViD> i believe im already there
<sistpoty> ViViD: no... the dependency of gpar should be generated
<ajmitch> which means you'll need to do the shlibs fun
<sistpoty> ajmitch: gpar2 is a different sourcepackage ;)
<ajmitch> sistpoty: I'm aware of that
<sistpoty> ahhh... ;)
<ajmitch> but any shared library package has to have the shlibs info in it
<minghua> okay, a question about maintainer's scripts
* ajmitch points at sistpoty 
* sistpoty hides
<minghua> if a -2 version package want to get rid of something -1 left
<minghua> I should add a .preinst script for -2, see if it's upgrading, compare versions, and do my clean-up if the version is smaller than -1
<minghua> does that sound correct?
* sistpoty points back to ajmitch
<ajmitch> something like that, I guess :)
<crimsun> mostly. If only -1 has the issue, then checking for -1 is not semantically what you want.
<sistpoty> minghua: no idea really
<crimsun> err, checking for < -1
<minghua> crimsun: I believe all versions < -1 has this problem
<crimsun> ah, ok
<minghua> okay, since no objections, I'll try this
* minghua goes downgrading first :-(
<minghua> and downgrading won't work properly because of the same problem with my local new package (incomplete fix), arrrrgh
<sistpoty> dolson: around? omins extended-description line extends 80 charachters... may I fix it and upload (since it's nice the way it is)
<sistpoty> s/extends/exceeds/
<dolson> sistpoty: dang
<dolson> sistpoty: yes, go ahead. I'll fix locally too
<sistpoty> dolson: ok, will do ;)
<dolson> thanks :)
<sistpoty> ;)
<dolson> sistpoty: hey, how come it says Ubuntu Installer on the dapper-changes list for most of my packages? is this because you modified them so it goes to this default name or something?
<crimsun> it's because your e-mail isn't known to katie
<dolson> well one of my first packages shows up as my name?
<sistpoty> crimsun: there is no katie any longer in the soyuz new world order
<sistpoty> dolson: when/which package?
<crimsun> hmph? dang.
<sistpoty> dolson: soyuz is currently still evolving, maybe they changed that part... but I would only count as a person who changed the package, if I updated/appended debian/changelog
<dolson> sistpoty: well, seq24 shows my name, although I am not the maintainer... maybe that's why I guess that's the only one
<ViViD> ok ive updated the lib package, its now libpar2-0_0.2-0ubuntu1 with .ex remove, updated rules, and shlibs
<sistpoty> dolson: ah, 12.Feb... a change in soyuz I guess
<dolson> sistpoty: no biggie, I was just curious. makes it harder for me to search the page for my name :)
<sistpoty> dolson: maybe s.o. in #launchpad knows the details ;)
<sistpoty> dolson: just from a sweep through the changes-ml, looks like it's restricted to ppl. of ubuntu-dev and ubuntu-core-dev group
<dolson> ah
<ViViD> and the binary is updated, anything i need to do please let me know so i can do it
<sistpoty> dolson: omins is upped
<sistpoty> ViViD: I'll take a look ;)
<dolson> sistpoty: cool deal :)
<sistpoty> btw.: I hope that nobody will ever ask in which order the packages are listed on revu
<sistpoty> *g*
<ViViD> sistpoty: can you remove the libpar2 (non libpar2-0) package i put on there?
<sistpoty> ViViD: sure
<ViViD> thanks
<ajmitch> sistpoty: what is the order? :)
<dolson> sistpoty: I was thinking of asking that earlier.. but I come to the conclusion it's semi-random, but ordered by # of advocates as well
<sistpoty> ViViD: why did you change the name of the sourcepackage?
<minghua> sistpoty: I was just going to ask the same question :-)
<sistpoty> ajmitch, dolson, minghua: it was a suggestion from \sh_away... but I don't recall it exactly any longer... was s.th. like first order: updated packages already in ubuntu/new packages, second order good/need work packages, third order number of advocates and fourth order number of total comments (or uploads?)
<ViViD> i changed it to match the package, the version stuff is added by debuild
<ajmitch> ViViD: the binary package name needed change, but not the source package name
<ViViD> i cant get it to take my orig.tar.gz unless its inside the tar.gz
<sistpoty> ViViD: the name of the sourcepackage should match the name upstream gave it (unless that's taken already)
<ViViD> the source package is autogenerated with whatever version is in the changelog
<ajmitch> yes, and you didn't need to change that
<ajmitch> the binary package name is in debian/control
<sistpoty> ViViD: no... the name of the sourcepackage doesn't change... it's always the thing in debian/control (after Source:)
<ajmitch> it was just the version number that needed changed in debian/changelog
<ViViD> i changed that
<ViViD> and it gave me the libpar2_ubuntublah gz
<ViViD> so version in changelog needs the ubuntu tag?
<sistpoty> ViViD: exactly
<ViViD> ok, so how do i stop it from building that gz with it...
<sistpoty> ajmitch, dolson, minghua: there is the tiny sql-statement responsible for revu-ordering: http://revu.tauware.de/~sistpoty/foo/index.py.txt
<sistpoty> (upload_rows)
<ViViD> so my gz should come out as libpar2-0.2.tar.gz right?
<ajmitch> no
<ajmitch> well
<sistpoty> ViViD: it
<ajmitch> you should have libpar2_0.2.orig.tar.gz
<ViViD> oh, you mean i added the -0 to the source pkg name
<sistpoty> ViViD: it'
<ajmitch> and then a libpar2-0.2 directory
<sistpoty> args... damn enter key
<ajmitch> the orig.tar.gz name has to match the source package name
<dolson> ah cool
<sistpoty> ViViD: it should always be called sourcepackagename_upstreamversion.orig.tar.gz
<ajmitch> as sistpoty says :)
<ViViD> yea i have that, but it doesnt upload it
<minghua> ViViD: dpkg-buildpackage -S -sa
<ViViD> thats what im doing and it gives me a changes, dsc, build and a updated tgz
<ViViD> then when i dput the changes it uploads the dsc, changes and updated tgz
<ajmitch> use ls, show us what is going on
<sistpoty> ViViD: is there a .upload file left behind?
<sistpoty> ViViD: then you'll need dput -f
<ViViD> yes
<ViViD> and it didnt ask to be forced, didnt overwrite anything cuz i changed the name to libpar2-0
<ViViD> well and the version
<ajmitch> you've changed the source package name back to libpar2?
<ViViD> the way i thought it should be is libpar2_0.2.tar.gz, libpar2_0.2.orig.tar.gz and the other files
<ajmitch> you shouldn't need libpar2_0.2.tar.gz
<ViViD> er, thats the debian source package
<ajmitch> ?
<ViViD> that gz contains the debian subdirectory
<ViViD> but debuild produces libpar2-0_0.2-0ubuntu1.tar.gz
* ajmitch sighs
<ViViD> agreed
<ajmitch> you should have libpar2_0.2.orig.tar.gz & a directory libpar2-0.2 in one place, right?
<ajmitch> no tar.gz should have the debian stuff in it
<ViViD> yea i started with libpar2_0.2.orig.tar.gz and an extracted libpar2-0.2 which i added the debian stuff to on my desktop
<ajmitch> that's fine
<ViViD> when i run debuil -S -sa from the libpar2-0.2 dir it gives me libpar2-0_0.2-0ubuntu1.changes, dsc, build, and tar.gz
<ajmitch> but you've still got the source package named wrong
<ViViD> yea i changed the source line in control back to libpar2
<ajmitch> debian/changelog also
<ViViD> so only Package in control should be libpar2-0
<ajmitch> yes
<ViViD> the version in changelog needs 0.2-0ubuntu1?
<ajmitch> and you'll also have to add in a section for libpar2-dev in debian/control later
<ajmitch> yes
<ajmitch> and the distribution must be dapper, not unstable
<ajmitch> which you already have, I see
<ViViD> yea thats what i use anyway
<ViViD> its only only install cd that has my sata drivers in the kernel
<ViViD> so i should be getting libpar2-0_0.2-0ubuntu1_source.changes,dsc and libpar2-0.2.orig.tar.gz
<ViViD> ?
<ajmitch> no
<ajmitch> libpar2-0_0.2-0ubuntu1_source.changes looks like it still has the source package named as libpar2-0
<ViViD> i havent updated it yet
<ViViD> er uploaded it
<ViViD> k now ive got libpar2_0.2-0ubuntu1_source.changes,dsc, and tar.gz
<ajmitch> tar.gz or orig.tar.gz?
<ViViD> and the binary should be build as libpar2-0
<ajmitch> what is your orig.tar.gz named?
<ViViD> libpar2-0.2.orig.tar.gz
<ajmitch> - must be _
<ajmitch> so libpar2_0.2.orig.tar.gz
<sistpoty> hm... speechd-up contains an info-page, which is dual licensed GFDL + GPL, debian/copyright has only GPL in it... would this be a blocker?
<ajmitch> sistpoty: I'd say so
<ajmitch> but I'm pedantic
<ViViD> ok thats changed, now it should upload it with the others?
<ajmitch> ViViD: what files are produced now?
<ViViD> i have libpar2_0.2-0ubuntu1_source.changes,dsc,build,tar.gz and libpar2_0.2.oirg.tar.gz
<sistpoty> ajmitch: but OTOH the info page displays the license when viewed... (and even contains the full license)
<ajmitch> sistpoty: everything should still be listed in debian/copyright
<sistpoty> ajmitch: ok
<ViViD> it still doesnt send my orig.tar.gz though
<dolson> whoa, Dapper will have a GUI installer?
<ViViD> so far it has a gui progress bar at the beginning
<sistpoty> TheMuso: read that part about debian/copyright? ;)
<ajmitch> ViViD: what files are produced by debuild, please?
<ViViD> but the rest is standard
* dolson hopes it's not slow like the Mandrake installer that was introduced around 9.0 or so
<TheMuso> sistpoty: Yes.
<sistpoty> TheMuso: and it FTBFS :(
<sistpoty> TheMuso: probably lack of build-dependency on autotools-dev
<TheMuso> FTBFS?
<sistpoty> fails to build from source
<ViViD> debuild -S -sa gave me libpar2_0.2-0ubuntu1_source.changes, libpar2_0.2-0ubuntu1.dsc, libpar2_0.2-0ubuntu1_source.build and libpar2_0.2-0ubuntu1.tar.gz, and i have my libpar2_0.2.orig.tar.gz which i started with
<TheMuso> Right.
<TheMuso> sistpoty: In pbuilder?
<sistpoty> TheMuso: yep
<ajmitch> something is still broken there
<TheMuso> Ok. u.a.c has been so broken I haven't been able to properly check. DOing so now.
<TheMuso> thanks :)
<ViViD> ajmitch: take a look at my control and changlog, its uploaded
<sistpoty> TheMuso: yep. autotools-dev seems to do the trick (at least it's going past the failure)
<TheMuso> Righto.
<TheMuso> Updating pbuilder and will try again...
<ajmitch> ViViD: when you do debuild -S -sa, do you see dpkg-source: building libpar2 using existing libpar2_0.2.orig.tar.gz
<ajmitch> ?
<ViViD> i got it
<ViViD> now it uploaded orig.tar.gz and diff.gz as wel
<ajmitch> ok
<sistpoty> TheMuso: please check all documentation files for copyright... iirc the .tex is still a little bit different than the other two files
<sistpoty> TheMuso: apart from that I'm happy with it
* sistpoty is afk for a cigarette
<TheMuso> sistpoty: Want me to re-upload?
<sistpoty> TheMuso: would be nice
* ajmitch goes afk also
<TheMuso> np
<LaserJock> hi monzie
<monzie> Hi LaserJock
<monzie> finall the Ebuntu packages are ready LaserJock
<ajmitch> monzie: really? you've got all the e17 packages done & ready to upload into ubuntu?
<monzie> no ajmitch , i got the e17 binary packages ready
<ajmitch> ah
<monzie> they can be installed over a clean breezy install now to get e17
<ajmitch> checkinstall again?
<monzie> yup
* ajmitch cowers in horror at the sight
<monzie> i hope some ppl download it , test it and offer some help for packaging
<jsgotangco> \o/ ajmitch \o/
<ViViD> yay, i got the other one set too now finally made some progress here
<TheMuso> Ok speechd-up is uploaded with build-deps adjusted.
<ajmitch> reportbug really needs fixed to not target ubuntu-users
<sistpoty> TheMuso: the copyright as well?
<zakame> hello MOTUs
<sistpoty> hi zakame
<TheMuso> That was fixed in the previous upload. It probably won't show on revu straight away.
* zakame goes to REVU
<TheMuso> sistpoty: Oh sorry, what is not complete about the copyright?
<TheMuso> sorry my bad. Mised it. :S
<sistpoty> TheMuso: no, you'll also need to add the copyright info from the .tex .texi and .info files
<sistpoty> (that's the reason I begged for another upload, the other change would have been trivial)
<TheMuso> Right.
<TheMuso> Sorry, been working on casper/a11y stuff today, and my mind is a bit fuzzy after having to do a crash course in bzr. :)
<monzie> anybody from ubuntu-cn here?
<LaserJock> ajmitch: what about reportbug?
<ajmitch> LaserJock: it files bugs at the users mailing list
<LaserJock> ugghh
<LaserJock> I've never tried it for Ubuntu, only Debian
<TheMuso> I don't see anything new copyright wise that I missed in the info file.
<sistpoty> TheMuso: the info-file itself is dual-licensed by gfdl and gpl
<TheMuso> Right. Just saw that.
<TheMuso> sistpoty: You guys must to a grep -ir on the directory for copyright right? :)
<LaserJock> monzie: you should really work on getting source packages made for Ebuntu, then we can really test E17.
<zakame> ajmitch: right, to ubuntu-users, just tried that yesterday to file a bug for masqmail (which I should be doing now)
<sistpoty> TheMuso: that's how I do it
<TheMuso> Thought so.
<zakame> monzie: heya, how's the e17 packaging going?
<monzie> hi zakame
<monzie> got the binary packgaes ready
<monzie> trying to get some location to upload it , it
<monzie> it's 35 MB
<monzie> LaserJock, i have never done packaging before, and
<monzie> there are so many libs and deps that everything is getting confusing
<monzie> but i am still trying, eet and evas are ready
<TheMuso> Ok, try again. If not happy this time, shoot me. :)
<ajmitch> monzie: will you put eet & evas up for review?
<monzie> is there a point ajmitch ? FF is today , isn't it?
<ajmitch> yes, you get comments & corrections
<monzie> and those libs are for E17 only, they have no other use
<ajmitch> so that you learn more about packaging
<ajmitch> it's still worth doing it
<LaserJock> monzie: putting stuff on REVU should really help
<monzie> okay, i'll do it, but first i have to upload my bin packages
<ajmitch> even if we don't get things into dapper, they could still be ready for upload once dapper+1 opens
<jsgotangco> don't rush :)
<ajmitch> instead of spending 2 months getting things right & missing dapper+1 freezes
<zakame> yep
<monzie> ya , thanks ajmitch , i am really doing all i can
<monzie> thanks LaserJock
* ajmitch adheres to the review early, review often approach
<sistpoty> hehe, I guess the review often is sometimes a problem with the number of packages on revu
<ajmitch> true :)
<ajmitch> but that's because I'm lazy & don't review the thousands of packages like you do
<zakame> ajmitch++
<sistpoty> hehe... I am lazy as well, I should get some stupid work done, but I prefer reviewing ;)
* ajmitch is busy doing stupid work, but also busy talking on irc
<sistpoty> *g*
<zakame> heh
<tepsipakki> sistpoty: whoa, thanks for the comments!
<sistpoty> tepsipakki: you're welcome
<tepsipakki> I'm almost done with libgssapi
<ajmitch> sistpoty: I'll need to get you to review some of mine :)
<sistpoty> TheMuso: 1999 doesn't fix the copyright thing yet... you'll need to mention the GFDL/GPL dual license (and propably cite the complete GFDL)
<ajmitch> why cite the GFDL in its entirety?
<sistpoty> ajmitch: review packages from you or packages you'd have to review?
<ajmitch> hm, I thought it was in common-licenses
<sistpoty> ajmitch: can it be referred to?
<ajmitch> sistpoty: review packages I've made
<LaserJock> ajmitch: GFDL isn't installed locally so it has to be all there
<zakame> gaah
<sistpoty> ajmitch: bah... I wouldn't find a thing, and if I would I'd think I'm wrong ;)
<LaserJock> hmm, but what is being GFDL'd. it's not DFSG free.
<sistpoty> TheMuso: maybe you can refer to the GFDL in the info-page (should be in there)... what do other's think?
<tepsipakki> sistpoty: what did you mean when you said something about -dev packages and dependancies..?
<sistpoty> LaserJock: it is... dual license GPL/GFDL
<ajmitch> LaserJock: GFDL+GPL dual-license in this case
<ajmitch> sistpoty: you don't think I make mistakes??
<sistpoty> tepsipakki: what package?
<ajmitch> deluded person
<sistpoty> hehe
<tepsipakki> sistpoty: I'm not sure, you mentioned it here ;)
<ajmitch> sistpoty: another revu uploader for you to handle
<LaserJock> sistpoty: can you use a dual license that aren't compatible? I'm not very knowledgable about licenses.
<tepsipakki> sistpoty: either libgssapi or librpcsecgss
<sistpoty> tepsipakki: just a moment
<ajmitch> LaserJock: sure
<LaserJock> ajmitch: ok thanks, that seems counterintiutive to me but ok.
<ajmitch> LaserJock: when the license is applied, you have th choice of which terms it falls under
<sistpoty> LaserJock: sure... you have the choice which one should apply (as licensee)... dual-license != mixing licenses
<LaserJock> ok, that makes more sense
<LaserJock> I'm currently fighting with docteam licensing so that is why I asked.
<sistpoty> tepsipakki: at least from my comments I can't see s.th. about -dev dependencies right now
<sistpoty> (on revu)
<tepsipakki> 03:13 < sistpoty> tepsipakki: and one more thing not listed: the -dev package should depend on all -dev packages needed to satisfy headers in this -dev package (not sure if any of the build-dependencies are needed though)
<tepsipakki> :)
<sistpoty> tepsipakki: ah... right.
<sistpoty> tepsipakki: if there are other -dev packages needed, when you want to compile s.th. that uses your lib, you'll need to build-depend on these as well
<tepsipakki> build-depend and not install-depend?
<sistpoty> tepsipakki: install-depend ;)
<tepsipakki> right ;)
<sistpoty> tepsipakki: example, if there is s.th. like "#include <foobar/foobar.h>" in it, you'd need a dependency on libfoobar-dev
<tepsipakki> so, libgssapi-dev should depend on libkrb5-dev, and librpcsecgss-dev should depend on libkrb5-dev and libgssapi-dev
<tepsipakki> ?
<sistpoty> tepsipakki: if these are needed once you want to compile s.th. with the headers from the -dev package: yes
<tepsipakki> hmm, I'll try grepping
<sistpoty> tepsipakki: (however librb5-dev for librpcsecgss-dev gets drawn in automatically by libgssapi-dev)
<tepsipakki> that's true
<tepsipakki> hmm, doesn't seem that gssapi.h includes anything out of the normal stuff
<sistpoty> that's good ;)
<tepsipakki> same goes for librpcsecgss
<sistpoty> (I didn't check if anything is in there... was just a wild guess... and only really problematic for libraries on which other libraries depend on)
<tepsipakki> yeah, I get it now :)
<tepsipakki> about libgssapi: why should the libgssapi.conffiles be removed?
<sistpoty> tepsipakki: it's a file under /etc... so libgssapi.conffiles will be generated during build. if it's there it's being appended to and you end up having the same conffile in there twice
<tepsipakki> oh..
<tepsipakki> I've built and installed it but it seems normal
<sistpoty> it *should* work, but lintian gives a warning
<tepsipakki> so it seems
<tepsipakki> I asked about the versioning here yesterday, and it was told that -1ubuntu1 is the way to go.. upstream is also a debian maintainer so he _could_ upload them to debian if he wants :)
<tepsipakki> but now he's just interested how I'm doing .)
<tepsipakki> :)
<sistpoty> tepsipakki: no, if he'd upload the same stuff to debian, he'd name it -1 (and thus -1ubuntu1 cannot be synced any longer)
<tepsipakki> hmm ok, true
* sistpoty is out for just another cigarette
<sistpoty> phew... dawn already breaking... time to go to bed
<sistpoty> good night everyone
<tepsipakki> sleep well, I just woke up :)
<sistpoty> :)
<tepsipakki> cp: cannot stat `./debian/gssapi_mech.conf': No such file or directory
<tepsipakki> dh_install: command returned error code 256
<tepsipakki> so, that didn't work
<tepsipakki> eww, my bad
<jsgotangco> ajmitch: how bad is checkinstall?
<minghua> good question :-)
* minghua awaits ajmitch's answer too
<jsgotangco> the goals seem sane...
<LaserJock> but there is no source. to me that is the main problem. You only get a binary package out. At least that is my understanding
<jsgotangco> ahh
<jsgotangco> it seems convinient for self use
<Hobbsee> LaserJock: that is correct
<jsgotangco> but not for general distribution
<Hobbsee> apparently the dependencies arent done very well, from what i've heard earlier
<minghua> jsgotangco: if you ask me, I would say it's very, very, very bad :-)
<LaserJock> I've used it before for some "tweaking" of the gnuplot source package for my own personal use.
<ajmitch> jsgotangco: Don't Go There
<jsgotangco> ajmitch: that's why im asking
<ajmitch> jsgotangco: there are reasons why we go through this pain of packaging
<minghua> the thing I hate checkinstall the most is not repeatable at all, it completely depends on the build environment
<ajmitch> and it's not just a love of self-flagellation
<ajmitch> minghua: of course, and it's antithetical to a free software distribution
<jsgotangco> ahh
<LaserJock> I'm thinking of having something in the Ubuntu Packaging Guide about making quick packages but I think I'll go more towards how to quickly tweak something in the source package and build a .deb
<LaserJock> I think that is what most users will want
<ajmitch> it really isn't too hard to make a usable source package
<ajmitch> for larger projects, it may be
<jsgotangco> ajmitch: ok so its good to say that if you're going to use checkinstall, don't even think of distributing your package right?
<ajmitch> jsgotangco: more or less
<ajmitch> jsgotangco: or 'for personal consumption only'
<ajmitch> brb, trying out more bling
<tepsipakki> Now running lintian...
<tepsipakki> E: libgssapi1: ldconfig-symlink-missing-for-shlib usr/lib/libgssapi.so.1 usr/lib/libgssapi.so.1.0.0 libgssapi.so.1
<tepsipakki> should I include the link in .files or not?
<tepsipakki> it was, but I removed it
<minghua> tepsipakki: why are you still using .files?  I heard that is outdated technology
* minghua always user .install instead
<minghua> s/user/use/
<tepsipakki> minghua: it's not my idea.. upstream has debian-directory
<tepsipakki> actually, there's also a .install
<ajmitch> ah, I guess I'll have to turn on composite extension manually
<minghua> tepsipakki: upstream has both .files and .install in their tarball?
<tepsipakki> minghua: yes..
<minghua> well, well, well.
<Mithrandir> nuke upstream's debian/ and repack the orig.tar.gz, then.
<minghua> tepsipakki: I would follow Mithrandir's advice
<tepsipakki> Mithrandir: =) "please ask upstream to provide a package w.o. debian-directory for the next release" as was told by sistpoty
<tepsipakki> ok, I'll just do that then
<tepsipakki> maybe learn to use cdbs in the meantime
<Mithrandir> tepsipakki: either works.  upstream-provided debian/ directories are evil.
<tepsipakki> upstream is also a debian devel :)
<Mithrandir> is it shipped as a native package?
<tepsipakki> no
<Mithrandir> it shouldn't ship debian/ in the orig.tar.gz even if upstream is a DD.
<tepsipakki> ok, I'll tell him about it
<viviersf> ajmitch, ping
<ajmitch> viviersf: pong
<dolson> good morning dholbach
<ArmeBosse> who is daemon@poleboy.de ?
<dolson> sistpoty? maybe
<dholbach> ArmeBosse: sistpoty
<dholbach> morning everybody - hai dolson
<ArmeBosse> thks
<dolson> hi zakame
<zakame> hi all
<minghua> dholbach: any words about when approved UVF exceptions will get synced from Debian?
<dholbach> no, unfortunately not - were any packages synced at all?
<zakame> heya dolson
* zakame learns to write manpages
<dolson> hi
<minghua> dholbach: no idea, I have only one UVF exception :-)
<Tonio__> hello
<viviersf> guys
<viviersf> whats an easy way to update the alternatives ?
<ArmeBosse> update-alternatives
<viviersf> yeh i know that
<viviersf> i want a easy way of switching between 2 of em
<viviersf> without any user input
<viviersf> otherwise ill have to make an expect scripts which i dont really want to do
<ArmeBosse> i don't know other easy way, sorry
<ArmeBosse> someone know when sistpoty will be back ?
<minghua> update-alternative can be non-interactive, if that's what you want
<TheMuso> It was suggested for one of my packages that I probably need to sight the gfdl. How should I go about it? Do I point to a file on the system somewhere? It is not in the common licenses directory.
<TheMuso> and does anybody know of a good guide to how one should format their copyright file?
<dholbach> TheMuso: /usr/share/debhelper/dh_make/licenses/
<TheMuso> dholbach: Thanks.
<TheMuso> dholbach: I don't see it there.
<TheMuso> Oh, sorry.
<dholbach> dh-make maybe
<TheMuso> Now I know what you are ferring to.
<dholbach> sorry
<TheMuso> dholbach: I was told that I might have to reference the gfdl in mine though.
<TheMuso> The copyright file for speechd-up is much the same as the gpl licenses in the directory you referred to above.
<dholbach> and that is not included in the /usr/share/common-licsense
<dholbach> if you want to be 100% sure, include it
<TheMuso> No it isn't.
<TheMuso> dholbach: WOuld it be ok if I was to point people to the info file in copyright? i.e. say that they can find a copy of the license by running the info program - info speech-dispatcher?
<dholbach> for me it would, but not sure if that's commonly accepted/approved *shrug*
<dholbach> you might ask in #ubuntu-devel
<TheMuso> hmm ok.
<_mindspin> Hi, I was sent here to ask which versioning software is used by the kernel developers?
<Gloubiboulga> Could anyone have a look at http://revu.tauware.de/details.py?upid=1971 ?
<TheMuso> _mindspin: git
<_mindspin> thanks
<dholbach> Gloubiboulga: we don't seem to have netswitch, do we?
<TheMuso> Ok, if there are any MOTUs available, I kindly ask you to look at speechd-up on revu. I have just finished uploading it again, and the copyright file is the only thing that needs checking, so I am lead to believe. Thanks.
<Gloubiboulga> dholbach, not yet
<dholbach> hrm
<Gloubiboulga> it's been uploaded yesterday
<dholbach> I'd formulate  configure.in's   gtk+-2.0 >= 2.6.0   in debian/control
<dholbach> (but that's not ultra urgent)
<dholbach> what about the segfault?
<Gloubiboulga> dholbach, I can't reproduce the segfault on my dapper box, nor in a chroot
<Gloubiboulga> Tonio_, tested it to, it works fine on his box
<Gloubiboulga> s/to/too
<dholbach> apart from that it looks good so far
<Tonio_> very nice ;)
<Gloubiboulga> thanks Tonio_ , but you've done the biggest part iirc ;)
<Tonio_> Gloubiboulga: I did the *simplest* part :)
<ArmeBosse> ajmitch: ping
<tepsipakki> cdbs is lovely... life is not the same after using it :)
<freeflying> looking for review http://revu.tauware.de/details.py?upid=2004
<tepsipakki> freeflying: remove extra whitespace from the description lines :)
<freeflying> tepsipakki: thx
<freeflying> tepsipakki: anymore?
<tepsipakki> freeflying: there should be only one in the beginning of each line. I don't know about the indents
<freeflying> tepsipakki: each line in details shall indent
<tepsipakki> freeflying: yes but only one whitespace, in the diff there seems to be two, but lintian is not complaining hmmm..
<freeflying> tepsipakki: ok, I'll correct it
<tepsipakki> but I'm not a qualified reviewer, so there might be more..
<freeflying> tepsipakki: :)
<Gloubiboulga> dholbach, I've updated the gnetswitch package and reuploaded it
<dholbach> two times libgkt2.0-dev
<dholbach> but nm
<tepsipakki> W: libnfsidmap1: package-name-doesnt-match-sonames libnfsidmap0
<tepsipakki> is that worrying?
<dholbach> i'd name it <0> then - what's the library name it ships?
<tepsipakki> libnfsidmap.so.0.1.0
<Gloubiboulga> damn...
<dholbach> so that's libnfsidmap0 as a package name
<tepsipakki> the problem is that libnfsidmap1 is already in the archive..
<dholbach> and upstream switched back to .0?
<tepsipakki> I don't think they ever were at .1
<dholbach> so you updated a package?
<tepsipakki> yes
<tepsipakki> 0.8 is in now
<tepsipakki> this is 0.12
<dholbach> if you biuld the package, be sure to inspect it (i use mc for that) and look at the shlibs file and see if it's alright
<dholbach> else you should probably stick to it
<dholbach> so not worry about lintian
<dholbach> I'd just talk to the Debian maintainer and ask for his reasoning
<tepsipakki> that's upstream as well (J. Bruce Fields)
<tepsipakki> maybe I'll ignore this for now. someone should review the package btw =)
<tepsipakki> these three packages (libnfsidmap, libgssapi, librpcsecgss) are all pretty similar, and I've made changes per instructions from sistpoty
<tepsipakki> ok, new versions of libnfsidmap, libgssapi, librpcsecgss: http://revu.tauware.de/details.py?upid=2005 http://revu.tauware.de/details.py?upid=2010 http://revu.tauware.de/details.py?upid=2008
<Yagisan> G'day All - how are you today ?
* Yagisan waves at slomo
<slomo> hi Yagisan :)
<Yagisan> G'day slomo - how's your day been ? I had fun fixing the fedora box from hell
<slomo> i had fun writing a math exam that was far more easy than i thought :)
<Yagisan> slomo:  the fedora box was fun. It is in New Zealand, I'm not, and the problem is the link, and routing between the two. And someone put a fax on the backup modem line to the NZ server, just to make it more fun.
<marcin`> when is dapper package freeze?
<marcin`> I know that 23.02 but what timezone?
<tseng> why is ubuntu-desktop depending on xscreensaver anyway
<slomo> Yagisan: sounds exactly like that kind of job where one looses his sanity at some point :)
<tseng> ah just the data
<Yagisan> slomo: I think someone did - the contractors freaked, and someone had the bright idea to be knocking on my door at 8:30am yesterday morning to get me over to subcontract it
<Yagisan> slomo: somthing about me being the only linux guy they new that could a) get in, and b) fix it
<Yagisan> siretart: thanks for the heads-up on the openal transition on d-d-a. No API changes ? a simple rebuild will be ok ?
<siretart> Yagisan: I think so. (it was 'just' on d-d, since I'm not a DD)
<Yagisan> siretart: yes it was d-d - I'm tried and making typos. thanks - I will need to rebuild my private repos when the transition starts.
<dolson> hmm
<siretart> Yagisan: which of your packages is affected? did you consider joining the debian games team?
<Yagisan> siretart: deng - the one that upstream is correctly licensing and/or re-writing at last :)
<siretart> Yagisan: ah, I remember.
<Yagisan> siretart: I haven't really considered the games team, I honestly don't have much time for games anymore, so I can't test them as much as I should
<siretart> Yagisan: perhaps you can import your packages in the alioth svn. I think that would be more convinient for reviewing/working on them
<siretart> Yagisan: thats okay. no problem
<Yagisan> I'll certainly reconsider if I get more time, but -media, my private repo, and my security/hardened stuff takes up most free time I have now.
<dolson> hmm
<Yagisan> dolson: what's on your mind ?
<dolson> I don't know
<dolson> I guess I just wish I were a MOTU so I could've helped get through those packages
<Yagisan> dolson: well, I'm no MOTU, but I try to help. I try to pay attention to motu-media packages, and security related work
<siretart> dolson: just do motu stuff, you'll get upload priviledges sooner than you think
<Yagisan> dolson: I try to post patches (either my badly made, or shamelessly stolen), or at least instructions if I can, even just diagnosing why a bug happens is helpful
<dolson> don't mind me, I'm just being selfish though
<Yagisan> dolson: don't worry, I'm sure we can help you be more selfish too ;)
* dolson plays an ocarina
* Yagisan stumbles out for some food, and a drink to wipe away the memories of the fedora core 1 box from hell - bbl
<Seveas> any MOTU around?
<Seveas> siretart, poke
<nomed> there are pkges that have a /var/lib/dpkg/info/<pkge>.conffiles
<nomed> if i remove them those files are still in thei folder
<nomed> if i reinstall that <pkge> those files are not installed again ...
<nomed> any reason ?
<nomed> if i remove them <-- if i apt-get remove <pkge> ...
<dolson> nomed: that is how it is supposed to be isn't it?
<Yagisan> Seveas: why do you need a MOTU ? perhaps one of us can help
<zakame> evening MOTUs!
<dolson> nomed: if you want to remove them, then apt-get remove --purge
<nomed> dolson, yes
<nomed> ok
<nomed> i would fix xfdesktop4
<nomed> as it doesn't remove the conf files on purge
<zakame> Seveas: what's up?
<Seveas> Yagisan, bug 6585, should an UVF exception+sync be requested?
<Ubugtu> malone bug 6585 in nut "Hotplug dependency in nut-usb package" [Major,Confirmed]  http://launchpad.net/bugs/6585
<Yagisan> G'day zakame
<nomed> and it doesn't reinstall those files if they don't exist anymore
* Yagisan reading now
<nomed> for ex if user deleted them
<nomed> dolson, is there any pkge that could be a good sample where i can take a look ?
<dolson> you're asking the wrong guy
<Yagisan> Seveas: I can't see a list of bugs it fixes.
<zakame> heya Yagisan, what's up?
<freeflying> looking for reviewer :http://revu.tauware.de/details.py?upid=2004
<Yagisan> zakame: fixing b0rk fedora boxes in kiwi land
<nlindblad> afternoon masters
<zakame> Yagisan: whoa
<zakame> heya nlindblad
<nlindblad> zakame: how are you?
<Yagisan> zakame: it will make a good story when done. summary is box has routing issues, badly maintained, etc, and I needed to log in remotely to fix it. oh, and someone put a fax on the modem line.
<zakame> Yagisan: gaah, blog it! :D
<zakame> nlindblad: here contemplating on wheter bug 32280 could be fixed directly
<Ubugtu> malone bug 32280 in masqmail "Doens't start correctly" [Major,Fix released]  http://launchpad.net/bugs/32280
<nlindblad> zakame: okey
<Yagisan> Seveas: ok - searched through the bugs. Yes I say this needs a UVF exception to work correctly with 2.6.14+ kernels
<Yagisan> zakame: did I say it was fedora core 1 - it was like - ick. Configured obviously by someone new too.
<zakame> dholbach: thanks for checking (and uploading) 32280! :D
<Seveas> Yagisan, could you be so kind as to do this, I'm no motu myself (just triaging bugs)
* zakame hugs dholbach
<dholbach> zakame: no problem
* nlindblad hugs dholbach
<zakame> Yagisan: ick! blog extra too! :D
<jsgotangco> Yagisan: very nice....
<jsgotangco> so retro
<Yagisan> Seveas: actually - I'm not a motu either, but it's not too hard to do. I can issue it for you, but I need about 24hrs before I have the time free.
<nomed> i see it's the same for all the pkges that has a pkge.list file and a pkge.conffiles
<Yagisan> jsgotangco: well, no one asked if I was a Red Hat guy ...
<nomed> but what if during an upgrade the files listed in <pkge>.conffiles are different from older ones ?
<zakame> mhz_cook: what's cooking?
<Gloubiboulga> zakame, hello
<Gloubiboulga> zakame, do you have time for a review ?
<zakame> heya Gloubiboulga, wazup?
<zakame> Gloubiboulga: I'll try :D
<Gloubiboulga> thanks :)
<Gloubiboulga> it's gnetswitch : http://revu.tauware.de/details.py?upid=2007
* zakame checks
<Gloubiboulga> it needs netswitch to build, which is not in the archives yet
<jpatrick> Gloubiboulga: uploaded yesterday by moi, (package by Tonio_ )
<Tonio_> jpatrick: you uploaded gnetswitch yesterday ?
<jpatrick> Tonio_: no netswitch
<Tonio_> ah oki :)
<Tonio_> what about knetswitch ?
<Tonio_> raphink approved
<Tonio_> need a second one to upload :)
<jpatrick> I think raphink uploaded that
<Tonio_> nope he ust advocated
<jpatrick> hmm
<Tonio_> are there any other emergencies to revu ?
<Tonio_> I may have one hour of free time just now
<tepsipakki> tonio_: yes, please =)
<Tonio_> tepsipakki: url ?
<tepsipakki> ok, new versions of libnfsidmap, libgssapi, librpcsecgss: http://revu.tauware.de/details.py?upid=2005 http://revu.tauware.de/details.py?upid=2010 http://revu.tauware.de/details.py?upid=2008
<Tonio_> Gloubiboulga: what about gnetswitch ? has it been approved ?
<Gloubiboulga> Tonio_, dholbach approved it, and zakame is checking it
<jpatrick> Tonio_: I don't think he did (otherwise it would of have appeared at lp)
<tepsipakki> Tonio_: they should be pretty easy, and similar packages
<Tonio_> tepsipakki: why making usage of debhelper 4 ?
<Tonio_> just to know ;)
<Tonio_> Gloubiboulga: perfect, many thanks ;)
<Gloubiboulga> Tonio_, np, and thank you too :)
<Gloubiboulga> Tonio_, I think that Olivier should thank us ;)
<tepsipakki> Tonio_: in control? is it enough to depend on cdbs only?
<Tonio_> Gloubiboulga: hum, we should thank Olivier too hehe
<Tonio_> tepsipakki: yes, but well, it is nice to use the latest
<Tonio_> of course I will not give a NO for that reason :) I'm building it actually
<tepsipakki> Tonio_: the control-file is from upstream, but I made some changes to it
<tepsipakki> which were suggested
<Tonio_> oki ;)
<zakame> Gloubiboulga: src/main.c copyright notice needs to go to debian/copyright
<Gloubiboulga> zakame, which notice are you talking about?
<zakame> Gloubiboulga: from gnetswitch, the copyright snippet in src/main.c
* Gloubiboulga looks again
<dolson> Tonio_: you could review anything remaining from dana@ubuntustudio.com or forest@alittletooquiet.net, but I think most of them require the dssi-dev that isn't yet sync'd from debian
<Gloubiboulga> zakame, ok
<Gloubiboulga> it gpl v2 or later, not gpl v.2, right ?
<Tonio_> tepsipakki: libgssapi advocated
<zakame> yeah
<Gloubiboulga> zakame, do I update the FSF address in debian/copyright ?
<Gloubiboulga> do I need*
<Tonio_> dolson: well, already 3 packages to revu, and I have a look after, if I got time for this :)
<zakame> Gloubiboulga: quote directly from the source, even if the address is old
<Gloubiboulga> ok
<dolson> Tonio_: no prob. I just saw your message above, that's all :)
<zakame> Gloubiboulga: if it is, ping upstream about it, you don't have to make it your problem ;)
<Tonio_> Gloubiboulga: I did the change in knetswitch, you can use the same text maybe...
<tepsipakki> Tonio_: nice, thanks!
<Gloubiboulga> zakame, do you see other problems ?
<zakame> Gloubiboulga: attempting a build, hold on
<Gloubiboulga> ok :)
<zakame> Gloubiboulga: hmm debian/control , rather short description in contrast to what's on the webpage
<Tonio_> tepsipakki: http://revu.tauware.de/details.py?upid=2012
<zakame> Gloubiboulga: also, `Homepage' needs a nudge of one space, like ` Homepage:'
<Tonio_> sorry, I missed something, little improvement needed
<jpatrick> Tonio_: knetswitch advocated
<tepsipakki> Tonio_: yeah no problem, it was a mistake
<Tonio_> tepsipakki: correct this and I can advocate
<Tonio_> jpatrick: cool
<tepsipakki> Tonio_: I'll make the same changes to the other two as well..
<tepsipakki> copyright & compat
<Tonio_> hurg............ I have a problem with my proxy server..........
<Tonio_> I posted and I have the information on 2 pages ??????????
<Gloubiboulga> zakame, so I need 2 spaces in the debian/control file for the Homepage line?
<Tonio_> tepsipakki: http://revu.tauware.de/details.py?upid=2012 http://revu.tauware.de/details.py?upid=2005
<Tonio_> why is it uploaded twice ?
<Tonio_> damn ;)
<Tonio_> which one am I supposed to revu ?
<tepsipakki> the latest
<zakame> Gloubiboulga: yes
<tepsipakki> new one coming
<Tonio_> so the advocate is good finally..........;
<Tonio_> may I archive 2005 and keep 2012 ?
<tepsipakki> Tonio_: both of them are obsolete =)
<Tonio_> tepsipakki: yep, but when I post for one the comment appears on both revues.........;
<Tonio_> kind of bug....
<tepsipakki> ah, so it seems :)
<tepsipakki> http://revu.tauware.de/details.py?upid=2016
* Tonio_ is tired.........
* jpatrick has a headache
* tepsipakki gives Tonio_ a virtual cup of coffee
<jpatrick> hmm java...
<trappist> what to do about a bug that's been fixed for a long time but the bug report never got closed?
<jpatrick> malone #23018
<Ubugtu> malone bug 23018 in iptables "libipt_recent is not there" [Normal,Unconfirmed]  http://launchpad.net/bugs/23018
<trappist> yeah that one
<Tonio_> tepsipakki: hehe
<Tonio_> tepsipakki: second package advocated, nice, no problems found
<Tonio_> building the third one
<tepsipakki> cool
<Tonio_> tepsipakki: it is a pain to revu, cause they all depend each other.........
<Tonio_> ;)
<tepsipakki> hmm, yes, sorry :)
<Tonio_> tepsipakki: libnfsidmap-0.12 FTBFS........
<tepsipakki> argh
<tepsipakki> my pbuilder doesn't work so I couldn't test it myself.. but do you have a log somewhere?
<Tonio_> tepsipakki: yes, sending you the log
<tepsipakki> thankd
<tepsipakki> s/d/s/
<Tonio_> tepsipakki: anyway, this one isn't a NEW package.
<Tonio_> uploading it will require an uvf exception
<Tonio_> it is too late for this
<Tonio_> re dholbach
<Tonio_> dholbach: concerning uvf exceptions, will they stop today too, or is there another date ?
<tepsipakki> Tonio_: yes I know that, but it shouldn't be too late
<Tonio_> tepsipakki: building again and pasting you the buildlog
<tepsipakki> ok
<Tonio_> tepsipakki: http://ubuntu.pastebin.com/568686
<Tonio_> the build log
<tepsipakki> duh, it gave up pretty easily
<tepsipakki> I didn't build a binary myself before.. now it is fixed
<tepsipakki> I'll upload it shortly
<tepsipakki> one line too many in libnfsidmap-dev.install :/
<tepsipakki> http://revu.tauware.de/details.py?upid=2019
<tepsipakki> doesn't FTBFS anymore
<ArmeBosse> a revu admin can check why my package doesn't upload : vtigercrm
<crimsun> dholbach: sorry I missed your message yesterday; is it urgent?
<nomed> ok
<nomed> suposing i found an error (bug) within a <pkge>.install file ...
<nomed> what should i do ?
<nomed> should i just file a bug ...
<crimsun> file a bug, and attach a debdiff to the fixed version
<LaserJock> send a patch to the maintainer ;-)
<nomed> or can i even provide a patch for it ?
<nomed> LaserJock, perfect ..
<nomed> then
<nomed> what are the steps i should follow to provide the pacth ?
<nomed> is there any link that explain this ?
<tepsipakki> libgssapi and librpcsecgss needs another advocate =)
<LaserJock> nomed: file a bug, fix the package and do a debdiff on it and attach the debdiff to the bug report.
<nomed> LaserJock, k
<nomed> should i even run debchange ?
<crimsun> yes, it makes the application easier
<crimsun> otherwise we have to manually bump, etc.
<jpatrick> tepsipakki: be there asap
<tepsipakki> jpatrick: great, thanks
<nomed> now a new question ..
<nomed> i file a bug in launchpad
<nomed> i work on it
<nomed> i have a patch
<nomed> in launchpad that bug has a number
<nomed> and it seems i should even run debchange
<nomed> should i write even the bug number ?
<nomed> like #xxxx fixed
<crimsun> nomed: that's most helpful.
<tepsipakki> jpatrick: thanks for libgssapi ;)
<nomed> crimsun, k ...
<jpatrick> I suppose I'll upload
<crimsun> sigh, faculty meeting.
<tepsipakki> jpatrick: cool, did you look at librpcsecgss?
<jpatrick> tepsipakki: looks good, I'll upload both now
<tepsipakki> jpatrick: do you have access to main?-)
<jpatrick> It's main?
<tepsipakki> no, libnfsidmap is
<tepsipakki> so it's a new version
<jpatrick> No, I became motu recenty (last week)
<tepsipakki> heh, ok
<tepsipakki> but can you review it? someone else can then upload
<tepsipakki> it should be _perfect_ by now
<jpatrick> will do
<tepsipakki> awesome
<LaserJock> raphink: testing something or bad connection?
<jpatrick> tepsipakki: "dpkg-genchanges: warning: missing Section for source files"
<jpatrick> libgssapi
<tepsipakki> noooo..
<jpatrick> shall I add one quickly before upload?
<tepsipakki> yes please!
<jpatrick> which? :)
<tepsipakki> I have no idea
<tepsipakki> libs?
<jpatrick> ok, it's happy
<tepsipakki> the others have the same issue..
<jpatrick> [ uploaded ] 
<tepsipakki> phew
<tepsipakki> my ring finger is sore...
<tepsipakki> I should leave the keyboard for a day or two
<tepsipakki> jpatrick: I have to run now.. so thank you again ->
<jpatrick> ok, just doing librpcsecgss
<jpatrick> done
<Tonio_> Gloubiboulga: has gnetswitch finally been uploaded ?
<Gloubiboulga> nop
<Tonio_> is there a reason ?
<Tonio_> I see you have done many uploads
<Gloubiboulga> nop, zakame left without telling me the result of the build
<Tonio_> is it supposed to be clean ?
<Tonio_> ah ok.......;
<Gloubiboulga> Tonio_, yes, for minor things each time
<Gloubiboulga> I think it's ready to go now
<Tonio_> Gloubiboulga: ok, let me revu
<Gloubiboulga> ok :)
<Tonio_> hum........... I can't revu it ;)
<Tonio_> my own name on it hehe
<Gloubiboulga> yep, I didn't changed it
<Tonio_> I can't approve my own stuff....
<Tonio_> Gloubiboulga: can you find someone to revu ?
<Gloubiboulga> hum...
<Tonio_> once done I can upload it, but I can't reasonably revu something that has my name on it :)
<Gloubiboulga> any MOTU interested by a REVU? :)
* jpatrick is currently trying to fix a bug
<Gloubiboulga> raphink, ping?
<Tonio_> Gloubiboulga: aren't you a motu yourself ?
<Gloubiboulga> Tonio_, no
<Tonio_> hum
<Tonio_> we will find someone toonight :)
<Gloubiboulga> yes! :)
<nomed> umm .. ...
<nomed> how should i provide a patch for a pkge.install file ?
<nomed> should i simply attach a new file ?
<LaserJock> nomed: if your not up for changing the source package itself you could at least attach an new file. But a debdiff is the easiest for the person making the upload I would  think.
<nomed> LaserJock, debdiff doesn't show the diff in debian/pkge.install
<nomed> the one i modified ..
<LaserJock> no?
<LaserJock> it should
<nomed> LaserJock, it shows that there are new files installed ..
<nomed> but nothing about pkge.install file
<LaserJock> nomed: ok, what command did you use exactly?
<nomed> LaserJock, a simple debdiff pkge1.deb pkde2.deb
<nomed> but now i supose i shoudl add some options ?
<LaserJock> nomed: no, you need to debdiff the source package
<LaserJock> nomed: so debdiff pkge1.dsc pkge2.dsc
<nomed> k
<nomed> well .. it sounds  it has a logic :)
<nomed> i should get it by myself :)
<nomed> LaserJock, thanks for your availability
<LaserJock> nomed: np, just glad I can help :-)
<ViViD> good morning people
<jpatrick> evening ViViD
<ViViD> lol, its 10:30 A here
<LaserJock> hi ViViD, where you from?
<ViViD> west coast usa
<ViViD> -0800
<LaserJock> ViViD: cool, I'm in Reno, NV
<LaserJock> -0800 also
* jpatrick : Girona, Spain (+0100)
<ViViD> that must suck for saving money
<ViViD> im in seattle, wa
<LaserJock> ViViD: not really, seeing all the people pushing around carts cause they gambled their house and car away keeps me from the casinos mostly ;-)
<ViViD> do they still let you put real money into the slots there? here it sucks cuz you have to put in on a dumb ticket, takes most the fun out of it
<LaserJock> ViViD: no, you can do just about anything you want here when it comes to gambling.
<ViViD> or at least casino tokens, anything to make ching sounds when it drops into the tray
<ViViD> jpatrick: where are you that its evening?
<jpatrick> Girona, Spain
<LaserJock> ViViD: The state legislature just approved roaming gambling machines where you can wander around the casino with a handheld device ;-)
<ViViD> lol
<LaserJock> ViViD: but it's a terrible atmosphere. Smoky and dark. I get headaches pretty quick so I rarely go. I'm going to grad school so I don't have time or money to waste.
<ViViD> jpatrick: in spain, do you have to write C in english?
<jpatrick> ViViD: I am English (British to be precise)
<ViViD> well i guess its a language of its own heh
<ViViD> o cool
<ViViD> europe is really cool in how you can travel much shorter distances than in north america and experience vast differences in cultures and such
<ViViD> much easier to experiene "the world" from there
<ViViD> anyway, is anyone available to criticize my upload? i need to get this source packaging down so i can start uploading all my apps
<lionel_> ping raphink
<lionel_> Can somebody have a look on http://revu.tauware.de/details.py?upid=2021, i correct my package after raphlink comments
<lionel_> I'lle be back in fw minits (go home)
<ViViD> could someone look at http://revu.tauware.de/details.py?upid=2003 the package is finished, just need to make the the debian/ directory is set correctly
<Gloubiboulga> jpatrick, have you fixed your bug? :)
<Gloubiboulga> jpatrick, it you have a little moment to review gnetswitch, that would be very cool ;)
<ViViD> hmm, anyone know how i add new files to a source package, like i added foo to it, and it doesnt need to be compiled, but for make install, it needs to be moved to prefix/foo/bar...
<LaserJock> ViViD: I don't quite understand your question. You want to move a file after make install?
<jpatrick> Gloubiboulga: just have to upload fix - be right there
<Gloubiboulga> ok jpatrick
<Kyral> ...what change made the Evolution Junk Filter think everythng was junk?
<Kyral> and I am not kidding
<ViViD> LaserJock: yea, when the user performs make install, foo should be moved to prefix/foo/bar, but its just a text file, it doesnt need compiled or anything
<ViViD> actually, one is the app menu entry, and the other is a mime-type entry
<LaserJock> ViViD: are you using debhelper? in that case just use dh_install. if not you could just use install
<ViViD> yea but these files i just added in, and the install function doesnt move them
<ViViD> one should be in prefix=usr, /usr/share/applications and the other /usr/share/mime/packages
<ViViD> i guess i should just rebuid it
<LaserJock> ViViD: honestly, I'm totally lost by what you are saying. You want to move files from debian/ to wherever after make install right?
<ViViD> no, not from the debian dir, from the source directory that the debian directory is inside
<LaserJock> ViViD: ok, well then just use "install file destination" in debian/rules
<siretart> dholbach: did you already ping crimsun?
<ViViD> alright i got it thanks
<ViViD> now the package should be done, just need people to check my debian/ contents so i can fix it and get it advocated
<marcin`> hello MOTU's
<marcin`> I need some help with REVU
<marcin`> I cannot upload with dput
<marcin`> output says that there is error 553
<marcin`> Note: This problem might be caused by files already existent on the server.
<marcin`> 
<marcin`> could someone help me with this?
<marcin`> raphink: ping
<LaserJock> has anybody actually gotten freenx to work?
<raphink> marcin`: I'll remove the files from tiber
<raphink> then try to upload again
<marcin`> ok thanks
<raphink> marcin`: try and upload again now
<raphink> marcin`: did you talk with ArmeBosse ?
<jpatrick> Gloubiboulga: now I'm ready
<marcin`> yes
<raphink> good
<marcin`> raphink: yes we are on #vtiger-bounty
<raphink> ok I'm out
<raphink> talker people
<marcin`> raphink: he is away at the moment
<raphink> talker = talk later
<raphink> ;)
<jpatrick> au revoir raphink
<raphink> marcin`: ok try and find someone to review it, then I'll see it again tonight
<raphink> ciao jpatrick
<marcin`> raphink: I must say that I don't agree with few his changes.. but currently we want to put this package in dapper
<marcin`> raphink: so I'll live with these changes
<marcin`> raphink: so can I try to upload to revu again?
<raphink> good
<raphink> yes, try to upload now
<raphink> I'll stay around in case in fails again
<raphink> but then I'll leave
<raphink> please upload now marcin` I want to go out
<marcin`> 30 sek
<raphink> hmmpf
<jpatrick> :)
<marcin`> ok it's ok
<marcin`> raphink: sorry I had to remove some stupid line of code from rules....
<marcin`> raphink: I really we should talk about this package later...
<marcin`> raphink: but now upload goes to revu
<jpatrick> raphink: did you upload gnetswitch?
<raphink> jpatrick: yes I did
<jpatrick> ah, then my work is done
<jpatrick> ;-)
<raphink> marcin`: is it me or you're currently uploading a Debian native package?
<raphink> jpatrick: I'm sure there is more to upload before FF
<jpatrick> raphink: yep
<raphink> marcin`: you're uploading a tar.gz not a orig.tar.gz
<jpatrick> raphink: just been bug busting :)
<marcin`> raphink: I give up...
<raphink> marcin`: sorry?
<marcin`> raphink: I don't have time to fight with this now...
<raphink> hmmm
<raphink> you probably built the package without the orig.tar.gz in the parent dir
<raphink> it's very easy to fix
<marcin`> raphink: have no idea why there is tar.gz not orig.trg
<raphink> but vtiger won't get in as a Debian native
<raphink> cause it has no reason to be one
<marcin`> heh I downloaded this from ArmeBosse website
<raphink> wel most of the time the reason is that the orig.tar.gz is not present in the parent dir
<raphink> marcin`: armebosse had mistakenly made it a debian native
<raphink> you should have run debuild -S -sa
<raphink> before uploading
<marcin`> I did it
<Gloubiboulga> jpatrick, I'm ready too :)
<marcin`> I couldn't upload at all without -S -sa
<marcin`> raphink: so - what to do now?
<raphink> ok give me an ssh
<raphink> fast
<raphink> I want to go out with my friend
<marcin`> ssh?
<jpatrick> Gloubiboulga: raphink already uploaded so not much I can do
<jpatrick> Secure Shell
<raphink> and I don't want vtiger to waste my evening on stupid upload stuf
<raphink> marcin`: where is the package?
<raphink> I'll upload it
<raphink> marcin`: give me the website where it is
<marcin`> just a moment
<marcin`> ok ok
<marcin`> it will be on my website
<raphink> if you give me the url it might help
<marcin`> raphink: I'll upload to
<raphink> I need orig, diff.gz and dsc
<raphink> nothing else
<marcin`> raphink: http://194.114.146.58/vtiger
<marcin`> raphink: hmm there is already my old orig file...
<marcin`> raphink: it could help
<Gloubiboulga> jpatrick, ok, just saw it
<Gloubiboulga> raphink, merci :)
<marcin`> raphink: ok done
<marcin`> raphink: it's all there
<raphink> marcin`: done whazt??
<marcin`> package is on my website
<raphink> marcin`: you must be kidding
<marcin`> what?
<raphink> marcin`: where is the diff.gz ??
<jpatrick> :|
<raphink> oh nevermind
<raphink> I understood
<raphink> marcin`: nevermind I'll do it
<marcin`> I had to put new diff there
<raphink> yeah yeah nevermind
<raphink> don't worry
<raphink> but then you'll need to find two MOTUs to review
<raphink> since I'll be uploading it
<raphink> so I can't review it
<marcin`> to be honest I'm not sure if this package will be OK
<marcin`> but I'll try
<raphink> gets me crazy to have to make the diff again
<raphink> would take just 10 seconds to do it through ssh
<raphink> or vnc or whatever
<marcin`> sorry
* Gloubiboulga is off
<Gloubiboulga> bonne nuit
<raphink> I'm wondering if this is meant to be in dapper
<jpatrick> buenas noches...
<raphink> bn Gloubiboulga
<raphink> here we have two packagers, and none being able to turn debian-native package into a normal one
<marcin`> raphink: I'm really annoyed now...
<marcin`> raphink: please upload this package if you can
<raphink> marcin`: I'll tell you what I'm doing marcin`
<raphink> I'm getting the orig.tar.gz, the .dsc and the tar.gz
<raphink> then
<marcin`> raphink: but I'll upload my own package tomorrow
<raphink> marcin`: then you'll get your package in dapper+1 in 3 months
<raphink> marcin`: I think you didn't get that today is FF
<raphink> it is the _last_ day to get new packages in dapper
<raphink> tomorrow is too late
<marcin`> I know that
<marcin`> and this is why I accept ArmeBosse regressions today
<raphink> marcin`: ok here is what I'm doig
<raphink> just so you know
<raphink> I got the tar.gz and extracted it
<raphink> then I removed it
<raphink> then I got the orig.tar.gz
<marcin`> and propably these 2 MOTU's that has to review this package will say NO
<raphink> then I cd into the extracted dir
<raphink> and I run debuild -S -sa -kmykey
<marcin`> raphink: yeah I know what you did
<raphink> marcin`: then why didn't you do it?
<marcin`> raphink: you know that I uploaded correct packages earlier
<raphink> well not this time though
<marcin`> but now I ArmeBosse was working on this package
<ArmeBosse> here
<marcin`> and I just downloaded files from his website and did pbuild outside of my workspace
<marcin`> and I was in hurry so I forgot about this orig
<raphink> it's good to check other people's work before committing it
<raphink> ok
<raphink> it's up
<raphink> in 4 minutes it'll be available on REVU
<marcin`> and had no time to merge with my build tree
<marcin`> ok
<raphink> find MOTUs to review it
<ArmeBosse> i like "regression" term
<raphink> havea good evening :)
<jpatrick> raphink: we'll take over from here
<raphink> ciao
<marcin`> ArmeBosse: I don't have another term to name all we had to do with this package
<raphink> thanks jpatrick
<jpatrick> bye
<ArmeBosse> "changes"
<ArmeBosse> bye raphink
<marcin`> ArmeBosse: themes removed, you also added dh_link while we got script that does the same job in /etc/apache2/conf.d
<ArmeBosse> replyed in other chan already
<marcin`> ArmeBosse: I see
<ArmeBosse> so what you want again ?
<marcin`> nothing...
<marcin`> I'm just annoyed I want this package to be up and running
<marcin`> and I want to go and work on polish translation and custom modules
<marcin`> and I don't want to care about weird requirements from ajmitch_ or other MOTU's
<ArmeBosse> what's need to be polished ATM ?
<ArmeBosse> no more time yes
<marcin`> propably nothing
<marcin`> except that I know that sistpotty or propably other MOTU's could complain about copyright
<ArmeBosse> i must read back log bb
<marcin`> and propably about config.template.php in /etc/ too
<LaserJock_> marcin`: revu URL?
<ArmeBosse> we'll see
<ArmeBosse> i'm not agree with this point of view
<marcin`> LaserJock_: http://revu.tauware.de/details.py?upid=2026
<ArmeBosse> just wait MOTU review
<marcin`> ArmeBosse: sure
<marcin`> another thing is that I still don't understant how is possible to configure this package to use some 'random' theme
<marcin`> or 'random' language
<ArmeBosse> not package related ?
<ArmeBosse> "stupid line" i always like the terms you use and you collaborative point of view :)
<ArmeBosse> +r
<marcin`> well ajmitch_ complained a lot that this package has theme-blue as dependency and other themes as recommended
<marcin`> ArmeBosse: so he complained a lot but didn't said how is this possible to set
<marcin`> ArmeBosse: dependencies like: theme1 | theme2 | theme3
<ArmeBosse> well i'm waiting to talk with him
<marcin`> ArmeBosse: and then how user is supposed to choose between themes
<marcin`> ArmeBosse: while we really _need_ to have at least one theme
<LaserJock_> marcin`: at least one of them *has* to be installed
<marcin`> LaserJock_: but which one?
<LaserJock_> anyone
<LaserJock_> any one, I mean
<ArmeBosse> LaserJock_: there's no more package for theme
<marcin`> LaserJock_: it's not so easy - because it has then to be set in /etc/vtigercrm/config.inc.php
<ArmeBosse> there's only core with base theme
<marcin`> and this is regression for me
<marcin`> we had to give up and put all themes to single package
<LaserJock_> and you can't use debconf?
<ArmeBosse> and will introduce a debconf question to choose default theme
<marcin`> LaserJock_: sure I could - but tell me how?
<ArmeBosse> and it's not regression for me
<LaserJock_> marcin`: read debconf material
<marcin`> LaserJock_: I did
<marcin`> LaserJock_: tell me please one thing
<marcin`> LaserJock_: we got vtiger package and vtiger-theme1, v-theme2, v-theme3
<ArmeBosse> marcin`: if you don't know how to do it not a problem, i'll do it
<marcin`> LaserJock_: and we set in vtiger: Depends: v-theme1, v-theme2, v-theme3
<LaserJock_> marcin`: btw, I can see how the debian/copyright is going to be a mess but you do need to put the text of the licenses that aren't GPL, BSD, or LGPL
<marcin`> LaserJock_: then which one will be installed when user will do: apt-get install vtiger?
<marcin`> LaserJock_: tell this to ArmeBosse
<marcin`> LaserJock_: (about copyright)
<LaserJock_> marcin`: are you talking about v-theme1| vtheme-2| v-theme3 in Depends?
<ArmeBosse> collaborative :) lol
<ArmeBosse> LaserJock_: i prefer to wait for review of MOTU
<marcin`> ArmeBosse: yes we got perfect collaboration ;>
<marcin`> ArmeBosse: I added this license to copyright and you removed in next version
<LaserJock_> ArmeBosse: well, you can but you could also check the Debian Policy
<ArmeBosse> LaserJock_: if it's only this that can prevent vtiger to enter, we can have a consensus
<marcin`> ArmeBosse: so I don't care about this issue because it's not my fault
<ArmeBosse> for moment there's too many issues pending
<ArmeBosse> marcin`: i'm not here to count points, here waiting for MOTU review
<marcin`> LaserJock_: yes I'm talking about these dependencies
<marcin`> ArmeBosse: as I said - I don't care - LaserJock_ said about copyright to me but you are the author
<marcin`> ArmeBosse: so he should talk with you - EOT
<marcin`> LaserJock_: anyway forget about these issues now
<ArmeBosse> LaserJock_: have you got chapter in debian policy where i can refer to about copyright ?
<LaserJock_> ArmeBosse: yes just a sec, I've been dealing with this issue too lately
<ArmeBosse> k
<LaserJock_> ArmeBosse: http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
<marcin`> LaserJock_: so if we got 'Depends: theme1 | theme2 | theme3' then how user can choose which theme he want's to install and which one he wants to be default?
<ArmeBosse> thks
<ArmeBosse> marcin`: ok it's in debian policy so you can revert the copyright
<ArmeBosse> SPL copy i mean
<LaserJock_> marcin`: I'm not sure exactly. I don't think it will exactly do what you want. but any of those themes will satisfy the dependency. So the user could install theme2 and remove theme1 for instance
<LaserJock_> ArmeBosse: what about FPDF? freeware isn't a very descriptive license
<marcin`> LaserJock_: yes I know that but it's not enough to satisfy dependency
<ArmeBosse> i can't do more, author never set license
<LaserJock_> ArmeBosse: ugggh
<marcin`> LaserJock_: we also have to set $default_theme variable in config.inc.php
<ArmeBosse> freeware=do what you want
<LaserJock_> ArmeBosse: well, so perhaps Public Domain?
<marcin`> LaserJock_: but then we can for example have 10 themes and any could be default
<ArmeBosse> http://www.fpdf.org/?lang=en
<LaserJock_> marcin`: I think the first one might be the default or if you specify in an apt-get line
<ArmeBosse> http://www.fpdf.org/en/FAQ.php
<ArmeBosse> FPDF is Freeware (it is stated at the beginning of the source file). There is no usage restriction. You may embed it freely in your application (commercial or not), with or without modification. You may redistribute it, too.
<ArmeBosse> we can add this
<ArmeBosse> marcin`: you never can implement something like that, must regsister new theme, parse the file, show it in debconf
<ArmeBosse> many work
<LaserJock_> marcin`: seems like debconf would be much better but I've never used it so ...
<ArmeBosse> and in debian package i'll never do like that
<marcin`> yes it's pretty weird
<marcin`> but themes is one thing and we also have language packs that are simmilar issue
<LaserJock_> I guess I might be ignorant of debconf here but it doesn't seem like it would be that hard. Maybe I don't understand exactly what you're trying to do.
<ArmeBosse> not similar issue
<ArmeBosse> base theme and new added theme is not the same approach
<ArmeBosse> we must install package correctly, but user must select it in web app
<ArmeBosse> for base theme, we know them, so we can do like apache.conf
<ArmeBosse> marcin`: or in you need to parse themes dir
<ArmeBosse> must be a better approach
<marcin`> another thing is that I thought that Conflicts will save us from php5 issues
<marcin`> and after little talk with sistpotty he gave me this url: https://launchpad.net/distros/ubuntu/+source/ubuntu-meta/+bug/22335
<Ubugtu> malone bug 22335 in ubuntu-meta ubuntu-desktop "gnome-screensaver conflicts with ubuntu-desktop" [Normal,Fix released] 
<marcin`> and I had to remove this
<marcin`> so now nothing can save us if user will install php5...
<marcin`> anyway I need to do polish translation now
<ArmeBosse> conflicts with php5 is supposed to resolve which issue ?
<ArmeBosse> LaserJock_: you are a MOTU ?
<LaserJock_> hopfully soon will be in a week but not presently
<ArmeBosse> after reviewing the current package, only copyright blocks you ?
<ArmeBosse> any other people to review it ?
<LaserJock_> I just looked at the debian/copyright because marcin` had mentioned it. I didn't really look at the rest.
<ArmeBosse> k
<ArmeBosse> marcin`: can you upload a new package with SPL 1.1.2 inside ?
<ArmeBosse> marcin`: and remove copyright.txt and license_linux.txt from docs ?
<marcin`> 20 minutes
<TheMuso> Bye all. If you need me, please email me, themuso@themuso.com. Will be offline for the next couple of days.
<ArmeBosse> marcin`: ok, you probably need to remove the lines mentionning this toot
<ArmeBosse> -t
<marcin`> ArmeBosse: and I also can remove this dh_link right?
<ArmeBosse> yes
<ArmeBosse> i update svn on vtigerforge
<tepsipakki> hi, anyone available for a last check on http://revu.tauware.de/details.py?upid=2019 ?
<tepsipakki> noo, don't leave me :)
<ArmeBosse> marcin`: in the same idea, QPL 1.0 and MPL 1.1 must be added
<marcin`> mhm
<marcin`> few minutes please
<marcin`> I need to finish my meeting with customer
<sistpoty> hi folks
<sistpoty> are we in FeatureFreeze yet?
<tepsipakki> sistpoty: both libgssapi and librpcsecgss got uploaded :)
<sistpoty> congrats tepsipakki ;)
<tepsipakki> and thank you once again. I repackaged them, used cdbs this time
<sistpoty> you're welcome ;)
<dolson> crimsun: PAM patch completed by Kamion :D
<tepsipakki> sistpoty: there's still libnfsidmap, which should be easy (like those two earlier), so how about it?-)
<sistpoty> tepsipakki: ok, I'll take a look...
<tepsipakki> http://revu.tauware.de/details.py?upid=2019
<tepsipakki> the url
<ArmeBosse> marcin`: svn updated
<sistpoty> tepsipakki: oh, it's in main...
<sistpoty> tepsipakki: you'll need to ask s.o. with main privs...
<ViViD> can someone please look at http://revu.tauware.de/details.py?upid=2003 and http://revu.tauware.de/details.py?upid=2024 please
<ArmeBosse> sistpoty: http://revu.tauware.de/details.py?upid=2026 next in the queue please :)
<tepsipakki> sistpoty: yes.. Kamion said that too, but I don't know who to ask
<ViViD> if they need work leave a comment, im gonna go take a shower
<sistpoty> omg... queue is getting longer, and I'm online for just 5 minutes ;)
<ArmeBosse> hh FF frenzy
<tepsipakki> heh
<sistpoty> tepsipakki: ajmitch_, siretart, slomo, \sh_away, tseng, dholbach (just to give you some examples)
<tepsipakki> sistpoty: ok I'll start poking
<sistpoty> tepsipakki: maybe you could also ask s.o. in #ubuntu-devel... though I assume they're all quite busy
<tepsipakki> I bet..
<sistpoty> ViViD: please don't advocate your own uploads ;)
<ArmeBosse> sistpoty: so no time to review vtigercrm again ?
<marcin`> ArmeBosse: where are QPL and MPL licenses?
<sistpoty> ArmeBosse: it's in the queue ;)
<marcin`> ArmeBosse: are there in vtiger sources somewhere?
<ArmeBosse> yes a second
<ArmeBosse> jpgraph/QPL.txt
<ArmeBosse> http://www.mozilla.org/MPL/MPL-1.1.txt
<ArmeBosse> in the template : $root_directory = '/usr/share/vtigercrm/';
<marcin`> ok right
<ArmeBosse> in docs, like your package INSTALLATION.txt and README.txt
<marcin`> yes I know
<ArmeBosse> i missed to remove 1 file in svn , why i repeat
<marcin`> I also wonder if is there any way to force apache to use php4 with apache.conf
<ArmeBosse> don't know
<sistpoty> ArmeBosse, marcin`: can't you check for a module?
<sistpoty> for the presence of a module even
<ArmeBosse> sistpoty: seems difficult to do for all webserver
<ArmeBosse> for apache 2 we can look mods-enabled dir
<ArmeBosse> if you look "advanced" webapps, they don't go so far
<ArmeBosse> my current example is gforge
<sistpoty> ArmeBosse: what I'm still wondering is, why it won't work with php5 installed (if php4 is present as well)
<sistpoty> ArmeBosse: is it using cgi or s.th. like modphp?
<ArmeBosse> sistpoty: conflicts with php5 is supposed to resolve which issue ?
<ArmeBosse> sistpoty: i don't know myself
<ArmeBosse> just vtiger doesn work with php5, only php4 is supported
<sistpoty> ArmeBosse: if it uses s.th. like mod-php, I guess the config-piece of apache could be tweaked to force use of php4 or display an error message if it's not enabled
<sistpoty> ArmeBosse: if it uses cgi, I guess you could replace the interpreter name with hardcoded php4 for the files. not quite sure if this works though (don't know exactly how cgi-scripts are executed by apache)
<ArmeBosse> we can use a2en
<marcin`> anyway we got an hour and we don't have any MOTU wwhat could review this
<ArmeBosse> the main problem :(
<marcin`> ArmeBosse: I'm just uploading new version with chages in copyright and rules
<ArmeBosse> k
<ArmeBosse> sistpoty: this can probably wait next release ?
<ArmeBosse> we've got a working package, and a tweakable on that can be more reliable later
<sistpoty> ArmeBosse: yes (but you shouldn't have a conflicts: php5 in the control, as discussed last night)
<ArmeBosse> it' removed :)
<sistpoty> :)
<ArmeBosse> last package seems ok for me ;)
<ArmeBosse> but i'm not motu :)
<sistpoty> phew... reviewing this beast will be fun... I guess I'll need an hour or so for it ;)
<ArmeBosse> just works(tm) ;)
<ArmeBosse> any webapps guru in motu ? maybe you ?
* sistpoty isn't really a guru, only some (limited) experience till now
<ArmeBosse> reviewers : http://revu.tauware.de/details.py?upid=2027
<ArmeBosse> marcin`: you reintroduced typo mistake
<ArmeBosse> marcin`: what did you use ? patch ?
<ArmeBosse> what's this ???
<ArmeBosse> you re introduced your embedded template ?
<ArmeBosse> ok so you revert my changes ...
<marcin`> holy crap
<marcin`> sorry
<marcin`> I had to use my build tree
<marcin`> to make revu upload
<marcin`> because your package is debian native
<ArmeBosse> orig.tar.gz is debian native ?
<marcin`> and I changed things in copyright but forgot about these one
<marcin`> there is no orig.tar.gz ob your webpage
<ArmeBosse> how did you do previous upload then ?
<marcin`> http://revu.tauware.de/details.py?upid=2026
<marcin`> take a look at last comment from raphink
<marcin`> he had to download this and upload again as ubuntu package
<ArmeBosse> http://fboudra.free.fr/debian/vtigercrm/vtigercrm_4.2.3.orig.tar.gz
<marcin`> heh too late :)
<ArmeBosse> hehe good liar :)
<marcin`> no really it wasn't there
<ArmeBosse> you can tell me
<ArmeBosse> before upload
<marcin`> anyway it doesn't matter
<ArmeBosse> it does matter
<marcin`> is any MOTU reviewing this ?
<marcin`> I could do another upload now
<marcin`> but not sure if there is anyone working on this
<ArmeBosse> i want previous package with the fix
<ArmeBosse> svn is sync
<ArmeBosse> just copyright not updated
<sistpoty> ViViD: libpar2 reviewed... please look at the comments and ask if s.th. is unclear
<marcin`> svn on vtigerforge?
<ArmeBosse> yes
<marcin`> btw I'm sorry but tell me again how to hell can I upload my files there?
<marcin`> to polish-lang project...
<ArmeBosse> admin interface of you project
<ArmeBosse> r
<marcin`> (I know you already did but I don't have irc log on)
<marcin`> ok and then?
#ubuntu-motu 2006-03-01
<sistpoty> marcin`, ArmeBosse: 2027 is the right one to review?
<marcin`> sistpoty: currently yes
<ArmeBosse> no it's not the right one*
<sistpoty> marcin`: what do you mean w. currently? another upload pending?
<marcin`> ArmeBosse: do you really want your config.template.php ?
<marcin`> sistpoty: just a moment
<sistpoty> marcin`: sure
<ArmeBosse> there's probably 2 different package from 2 people if we continue
* sistpoty gets a break and is out for a smoke
<marcin`> ArmeBosse: is there something else different than this postinst script?
<ArmeBosse> oh yes, i can send you a diff
<marcin`> ok
<ArmeBosse> there's 16 files changed from previous upload
<ArmeBosse> no 13
<marcin`> ?
<marcin`> no way...
<marcin`> you count these removed files that are related with 'themes' ?
<ajmitch_> morning all
<ArmeBosse> just a diff and count how many files
<marcin`> ArmeBosse: I ask about difference between package on your website
<marcin`> ArmeBosse: and this one that is currently in revu
<ArmeBosse> i talk about previous upload
<ArmeBosse> ajmitch_: hi
<marcin`> ArmeBosse: I got /debian directory from your current package
<ArmeBosse> svn is the real one synced
<marcin`> heh need to learn svn
<LaserJock> hi ajmitch_
<marcin`> can you tell me how to checkout this now?
<ArmeBosse> just read the page
<marcin`> ajmitch_: hello
<ArmeBosse> http://vtigerforge.fosslabs.com/scm/?group_id=20
<marcin`> ok got it
<marcin`> just a sec
<marcin`> anyway I think that sistpoty could take a look on vtiger now
<marcin`> time is running
<marcin`> and I'm almost sure that the only thing that could be different is this postinst script
<tepsipakki> ajmitch: I was told that you have main privs? Do you have time to look at libnfsidmap? Simple task ;)
<ArmeBosse> marcin`: you're wrong
<ajmitch_> tepsipakki: yes I do have upload privileges, no I don't have time
<marcin`> ArmeBosse: my password doesn't work
<ArmeBosse> http://revu.tauware.de/diff.py?upid1=2026&upid2=2027
<marcin`> ArmeBosse: need to checkout anonymous
<ArmeBosse> if you don't know your pass, you can't put polish lang
<tepsipakki> ajmitch: ok, np
<sistpoty> tepsipakki: btw.: is this a new upstream version?
<ArmeBosse> marcin`: http://revu.tauware.de/diff.py?upid1=2026&upid2=2027
<marcin`> ArmeBosse: I can log to polish lang as admin
<marcin`> ArmeBosse: and I know my password but this pass doesn;t work with svn for ubuntu package
<ArmeBosse> same pass
<ArmeBosse> use 3 times
<tepsipakki> sistpoty: yes
<ArmeBosse> same pass
<ArmeBosse> like alioth
<marcin`> shit... I also forgot about header in 'copyright'
<sistpoty> tepsipakki: you'll need to request an UVF-exception as well (just in case you haven't done so yet)
<ArmeBosse> UVF exception ?
<tepsipakki> sistpoty: done already
<sistpoty> good
<marcin`> ArmeBosse: no 'package was debianized by..." and my credentials
<marcin`> ArmeBosse: I added these additional licenses but forgot to change header
<sistpoty> ArmeBosse: UpstreamVersionFreeze was some time ago, that means new upstream version for existing packages need prior approval
<ArmeBosse> k
<ArmeBosse> marcin`: you don't seem to look same diff file
<marcin`> I look on this *2027
<marcin`> we need to synchronize in 100%
<marcin`> I'll be ready
<marcin`> in 10 minutes
<marcin`> sistpoty: are you here?
<sistpoty> marcin`: yes
<marcin`> sistpoty: short question
<marcin`> sistpoty: we need to synchronize some changes but I also got more general question
<sistpoty> go ahead then ;)
<marcin`> sistpoty: we have some not so important differences between ArmeBosse repo and mine
<marcin`> sistpoty: but there is one important thing
<marcin`> sistpoty: in vtigercrm-mysql-local we need to create /etc/vtigercrm/config.inc.php file
<marcin`> sistpoty: we do this in *.postinst script but in different way
<ArmeBosse> i'll bet and win ;)
<marcin`> sistpoty: ArmeBosse has debian/config.template.php file
<marcin`> sistpoty: and he want's to install this file in /etc/vtigercrm/
<marcin`> sistpoty: from 'rules' script
<ArmeBosse> he can look previous package
<marcin`> sistpoty: and then use this template to as input to generate /etc/vtigercrm/config.inc.php
<ArmeBosse> http://revu.tauware.de/details.py?upid=2026
<marcin`> sistpoty: hmm I'm lost now maybe previous...
<marcin`> ArmeBosse: right
<marcin`> sistpoty: so there you can take a look at ArmeBosse way
<marcin`> sistpoty: and in current  http://revu.tauware.de/details.py?upid=2027
<marcin`> sistpoty: you can take a look at my way in .postinst
<sistpoty> phew... before I take a look... just a questions, maybe it solves the issue
<marcin`> sistpoty: I create config.template.php on the fly with mktmp and it goes to /tmp
<marcin`> sistpoty: and then I use this file as input for postinst - and remove on the end
<marcin`> sistpoty: question is - which solution is better
<sistpoty> marcin`, ArmeBosse: if you install that file under /etc... is creating the actual config from it repeatable (as in calling a command and get a config from it)?
<marcin`> sistpoty: will you complain on ArmeBosse way?
<ArmeBosse> repeatable yes via dpkg-reconfigure
<sistpoty> only config-files should actually go to /etc/... if the template doesn't fulfill the meaning of a config-file, it shouldn't be there
<ArmeBosse> rule / debian policy to refer to please ?
<sistpoty> but in the case, that an admin has the possibility to change the template and easily create a new (actual) config-file from it, it sounds like a good solution to me
<sistpoty> ArmeBosse: probably in fhs... or in debian-policy where it says about config-files... would need to look myself
<ArmeBosse> my point of view:
<ArmeBosse> for me it must be readable and maintainable
<marcin`> ArmeBosse: heh and I missed README.Debian... need to change my build scripts...
<ArmeBosse> a postinst is postinst and not a template
<ArmeBosse> marcin`: you missed many things
<marcin`> ArmeBosse: but user should not maintain *.template.inc
<ArmeBosse> if i need to change the template i don't want to touch postinst file
<ArmeBosse> from my point a view a non sense
<ArmeBosse> user no, user don't touche /etc
<marcin`> ArmeBosse: the thing is that user shouldn't touch template.php at all
<ArmeBosse> admin yes
<marcin`> ArmeBosse: ok - not user - admin
<marcin`> ArmeBosse: but if admin - then stil he should touch config.inc.php - not template.php
<ArmeBosse> i want to use dbconfig facility
<sistpoty> ArmeBosse: neither fsh nor debian-policy seem to provide exhaustive information on this
<ArmeBosse> yes in general, it's to admin point of view
<sistpoty> only thing in fhs is: /etc contains configuration files and directories that are specific to the current system.
<sistpoty> so the question is: is this used to configure s.th. or just a template, which an admin can use as *template* to write his config-file from
<marcin`> sistpoty: it's just template
<ArmeBosse> not for me :)
<ArmeBosse> hehe
<marcin`> sistpoty: but in fact it's not for admin - postinst uses this file as input to generate config.php
<sistpoty> ok, ArmeBosse, with your solution I could dpkg-reconfigure and would have a new config-file, right?
<ArmeBosse> anyway i'll keep it like this in debian package as we can't find consensus
<ArmeBosse> yes
<sistpoty> ok... then to marcin`'s solution
<marcin`> sistpoty: yes with his solution you end with two files in /etc/vtiger
<marcin`> sistpoty: with /etc/vtigercrm/config.inc.php and config.template.php
<sistpoty> marcin`: you create the actual config on the fly in postinst, right?
<marcin`> sistpoty: right
<sistpoty> marcin`: so you don't need another file... but what happens if the user changed the config-file himself?
<marcin`> in fact out solution are simmilar
<sistpoty> marcin`: will it get overwritten?
<sistpoty> (on upgrading for example=
<marcin`> hmm propably dpkg will ask if it should be overwritten or not
<ArmeBosse> lol
<sistpoty> marcin`: so you have the config-file itself *inside* the package and modify it during postinst?
<marcin`> sistpoty: yes because we need to put some info about database there
<marcin`> sistpoty: ArmeBosse solution does the same thing with the same tool
<marcin`> sistpoty: the only difference is that he puts his template file to /etc/vtigercrm
<marcin`> sistpoty: and it stays there
<sistpoty> marcin`: that's wrong... you cannot modify a file during postinst, that's a conffile inside the package (and this is part of the policy)
<marcin`> sistpoty: after installation
<marcin`> sistpoty: while I put my file in /tmp and remove after postinst will create /etc/vtigercrm/config.php
<ArmeBosse> config.inc.php
<marcin`> yes config.inc.php
<sistpoty> marcin`: so /etc/vtigercrm/config.php is *not* part of the package?
<marcin`> no
<sistpoty> ok
<marcin`> as I said - our solutions are almost identidal
<ArmeBosse> of source package you mean ?
<sistpoty> marcin`: but the issue still remains: what if an admin changes /etc/vtigercrm/config.php... will it get overwritten (e.g. on upgrade) or not?
<marcin`> sistpoty: it will if admin will let to do this
<marcin`> sistpoty: I don't understand this question
<marcin`> sistpoty: if you got some file in etc and you change this file then postinst will ask you what to do with config - keep/overwrite/show diff
<marcin`> sistpoty: right?
<marcin`> sistpoty: thing is you got two solutions:
<sistpoty> marcin`: if it's a conffile (i.e. *inside* the package) dpkg will do it for you
<sistpoty> marcin`: if it's created during postinst, you'll need to make this sure for yourself
<marcin`> sistpoty: 1. install debian/template.php to /etc/vtiger/template.php -> run postinst and use template.php to create /etc/vtiger/config.php
<ArmeBosse> using dbconfig-common
<ArmeBosse> 1 is me ;)
<marcin`> sistpoty: 2. create temporary template in tmp/template.php -> run postinst and use tmp/template.php to create /etc/vtiger/config.php -> clean tmp/template.php
<sistpoty> marcin`, ArmeBosse: there is no such thing as "the right way" for it...
<marcin`> we both use the same script to generate config.inc.php but different sources
<sistpoty> marcin`: with 2. you'll need to ensure that admin-changes aren't lost (for 1. as well, but it's not so bad, if the created file get's overwritten imo)
<marcin`> and the only one 'visible' difference is that ArmeBosse keeps his template.php in /etc and I clean it
<ArmeBosse> sistpoty: i know just we're not agree between us ;)
<sistpoty> hehe
<ArmeBosse> dismissed !!!
<ArmeBosse> like MTV program
<sistpoty> imo, 1. is s.th. that's more handy for an site-admin, since he can always change the template and regenerate the config-file from it
<marcin`> ArmeBosse: well the thing is that it's not the problem for me how this config.php is createt
<marcin`> created
<marcin`> ArmeBosse: I like this template.php too
<ArmeBosse> so wher's the problem ?
<marcin`> ArmeBosse: but I think that we should clean this file from /etc
<sistpoty> so I would personally go for 1.... but as stated before, there is "right"/"wrong" way for both of it
<marcin`> ArmeBosse: in my opinion in /etc/ should be only 'real' config not template+config
<ArmeBosse> sistpoty: an other think, i'm also upstream and debian maintainer, and keep this like that. just ubuntu package is "collaborative", so fork the solution or not
<marcin`> ArmeBosse: unfortunately dbconfig-common script apparently doesn't support relative paths so we need to put this template file somewhere
<sistpoty> marcin`: exim4 does it (similar) to ArmeBosse's solution... you have /etc/exim4/update-exim4.conf.conf and /etc/exim4/exim4.conf.template, and can call a script to generate the actual configuration files from it
<sistpoty> marcin`: imo a template from which a config-file can be created is a config-file as well
<sistpoty> but anyways... I stated what thing I'd prefer... both seem "right" as long as they respect 10.7 from debian-policy
<marcin`> okidoki
<marcin`> it will be ArmeBosse's solution in package
<ArmeBosse> an issue resolved
<marcin`> need to copy these differences carefully
<ArmeBosse> alleluia
<marcin`> ArmeBosse: :)
<sistpoty> hehe... luckily you didn't disagree on wether to use cdbs or debhelper *g*
<marcin`> ArmeBosse: and we are sure that sistpoty will accept this postinst ;)
<ArmeBosse> must ajmitch_ turn ;)
<ajmitch_> ?
<ArmeBosse> sistpoty: my original package was debhelper :)
<ArmeBosse> theme issue :)
<marcin`> sistpoty: cdbs was my part
<ArmeBosse> you don't know yet ?
<sistpoty> d'oh *g*
<ArmeBosse>  :)
<ArmeBosse> ajmitch_: you seems busy, don't know if we can disturb you
* ajmitch_ is busy
<ArmeBosse> hehe
* sistpoty is out for another cigarette... brb
<marcin`> ArmeBosse: ok I will start to upload in 5 minutes
<ArmeBosse> ok
<ArmeBosse> how many diffs ?
<marcin`> hmm few
<marcin`> copyright
<ArmeBosse> than svn
<ArmeBosse> or 2027
<marcin`> svn
<marcin`> copyright, rules, config.template.php - I think that's all
<ArmeBosse> have you commit your changes ?
<marcin`> not yet
<ArmeBosse> k
<marcin`> btw my svn doesn't work...
<ArmeBosse> lang you mean ?
<marcin`> I mean developer svn with my password
<marcin`> no - ubuntu package
<ArmeBosse> 3 times same password like alioth
<marcin`> ArmeBosse: lang too
<marcin`> ArmeBosse: aaah so I need to put my password 3 times :) ?
<marcin`> cool - good to know ;)
<ArmeBosse> yes :)
<raphink> key pairs are useful for such things sometimes ;)
<raphink> in order to NOT put your password, 3 times
<ArmeBosse> also
<ajmitch_> or just having a non-broken setup
<raphink> mhm
<sistpoty> hey raphink
<raphink> hi sistpoty
<raphink> I'm just passing through
<LaserJock> ajmitch_: ? having to put in your password 3 times is a broken setup?
<raphink> about to go to bed and ready through the REVU2 spec and classes ;)
<sistpoty> raphink: great news :)
<sistpoty> hi LaserJock
<raphink> :)
<ArmeBosse> ajmitch_: gforge issue no ?
<ajmitch_> LaserJock: if it's entering the same password 3 times in a row, then something is wrong
<ajmitch_> ArmeBosse: probably
<raphink> Hi Laserjock <><
<dholbach> good night
<sistpoty> gn8 dholbach
<ajmitch_> night dholbach
<LaserJock> hi sistpoty
<raphink> hi dholbach
<LaserJock> bye dholbach
<ArmeBosse> bye dholbach
<dholbach> night guys - you rock!
<LaserJock> hi raphink <><
<raphink> :)
<LaserJock> ajmitch_: well, on svn.debian.org I have to do it at least twice because of ssh and svn
<raphink> huhu
<LaserJock> I thought that was common for svn+ssh
<ArmeBosse> common with gforge
<ArmeBosse> 3 or 4 ;) and probably 5
<LaserJock> hmm, that seems a bit excessive
<sistpoty> hi ogra
<raphink> hi ogra
<ogra> hey
<raphink> :)=
<marcin`> ArmeBosse: vtigercrm goes to revu
* raphink loves the #ubuntu-motu chan
<raphink> it's a nice place to be :)
<ArmeBosse> raphink: revu tools are available on dapper ? or i must add universe repo ?
<raphink> ArmeBosse: it's available in dapper universe
<ajmitch_> hello ogra
<raphink> and you probably have to edit /usr/bin/revu-build and change PBUILDERNAME to "sudo pbuilder"
<ajmitch_> raphink: have you documented revu-tools?
<raphink> ajmitch_: yes, on the wiki
<ajmitch_> raphink: I mean in the package
<ajmitch_> since people can use it offline
<raphink> ajmitch_: https://wiki.ubuntu.com/MOTU/Packages/REVU/REVU-Tools
<raphink> ajmitch_: oooh
<raphink> ajmitch_: well there are short help messages with --help
<ajmitch_> raphink: since every binary/script must have a man page, right? ;)
<raphink> and manuals
<raphink> :)
<ajmitch_> and it wouldn't have been advocated without them, right?
<raphink> man revu-{report, build, orig}
<raphink> sure ;)
<ajmitch_> so is all the info on the wiki in the package?
<raphink> revu-review doesn't have a manpage yet though. I forgot to make one, I will add it in 0.6
<raphink> not all of them no
<raphink> the manpages are a bit more concise
<sistpoty> ajmitch_: well, we weren't that strict on one or two missing manpages lately ;)
<raphink> but they explain how to use the commands
<raphink> sistpoty: I'm usually strict on manpages ;)
<raphink> so I am to be with myself, too
<sistpoty> raphink: I'm usually as well, though I did some uploads the last days w. missing manpages (if this was the only problem)
<raphink> ajmitch_: you can have a look at the man pages for revu-{build,orig,report}
<ajmitch_> sistpoty: it depends on how far we allow standards to slip :)
<raphink> sistpoty: hehe
<raphink> we want the best stuff in
<sistpoty> well, I guess I'll file bugs on the packages that are passed the new-queue... then we can see if the maintainer actually cares ;)
<ajmitch_> sistpoty: sure, including some of mine ;)
<sistpoty> I didn't upload packages from you ajmitch_ ;)
<sistpoty> oh... gmult is ready to go (but needs another advocacy)... http://revu.tauware.de/details.py?upid=2001
<ajmitch_> I still have to fix up a number of bugs
<raphink> ajmitch_: e.g. http://raphink.net/debian/mans/revu-report.html
<raphink> ajmitch_: do you think that's clear enough?
<ajmitch_> raphink: maybe
<raphink> maybe ;)
<raphink> lol
<raphink> ok
<ArmeBosse> marcin`: something strange orig.tar.gz changed
<ArmeBosse> config.php typo problem
<LaserJock> heah, can a REVU admin nuke gaussum?
<marcin`> config.php where?
<raphink> LaserJock: sure, why?
<ArmeBosse> copyright line 1 no mail
<ArmeBosse> which we provide
<raphink> LaserJock: why should it be nuked?
<LaserJock> raphink: I took the ITP over and got it into Debian and it is in the sync queue right now so that upload is obsolete
<ArmeBosse> vtiger-crm in comments
<raphink> LaserJock: ok
<ArmeBosse> dirs no / needed at the en of path
<ArmeBosse> rules: find $(WEBAPPDIR) -name "*.jpg" -perm /a+x -exec chmod a-x {} \;
<LaserJock> raphink: that's the second email you sent :-)
<ArmeBosse> no lintian warning about jpg ?
<marcin`> dont know need to build it
<ajmitch_> LaserJock: becoming a high-flying debian maintainer now, are we? :)
<LaserJock> ajmitch_: heck yeah ;-)
<ajmitch_> LaserJock: it pays well?
<ArmeBosse> re add version comment in sql file please
<LaserJock> ajmitch_: actually it was much easier than I thought it would be. Especially for the package that I put on REVU and got uploaded to Universe first
<LaserJock> ajmitch_: It took a whole 2 days to get somebody to upload it to NEW
<ajmitch_> that's pretty good
<ajmitch_> depends on the sponsor, though
<ajmitch_> some of us can be pretty slack
<LaserJock> ChrisH
<ajmitch_> right
<ArmeBosse> (2006 key) in your name is not needed
<LaserJock> but with gausssum I took over the ITP for the guy and had to do some tweaking so it took a bit longer. So now I have 2 packages in Debian which I think is pretty awesome.
<sistpoty> LaserJock: yes... I've got only two packages in ubuntu so far ;)
<LaserJock> well, for the most part I really try to aviod packaging new programs from scratch. I feel like Universe needs enough work  that I shouldn't spend all my time packaging new stuff.
<LaserJock> but I appreciate those who do
<raphink> LaserJock: the second email I sent ??
<ArmeBosse> marcin`: i confirm there's a change in orig.tar.gz
<raphink> what are you talking about LaserJock ?
<LaserJock> raphink: yeah, on the 15th you had an almost identical comment  on gausssum
<raphink> LaserJock: really?
<LaserJock> yeah
<raphink> oh yeah right
<ajmitch_> raphink: explain this..
<ajmitch_> * Keep only one entry in debian/changelog till this package is released officially.
<raphink> well I guess that shows it's just me ;)
<raphink> ajmitch_: well there's no need to talk about the new upstream version since it was never released in Ubuntu yet
<raphink> ajmitch_: so only 5.3 should be listed in the changelog imo
<ajmitch_> raphink: so? it's still fine to leave in that info
<raphink> 5.2 having only been produced on revu
<ajmitch_> raphink: I'm just going to have to disagree with you
<raphink> ajmitch_: not what I was told by other MOTUs when I was reviewed in the past ;)
<raphink> ajmitch_: sure you can disagree :)
<marcin`> ArmeBosse: I'm not sure if I'll be able to sign this package if I'll remove (2006 key)
<raphink> and I'm fine with having your point
<ajmitch_> raphink: sure, but I can still think you're wrong :)
<LaserJock> hmm, I can see including previous upstream releases but I think it is nice if it doesn't go in a 0ubuntu30 or something
<raphink> ajmitch_: some months ago, I was explained that it was better to only keep the entries for official releases in the changelog
<ArmeBosse> marcin`: don't know too
<raphink> so users don't begin to search for the other versions in the archives
<raphink> if they were never released
<ajmitch_> how many users would know to look in a changelog & try & hunt down other versions?
<ajmitch_> it's not exactly going to be a common activity
<raphink> ajmitch_: the point being that when I see a 0ubuntu5 in Ubuntu I expect there was a 0ubuntu{1-4} released before
<ajmitch_> especially as released versions get removed from the archive as well
<raphink> ajmitch_: I would
<ajmitch_> s/released/uploaded/
<raphink> developers would
<raphink> and it's pretty useful to have reliable versionning for this reason
* ajmitch_ sighs
<raphink> hehe
<raphink> when I'm hunting for bugs for example
<raphink> and I see ina  changelog `unstable`
<ajmitch_> working in MOTU just isn't fun like it used to be
<raphink> I try to find tracks of the package in Debian
<raphink> which seems logical
<ajmitch_> raphink: if there were multiple versions uploaded to dapper, only 1 will still be there
<ajmitch_> so you can't search through that history
<raphink> unless someone released it as part of `unstable` unofficially, and there's no way to know where
<raphink> ajmitch_: sure on LP I can
<LaserJock> raphink: I can understand your point but you sacrifice having a true change log
<ajmitch_> if someone uploaded it to unstable, then it will be removed on a newer upload
<raphink> and on changelogs.ubuntu.com too
<raphink> thankfully
<ajmitch_> raphink: that package is still *gone*
<raphink> LaserJock: depends how you see it'
<ajmitch_> removing info just because you like a cleaner changelog is still wrong, imho
<raphink> not just because I like cleaner changelog ajmitch_
<raphink> but because a prerelease change is not a real change for users
<ajmitch_> I don't know why I bother
* ajmitch_ goes back to work 
<raphink> ajmitch_: hehe ;)
<sistpoty> actually I second ajmitch_'s opinion...
<raphink> ajmitch_: don't get me wrong I get your point
<LaserJock> maybe we should have an Ubuntu vacation when Dapper is released :-)
<raphink> :)
<sistpoty> though I don't think we should encourage ppl. to do a new version *only* for revu
<raphink> LaserJock: hehe
<sistpoty> (or rather disencourage them)
<ajmitch_> LaserJock: I'm having a long-term ubuntu vacation at the moment
<ajmitch_> LaserJock: and I've got no real incentive to finish it
<LaserJock> ajmitch_: how long? still in AU
<ajmitch_> LaserJock: yes I'm still in .au, and I'll probably keep away from MOTU after that as well
<iiping> lo guys can u tell me what ui can use gstreamer
<raphink> iiping: what ui?
<LaserJock> ajmitch_: well, we will miss you, but I can understand.
<iiping> like totem or kaffeine? other ui
<raphink> ajmitch_: after what?
<LaserJock> iiping: you seem to know already ;-)
<ArmeBosse> marcin`: in 5 minutes i'll go sleeping, if you can put a last package
<ajmitch_> raphink: after I get back to NZ
<sistpoty> marcin`, ArmeBosse: why is there a strict dependency on php4? doesn't vtigercrm work with libapache[2] -mod-php4 as well?
<raphink> ajmitch_: hmm ok although I guess there's a reason
<iiping> is there other alternative ui for gstreamer. i am having problem with totem and kaffeine on the sub title options
<ajmitch_> sistpoty: php4 depends on libapache2-mod-php4 | libapache-mod-php4
<ajmitch_> | hph4-cgi
<LaserJock> iiping: you should probably try #ubuntu, this isn't a support channel.
<sistpoty> ajmitch_: but libapache-mod-php4 doesn't depend on php4
<iiping> ok
<marcin`> ArmeBosse: I confirm that orig could change
<marcin`> ArmeBosse: and it's ok
<marcin`> ArmeBosse: next upload will go to revu in 3 min.
<sistpoty> ajmitch_: ah, got it... it's a meta-package... thought this was the cli
<ArmeBosse> could or have changed ?
<ajmitch_> sistpoty: circular dependencies are bad :)
<marcin`> ArmeBosse: this was because as I said - there was no orig.tar.gz on your website
<sistpoty> ajmitch_: indeed
<marcin`> ArmeBosse: and raphink did one from tar.gz
<marcin`> ArmeBosse: so it could be different
<ArmeBosse> i already gives you right url in debian dir
<marcin`> ?
<ArmeBosse> and you must justified why there's a diff with upstream source archive
<ArmeBosse> 23:56 < ArmeBosse> http://fboudra.free.fr/debian/vtigercrm/vtigercrm_4.2.3.orig.tar.gz
<ArmeBosse> 2h ago
<raphink> marcin`: no I didn't do one from tar.gz
<marcin`> ArmeBosse: ok but what's the problem?
<raphink> I got the debian/ back from tar.gz
<marcin`> ArmeBosse: are these file really different?
<raphink> and used the orig.tar.gz that you gave me
<marcin`> ArmeBosse: or have just different md5?
<raphink> to generate the diff and dsc
<ArmeBosse> you provide a different original source archive
<raphink> as should have been
<sistpoty> marcin`: different md5sum's is bad, if there is no *real* reason to repackage the tarball
<marcin`> it was accident
<marcin`> forget about it
<sistpoty> marcin`: we can never sync a version (same upstream version) from unstable, if the orig.tar.gz isn't bit-identical
<ArmeBosse> i'm not motu so you don't listen to me ;)
<ajmitch_> ArmeBosse: don't worry, being a MOTU is no guarantee of that either ;)
<ArmeBosse> hehe second one that tell me this
<marcin`> ArmeBosse: ok - tell me how do you create orig?
<ajmitch_> LaserJock: I see you had an overwhelming response of 7 votes to your poll
<LaserJock> ajmitch_: really, I haven't looked at it so far.
<ArmeBosse> download from url
<ajmitch_> yeah, modifying the merge list code won out 5-2
<ajmitch_> LaserJock: 7 isn't too bad considering the number of active motus
<marcin`> what url???
<marcin`> is there tar.gz in vtiger.com somewhere?
<sistpoty> oh... poll is over? damn, seems like I'd need to code then ;)
<ArmeBosse> 23:56 < ArmeBosse> http://fboudra.free.fr/debian/vtigercrm/vtigercrm_4.2.3.orig.tar.gz
<ajmitch_> sistpoty: sorry :)
<LaserJock> ajmitch_: well, I had hoped for more but 7 is better than the 3 that were at the MOTU meeting ;-)
<ArmeBosse> must be : 8336550 2006-02-19 21:31 vtigercrm_4.2.3.orig.tar.gz
<sistpoty> ajmitch_: np, I'll do a very dirty hack (once again) *g*
<lionelp> sistpoty: can you check http://revu.tauware.de/details.py?upid=2030, Raphlink has ever Advocated and i am looking for a second
<sistpoty> lionelp: few minutes
<lionelp> np
<LaserJock> hmm, I wonder who the other "no coordination" vote was ;-)
<sistpoty> ArmeBosse, marcin`: I'd like to see the text-files in XTemplate and JPGraph in /usr/share/doc/<package> (or symlinked there)... at least the QPL (which imo should be in debian/copyright as well)
<sistpoty> (the files installed in the package actually)
<marcin`> ArmeBosse: ok mine is differen
<marcin`> t
<marcin`> ArmeBosse: how do you create your orig?
<ArmeBosse> not in the policy :) must be in copyright
<ajmitch_> sistpoty: dirty hacks get us through a release cycle :)
<ajmitch_> sistpoty: reminds me that I have to do dirty, ugly & nasty hacks for unmet deps like I promised
<ArmeBosse> marcin`: from vtiger.com then dh_make
<raphink> good night all
<sistpoty> ajmitch_: well, siretart's list is quite good atm
<ajmitch_> sistpoty: sure, I don't mind using that for now
<sistpoty> ajmitch_: but feel free to provide a better solution, even if it's a dirty hack ;)
<LaserJock> I don't know that I've ever seen a clean hack
<sistpoty> well said
<marcin`> sistpoty: QPL is already in copyright
* sistpoty looks again
<marcin`> sistpoty: THE Q PUBLIC LICENSE
<sistpoty> marcin`: ah, found it
<ajmitch_> LaserJock: some hacks are elegantly clean
<ajmitch_> a 'hack' doesn't mean that it's dirty
<sistpoty> marcin`: maybe you could add a line explaining the acronyms in debian/copyright at the beginning?
<marcin`> sistpoty: I think ArmeBosse will do this better
<marcin`> sistpoty: he is involved in vtiger upstream
<marcin`> sistpoty: and they are fighting with licenses all the time
<sistpoty> marcin`: just change "QPL can be found at" to "QPL (Q Public License) can be found at"
<sistpoty> marcin`: but it's ok for me the way it is as well
<marcin`> ok I'll try with next upload
<ArmeBosse> extra-time
<marcin`> btw I uploaded new package to revu few minutes ago
<marcin`> ArmeBosse: have absolutely NO idea why there is no your mail in copyright
<LaserJock> ajmitch_: hmm, I suppose. I've never written one (not that I write much code), but I imagine the exist somewhere
<marcin`> I got this mail in deb packages
<ArmeBosse> your script ?
<marcin`> there is no scirpt that could change this
<ArmeBosse> if write file and do just a debuild, you can't drop my mail
<marcin`> I can tell you more
<marcin`> this mail is in diff file!
<ArmeBosse> you use patch ?
<marcin`> no just pbuilder
<marcin`> http://revu.tauware.de/revu1-incoming/vtigercrm-0602232010/vtigercrm_4.2.3-0ubuntu1.diff.gz
<marcin`> it's there
<marcin`> I mean this mail
<marcin`> I don;t know why this is in http://revu.tauware.de/diff.py?upid1=2028&upid2=2031 here
<sistpoty> marcin`: if you look at debdiffs in the browser, they are treated as html... so < and > are taken as tags (known revu-bug)
<marcin`> ArmeBosse: see!
<ajmitch_> marcin`: what license is FPDF under? 'freeware' can cover many proprietary licenses
<ajmitch_> http://revu.tauware.de/revu1-incoming/vtigercrm-0602232010/vtigercrm-4.2.3/debian/copyright has the email addresses
<marcin`> please guys - don't ask me about licenses
<LaserJock> ajmitch_: apparently it is basically Public Domain. It doesn't really have a license. I asked earlier ;-)
<marcin`> -> ArmeBosse
<ajmitch_> LaserJock: that must be clarified then
<LaserJock> ajmitch_: That is what I thought, but they had bigger issues at the time
<ajmitch_> LaserJock: no license is implicitly undistributable, unless there's an explicit statement to the contrary
<ArmeBosse> marcin`: orig.tar.gz different
<ArmeBosse> marcin`: copyright your mail was dropped
<marcin`> ArmeBosse: moment
<LaserJock> ajmitch_: exactly
<marcin`> ArmeBosse: read what sistpoty wrote a minute ago
<ArmeBosse> ajmitch_: probably must add what's is in FAQ
<marcin`> ArmeBosse: <> are taken as html tags in revu
<ArmeBosse> ?
<ArmeBosse> just one
<ArmeBosse> not others ?
<sistpoty> the debdiffs from revu are actually just a "plain" debdiff... you could dl that and use right away, but the browser will render it as html
<ArmeBosse> i download tar.gz dsc and diff and extract them
<ArmeBosse> with dpkg-source
<ArmeBosse> ajmitch_: FPDF is Freeware (it is stated at the beginning of the source file). There is no usage restriction. You may embed it freely in your application (commercial or not), with or without modification. You may redistribute it, too.
<ArmeBosse> marcin`: we can add this notice
<ajmitch_> ArmeBosse: that's great, it needs to be in there
<ArmeBosse> from FAQ, must be mentionned
<ArmeBosse> http://www.fpdf.org/en/FAQ.php#1
<ArmeBosse> and my comments in mysql file missing :)
<marcin`> ArmeBosse: I don't get it - you take *.zip from vtiger.com - and then what you do to get *.orig.tar.gz?
<marcin`> ArmeBosse: how do you perform zip->tar.gz?
<crimsun> dolson: indeed (RE: PAM) :)
<crimsun> d'oh, I missed Daniel again
<ajmitch_> hi crimsun
<ArmeBosse> the problem comes from your source : modules\reports\lang...
<sistpoty> hi crimsun
<ArmeBosse> you have probably edited a file
<ArmeBosse> and a tmpf file was introduced
<crimsun> 'lo ajmitch_, sistpoty :)
<marcin`> ArmeBosse: I?
<LaserJock> hi crimsun
<marcin`> ArmeBosse: are you talking to me about this modules/reports/lang?
<ArmeBosse> http://prdownloads.sourceforge.net/vtigercrm/vtiger_CRM_4_2_3.tar.gz?download
<crimsun> 'lo LaserJock :)
<ArmeBosse> original file
<ArmeBosse> yes
<marcin`> ArmeBosse: it istn't mentioned on vtiger.com
<marcin`> ArmeBosse: on vtiger.com link goes to *zip
<sistpoty> lionelp: you should also use the exact file you downloaded as orig.tar.gz
<marcin`> ArmeBosse: http://prdownloads.sourceforge.net/vtigercrm/vtiger_CRM_4_2_Source.zip?download
<ArmeBosse> http://prdownloads.sourceforge.net/vtigercrm/vtiger_CRM_4_2_3.tar.gz?download
<sistpoty> lionelp: but if this is the only issue, I'll exchange it myself before uploading ;)
<ArmeBosse> us too ;)
<marcin`> ArmeBosse: propably this difference is between zip and tar.gz from vtiger.com
<ArmeBosse> so you've got an extra file in modules Reports language
<ArmeBosse> no
<ArmeBosse> remove en_us*~
<lionelp> sistpoty: you mean just mv the original tar.gz ?
<sistpoty> lionelp: exactly
<ArmeBosse> i can't stay anymore 2:38 am
<sistpoty> lionelp: there is another issue: your debian/copyright needs to mention every file from a different author/under a different copyright, e.g. md5.c
<sistpoty> lionelp: and the according license
<ArmeBosse> you know the issue :
<ArmeBosse> http://www.fpdf.org/en/FAQ.php#1
<ArmeBosse> acronym
<ArmeBosse> orig.tar.gz
<ArmeBosse> my comments in sql file
<ArmeBosse> you mail in copyright dropped
<sistpoty> lionelp: but apart from that, gastman is fine, so please change these two issues ;)
<ArmeBosse> jsut that :)
<marcin`> ArmeBosse: please explain a little more
<ArmeBosse> about ?
<lionelp> sistpoty: i start changing
<sistpoty> ok
<ArmeBosse> my boss will kill me tomorrow morning ...
* sistpoty can't stay up much longer as well... my gf will kill me otherwise *g*
<marcin`> 1. I just downloaded tar.gz from vtiger.com
<lionelp> sistpoty: in the copyright, i should mention : md5.c : gnagna, the rest :
<lionelp> sistpoty: when is the deadline for the latest update in revu ?
<marcin`> ArmeBosse: so if you removed en_us~ then you got wrong orig
<sistpoty> lionelp: just make sure to mention the exact licenses and what files are covered
<marcin`> ArmeBosse: because this file is there
<ArmeBosse> marcin you have downloaded my file too and it's the exact orig file
<ArmeBosse> so i think it's not the orig file the problem
<sistpoty> lionelp: there is no exact deadline, actually we're in a grayzone right now already ;)
<ArmeBosse> but the extra file that you have
<lionelp> i know, that was why i asked
<ArmeBosse> if you have verified the size that i gave you ...
<marcin`> I'll try to find why there is a difference
<ArmeBosse> if you have my file, check the size
<ArmeBosse> if it's ok then it's your extra file
<marcin`> propably this is because I repackage orig
<ArmeBosse> i'm not familiar with debuild/dput
<ArmeBosse> re package ?
<marcin`> what do you do to change tar.gz to orig.tar.gz - rename only?
<ArmeBosse> yes
<marcin`> ok and that's the problem
<ArmeBosse> dh_make stuff
<ArmeBosse> but i think using -f rename only
<marcin`> dh_make doesn't create orig
<ArmeBosse> use my file, we gain times
<ArmeBosse> copy you deb dir
<ArmeBosse> tar zxf the right orig
<ArmeBosse> and continue
<marcin`> it's not so easy
<marcin`> I know why these files are different
<marcin`> they got different directories
<ArmeBosse> ?
<marcin`> as I said I create vtigercrm-4.2.3 dir
<marcin`> and extract source there then package
<marcin`> vtiger_crm is in orig - I got vtigercrm-4.2.3
<ArmeBosse> not a problem
* ajmitch_ agrees, it doesn't matter what the directory is named
<marcin`> so I can keep this as is?
<ArmeBosse> yes
<marcin`> ok two questions then - what comments in sql?
<marcin`> you wrote few minutes ago?
<ArmeBosse> -- vtigercrm 4.2.3
<marcin`> and what should I do with this fpdf.org?
<marcin`> ok I'll add this comment
<ArmeBosse> fpdf is a freeware blah blah definition from the author that can found on url URL: copy paste hi comments
<ArmeBosse> +be
<marcin`> to copyright?
<ArmeBosse> his
<ArmeBosse> yes
<marcin`> ok just a moment
<ArmeBosse> ajmitch_: agree ?
<ArmeBosse> 3 min max
<lionelp> sistpoty: still there ?
<ArmeBosse> 2:20
<sistpoty> lionelp: yes
<lionelp> i corrected : http://revu.tauware.de/details.py?upid=2032
<sistpoty> lionelp: good... will take a look
<ArmeBosse> 1:40
<ArmeBosse> 1:00
<marcin`> are you waithing for me or ajmitch_ ?
<ArmeBosse> you
<ArmeBosse> just a moment
<marcin`> and what should I do in 1 minute?
<ArmeBosse> you don't know me sleepin :)
<marcin`> I will not upload this in 1 min it takes about 8 on my connection
<marcin`> I added this to copyright
<ArmeBosse> so see you later :)
* ArmeBosse is away
<sistpoty> lionelp: you should include the exact notice from the code... if you want, I'll fix that up and upload
<lionelp> sistpoty: ok, i include, you have better to do i think :)
<sistpoty> lionelp: ok for me... but I'll be in bed in 10 minutes, so hurry ;)
<sistpoty> (wouldn't take too long if I'd do it, otherwise I wouldn't suggest it)
<freeflying> sistpoty: hi
<sistpoty> lionelp: and you miss win32/strsep.c
<sistpoty> hi freeflying:
<marcin`> sistpoty: question about your comment: http://revu.tauware.de/details.py?upid=2031
<marcin`> sistpoty: you want me to move text files from XTemplate and JPGraph to /doc
<freeflying> sistpoty: need review , can you ?
<zakame> hi MOTUs
<ajmitch_> marcin`: btw debian/copyright should not say to look at an URL
<sistpoty> freeflying: sorry, almost in bed
<marcin`> sistpoty: you mean README or LICENSE too?
<ajmitch_> hi zakame
<crimsun> freeflying: url?
<freeflying> crimsun: http://revu.tauware.de/details.py?upid=2011
<lionelp> sistpoty: uploaded again, still in the queue
<zakame> hello ajmitch_ ! :D
<sistpoty> marcin`: basically the text files, that contain documentation
<marcin`> ajmitch_: you mean this MPL and QPL ?
<sistpoty> hi zakame
<ajmitch_> marcin`: I mean if you did what ArmeBosse suggested for fpdf
<ajmitch_> zakame: how's it going?
<zakame> ajmitch_: Manila's now almost in a state of emergency atm
<marcin`> ajmitch_: but I pasted all text from this url
<lionelp> sistpoty: http://revu.tauware.de/details.py?upid=2033
<marcin`> ajmitch_: not just url
<crimsun> freeflying: can you use debhelper 5?
<freeflying> crimsun: ok
<sistpoty> lionelp: win32/strsep.c still missing (at least from looking at the debdiff)
<ajmitch_> marcin`: ok, good
<ajmitch_> zakame: why is that?
<ajmitch_> zakame: coup in the making?
<zakame> ajmitch_: yeah
<lionelp> sistpoty: it is covered by GPL isn't it ?
<freeflying> crimsun: any others?
<crimsun> zakame: hope you're safe
<crimsun> freeflying: still looking
<ajmitch_> zakame: nervous times
<freeflying> crimsun: thx
<sistpoty> lionelp: it has a different author and is covered by LPGL if I read it correctly
<sistpoty> lionelp: yep... LPGL
<lionelp> arf, sorry :-(
<sistpoty> lionelp: np
<zakame> ajmitch_: yeah :( but like jsgotangco said in -ph, I've decided to stay productive :)
<crimsun> freeflying: ok, I presume you're referring to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354094 ? Are you packaging it for Debian, then?
<Ubugtu> debian bug 354094 in ITP "quarry -- A multi-purpose GUI for several board games" [Wishlist,Open] 
<jsgotangco> ajmitch_, bah...i've experience 8 coups in 1986...
<jsgotangco> err 1988
<freeflying> crimsun: I don't know how to solve this issue . for I hope it can be upload to ubuntu universe firstly
<ajmitch_> jsgotangco: haha, it must be fun living in such a country ;)
<ajmitch_> people in NZ are too apathetic about politics for a good coup :)
<jsgotangco> ajmitch_, yesterday while driving on the way home, i actually saw a shootout (robbers)
<crimsun> freeflying: ok, whether you choose to try to push it into Debian first and then sync it from Sid is your choice
<jsgotangco> military adventurism here is more interesting than a tom clancy novel
<zakame> jsgotangco: not to mention the fissure at Adriatico
<ajmitch_> jsgotangco: NZ & Australia are so boring in comparison
<freeflying> crimsun: will debian sid sync package from ubntu ?
<jsgotangco> zakame, yeah, pretty bad omen for the government i'd say
<freeflying> s/ubntu/ubuntu
<crimsun> freeflying: not afaik, but I don't know; perhaps ajmitch_ can shed some light
<jsgotangco> ajmitch_, funny though, most people don't mind it anymore really....the people who join the coups and rallies are very much the same personalities...majority of the population just watch the powerplay
<crimsun> freeflying: otherwise just a very minor whitespace and the GPL symlink issues in debian/copyright
<ajmitch_> freeflying: it's always up to the debian maintainer as to what they choose to do with a package
<freeflying> crimsun: if I prepare to push it into debain ,then where shall I upload firstly ?
<ajmitch_> freeflying: do you plan to maintain it in debian?
<freeflying> ajmitch_: Maybe , I don't know if I have that qualification
<ajmitch_> qualification?
<crimsun> it's more about willingness to maintain
<ajmitch_> why do you think it'll be less of a challenge in ubuntu? :)
<crimsun> frankly, it's much easier to sync from Sid into Ubuntu
<ajmitch_> crimsun: unless you can upload into both & just use something like bzr to maintain the branches :)
<crimsun> true :)
<freeflying> ajmitch_: Anyway , guys here may help me on package , :)
* ajmitch_ wonders if he'll be allowed to upload f-spot 0.1.10
<crimsun> freeflying: in any case, just those two issues in debian/copyright
<freeflying> crimsun: someone have told me that the whitespace is too much , so I decrease them
<crimsun> freeflying: err, just between "Author:" and "Paul"
<freeflying> crimsun: and how about the symlink of GPL ?
<lionelp> sistpoty: http://revu.tauware.de/details.py?upid=2034
<crimsun> freeflying: should be /usr/share/common-licenses/GPL
<sistpoty> freeflying: I just took a glimpse... is it a game? then it should go to /usr/games
<crimsun> freeflying: but-- if your paste from the boilerplate actually coincides with the license in quarry, then what you have it fine.
<crimsun> (mm I can't spell)
<freeflying> crimsun: the author use gpl-2, but actually , some files it use are gpl ,so I change it to gpl
<freeflying> sistpoty: it's means that I shall put them into /usr/games?
<sistpoty> freeflying: yes
<sistpoty> crimsun: you can take my last comment on quarry as advocate, once these issues are fixed ;)
<sistpoty> freeflying: please also look at my other comments
<crimsun> sistpoty: sure
<freeflying> sistpoty: how to put them into /usr/games ?
<sistpoty> freeflying: either debian/rules or patch the install-target
<sistpoty> (and make sure it still works)
<freeflying> sistpoty: got it . thx
<allee> freeflying: then put both headers gpl and gpl 2+ into copyright file.   and add License:'   just like 'Copyright:'
<freeflying> allee: can do like that ?
<allee> freeflying: can?  You have to! ;)  You need to cut&paste every license that is used in the sources
<freeflying> allee: wow, it's will be so long
<sistpoty> not every license... only every license that differs or has another author
<allee> freeflying: Only one for GPL and one for GPL 2+ is enought
<allee> freeflying: but if the license is not one you find in common-licenses, you to include the complete text of the license (and yes this can be very long)
<sistpoty> lionelp: the upstream tarball and your orig.tar.gz still aren't identical...
<sistpoty> lionelp: but I'll exchange these and upload, if you don't mind
<ViViD> sistpoty: i removed the symlinks, but ldconfig doesnt recreate them and the package wont run, is it ok if i leave the necessary one in? and move the other to -dev package, otherwise i need to move them both to the dev, and the binary program will then depend on the dev package
<lionelp> siretart: no pb for me
<sistpoty> ViViD: ldconfig will create the (necessary) symlink on installing... otherwise there's s.th. wrong
<lionelp> thanks a lot
<sistpoty> lionelp: np
<ViViD> yea it doesnt create it, it should apparently create libpar2.so from libpar2.so.0.0.1 but it doesnt
<sistpoty> ViViD: did you read the library packaging guide? there should be one symlink in the -dev package iirc
<ViViD> yea im reading it
<sistpoty> ViViD: libpar2.so should be in the -dev package
<ViViD> yea and then the gpar2 will depend on the dev package
<sistpoty> ViViD: at least iiirc...
<sistpoty> ViViD: no
<allee> freeflying: did you try to build in pbuilder?  Just librsvg2-dev, no lib<widgetlib-of-your-choice) in build-deps.
<ViViD> whatever contains libpar2.so is what gpar2 depends on
<freeflying> allee: it can be build with pbuilder
<allee> freeflying: heh, nice
<sistpoty> ViViD: no, it doesn't... just try to build it and install the library-package and gpar2... try using ldd on the binary of gpar2 and check if it has unresolved shared objects
<ajmitch_> ViViD: if gpar2 depends on libpar2.so, it's used shared libraried in a broken way
<freeflying> crimsun: if I want to push it into debain , who can be my sponsor  here ?
<marcin`> sistpoty: vtigercrm is in revu now - new upload
<crimsun> #debian-mentors is probably better
<marcin`> sistpoty: if you are there then could you take a look at it?
<crimsun> I don't feel it's courteous to yoke our few DDs with even more ;)
<sistpoty> marcin`: sorry, but I really need to go to bed now
<sistpoty> lionelp: gastman uploaded ;)
<sistpoty> ok... and now I'm off to bed ;)
<sistpoty> gn8 everyone
<freeflying> crimsun: then firstly I upload it to mentors
<marcin`> ajmitch_: are you still there?
<allee> freeflying: hint: debian-mentor have their own check list for pkgs.  Make sure that you have everything in there
<allee> nite
<freeflying> allee: what you mean everything ?
<allee> everything listed in their check list
<ajmitch_> marcin`: yes?
<marcin`> ajmitch_: could you take a look at vtigercrm in revu?
<Se7h> hi there
<ajmitch_> marcin`: no, I don't have that much time at the moment
<marcin`> ajmitch_: btw it's already too late to put this package to dapper right?
<marcin`> ajmitch_: package freeze?
<ajmitch_> I guess so, but I'm not in cahrge of that (or anything really)
<ajmitch_> s/cahrge/charge/
<ViViD> alright i fixed all that he said i needed to
<ViViD> if anyone is available please take a look at http://revu.tauware.de/details.py?upid=2037 and http://revu.tauware.de/details.py?upid=2038
<Pupeno> Where can I contribute new packages for ubuntu and backports for breezy-backports ?
<crimsun> backports are generated from the current devel branch to the most recent stable version.
<crimsun> for new packages, see the url linked from wiki/MOTU
<freeflying> crimsun: how to work for backport ?
<crimsun> freeflying: I don't understand your question
<crimsun> (use pin yin if necessary)
<freeflying> crimsun: :) If I want backport some package back to breezy , how shall I do it
<crimsun> freeflying: you have to ask for it to be backported via the backport mailing list, stating the rationale and the build log
* ajmitch_ wants new f-spot in dapper
<Se7h> crimsun do u have any idea why my external hd goes into 'sleep' ?
<Se7h> (i know the question is on the wrong channel but i might get a quicker answer here)
<crimsun> Se7h: sorry, that's a bit too vague
<Se7h> it just hibernates some times
<Se7h> and hdparm wont help a thing
<Se7h> (i think)
<crimsun> Se7h: usb?
<Se7h> yes
<zakame> huh? can't you upload/request UVF except?
<crimsun> zakame: I think he just wants it, not that he can't request it :)
<Se7h> thats correct :p
<crimsun> Se7h: hmm, I don't have any problems with the external USB HD I use doing that. You probably want to direct that question to mjg59
<Se7h> i still don't get why it goes into that mode while its being used. it's kinda annoying getting the music 'paused'
<Se7h> wheres that guy ?
<crimsun> in -kernel, -laptop, -devel, among other places
<ajmitch_> zakame: hm?
<Se7h> uhum k
<Se7h> ty
<Se7h> i'll try him
<ajmitch_> zakame: I'm still waiting on approval for 0.1.9, and 0.1.10 is out & packaged now
<ajmitch_> I scared him off..
<Se7h> crimsun any more references besides mjg ?
<crimsun> Se7h: possibly benc
<monzie> hi all hard-working motu's
<ajmitch_> that rules me out
<Pupeno> how do you choose the section a package is going to end up in a repository by debarchiver ?
<Se7h> in the 'control' file
<Pupeno> Se7h: is that for me ?
<Se7h> yes
<Pupeno> in the control file I choose things such as libs, comm, etc, but the sections by debarchiver are avobe that (main, non-free, contrib... or universe, multiverse, etc).
<Se7h> well i create the control faile manually
<Se7h> :s
<Pupeno> I do create the control file manually too, what's the point ?
<LaserJock> hi monzie hi Se7h
<monzie> hi LaserJock
<Se7h> hey LaserJock
<Se7h> Pupeno non, i just felt like saying it
<Se7h> lol
<Se7h> Section: games
<Se7h> that can be an example
<Pupeno> Se7h: yes, I have Section: libs
<Pupeno> Se7h: but how do I choose the upper level ? Section: non-free/libs ?
<Se7h> i might be too dumb for this
<Se7h> what do u mean by upper level ?
<LaserJock> hmm, I think it would probably depend on what you upload to? In Ubuntu anyway.
<LaserJock> Pupeno: you might want to check out http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections
<LaserJock> hi minghua
<minghua> hello LaserJock
<viviersf> ah gr8, typical of hp products
<viviersf> a dvd rewriter that cannot write on a dvd rw disc
<ajmitch_> heh
<ajmitch_> sounds usual
<viviersf> :(
<ajmitch_> I haven't tried a rw dics in my acer laptop
<viviersf> ah wait
<viviersf> hmmm
<viviersf> this is dvd-rw discs
<viviersf> ok no thats not it
<viviersf> brb
<crimsun> cya ajmitch_
<siretart> morning
<Gloubiboulga> hi siretart
<siretart> hi Gloubiboulga
<zakame> hello MOTUs
<ArmeBosse> hi all
<ArmeBosse> looking for an advocate : http://revu.tauware.de/details.py?upid=2035
<dholbach> good morning motu world
<ViViD> if anyone is available to check out/advocate if its ready please take a look at http://revu.tauware.de/details.py?upid=2039 and http://revu.tauware.de/details.py?upid=2040
<dholbach> Aren't we in Feature Freeze yet?
<StevenK> I thought we were?
<dholbach> yeah
<StevenK> It's been the 24th in UTC for 8 hours, so we ought to be.
<dholbach> ViViD: Feature Freeze means for us, that we can't accept NEW packages into Ubuntu any more, they will have to wait for Dapper+1 - I'm sorry.
<dholbach> ViViD: if somebody steps up to review your packages and make them better, that's fine - it's just they won't likley end up in DApper.
<ViViD> i though this was for adding to the universe section
<dholbach> yes, it is.
<dholbach> NEW stuff for Universe and Multiverse.
<ViViD> well either way its going to need to be advocated to get into either, and its not going to get in by waiting 6 months to do anything more
<dholbach> ViViD: absolutely right.
<dholbach> I just didn't want to give false hope.
<zakame> I think we are already
<ViViD> i have an apt server already, so it doesnt matter what release is added officially
<Tonio__> hi all
<ViViD> what is dapper+1 going to be called?
<dholbach> It's not announced yet.
<ViViD> and how long after dapper releases does devel start
<dholbach> ViViD: usually a week
<dholbach> the guys in #ubuntu-desktop joked, it might be "huggy holbach"
<ViViD> about 8-10 weeks to get all these ready
<dholbach> yeah, in the meantime we have a lot of packages to fix
<dholbach> malone is quite full of universe bugs
<dholbach> and we have unmet dependencies to clear as well
<dholbach> I'll think over the weekend, how we can organize all this.
<ViViD> mine apps are bug free, but im new to source packaging, was using these first two to make a lib and binary template
<ViViD> only bug report ive got for it was someone running sid, but on two systems i was unable to duplicate the problem
<dolson> morning dholbach
<dholbach> hey dolson
<dholbach> dolson: how are you?
<dolson> dholbach: well, ok. I sat at the ER yesterday for 5 hours waiting for blood test results, only to have them be negative.. what a waste of time. how are you?
<dolson> dholbach: I am a little disappointed none of the dssi apps will be in dapper though. but I'll get over it
<dholbach> i'm fine, nothing a coffee couldn't remedy
<dholbach> dolson: i looked at them, but dependencies were missing, so i couldn't test them properly
<dolson> dholbach: yeah, dssi-dev needs to be sync'd from debian
<dholbach> dolson: don't be too disappointed - there's still a lot to do in general for the release and "after the release is before the release" :)
<dholbach> dolson: i'm very pleased with what you achieved in so little time
<dolson> dholbach: that makes me happy :) 15 days ago I didn't even know what debuild was. :P
<dholbach> :-)
<dholbach> dolson: I'd be happy if you'd try to gather followers, form a team (on launchpad too, assign the bug reports for audio stuff to the team) - that'd be a worthwhile goal for the meantime
<dolson> dholbach: I'll talk with forest and maarten.. not sure who else will help. I get a lot of people on MSN bitching at me that I didn't package the new version of lilypond or denemo or csound etc.
<ViViD> dholbach: if you get some time, can you look at my apps? i think they're pretty close, and i kinda need to get them ok before i start packing the rest
<dolson> seems most people are not willing to help, but just bitch me out for not working hard enough
<dholbach> dolson: you should write to the mailing lists, announce a meeting, stuff like that - if you're interested in such a team
<dholbach> ViViD: I'm quite busy at the moment, sorry.
<ArmeBosse> how can i know if package was uploaded in revu successfully instead of waiting/refresh website ?
<ArmeBosse> i have always "successfully uploaded package" but never see them
<tepsipakki> ArmeBosse: make sure you've uploaded sources, not binaries
<ArmeBosse> tepsipakki: .dsc .orig.tar.gz .diff.gz source.changes only
<ArmeBosse> marcin`: hi
<marcin`> ArmeBosse: hi
<marcin`> ArmeBosse: good to see you because I got a question and problem
<marcin`> ArmeBosse: I got polish translation for vtiger
<marcin`> ArmeBosse: (it's also in vtigerforge)
<marcin`> ArmeBosse: and it doesn't work propely
<marcin`> ArmeBosse: because polish lang needs code pacge to be ISO-8859-2
<marcin`> ArmeBosse: and it's set in content type and I can see in page source that it should be ISO-8859-2
<marcin`> ArmeBosse: but in browser it's still ISO-8859-1
<marcin`> ArmeBosse: could you give me hint what can be reason?
<ArmeBosse> i'll look
<ArmeBosse> please can you pv message me for this, not ubuntu-motu related ;)
<marcin`> let's go to #vtiger-bounty
<marcin`> it's vtiger related because *-lang-pl package doesn't work propely
<viviersf> whats the command to add a new thing to a changelog ?
<viviersf> ViViD, why you ping me
<ArmeBosse> debchange ?
<raphink> dch
<ArmeBosse> same just an alias
<ArmeBosse> raphink: no way to upload ...
<raphink> ArmeBosse: essaie encore
<ArmeBosse> raphink: a gne de le faire sous sid ?
<raphink> normalement non
<ArmeBosse> k
<ArmeBosse> Successfully uploaded packages.
<raphink> ah bon?
<raphink> je crois pas moi
<raphink> ah bah je sais pourquoi c'est bloqu
<raphink> le source.changes a t rejet
<ArmeBosse> je sais bien, je vois rien mais dput met a
<ArmeBosse> 11:01 < ArmeBosse> how can i know if package was uploaded in revu successfully instead of waiting/refresh website ?
<raphink> quoi?
<ArmeBosse> fill as wish list ;)
<ArmeBosse> je sais bien que c'est pas pass je vois rien
<ArmeBosse> mais je sais jamais pourquoi ...
<raphink> bon j'ai vir le source.changes des rejected
<raphink> essaie encore
<raphink> ;)
<ArmeBosse> pas de report  part le message de dput Succ..
<ArmeBosse> c'est pour revu2 ? :)
<raphink> quoi donc?
<raphink> a doit tre bon l, le source.changes a t accept
<raphink> attend 2 minutes et a sera up
<ArmeBosse> know if a package was uploaded in revu successfully instead of waiting/refresh website
<ArmeBosse> and mail report for failed upload :)
<raphink> ArmeBosse: ben c'est rejet
<raphink> ArmeBosse: il faut que tu trouves pourquoi
<lmanul> Tiens, le franais a envahi une autre chan, en plus de #ubuntu-desktop :)
<ArmeBosse> siretart: ping
<siretart> ArmeBosse: wassup?
<raphink> lmanul: tu sais que qu'on prpare un coup d'tat francophone?
<lmanul> raphink: yes ! je m'associe ! attribuons de force  Mark la nationalit franaise :-p
<raphink> haha
<raphink> :)
<raphink> lmanul: on a dj pris d'assaut les MOTUs Kubuntu
<raphink> en plus on a des associs dans la foule ;)
<raphink> comme dholbach par exemple ;)
<dholbach> tssss :)
<lmanul> haha
<raphink> dholbach: :)
* raphink hugs dholbach 
* lmanul hugs dholbach
<dholbach> :-))))
<dholbach> le gens franaises :)
<raphink> :)
<ArmeBosse> bug ? : http://revu.tauware.de/diff.py?upid1=2035&upid2=2043
<ArmeBosse> page was redirected
<kbrooks> um.
<Lathiat> hi kbrooks :)
<kbrooks> i'd like to see debins in universe in dapper. what do i do
<Lathiat> kbrooks: do you have any experience at all with debian packaging?
<kbrooks> "tseng you could make it in for dapper if you hurry :)"
<Hobbsee> it's after feature freeze anyway, isnt ti?
<Hobbsee> in any and all timezones
<Lathiat> iirc you could still upload a new universe package
<Lathiat> kbrooks: and if not would you like to learn? :)
<kbrooks> yes
<kbrooks> but can i learn quicly
<kbrooks> crash course?
<dolson> what is debins?
<Lathiat> https://wiki.ubuntu.com/MOTU/Packages/New
<Lathiat> see the second section
<dolson> debins looks like the same thing as gdebi?
<Lathiat> it is
<Lathiat> doesnt  mean it cant be packaged tho :)
<nomed> is there a way to tell cdbs to use autogen.sh instead of configure ?
<tseng> you shouldnt be doing that in a package
<tseng> it should already have configure generated
<siretart> nomed: If you are asking this question, I think you are better of with running plain debhelper
<tseng> siretart: or applying a patch to fix the package first
<nomed> tseng, i know what you mean :)
<nomed> what i would try to understand is ...
<nomed> if the pkge cames from an svn version
<nomed> the configure within it is probably pre-generated using autogen.sh ..
<nomed> true ?
<tseng> does the package have a make distcheck target
<nomed> umm .. no
<tseng> (after configuring)
<tseng> autogen, configure, make distcheck
<siretart> nomed: your upstream didn't make any release yet?
<nomed> siretart, it's not a pkge i maintain
<nomed> these pkges use the debian rules files
<nomed> but debian pkges are not from svn
<nomed> so i was trying to figure out what happens in that case
<tseng> you make a 'release' from svn, ideally
<tseng> a snapshot tarball using the same tools upstream would to make a release
<nomed> tseng, yes
<siretart> nomed: listen to tseng. try to create a 'release' tarball by using 'make dist' or something
<nomed> siretart, k
<nomed> i got it
<tseng> you dont just tar up your checkout and force debian/rules around it
<tseng> yay
<tseng> so, if you have make distcheck
<tseng> it will do the work for you
<ArmeBosse> siretart: can you try http://revu.tauware.de/diff.py?upid1=2035&upid2=2043
<siretart> getpdf? wtf?
<ArmeBosse> diff appear then redirected ...
<siretart> I think there is something in the package which confuses the webbrowser
<siretart> interesting
<ArmeBosse> other issue: mail removed in control file
<ArmeBosse> 02:24 < sistpoty> if you look at debdiffs in the browser, they are treated as html... so < and > are taken as tags (known revu-bug)
<siretart> ArmeBosse: I appreciate every patch ;)
<ArmeBosse> :)
<jpatrick> If a packages verison is 0.12.10-2 and I've repackaged to fix a bug should it be 0.12.10-3ubuntu1 ?
<dholbach> 2ubuntu1
<jpatrick> dholbach: ok, thanks
<thesaltydog> dholbach, ciao daniel!
<raphink> dholbach: any reason for rejecting the update-grub `splashimage line` bug ?
<dholbach> Ubuntu (Dapper) -> Ubuntu
<raphink> ah ok
<dholbach> the launchpad guys asked me to do this
<dholbach> as Dapper is not released yet, it doesn't make much sense
<raphink> but then it's confirmed in Ubuntu
<raphink> dholbach: yes
<dholbach> yeah
<raphink> there
<raphink> :)
<raphink> it's not a bad bad bug
<raphink> but well
<freeflying> raphink: hi
<pappan> raphink: sec hole ?
<raphink> pappan: ?
<raphink> hi freeflying
<pappan> raphink: the bug u r talking abot
<raphink> https://launchpad.net/malone/bugs/32333
<Ubugtu> malone bug 32333 in grub "kubuntu-grub-splashimages adds a splashimage config line to GRUB's menu.lst to the wrong place" [Normal,Confirmed] 
* jpatrick just uploaded a fix for #4385
<freeflying> raphink: need review http://revu.tauware.de/details.py?upid=2042
<raphink> freeflying: you know we're in FF now
<jpatrick> freeflying: it's feature freeze on
<freeflying> raphink: jpatrick I see, I just want to know if ther any problems with that package , maybe I'll push it into debian
<raphink> nice
<jpatrick> yeah, put it into debian then sync for dapper+1
<raphink> :)
<freeflying> so I wanna if there any other problems
<thesaltydog> dholbach, I have fixed this bug: https://launchpad.net/products/bum/+bug/29831 , but unfortunately after UFV..
<Ubugtu> malone bug 29831 in bum "BUM leaves lock file around after failing to start" [Normal,Fix released] 
<jpatrick> can't we upload bug fixes?
<raphink> thesaltydog: UVF doesnt prevent from fixing bugs thankfully
<freeflying> jpatrick: the eva package still include configure and Makefile in diff, I remove the autoconf from buoild-dep
<raphink> nor does FF
<raphink> freezing the features doesn't mean we freeze the bugs too ;)
<thesaltydog> raphink, yes, :-) I mean, it will not be synched in dapper..
<jpatrick> because I've uploaded two fixes recently
<raphink> thesaltydog: if it fixes a but, you can request a UVF exception
<raphink> s/but/bug/
<thesaltydog> raphink, I don't know the procedure.
<raphink> thesaltydog: https://wiki.ubuntu.com/MOTU/UpstreamVersionFreeze
<raphink> thesaltydog: also, look at the ML to see how previous exceptions were requested
<thesaltydog> raphink, ok. tnx.
* ..[topic/#ubuntu-motu:siretart] : Ubuntu Masters of the Universe: Ubuntu Universe Repository Maintainers | http://wiki.ubuntu.com/MOTU | http://wiki.ubuntu.com/MOTU/Documentation | We are in feature freeze now. Focus on fixing bugs, malone is full of them.
<jpatrick> I'm going though the Kubuntu ones
<dolson> dholbach or whoever: if I apply a patch from a bug report to add a .desktop file, do I have to do anything to the changelog if the patcher added an appropriate changelog entry with their name/email? ie: should I change that to me before building and uploading to REVU, or leave it as their name?
<marcin`> ArmeBosse: ping
<tseng> Lathiat: oh jeez
<tseng> Lathiat: my alps is ass slow now, what was the fix
* Lathiat laughs at tseng 
<tseng> :/
<Lathiat>   Option          "MinSpeed"              "0.49"
<Lathiat>         Option          "MaxSpeed"              "0.63"
<Lathiat> in synaptics mouse section
<Lathiat> do you have a laptop with a real synaptics?
<Lathiat> i've been waiting for mjg59 to tell me what effect that setting has on real snaptics
<Lathiat> if its good i want to get those to defaults
<Lathiat> if bad i need to ffigure out some way to make it know the difference
<Gloubiboulga> dolson, if you change something in the package, you have to add a changelog entry I think
<Gloubiboulga> dolson, forget it
<Gloubiboulga> but dolson, what do you want to upload on REVU ?
<tseng> Lathiat: nice
<dolson> I want to close bugs
<tseng> this is more acceptable
<dolson> anyhow, he didn't really format the changelog entries well, so I'll just put my own
<Gloubiboulga> dolson, then create a debdiff and attach it to the bug on malone
<dolson> Gloubiboulga: how do I do this?
<Gloubiboulga> dolson, on the rigth of the page you'll find an "add an attachment" entry"
<dolson> Gloubiboulga: I know that. how do I make a debdiff?
<Gloubiboulga> oh, sorry
<Toadstool> Speaking about debdiff and malone, anyone who wants to tell me if I've done things the right way in malone 32695 ?
<Ubugtu> malone bug 32695 in denemo "Missing librsvg2-common dependency " [Normal,Unconfirmed]  http://launchpad.net/bugs/32695
<dolson> Gloubiboulga: here, look at this: https://launchpad.net/distros/ubuntu/+source/galan/+bug/28761
<Ubugtu> malone bug 28761 in galan "Missing .desktop file" [Normal,Unconfirmed] 
<Gloubiboulga> just debuild -S -sa the changed package and run `debdiff` with the 2 dsc files
<dolson> Gloubiboulga: it's been there for 5 weeks. I want to close it. I did this in the past with seq24, and I did it by patching and uploading to REVU
<Gloubiboulga> dolson, ping a MOTU to get it uploaded ;)
<jpatrick> ...
<dolson> I'm sorry if I'm being stupid, but I don't understand what I am supposed to do here. it just seems like they've been sitting there with patches for 5 weeks and nothing has happened since. I want to up it to REVU. this is not the way to do it? what can *I* do as a non-MOTU?
<jpatrick> not a lot
<jpatrick> but I can help you
* Gloubiboulga needs to leave
<dolson> jpatrick: ok. there are 11 packages that are simply missing .desktop files, and all of them have patches on Malone from what I see.
<jpatrick> where's the revu one?
<dolson> I didn't upload any to REVU yet. I did seq24 a couple weeks ago, and it's already been put back into Dapper, which is why I thought I was doing this correctly
<jpatrick> just put your fixes in revu and I'll see if it's ok
<dolson> ok, that's what I was going to do, but Gloubiboulga said not to
* dolson goes back to work. :)
<Toadstool> jpatrick: if you have time, can you check bug 32695, please ? :)
<Ubugtu> malone bug 32695 in denemo "Missing librsvg2-common dependency " [Normal,Unconfirmed]  http://launchpad.net/bugs/32695
<jpatrick> you made a patch?
<jpatrick> yep
<jpatrick> ok - looks good
<Toadstool> i spent about an hour with gdb and gdk code and finally it was just a missing dependency, I'm a moron :)
<jpatrick> Toadstool: I have one problem... denemo's in main
<Toadstool> argh !
<Toadstool> silly me
<jpatrick> got another patch?
<Toadstool> not yet, i'm looking for another package to debug :)
<Toadstool> what can I do about about denemo ?
<Kyral> Morning MOTU
<Toadstool> find a core-dev ?
<jpatrick> poke a maintainer
<Toadstool> ok
<Toadstool> thanks jpatrick
<jpatrick> no problemo
<siretart> Toadstool: I'm checking denemo patch
<Toadstool> that's a tiny and minor one, but thanks
<dolson> jpatrick: should I change the bug reports to Fix Committed or Fix Released once I upload to REVU?
<siretart> Toadstool: but its main, and difficult to upload for mere motus :)
<jpatrick> I'll have to upload to the archives first
<jpatrick> heh
<siretart> dolson: rather not. REVU is not part of launchpad (yet)
<Toadstool> siretart: yep jpatrick already told me that :)
<Toadstool> i didn't notice
<siretart> Toadstool: apt-cache showsrc denemo
<dolson> jpatrick: ok, I uploaded to REVU already
<jpatrick> galan?
<Toadstool> siretart: yeah I know I'm a moron :)
<siretart> Toadstool: no, it is a useful patch. really
<jpatrick> dolson: which package?
<dolson> jpatrick: galan, meterbridge, mhwaveedit, muse, puredata, qsynth, rezound, sooperlooper, spiralsynthmodular, terminatorx
<dolson> jpatrick: oh, and wavesurfer
<jpatrick> galan has one nasty .dif
<jpatrick> .diff*
<siretart> Toadstool: I just uploaded your patch. please handle the malone bug yourself, ok?
<Toadstool> you mean I can close it ?
<jpatrick> Toadstool: Fix Released
<Toadstool> ok thanks siretart
<Toadstool> and jpatrick :)
<dolson> jpatrick: yeah, it's big..  not my fault though :)
<jpatrick> dolson: ok, now doing galan
<dolson> jpatrick: just for your reference, the only things I've changed in all of these is added the .desktop file, added the dh_install and dh_desktop to debian/rules, and added an entry in the changelogs, so they should be all fairly straightforwar
<dolson> d
<jpatrick> yep
<jpatrick> dolson: galan uploaded
<dolson> jpatrick: so now I can change the bug report to fix released?
<dolson> or do you do that
<jpatrick> did
<dolson> k
<jpatrick> next! ;)
<jpatrick> dolson: muse done
<dolson> jpatrick: cool
<marcin`> ArmeBosse: ping
<ArmeBosse> marcin`: yes
<marcin`> I got few vtiger related questions so could you go to priv query or #v-bounty?
<thierry> dholbach : why did you rejected all my dapper bugs about .desktop file? is it too late for dapper?
<dholbach> no
<dholbach> i just closed the "Ubuntu (Dapper)" task
<dholbach> the "Ubuntu" part is still valid
<LaserJock> I think  the LP people might want to do something about that. It can be very confusing
<thierry> dholbach : k I see, then thanks! :)
<dholbach> it doesn't make sense to distinguish between "Ubuntu" and "Ubuntu (Dapper)" atm, as Dapper is not yet released - it's fixed in LP now
<thierry> dholbach : k, but I wanted the fix to get to dapper so...
<dholbach> Ubuntu is alright
<dholbach> everybody will understand that
<thierry> k
<LaserJock> thierry: you want to get the fix in Ubuntu primarily ;-)
* jpatrick starts on malone #3962
<Ubugtu> malone bug 3962 in gnomebaker "[PATCH]  gnomebaker absolute icon path" [Normal,Unconfirmed]  http://launchpad.net/bugs/3962
<LaserJock> hmm, how do I recursively use "find -name"?
<dolson> LaserJock: find . -name ?
<dolson> or am I misunderstanding something
<LaserJock> dolson: it doesn't seem to be recursive, it only looks in the present directory
<ArmeBosse> LaserJock:  find $(WEBAPPDIR) -name "*.php" -perm /a+x -exec chmod a-x {} \;
<ArmeBosse> but not a find guru :) just an example
<LaserJock> hmm, I'm just trying to find all the shell scripts so I'm doing "find . -name *.sh" and I only get the one in the current directory
<ArmeBosse> LaserJock: find . -name "*.sh"
<LaserJock> ArmeBosse: hmm, that worked. I'm not sure exactly why.
<ArmeBosse> ->"*.sh "
<ArmeBosse> ->"*.sh"
<ArmeBosse> double quote
<LaserJock> but why would it find the one in the current directory?
<ArmeBosse> hmm right ...
<LaserJock> anyway, whatever. thanks ArmeBosse
<ArmeBosse> np
<marcin`> ArmeBosse: hi again
<marcin`> ArmeBosse: got a question about this *.orig.file
<marcin`> ArmeBosse: I don't know how you do this
<marcin`> ArmeBosse: could you help me and tell how you do this dh_make thingy?
<Gloubiboulga> marcin`, you can just rename the upstream tarball
<Gloubiboulga> or use dh_make -f the.tarball.tar.gz iirc
<marcin`> Gloubiboulga: thanks...
<marcin`> Gloubiboulga: rename was the trick
<Gloubiboulga> marcin`, no problem :)
<marcin`> Gloubiboulga: ehh I still don't understand this dh_make magic...
<marcin`> Gloubiboulga: so I got directory let's say: app-1.0 and I downloaded tar.gz with sources
<marcin`> Gloubiboulga: so I put this tar.gz to app-1.0 and rename to app-1.0.tar.gz
<marcin`> Gloubiboulga: I run dh_make there and it creates debian directory for me
<marcin`> Gloubiboulga: and ../app-1.0.orig.tar.gz
<marcin`> Gloubiboulga: then I customize files in app-1.0/debian and what should I run to build this?
<Gloubiboulga> debuild -S -sa
<LaserJock> marcin`: http://www.debian.org/doc/maint-guide/ch-first.en.html#s-dh_make
<Gloubiboulga> and it's app_1.0.orig.tar.gz
<dholbach> have a nice weekend
<Gloubiboulga> bye dholbach
<dolson> cya dholbach
<LaserJock> cya dholbach
<marcin`> Gloubiboulga: it's propably because I'm so stupid but I still don't understand one thing
<LaserJock> marcin`: what don't you understand? what dh_make does?
<marcin`> LaserJock: I don't understand which command unpack tar.gz in my build directory
<marcin`> LaserJock: because I create directory for my package right? mkdir app-1.0
<marcin`> LaserJock: then I put app-1.0.tar.gz there and run dh_make
<LaserJock> marcin`: no, just a sec.
<marcin`> LaserJock: dh_make will create ../app-1.0.orig.tar.gz and app-1.0/debian
<Gloubiboulga> marcin`, you have to unpack the tar.gz manually first
<Gloubiboulga> then cd theNewDir
<Gloubiboulga> and run dh_make inside this directory
<LaserJock> dh_make just does the initial debianization of the source. ie added debian/ with some templates and makes the .orig.tar.gz from the tarball
<marcin`> LaserJock: I'm definetly dumb and dumber in one person today... :)
<marcin`> LaserJock: but I understand what dh_make does
<marcin`> LaserJock: unfortunately I still don't understand how to unpack original source
<LaserJock> tar -xzf
<marcin`> LaserJock: ok ok I know tar commanf
<marcin`> LaserJock: the thing is that I can have app-1.0.tar.gz but it can unpack files to some different directory than app-1.0/
<LaserJock> marcin`: whatever, I think dh_make will take care of that for you. or you can mv it
<marcin`> LaserJock: heh and I do this at the moment
<marcin`> LaserJock: but then I got not original orig.tar.gz
<LaserJock> marcin`: did you mv it to app-1.0/ ?
<marcin`> LaserJock: for example I got vtiger_CRM_4_2_3.tar.gz and it contains /vtiger_crm directory
<LaserJock> marcin`: ok mv it to vtivercrm-4.2.3/
<marcin`> and then if I build this then new orig will have files in vtigercrm-4.2.3/ right?
<LaserJock> well, I guess vtigercrm-4.2.3/ ;-)
<LaserJock> marcin`: right
<marcin`> I mean inside orig.tar.gz
<marcin`> exactly and this is the problem
<LaserJock> marcin`: ok, just take vtiger_CRM_4_2_3.tar.gz and untar it. then move vtiger_crm to vtigercrm-4.2.3/. then run dh_make inside of that directory
<marcin`> because ArmeBosse and some MOTU's reviewing my upload to REVU complained that I use 'non original' orig.tar.gz
<LaserJock> right
<marcin`> so what exactly should I do to avoid this problem?
<LaserJock> marcin`: do what I said :-)
<LaserJock> and when you use dh_make you can use
<LaserJock> dh_make -f ../vtiger_CRM_4_2_3.tar.gz
<LaserJock> marcin`: it's all at http://www.debian.org/doc/maint-guide/ch-first.en.html#s-namever
<marcin`> LaserJock: thanks a lot
<LaserJock> np
<marcin`> LaserJock: holy crap.. noooo
<marcin`> LaserJock: I did what you said
<marcin`> LaserJock: and everything is ok but......
<marcin`> LaserJock: my vtigercrm-4.2.3.orig.tar.gz contains vtigercrm-4.2.3
<LaserJock> right
<marcin`> LaserJock: while ArmeBosse has vtigercrm-4.2.3.orig.tar.gz that contains vtiger_crm
<LaserJock> I don't think he should
<LaserJock> he must have just renamed the tarball
<marcin`> yes
<marcin`> but I got no idea how he could build package with this orig...
<LaserJock> marcin`: what do you mean?
<LaserJock> oh, I see what you're saying. I don't know if it won't build but it isn't standard I don't think.
<mitsuhiko> any GNOME guys online?
<dolson> can I not include a png file in the debian/ dir?
<LaserJock> why not?
<dolson> dpkg-source: cannot represent change to debian/ldrum.png: binary file contents changed
<ArmeBosse> LaserJock: you're wrong
<ArmeBosse> LaserJock: my orig is standard
<ArmeBosse> LaserJock: and dh_make only rename when you use -f params
<LaserJock> ArmeBosse: really? I thought they had to have <packagename>-<version>
<ArmeBosse> marcin`: ping
<marcin`> ArmeBosse: no doubt but tell us how you did it?
<ArmeBosse> tar zxf .tgz
<ArmeBosse> mv to a correct name to use dh_make
<ArmeBosse> if you don't do it dhmake complain about naming scheme
<ArmeBosse> then use dhmake with -f params
<marcin`> exactly
<ArmeBosse> anyway you don't need to do this
<ArmeBosse> you take orig.tgz
<ArmeBosse> decompress
<marcin`> .tar.gz
<ArmeBosse> put you deb dir inside
<ArmeBosse> you know what i mean
<ArmeBosse> then as usual debuild
<ArmeBosse> nothing difficult
<dolson> LaserJock: am I right or no? I can't put binary files in debian/ /
<dolson> ?
<marcin`> holy shit I don't know what do you mean because my orig.tar.gz contains vtigercrm-4.2.3 not vtiger_crm
<LaserJock> dolson: you can, but it might complain. I'm not quite sure why you are getting that message
<marcin`> ArmeBosse: let's do this from the beginning
<LaserJock> dolson: I've done it and have never had a problem. what are you doing?
<marcin`> ArmeBosse: I got directory /home/marcin/x
<dolson> LaserJock: debuild -S -sa -kdana@ubuntustudio.com
<marcin`> ArmeBosse: I put vtiger_CRM_4_2_3.tar.gz in this directory
<marcin`> ArmeBosse: /home/marcin/x/vtiger_CRM_4_2_3.tar.gz
<marcin`> ArmeBosse: what next?
<LaserJock> dolson: so did you change the .png or something? I don't think it is so much complaining about the file itself, just that it is trying to diff a binary
<ArmeBosse> tar zxvf vtiger_CRM_4_2_3.tar.gz
<dolson> LaserJock: I made the png, because there is no icon included in the orig.tar.gz.
<ArmeBosse> mv vtiger_crm vtigecrm-4.2.3
<LaserJock> dolson: right. I'm not sure that it is a problem. but I don't remember seeing that when I did the same thing
<ArmeBosse> cd vtigercrm-4.2.3
<dolson> dpkg-source: unrepresentable changes to source
<ArmeBosse> dh_make -f ../vtiger_CRM_4_2_3.tar.gz
<ArmeBosse> rm -f debian/*
<ArmeBosse> cp -rf youdebiandir/* debian
<ArmeBosse> debuild -S -sa
<LaserJock> dolson: do you have any swap files from editing in debian/ perhaps?
<dolson> LaserJock: ls -la doesn't show anything other than what should be in there
<ArmeBosse> understand ?
<LaserJock> dolson: hmm, you might just keep going for now. I'm not sure what's going on. I would probably have to look at the source package.
<dolson> LaserJock: well it errors out, so I can't continue from here
<LaserJock> dolson: oh, well that is a problem
<ArmeBosse> marcin`: what changes have you made to the package ? or do i need to wait the surprise ?
<LaserJock> ArmeBosse: that is what I told marcin` to do. ;-)
<ArmeBosse> :)
<ArmeBosse> each motu or "future" motu has a different point of view :)
<marcin`> ArmeBosse: currently I work on polish translation and wait for 4.2.4rc1
<ArmeBosse> i think you have prepared a new upload
<marcin`> ArmeBosse: and although I understand now what you did I still think that it's weird
<marcin`> because you don't have to use -f ../vtiger_CRM with dh_make
<ArmeBosse> i don't care
<ArmeBosse> :)
<marcin`> and no I don't have new upload but I will when I'll prepare *-lang-* packages
<LaserJock> marcin`: why is it a problem? you only have to do it once.
<marcin`> I know that you don't care and it's really hard to 'collaborate' with you while you remove almost all changes I do
<marcin`> but anyway it's not a place to talk about it
<marcin`> you are a maintainer
<ArmeBosse> LaserJock: because marcin have a strange "collaborative" work on this package
<marcin`> I'll put all things I'll do to vtigerforge
<LaserJock> it would be *nice* if the .tar.gz unpacked to <packagename>-<version> but it's easy to change
<marcin`> and then you will do uploads I don't care about this package anymore
<ArmeBosse> LaserJock: next release 4.2.4 will be ok, i'm vtiger dev
<ArmeBosse> marcin`: thks
<marcin`> but I still think that's plain stupid to remove such trivial things like I did in last upload
<ArmeBosse> a real different point of view and we proably can't continue to work together
<marcin`> while I change install to put README to /doc and you change this to symlink
<marcin`> I see no point in such work
<ArmeBosse> i never said your change are stupid :)
<ArmeBosse> please be polite
<LaserJock> marcin`: dude, you really need to chill out. Rather than being so aggressive and sometimes rude you should ask questions and see if changes are ok with your "collaborator"
<marcin`> LaserJock: my changes were obvious
<LaserJock> marcin`: obviously they weren't to him
<marcin`> LaserJock: I did only this what sistypotty said in his suggestion on http://revu.tauware.de/details.py?upid=2043
<ArmeBosse> keep cool, we missed dapper now
<ArmeBosse> motu are not god :)
<marcin`> LaserJock: Id like to see the text-files in XTemplate and JPGraph in /usr/share/doc/vtigercrm (or symlinked there)
<ArmeBosse> we can have discussion with them
<ArmeBosse> if we are not agree ;)
<LaserJock> marcin`: fine, but explain those changes and discuss them, don't just say it is stupid for him to not making the changes
<marcin`> LaserJock: so I changed .install to put README to doc
<ArmeBosse> we can explain why we do things
<marcin`> LaserJock: then ArmeBosse removed what I did and said that he likes symlinks...
<marcin`> LaserJock: so such work is plain waste of time for me
<LaserJock> marcin`: no it isn't but sometimes you have to convince your "collaborator" that the changes are worthwile
<ArmeBosse> i don't count how many time you revert my changes ;)
<marcin`> LaserJock: as I said to ArmeBosse there is project on vtigerforge
<ArmeBosse> what you call "regression"
<marcin`> LaserJock: so we should first put our work there and then after discussion - upload to revu
<marcin`> ArmeBosse: well sorry about that, but in my opinion my changes were good
<ArmeBosse> this is word ... you never do that :)
<marcin`> ArmeBosse: anyway in fact these 'regressions' weren't always your fault
<ArmeBosse> yes marcin your changes are always good and mine are "regression", i know the drill
<marcin`> ArmeBosse: for me biggest regression in this package is that we had to remove separate theme packages
<LaserJock> ok,  lets just step back a sec. OK, marcin do you have a reason other than sistpoty said to remove the symlink?
<marcin`> LaserJock: which symlink?
<LaserJock> the README thing
<ArmeBosse> LaserJock: you didn't follow the story :)
<marcin`> LaserJock: in package reviewed by sistypoty there were /XTemplates/README files
<LaserJock> ok
<marcin`> LaserJock: and sistypoty said that he would like to have these files in /doc
<LaserJock> ok
<marcin`> LaserJock: so I changed .install a bit and moved these files to /doc just like he said
<LaserJock> ok
<LaserJock> ok, so ArmeBosse why didn't you like his change?
<marcin`> LaserJock: and now we got new upload in REVU with these changes removed
<marcin`> LaserJock: maybe ArmeBosse just haven't seen these changes
<ArmeBosse> i prefer 2nd proposal : symlink
<marcin`> LaserJock: and he just uploaded older versions of his .install
<ArmeBosse> marcin`: i saw well what you do ;)
<LaserJock> ok, so ArmeBosse prefers symlinks and that is compatible with sistpoty's recomendation
<ArmeBosse> yes but i didn't introduce the symlinks
<marcin`> exactly - you just removed my changes
<ArmeBosse> because i wait a new review of current package
<LaserJock> marcin`: so what you could have done is ask ArmeBosse if he prefers symlinks or actual cp ing
<ArmeBosse> and do all necessary changes
<ArmeBosse> because now we missed dapper
<marcin`> I'm wasting my time
<ArmeBosse> so i don't need to speed up the process
<ArmeBosse> just look how many uploads
<LaserJock> marcin`: my only concern is you will be facing similar problems with any collaboration.
<ArmeBosse> without any reviewing
<ArmeBosse> a miracle if he find someone to collaborate with
<ArmeBosse> he probably never work in a team
<marcin`> ArmeBosse: it's your point of view because you filled ITP and you are 'maintainer'
<marcin`> ArmeBosse: so you think all your changes are ok
<marcin`> ArmeBosse: and sorry but I see no point in arguing what is better - mv README to /doc or symlink
<LaserJock> marcin`: ok, if he is the maintainer then you need to defer to him. But in the end it got fixed correct?
<LaserJock> marcin`: but if you had communicated a little better you could have avoided wasting your work.
<ArmeBosse> https://wiki.ubuntu.com/DebianCollaboration
<marcin`> LaserJock: well not currently he just removed my changes so in his current upload README is in /usr/share/vtigercrm/XTemplate
<LaserJock> ArmeBosse: so did you use symlinks or not address it at all?
<marcin`> LaserJock: he just removed my work and want's to wait for... I don't know... something
<marcin`> LaserJock: and no he didn't introduced symlinks
<ArmeBosse> LaserJock: like said, i'll adress the issue with symlink but i'm waiting a review in case there's othe complains
<LaserJock> marcin`: well, as long as it gets done. He has a legitimate concern. He doesn't want to keep uploading. He wants to get all the changes done at once.
<LaserJock> marcin`: does that make sense?
<marcin`> maybe so as I said - I don't care about this package anymore
<ArmeBosse> there's already 3 uploads, without any review. i don't like this
<marcin`> I'll upload my work to vtigerforge svn and will wait when ArmeBosse will remove this ;)
<marcin`> (or maybe not - who knows ;)
<ArmeBosse> remove what ?
<marcin`> dunno some new changes...
<marcin`> don't you think that we should try to do something with themes again?
<ArmeBosse> no it's part of base package and not an extra amount of size
<marcin`> so maybe someday I'll do something
<Kyral> Actually...how would I package a theme(XFCE, GTK, etc)
<LaserJock> marcin`: If you communicate what you're doing with your collaborator rather than assume that everything you do is going to be unquestionably accepted then it will go much smoother. An if they don't want to make the changes at that time but say they are going to deal with the issue there shouldn't be a problem.
<marcin`> LaserJock: it's not a problem for me - at least is not a problem until these changes do not broke package
<ArmeBosse> each problem we meet, we're never agree, each one have a different point. in a "team" of 2 it's a _bit_ problematic ...
<LaserJock> I agree
<marcin`> exactly
<marcin`> and maybe I'm a little bit too emotional but I'll calm down now
<LaserJock> but Universe is a community effort so we need to be able to "play well" within the team, right?
<marcin`> I was just annoyed by changes that ArmeBosse did yesterday because they broke package
<ArmeBosse> right, but like policies differ in interpretation :)
<marcin`> now package is at least installable so as I said - he want's to be maintainer then now it's his problem
<ArmeBosse> they break anything just not in phase with sistopy comments
<marcin`> ArmeBosse: sorry but you try too much to be 'boss'
<marcin`> ArmeBosse: I just hoped that this package could be 50/50 collaborative work
<marcin`> ArmeBosse: I just don't have time to argue and fight for each change
<marcin`> ArmeBosse: so you can complain about how I collaborate with you
<marcin`> ArmeBosse: but I can do the same
<ArmeBosse> i'm agree for 3 last lines :)
<marcin`> ArmeBosse: you figth for everything - remember how many times we had to change 'copyright' file?
<ArmeBosse> like a mirror
<ArmeBosse> just a different point of view
<marcin`> ArmeBosse: now this file is almost like I did few uploads ago
<ArmeBosse> dog and cat
<LaserJock> marcin`: you can't expect to just come in and expect to be a 50/50 collaborator. You have to recognize that he is the Maintainer and so he has ultimate responsibility for the package. You can work up to that but it takes time I think.
<marcin`> ArmeBosse: but you at least had to try to make this file to look like you want
<ArmeBosse> look copyright file of your original package and come back :)
<marcin`> LaserJock: it's new package
<marcin`> LaserJock: I did my package and he did his
<marcin`> LaserJock: my package was better in some things - his was in other things
<LaserJock> ok
<marcin`> LaserJock: we agreed that we should merge and I did merge job
<marcin`> LaserJock: he is maintainer only because he filed ITP first
<ArmeBosse> lol
<marcin`> LaserJock: so please don't tell me that I have to listen to "Maintainer" as boss and keep quiet when he removes my work
<marcin`> ArmeBosse: nothing funny
<ArmeBosse> you :)
<marcin`> LaserJock: and to be honest another problem was that we were in hurry
<LaserJock> marcin`: I'm not saying keep quite or anything. But don't be rude about it.
<marcin`> LaserJock: because we wanted to put this in dapper
<LaserJock> marcin`: yes, I know and FF can cause a lot of stress
<marcin`> LaserJock: and propably this was biggest problem
<marcin`> anyway I'll still work on this package and software
<marcin`> and as I said I'll upload my changes to SVN
<marcin`> then ArmeBosse will upload things to REVU with any .orig.tar.gz file he wants to
<marcin`> ;)
<LaserJock> marcin`: I'm not blaming you for everything, both of you seem to have some collaboration issues.
<LaserJock> I'm just trying to diffuse the situation a little bit.
<marcin`> well we will see in future
<marcin`> if ArmeBosse will accept some changes in future then we propably could work on this package
<LaserJock> marcin`: I'm sure if you do good work he will
<marcin`> now I need to work on polish translation and some customizations that I will not publish so they are not important to anyone here
<marcin`> LaserJock: I hope so - but today I'm not sure
<LaserJock> ok, well why don't we leave it at that for now, ok?
<ArmeBosse> right
<marcin`> I got different question
<marcin`> what will happen if I'll remove all language* packages in ubuntu?
<LaserJock> umm, I don't think that is a good thing to do
<LaserJock> I think you need to have at least 1
<marcin`> for example how will gnome work if I'll remove all language-pack-gnome* ?
<marcin`> LaserJock: I agree but I'm not sure
<marcin`> LaserJock: synaptic it not trying to stop me
<LaserJock> from removing all of them?
<marcin`> LaserJock: yup
<LaserJock> hmm, maybe ask  -devel
<marcin`> LaserJock: it should complain don't you think so?
<LaserJock> I would have thought so but maybe there is a reason it doesn't
<LaserJock> hmm, I'm trying to think of ways to describe "source tarballs" and "Debian source packages". I keep wanting to call them both source packages. Is there a better terminology for upstream source.?
<dsas> hi guys, I appreciate you're all probably pretty busy at the moment, but could someone point me towards a "how to" on generating meta-packages?
<siretart> dsas: apt-cache show equivs
<dsas> siretart: sweet, thanks muchly.
<LaserJock> hi siretart
<siretart> huhu LaserJock
<LaserJock> siretart: how's it going? it must be pretty late over there
<siretart> LaserJock: it is 11pm. I'm in bed already ;)
<LaserJock> ahh
<Gloubiboulga> I'm not in bed but I'll soon be in
<Gloubiboulga> good night
<LaserJock> cya Gloubiboulga
<dolson> Ohh noooo
<LaserJock> what?
<LaserJock> hi Ubuntu member Hobbsee
<Hobbsee> hey LaserJock
* Hobbsee defenestrates the 2.6.16 kernel which is often making her computer crash on boot with the wireless card.  stupid thing!
<LaserJock> "defenestrates"? must be a .au word
<crimsun> it's not used often in the States; we don't know the value of Chaucer
<crimsun> (at least those of us who didn't major in English lit)
<LaserJock> dang, wasn't even in my OSX dashboard dictionary. I had to use a google search :(
<Toadstool> re MOTUs
<Hobbsee> crimsun: LaserJock: most people dont know it.  not even here
<bluefoxicy> Anyone want to give me a hand building gtk-gnutella 0.96.1 into an official-quality deb on amd64?
<Hobbsee> for the ignorant, defenestration is the act of throwing someone or something out of a window :P
<bluefoxicy> it's a bugfix release on 0.96, the one in dapper is old and refuses to run without manually overriding its "anti-ancient version" thing in the config file
<Toadstool> what's funny is that I understand defenestrate 'cause "defenestration" is a french word ;)
<bluefoxicy> I could just build and install it but I'm looking into making a deb as an exercise
<LaserJock> bluefoxicy: you might start by looking at the source package for the previous version
<bluefoxicy> o.o
<crimsun> there was a uvf exception request for gtk-gnutella, I thought...
<LaserJock> yeah, I believe  so
<marcin`> LaserJock: http://en.wikipedia.org/wiki/Defenestrations_of_Prague
<marcin`> LaserJock: it's propably more .eu word than .au
<LaserJock> yes, I see ;-)
<dolson> LaserJock: I got a new game.. so I guess packaging will take a backseat for a while :)
<Hobbsee> marcin`: i have a habit of trying to insert random words into  my exams - unfortunately, i didnt get the chance to use antidisestablishmentarianism, but i did succeed with defenestration!
<Toadstool> :D
<Hobbsee> hehe
<marcin`> Hobbsee: well this word is propably something unusual for US people
<Hobbsee> probably yeah
<marcin`> Hobbsee: but in Europe we learn about defenestration in high school
<LaserJock> hi minghua
<LaserJock> yeah, no defenestrations here ;-)
#ubuntu-motu 2006-03-02
<marcin`> got a question
<marcin`> could someone tell me it this is acceptable to create package that could change config file created by another package?
<marcin`> s/me it/me if it/
<marcin`> ehh
<marcin`> sorry I'm tired - my english sucks - but I hope you get my point
<crimsun> as in package X would alter a conffile of package Y?
<marcin`> crimsun: yes
<crimsun> I'm pretty sure directly doing so is a grave Policy violation
<marcin`> I give an example - I would like to add language pack for some app
<marcin`> and I need to add this language to some Array entry in main package config
<marcin`> is this acceptable? or policy violation?
<crimsun> http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.4
<marcin`> crimsun: thanks
<crimsun> marcin`: np
<minghua> hello LaserJock
<marcin`> crimsun: ok this is pretty clear
<marcin`> crimsun: but now I don't know how to do one thing
<marcin`> crimsun: maybe you could have some idea
<marcin`> crimsun: thing is: I got package X that depends on A | B | C
<marcin`> crimsun: so I can install any: A | B or C to satisfy dependency
<marcin`> crimsun: then I got a little problem because I need to create some postinst script in X
<marcin`> crimsun: because it has to set some settings in it's config file
<marcin`> crimsun: it has to set if there is A or B or C installed
<marcin`> crimsun: but it is doable
<marcin`> crimsun: problem is that for example I can install X + A + C
<marcin`> crimsun: dependency will be ok
<marcin`> crimsun: but then I can remove C - apt will not complain because there is still A
<crimsun> marcin`: do A && B && C all share one conffile?
<marcin`> crimsun: so still no problem with dependencies
<marcin`> crimsun: but then how could I force X to update it's conffile because C is removed?
<marcin`> crimsun: I think that X will own conffile and will create this with postinst
<marcin`> crimsun: so postinst script could detect if for example there is A and C
<marcin`> crimsun: and will set this in conffile
<crimsun> that seems unwise architecturally
<marcin`> crimsun: I know but don't have any better idea...
<LaserJock> marcin`: why isn't this stuff just all in the same package?
<marcin`> crimsun: and this is why I ask gere
<marcin`> here
<marcin`> LaserJock: because they got different sources, separate development and can be pretty big
<crimsun> ok, do you have control over A, B, and C?
<marcin`> crimsun: what do you mean 'control' ?
<crimsun> marcin`: what is the relation of X to A | B | C ?
<marcin`> crimsun: X needs at last one of them to work properly
<marcin`> crimsun: let's say that X is application and A = english | B = german | C = polish lang packs
<marcin`> crimsun: and then there has to be at least one for this app to work
<marcin`> crimsun: but this application X has to know about them - it needs a list of languages in conffile
<marcin`> crimsun: if I set up dependency X -> A | B | C then I could install only B
<marcin`> crimsun: and because X depends on B then B will be installed first then X
<minghua> one possible solution I can see is not making said config file a conffile
<marcin`> crimsun: so, postinst in X will know that B is available and will add info about B to conffile
<minghua> but provide a tool in X to generate said file according to other configurations
<minghua> then call said tool in A, B, C 's postinst and postrm
<marcin`> crimsun: but then if I'll add C and A there will be no way to add these to conffile owned by X
<crimsun> yeah, that's the issue I'm trying to think of
<marcin`> crimsun: without dpkg-reconfigure X
<crimsun> because you don't necessarily have control over A's, B's, or C's prerm
<marcin`> minghua: could you tell more about your solution?
<marcin`> minghua: I don't understand it yet
<crimsun> that solution is akin to what language-pack-* do
<marcin`> crimsun: yes but unfortunately not in 100%
<crimsun> language-pack-* depend on locales, and each time a language-pack-* is installed, /usr/share/locales/install-language-pack is invoked
<crimsun> yes, that's the issue of "control" that I'm referring to
<marcin`> crimsun: because you can remove all language-pack- and applications that use languages
<crimsun> because to have X function as you wish, you need to provide a means for A, B, and/or C to call some utility provided by X
<marcin`> crimsun: will still work and will be set to default english
<marcin`> crimsun: so you can remove all lang packs and for example gnome will still work
<marcin`> crimsun: my X'app won't
<minghua> marcin`: that doesn't really matter, you can enforce that one of A, B or C must be installed by dependency
<minghua> to make it easier to talk, say your X needs a /etc/X.conf config file
<marcin`> ok and?
<minghua> you don't ship it in your X package, but provide a /usr/bin/update-X-config tool to generate it
<minghua> then your A, B, C can each ship a /etc/X.conf.d/{A,B,C} respectively
<minghua> the update-X-config tool can read these files in /etc/X.conf.d/ and generate a /etc/X.conf file accordingly
<minghua> now you have X Depends: on A | B | C, and have A, B, and C's postinst and postrm scripts all call /usr/bin/update-X-config
<minghua> I think your problem should be solved
<marcin`> minghua: you are optimist ;)
<crimsun> it's more problematic if he's dealing with actual language packs, though, because he doesn't control their post*
<minghua> well, optimist for other people's problem :-)
<marcin`> minghua: because this config file has to be in php syntax
<minghua> crimsun: that's true, I am assuming he has complete control for all X, A, B and C packages
<marcin`> minghua: I will have complete control over X,A,B,C and D-Z ;)
<crimsun> oh, in that case the "problem" is moot
<crimsun> I'm thinking more along the lines of actual language packs, where you might want to compare a hash of the mtime of /var/lib/locales/
<crimsun> it sounds like your issue is much simpler :)
<marcin`> hmm ok maybe but I see a little issue here...
<marcin`> I got X and it provides 'configUpdateTool'
<marcin`> and it depends on A | B | C and minghua says that they should call this configUpdateTool from their postinst?
<marcin`> but they cannot while they don't depend on X :)
<marcin`> and if X depends on A/B/C then one of them will be installed first ;)
<crimsun> if A | B | C use a conffile that X owns, then they each must depend on X
<marcin`> so X-> A | B | C and A->X B->X and so on?
<minghua> hmm, good point
<minghua> that would be a circular dependency
<minghua> now I know why there is a libgtk2.0-bin package :-)
<LaserJock> hmm, I say upload it and see how many users complain ;-)
* LaserJock hides *g*
<crimsun> yep, that's why a lot of packages split out -base and -common, etc.
<minghua> marcin`: split X to two packages, X and X-bin, X would depends on X-bin and A | B | C, but A, B, and C will only depend on X-bin, not X
<minghua> LaserJock: that seems to be some maintainer's opnion as well, unfortunately :-(
<LaserJock> minghua: I don't know that it would make it past REVU and elmo though
<marcin`> minghua: and which package should own this config-tool? X or X-bin ?
<crimsun> the latter
<crimsun> (if you used the former, you'd be in precisely the predicament we've all described)
<marcin`> I see smoke over my head....
<marcin`> so I install X-bin first...
<minghua> LaserJock: well, as a matter of fact, they do
<marcin`> then X which depends on A/B/C so at least one of them will have to be installed right?
<marcin`> so they will run some ConfTool from X-bin to generate config for X ?
<marcin`> am I right?
<minghua> LaserJock: I was sad to see the /usr/lib/pkgconfig/*.pc files installed in skim package, instead of libskim-dev, for example
<minghua> apparently the maintainer hasn't tried using libskim-dev in a pbuilder himself
<minghua> marcin`: roughly right, although you don't need to install X-bin first
<minghua> I believe you can install them together
<minghua> I think A depending X-bin will make sure X-bin is unpacked and configured when A's postinst runs (but I may be wrong)
<marcin`> ok let's assume
<minghua> now after saying that, apparently postrm is not a good place as when running A's postrm X-bin can be already removed...
<marcin`> I run: apt-get install X
<marcin`> it will install X-bin, A, and X
<marcin`> and it's ok
<crimsun> in that case you want X-bin to be a PreDepends of A,B,C
<marcin`> then I want to install B so I run
<marcin`> apt-get install B
<marcin`> X-bin is already there so this will install without problem
<marcin`> but then how will X know that B is installed?
<marcin`> B will have to update configuration?
<crimsun> actually no, don't use PreDepends, as that's a special corner case
<crimsun> Policy 7.2 states that if configuring X is delayed until all of X-bin, A, B, and C are configured
<crimsun> s/if//
<crimsun> or in your case, until X and at least one of A | B | C
<crimsun> argh
<crimsun> until X-bin and at least one of A | B | C
<atie_> hi, all
<LaserJock> hi atie_
<atie_> hi, LaserJock.
<atie_> minghua, ping.
<Se7h> hi
<LaserJock> hi Se7h
<Se7h> hey there LaserJock
<atie_> After writing uvf exception to motu ml, then do I need to upload source package to REVU by myself?
<crimsun> is it a sync, a merge, or a new upstream not in Debian?
<crimsun> (syncs don't need to be uploaded to REVU)
<atie_> Updated version is in Debian.
<crimsun> so it's a sync or a merge?
<atie_> It's sync, I guess.
<crimsun> then there's no need to upload to REVU
<freeflying> atie_: hi
<atie_> freeflying, hi
<atie_> crimsun, then just wait for approval?
<crimsun> yes
<freeflying> atie_: ttf-alee has new upstream released
<atie_> freeflying, yes. I wrote uvf-exception for that.
<minghua> atie_: pong
<atie_> minghua, thank for the mail.
<minghua> atie_: ah, sure, you are welcome :-)
<zakame> hi MOTUs
<atie_> minghua, does corrected one look OK?
<Hobbsee> bug 8681
<Ubugtu> malone bug 8681 in control-center capplets "Changing keyboard layouts in keyboard configuration applet gives an error" [Normal,Rejected]  http://launchpad.net/bugs/8681
<minghua> atie_: haven't looked carefully yet, will reply tonight
<atie_> minghua, thank you.
<LaserJock> hi bmonty
<bmonty> hey LaserJock
<Psi-Jack> Hmm. Where's the basic docs on building a new package? :/
<LaserJock> Psi-Jack: I'd check out some of the links at wiki.ubuntu.com/UbuntuPackagingGuide/Resources
<Psi-Jack> I think I found it. Finally. ;)
<crimsun> that looks familiar, LaserJock ;)
<Psi-Jack> I'm trying to upgrade mldonkey-server to 2.7.3 for me. heh
<LaserJock> crimsun: yep
<zakame> afternoon MOTUs
<Gloubiboulga> morning zakame ;)
<zakame> heya Gloubiboulga! :D
<Hobbsee> hey zakame
<Hobbsee> hey Gloubiboulga
<Gloubiboulga> hi Hobbsee
* Hobbsee wishes her machine built quicker!
<zakame> heya Hobbsee!
<Hobbsee> :)
<zakame> built what?
<Hobbsee> kdenetwork
<Hobbsee> trying to patch it, we'll see if it works
<Hobbsee> heh, doesnt work - wont even build
<zakame> evening MOTUs
<freeflying> zakame: evening
<zakame> hi freeflying :)
<xerxas> hi
<xerxas> we're already in the freeze ?
<xerxas> oops
<xerxas> topic
<xerxas> sorry guys
<LaserJock> ok, I must admit I'm a little confused about UVF exceptions
<LaserJock> it seems like anything that isn't going to cause problems is getting an exception. I thought it had to be important, bug-fix only changes.
<bmonty> I think that if a package doesn't have any packages that depend on it, the UVF exception is a formality
<LaserJock> hmm, well I wish I had known that earlier
<bmonty> why is that?
<LaserJock> because there are quite a few science related packages that I could've gotten in
<bmonty> LaserJock: well there is always dapper+1 :)
<LaserJock> bmonty: yes, I just wish I had known. I guess I was taking UVF more seriously than I needed to
<Kyral> LaserJock: just get them in Debian and then Sync them when Dapper+1 opens :D
<LaserJock> Kyral: I'm talking about syncing from Debian now. I think we could more updated science packages if I had know earlier
<Kyral> ah
<Kyral> soerry lol
<LaserJock> hmm, yeah. we are up to 98 outdated packages in Dapper for MOTU Science.
<Kyral> heh
<Kyral> I may cleanup EasyChem soon
<Kyral> like in debian/
<Kyral> oh...are any outstanding accepted UVF Exceptions going to be brought in?
<LaserJock> Kyral: what do you mean?
<Kyral> Daniel accepted the UVFE for GTKEdit a couple weeks ago but I haven't seen it sync'd
<Kyral> or Accepted
<LaserJock> Kyral: well the syncs and NEW are pretty backed up
<Kyral> ah
<LaserJock> are UVF exceptions harder to get after FF?
<LaserJock> I might try to get a few in before Dapper is released
<Kyral> hmm
<Kyral> I should write a script to build the newest XFCE from SVN
<toma> Kyral: out of curiousity, do you know how many users use xfce as primary desktop?
<marcin`> do I need to be MOTU to post comment to REVU?
<Gloubiboulga> marcin`, I think so
<marcin`> Gloubiboulga: comments to my own packages too :) ?
<Gloubiboulga> oh
<Gloubiboulga> you have to login to comment your packages
<marcin`> I'm in - and what then?
<Gloubiboulga> marcin`, the comment form is on the bottom of your package page
<Gloubiboulga> if you're correctly logged in, you can see and use it
<marcin`> ehhh I see... it's because I'm comaintainer and maintainer did last upload
<marcin`> so I cannot post comment to this package
<marcin`> ok thanks
<Gloubiboulga> np
<marcin`> now I know what to do
<marcin`> another question - is REVU for new packages only?
<jpatrick> no
<marcin`> what if I would like to repackage some existing apps?
<jpatrick> not if someone's working on it
<marcin`> working -> you mean in REVU?
<jpatrick> recently updated
<marcin`> jpatrick: recently updated in REVU or in universe?
<jpatrick> revu
<TomaszD> excuse, there was talk on the motu list to update psi to 0.10. I still don't see Psi updated and it's been a big while. Any news on this?
<marcin`> jpatrick: ok
<marcin`> jpatrick: but what if there is some package but I would like to prepare the same software but in different way?
<jpatrick> I think no
<marcin`> jpatrick: for example: I would like to use CDBS while currently someone doesn't want to... etc. ?
<marcin`> jpatrick: what then?
<jpatrick> well you'll overwrite they're fiels
<bmonty> marcin`: why repackage an app just to change the packaging system?
<marcin`> bmonty: it was just an example
<bmonty> marcin`: it is better to coordinate your changes with the person who packaged the app in the first place
<marcin`> bmonty: sure but what if we don't agre?
<marcin`> agree?
<marcin`> bmonty: and have different visions?
<bmonty> marcin`: is this a hypothetical question, or are you currently trying to make a change the packager doesn't agree with
<marcin`> bmonty: I'm not sure if I want to... because I'm tired, annoyed etc. so I'll propably just leave this
<marcin`> bmonty: but there is such possibility
<marcin`> bmonty: just asking now
<bmonty> marcin`: I guess I would say that in general you should coordinate your changes, but if you can't resolve them you should discuss your proposed changes here
<marcin`> bmonty: it's pretty hard while I'm not MOTU (yet)
<marcin`> bmonty: and cannot comment uploads
<jpatrick> email to packager then
<marcin`> jpatrick: sure but it's not good idea when packager rejects changes right?
<jpatrick> it's up to him
<jpatrick> or her
<spacey> if i want to add items to the gnome menu systemwide, where do i have to throw the desktop files? /usr/share/applications?
<Gloubiboulga> spacey, yes
<spacey> do i need to run a scrip to update the menu?
<spacey> or is it automagicly
<Gloubiboulga> I think you have to run dh_desktop (not sure of this)
<spacey> update-desktop-database
<spacey> seems to be called from dh_desktop
<spacey> ah crap
<spacey> not that easy
<Gloubiboulga> what's the problem spacey ?
* TomaszD is away: Away for whatever reason.
<spacey> well its not about packaging
<spacey> just wanted to quickly add a few items systemwide
<LaserJock_away> hi minghua
<Gloubiboulga> LaserJock, hi
<Gloubiboulga> LaserJock, I've sent a mail to the debian mentors ML to find a sponsor for my texmaker package
<minghua> hi LaserJock
<LaserJock> hi Gloubiboulga
<LaserJock> Gloubiboulga: I saw that, great
<Gloubiboulga> I hope someone will be interested :)
<minghua> Gloubiboulga: yeah, just saw that, good luck
<Gloubiboulga> thanks minghua :)
<Gloubiboulga> my first debian contribution...
<LaserJock> Gloubiboulga: yeah, I realy hope that gets through. I know there were quite a few posts on the ubuntufourms asking for a packag.
* minghua is glad to see texmaker 1.3-1 package having a much simpler dependency
* jpatrick really has to get his packages to debian
<Gloubiboulga> I've also requested an UVF exception for this package
<Gloubiboulga> I've also uploaded on REVU today
<Gloubiboulga> +it
<LaserJock> Gloubiboulga: I got about 4 emails from REVU this morning :-)
<Gloubiboulga> LaserJock, yeah, very minor fixe each time... but 4 uploads needed
<desrt> tseng; !
<desrt> tseng; muine is a real pain in the ass for a few reasons right now
<tseng> desrt: sorry to hear
<tseng> desrt: my local copy is elite
<tseng> desrt: ill upload it as soon as i get freeze aproval
<desrt> tseng; rocking.
<tseng> desrt: :D
<desrt> tseng; does it have gst0.10 and working dbus?
<tseng> desrt: mine does
<desrt> i <3 you
<tseng> desrt: im not sure if ill do gst0.10
<tseng> its in cvs
<desrt> you need to
<tseng> i might backport it
<desrt> gst 0.8 doesn't exist in dapper, really
<tseng> or snapshot
<tseng> its not much of a backport, its well contained
<desrt> i just debfostered my system today and it uninstalled all of my gst0.8 plugins because they're no longer part of ubuntu-desktop
<tseng> just diff and go
<desrt> so i had to reinstall alsa and vorbis to get muine going again
<tseng> yeah i have another bug on that
<tseng> someone actually managed to get a system without playbin
<tseng> for 0.8
<desrt> the solution is not to introduce additional dependencies
<desrt> the solution is 0.10 :)
<tseng> I agree.
<desrt> do you have anything for me to test?
<tseng> not quite
<desrt> k
<tseng> in /usr/bin i have a copy of the 0.8.4 package from debian
<tseng> in /usr/local/bin i have a build of HEAD with gst 0.10
<tseng> something in between is what ill upload
<desrt> i have an irrational aversion to /usr/local
<desrt> probably as a result of years of putting up with freebsd abusing my filesystem
<tseng> i dont like to build random cvs crack in /usr
<tseng> but yeah, bsd gets it not quite right
<tseng> /usr/local/etc makes me stabby
<desrt> :)
<desrt> freebsd makes me feel like /usr/local isn't for me anymore
<desrt> so i use /opt/gnome now
<tseng> we have a "network device" at work called an f5 bigip
<tseng> runs freebsd
<tseng> its a ssl load balancer
<tseng> complete crack
<tseng> after the config file gets to a few thousand lines the web interface falls over and your configuration tool is classic vi
<tseng> real men use ^h
<desrt> I WANT TO FUCKING MURDER EVOLUTION
<desrt> ahem
<tseng> i gave up evolution for lent
<desrt> it sucks so fucking bad these days
<desrt> it's seriously turning into a heaping pile of dung
<tseng> go outsourcing
<desrt> and thunderbird is so bloody ugly
<LaserJock> I like thunderbird cause I can use it in linux, windows, and OSX but I haven't found a "Reply to list" button :(
<dolson> same thing with Gmail for me.. no reply to list.. argh. stupid that only the Ubuntu lists don't set the ReplyTo
<minghua> mutt rules ;-)
<dolson> hey, are any of you guys using Xgl with Gnome?
<desrt> i was.  it's freakin' awesome
<dolson> yes, it is awesome.
<dolson> but I want to know if someone is using it right now and could test if MouseKeys works for them
* minghua wishes he has a video card with better opengl support 
<dolson> X crashes when I try to move the mouse cursor with Gnome mousekeys.
<dolson> this is frustrating
<tepsipakki> dolson: it crashed on me when I tried to write something with the shift down
<tepsipakki> gave up then
<dolson> lol
<dolson> don't use caps!
<tepsipakki> heh
<tepsipakki> don't use environment variables :)
<dolson> argh, I can't take this anymore
<LaserJock> hi crimsun
<dolson> brb
<LaserJock> right now I'm avoiding X anyway ;-) CLI for me
<crimsun> hi LaserJock
<crimsun> that's funny, I'm having my stint w/ Kubuntu ;-)
<LaserJock> crimsun: cool
#ubuntu-motu 2006-03-03
<dolson> back. :(
<LaserJock> hi Hobbsee
<Hobbsee> hey LaserJock
<LaserJock> hi seth
<tseng> I had to turn Xgl off to watch video
<seth> hiya LaserJock
<LaserJock> so does Xgl run regular stuff faster? or is it just bling?
<tseng> its all bling
<tseng> and only works on a few bits of hardware
<tseng> people like to harp on how it makes things appear "smoother" by redrawing damage in an offscreen buffer
<crimsun> KDE won't even load with Xgl on the i810 driver
<tseng> but that makes it play video at half speed
<tseng> on my geforce4 ti
<tseng> not what i consider a low end piece of equipment
<LaserJock> I kinda wish X was faster but I kinda like the bling too. OSX has really nice bling I'm finding.
<Amaranth> OS X bling is nice
<minghua> isn't graphical interface at all just bling? :-P
<dolson> minghua uses one of those keyboards with 4 keys, 0, 1, abort, and enter
<minghua> real men don't need abort
<LaserJock> minghua: to some degree I agree, but there are quite a few apps that just aren't the same in ASCII art ;-)
<dolson> yeah, well, you shouldn't need enter either. you should just code that in with extra 1s and 0s
<dolson> LaserJock: he plays games like UT with libaa :)
<crimsun> abort is for wussies, real men don't need to abort because their programs never have bugs
<minghua> btw I never claimed I don't like bling, or I am a real man :-)
<dolson> Xgl looks great, but simply is way too immature at this time. especially if something like GNOME MouseKeys crashes it. :(
<LaserJock> hi raphink
<raphink> hello LaserJock <><
<LaserJock> how's it going?
<raphink> quite good :)
<raphink> just back from playing billards with a friend
<raphink> and I tried to install Kubuntu DF4 and enable Xgl+compiz to see if it worked "out of the box"
<raphink> how about you LaserJock ?
<LaserJock> I tried to get Flight 4 to install in a OSX qemu but it kept freezing. Breezey installed ok though.
<LaserJock> I'm trying to work on the Packaging Guide and figure if I need to do some UVF exception requests
<LaserJock> I should be doing a lot more work at school but Ubuntu is much more exciting
<raphink> hehe indeed :)
<raphink> LaserJock: is the packaging guide to be released with dapper?
<LaserJock> yes
<raphink> maybe I should spend some time helping you then
<raphink> I'm going to work on REVU2 I think
<raphink> then a bit on klik
<raphink> and I might get some time to work on the packaging guide if you want me in ;)
<LaserJock> it's in the gnome-help, I'm not sure if it is in KDE yet
<LaserJock> raphink: any help is always welcome, I'd like at least to get some MOTU's to look it over when I'm reasonablly done
<raphink> sure :)
<raphink> I have to set some goals now
<raphink> reviewing is not a priority anymore
<raphink> so my main activity is gone ;)
<raphink> and I'm not much of a bug fixer ;)
<LaserJock> I'm not very good at bug fixing either, it seems like it usually comes down to something upstream needs to fix.
<raphink> mhm
<raphink> I'll let people who are good at it fix bugs ;)
<raphink> I'll review and upload fixes when that's useful ;)
<raphink> but I enjoy developping more
<raphink> if I can do it
<LaserJock> everybody has their specialization
<raphink> LaserJock: sure :)
<LaserJock> I'll like organizing and documenting, and merging ;-)
<raphink> yes, too :)
<raphink> I had fun working on the wiki
<raphink> :)
<raphink> I think I'll be waiting a bit for klik
<raphink> although I think it's already in a distro
<LaserJock> hi marcin`
<marcin`> LaserJock: hi
* dolson groans
<LaserJock> dolson: what's wrong?
<dolson> LaserJock: oh lots of things. :)
<Se7h> hi
<dolson> LaserJock: I just discovered some sore spots on my head... gotta ask the doc about that. and I'm disappointed at the Gnome screensaver stuff on the -devel list
<LaserJock> I see
<dolson> I guess I'm stupid to think that a screensaver that requires configuration options should be configurable to be user-friendly
<LaserJock> dolson: well, to be honest I really don't understand why Gnome what it does sometimes. I've given up trying to figure out what they are thinking. For the most part it works for me so I leave it at that.
<dolson> LaserJock: yeah, but it is a source for headaches.. maybe that's where the sore spots came from!
<LaserJock> lol, could be. I've got a hole in my tooth I need to get fixed. Maybe it is from all the Malone bugs ;-)
<dolson> I need to get my wisdom teeth pulled, not looking forward to that
<marcin`> LaserJock: remember our discussion we had yesterday about problems with collaboration?
<LaserJock> marcin`: sorry, was eating dinner. yes, I remember
<hub> is that bug ok to fix? https://launchpad.net/distros/ubuntu/+source/exiv2/+bug/32905
<Ubugtu> malone bug 32905 in exiv2 "improper split -dev and lib and dependencies there of" [Normal,Unconfirmed] 
<hub> I just filed it, and I am willing to fix it
<minghua> hub: looks like proper analysis to me
<hub> minghua: well I'm having the problem
<hub> when I see how the package is made, I'm not surprised
<hub> I'll fix it
<hub> debian has a newer version anyway
<hub> I'll check it a report upstream to have it fixed
<marcin`> LaserJock: no problem...
<hub> so the question is do I upload directly or not
<marcin`> LaserJock: anyway today I just realized that vtigercm package in REVU is broken
<minghua> hub: my understanding is that for new debian version you need a UVF exception, right?  so I'll just upload the fix if I were you
<marcin`> LaserJock: and is broken because Maintainer removed my changes but did it wothout care so now package doesn't work properly in few cases
<hub> no
<hub> not new debian
<hub> juste a patch of this one
<hub> I didn';t intend to update from debian
<LaserJock> minghua: new debian version is ok, just not new upstream version
<minghua> LaserJock: oh yes your are right
<LaserJock> marcin`: ok, well can you make a patch to fix it?
<hub> LaserJock: afaik new debian version not ok
<hub> LaserJock: anyway I'm just fixing the package in place
<hub> LaserJock: I'll check the debian package in sid and submit a debdiff
<LaserJock> hub: no, https://wiki.ubuntu.com/UpstreamVersionFreeze
<hub> LaserJock: new debian = upstream
<LaserJock> no
<hub> "The point at which we cease accepting new upstream versions of packages, whether they are sourced from Debian or not."
<LaserJock> yeah, whether they come from Debian or not we don't take any newer upstream versions which is not the Debian versions
<hub> well whatever.
<hub> there is not need to get a newer version
<hub> just fixing the package
<LaserJock> right
<hub> the newer version will come after the release
<hub> uploaded
<LaserJock> sweet
<crimsun> Seveas: is someone working on the hoary and dapper fixes for CAN-2006-0579?
<crimsun> (rather, did you coordinate w/ someone to push in those fixes?)
<zakame> hello MOTUS
<crimsun> hi zak
<TheMuso> c
<TheMuso> crap...
<jsgotangco> d
<jsgotangco> darn...
<TheMuso> heh!
<TheMuso> Twas the wrong window, as sometimes my KVM decides to hahve a little screw up. :)
<fabbione> hellp
<fabbione> hello
<fabbione> who is "Gauvain Pocentek"?
<crimsun> 'lo fabbione
<fabbione> hey crimsun
<fabbione> does he IRC?
<robitaille> https://wiki.ubuntu.com/Gauvain
<fabbione> thanks
<fabbione> he is  not online
<fabbione> i assume he is a fresh MOTU
<fabbione> right?
<fabbione> can somebody please explain to him that:
<fabbione> Changes:
<fabbione>  splay (0.9.5.2-7build1) dapper; urgency=low
<fabbione>  .
<fabbione>    * Ubuntu rebuild
<fabbione> makes no sense
<fabbione> there must be a reason for a rebuild..
<fabbione> specially for 4 pkgs...
<crimsun> he doesn't have upload right afaict
<fabbione> oh i see
<fabbione> ah ah ah
* fabbione warms up the big fat clue bat 
<zakame> hmm where is he?
<fabbione> ok
<fabbione> thanks for the info guys
<crimsun> np :)
<zakame> hey Gloubiboulga
<Gloubiboulga> hey zakame :)
<zakame> Gloubiboulga: fabbione was looking for you earlier, re: 4 pkgs with `Ubuntu rebuild' in the debian/changelog
<zakame> <fabbione> Changes:
<zakame> <fabbione>  splay (0.9.5.2-7build1) dapper; urgency=low
<zakame> <fabbione>  .
<zakame> <fabbione>    * Ubuntu rebuild
<zakame> <fabbione> makes no sense
<zakame> <fabbione> there must be a reason for a rebuild..
<zakame> <fabbione> specially for 4 pkgs...
<Gloubiboulga> zakame, yes, I mailed me
<Gloubiboulga> he mailed me*
<zakame> ah
<zakame> heya poningru
<Gloubiboulga> I've posted debdiffs on malone for the unmet deps, but have not been precise in the changelog
<Gloubiboulga> this won't happen again ;)
<TheMuso> Is there any way in malone to search only for universe bugs?
<TheMuso> If there is, I haven't found it yet. :)
<raphink> TheMuso: not that I know
<raphink> TheMuso: but when you look at a bug, using the package overview tells you whether it's a universe or main package
<TheMuso> Right. I guess another way would be to look up one's apt-cache to see where it is from.
<Lathiat> hrm is anyone here using apache2 on breezy with suexec on vhosts?
<Lathiat> i cant seem to get mine to play ball and im wondering if theres a bug
<Lathiat> if i pout the SuexecUserGroup line in, the scripts give "immature end of headers back", bu the same script runs fine if i suexec it with mod_userdir (e.g. ~lathiat/squaa.org/test.cgi rather than squaa.org/test.cgi)
<jsgotangco> uh oh
<jsgotangco> tv is now showing tanks
<jsgotangco> oh crap
<raphink> yop gusaweb racoon97
<racoon97> raphink>  hi :)
<raphink> && hello jpatrick too :)
<gusaweb> raphink hello
<jpatrick> yo raphink
<raphink> :)
<raphink> pretty silent today :)
<jpatrick> do you remember what this XDG .desktop file thing was about?
<jpatrick> I'm adding it to the PackagingGuide
<raphink> sure jpatrick I documented it on the wiki
<raphink> https://wiki.ubuntu.com/MOTU/Packages/Reviewing#head-8ee1f680b469a5bb2c262876490529a32362cf9d
<raphink> jpatrick: there are links to FreeDesktop.org
<jpatrick> great
<TheMuso> c
<TheMuso> sorry wrong window again.
<jsgotangco> lol
<TheMuso> Has to do with switching back to this machine with my KVM. I could press the button on the KVM as I moved it onto my desk today, but am still used to using the keyboard to switch around.
<TheMuso> And speakup sometimes likes to play tricks on me.
<Tonio_> hi
<Gloubiboulga> hi Tonio_
<ivoks> hi
<Tonio_> hello Gloubiboulga
<Psi-Jack> Hey, what's the best way to dist-upgrade to dapper right now?
<ivoks> dist-upgrade
<Psi-Jack> With apt, that is. :)
<jpatrick> ^^
<Psi-Jack> dist-upgrade alone, does not prove to work.
<jpatrick> change all breezy's to dapper in /etc/apt/sources.list
<Psi-Jack> Where's the Hoary to Breezy upgrade wiki?
<ivoks> or ask in #ubuntu
<ssam> https://wiki.ubuntu.com/BreezyUpgrade
<Psi-Jack> That's the one. :)
<Psi-Jack> I remember someone saying using that, was safer than just dist-upgrade. and since I have a server running Dapper, now, and it had problems JUST dist-upgrading, with just very bare minimums, I don't want to just dist-upgrade.
<ivoks> ?
<Psi-Jack> Hmm. That's odd..
<Psi-Jack> I was banned in #ubuntu, and I haven't even been there for days..
<ssam> dist-upgrade can remove packages
<ssam> i wondered if somebody could talk me though fixing bug https://launchpad.net/distros/ubuntu/+source/falconseye/+bug/31096
<Ubugtu> malone bug 31096 in falconseye "menu entries of some games not correct" [Normal,Confirmed] 
<ivoks> let me look at that..
<ssam> i am pretty sure it just involves changing the .desktop files for a number of packages
<ssam> or change the $PATH
<ivoks> huh?
<ssam> the gnome games use a full path like /usr/games/sol
<ivoks> /usr/games isn't in PATH?
<ivoks> afaik, /usr/games isn't in PATH only for uid 0
<ivoks> that is - root
<ivoks> it is in my $PATH
<ssam> its not in mine, i installed off a nightly about a week ago
<ssam> maybe its https://launchpad.net/distros/ubuntu/+source/coreutils/+bug/30287
<Ubugtu> malone bug 30287 in coreutils "$PATH screwed up; fixable but doesn't stay after reboot" [Normal,Unconfirmed] 
<ivoks> siretart: ping
<siretart> ivoks: hey ivoks! long time no see, how are you?
<ivoks> broken :( you?
<ivoks> i had a major accident on skiing :/
<ivoks> but... i have one question
<ivoks> i fixed one bug in vpnc, should I ask for UVF exception or just upload it?
<siretart> ivoks: oh,. sad to hear :( - I hope you'll recover soon!
<siretart> ivoks: if the fix doesn't include a new upstream version, which may break other stuff, just upload it
<ivoks> ok
<ivoks> it recreates /var/run/vpnc
<ivoks> i hate that /var/run on tmpfs :/
<ivoks> thanks
<siretart> ah, then its obvious. just fix and upload.
<siretart> and send a copy of your patch as wishlist bug to debian, so that they can include that in their next upload, faciliating our next merge
<ivoks> do they have /var/run on tmpfs too?
<ivoks> if not, then they don't need this
<ivoks> but i will send it...
<siretart> ivoks: there are plans to introduce that in debian as well
* siretart lunch - cu later
<ivoks> bye
<ivoks> bon appetit :)
<fredix> hi
<fredix> what about this bug ? https://launchpad.net/distros/ubuntu/+source/libgtk-mozembed-ruby1.8/+bug/6631
<Ubugtu> malone bug 6631 in libgtk-mozembed-ruby1.8 "libgtkembedmoz.so: cannot open shared object file" [Normal,Confirmed] 
<fredix> Does should I change the severity tag to critical ?
<siretart> a fix would be even better ;)
<fredix> siretart: sure, but how and who ?
<siretart> fredix: who: everyone. how: I don't know about ruby
<fredix> siretart: I suggested to rebuild the package, because it is fixed in Debian testing/sid
<fredix> siretart: So who can rebuild this package ?
<siretart> fredix: ah, after having a loog at this, it seems to be debian #345888
<Ubugtu> debian bug 345888 in libgtk-mozembed-ruby1.8 "package has no lib files." [<em,Fixed]  http://bugs.debian.org/345888
<siretart> so this bug can be fixed by just syncing it
<fredix> siretart: great, so who can syncing ? :)
<siretart> elmo hasn't processed syncs since 3 weeks :(
<jpatrick> he's working on the code
<siretart> this reminds me. I wanted to do another sync report, I will add this sync
<fredix> ok
<siretart> slomo_: do you have any open sync requests?
<siretart> slomo_: could you please paste them me somewhere? I'm preparing a sync summary
<fredix> siretart: libgtk-trayicon-ruby1.8 have the same prob, but not fixed in debian ...
<slomo> siretart: see the answer to your sync-thread on -motu :)
<siretart> slomo: I don't find your answer
<siretart> I see only answers from sistpoty, \sh, dholbach
<slomo_> siretart: "Mon, 20 Feb 2006 14:45:57 +0100"
<slomo_> siretart: but for mono-tools we already have a newer version so remove that
<siretart> slomo_: please bounce me that message, or better, give me an updated list, please
<slomo_> siretart: you can sync libgdiplus, gtk-sharp2, ikvm, nemerle, banshee, ipod-sharp, libipoddevice, gmime2.1... xsp and mod-mono have new upstream versions now in debian so we can't sync them anymore *shrug*
<siretart> email sent
<siretart> okay, another mplayer bug bites the dust
<ogra> siretart, ping ....
<siretart> ogra: hi
<siretart> ogra: did I break something?
<siretart> :)
<ogra> siretart, sorry for 6620, i wasnt aware of it ...
<ogra> didnt know you were working on it
<siretart> ogra: no problem, I'm glad you fixed that
<siretart> ogra: I just subscribed you before closing it, I hope this didn't annoy you too much
<ogra> nah
<ogra> i knew there was such a bug, but malone didnt want to sow it to me ....
<ogra> *show
* ogra thinks sometimes that we probably shouldnt interpret "full text search" with "you need to enter the full text to find it"
<siretart> I know about every mplayer bug, because the motumedia team is bug contact for mplayer and other multimedia related packages
<ogra> ah
<siretart> Seveas: nut?
<Seveas> siretart, see my previous mails about it to the motu list
<Seveas> tuesday, 15:59 and friday 17:05
<siretart> Seveas: besides that the UVF request was not granted yet, did you really check that the packages builds and works correctly in dapper? which version did you check?
<siretart> a mail with the body 'nut' does not suggest me that ;)
<Seveas> lol ;)
<Seveas> I did not check the very latest yet, will do now
<siretart> raphink: we did not agree on the UVF of wesnoth yet
<siretart> that is UVFER (exception request)
<siretart> who is Sasha Tsykin?
<bmonty> siretart: ping
<siretart> bmonty: hey, long time no see, how are you?
<bmonty> siretart: doing well
<bmonty> siretart: question on the open sync email
<bmonty> I think it is missing the packages from the wiki WorkInProgress page
* siretart doesn't see your question
<bmonty> siretart: I think it is missing the packages from the wiki WorkInProgress page
<bmonty> did it make it through that time?
<siretart> bmonty: I didn't check any wiki pages.
<bmonty> OK, do you want me to put the packages on the wiki page in to an email?
<siretart> that would be great
<bmonty> OK, will do
<siretart> I think collecting syncs via email is a better idea. I know that others don't, so I do this experiment.
<bmonty> siretart: thanks for making the effort, we definately needed a change from how it was being done before
<siretart> https://launchpad.net/people/motu/+poll/motu-workflow
<siretart> so nobody voted on using WorkInProgress, most of them voted for using the mailing list.
<siretart> I conclude from that that my opinion seems to be the majority
<bmonty> I think that eventually Malone needs to have features to support MOTU work
<siretart> bmonty: will add your sync request in the next summary next sunday
<bmonty> ok, thanks
<bmonty> grr, #python is useless....anyone done any external module development for python?
<bmonty> hey zakame
<zakame> hello MOTUs! :D
<zakame> hi bmonty! :D
<gusaweb> #ubuntu-doc
<gusaweb> sorry
<gusaweb> :)
<Seveas> siretart, newer nut builds and installs perfectly fine on dapper - can't comment on usage since I don't have a UPS
<sistpoty> hi folks
<trappist> how to mark a bug report as a dupe in malone?
<sistpoty> trappist: there should be a link "mark bug as duplicate" (on the right side iirc)
<sistpoty> dolson: I'm just filing a few bug reports and assign them to you for your packages that have made it into the archive that lack a manpage
<trappist> sistpoty: thanks, totally missed that
<sistpoty> np
* sistpoty is off again... cya
<terrex> ( o Y o )
<G0SUB> hello!
<G0SUB> I contribute directly to Debian which eventually percolate down to Ubuntu ... will this contribution count as contribution to Ubuntu?
<jpatrick> G0SUB: yes
<G0SUB> jpatrick awesome
<jpatrick> all deb devs == ubuntu devs
<G0SUB> jpatrick I am the maintainer of two debian packages in main & also the lead translator of Debian G-I to Bengali
<jpatrick> cool
<G0SUB> jpatrick I wonder if I could do some exclusive ubuntu work too
<G0SUB> jpatrick if you have any packages to maintain, I'd be happy to help
<jpatrick> I can't go though the NM process because I hardly the deb devs
<G0SUB> jpatrick but you are a Ubuntu member ... you can help me with that at least
<jpatrick> I'm MOTU
<G0SUB> aah, a MOTU awesome
<G0SUB> jpatrick can you tell me how I can help?
<jpatrick> right now it's limited to bug fixing
<G0SUB> I see, I can do that too
<jpatrick> http://launchpad.net/people/motu/+assignedbugs
<G0SUB> jpatrick how do I submit fixes?
<jpatrick> get an MOTU to upload it
<G0SUB> ok ...
<G0SUB> jpatrick can/will you?
<jpatrick> sure
<G0SUB> great! :)
<G0SUB> jpatrick one query ... if the bug is fixed in sid, will it still be open in malone?
<jpatrick> if it hasn't been synced no
<G0SUB> hmm
<G0SUB> jpatrick can you point me to some easyfix bug?
<jpatrick> G0SUB: maybe the motu-reviewers team? https://launchpad.net/people/motureviewers/+assignedbugs
<G0SUB> okay, those look easy enough!
<G0SUB> btw, do I need to join the team to submit fixes? or do I just prepare the fixed package and ask someone here?
<jpatrick> prepare and ask
<G0SUB> ok
<siretart> lol: Accepted cdebootstrap 0.3.11 (source i386)
<siretart>    * "The too late for Dapper, but not for Etch" upload
<siretart> err, that was this one: Accepted rsibreak 0.5.0-1 (source i386)
<siretart> not cdebootstrap
<dolson> when's Etch due for release? March
<dolson> March 2009 or so?
<G0SUB> haha
<siretart> dolson: currently debian targets december 2006 for etch release. currently debian is still on track for that date
<dolson> whoa.. why so soon?
<siretart> 18 months since sarge was targeted
<dolson> that's fast for debian though
<dolson> I don't wanna have to reboot my server *again* this Christmas
<siretart> dolson: they targeted 18 month for sarge as well, but there were some, uhm, lets say, 'exceptional circumstances'
<G0SUB> branden's aim in life is to have faster releases in debian
<dolson> I guess I don't have to upgrade my server if I don't want to. ah well, I'm sure there'll be a power outage long enough to trip my UPS shortly after the release
<dolson> G0SUB: is Branden going to release 8 versions of Etch? if so, I want to get Etch Ultimate for my system! :)
<G0SUB> dolson haha!
<G0SUB> jpatrick
<G0SUB> I have fixed Malone #6587
<Ubugtu> malone bug 6587 in seahorse "[patch]  Seahorse uses wrong category Cryptography in .desktop file" [Normal,Unconfirmed]  http://launchpad.net/bugs/6587
<G0SUB> kindly take a look at http://zope.gnowledge.org:8080/ubuntu/seahorse/
<jpatrick> G0SUB: native package
<G0SUB> ?
<jpatrick> there's no .orig.tar.gz or .diff file
<G0SUB> oh, ok ... in a sec
<jpatrick> G0SUB: making a .diff for the patch is better than touch the orig src
<G0SUB> jpatrick http://zope.gnowledge.org:8080/ubuntu/seahorse/diff.patch
<G0SUB> is it ok now?
<jpatrick> looks okay
<G0SUB> jpatrick :)
<G0SUB> when will it be uploaded?
<jpatrick> when I've done
<G0SUB> okay
<G0SUB> jpatrick when are you online usually? I will do more fixes tomorrow ... it's 01:26 here, I will leave now
<jpatrick> I'm online most of the time
<G0SUB> jpatrick yes, but we are in diff. TZs
<G0SUB> I hope you sleep for sometime :)
<jpatrick> I'm GMT + 1
<G0SUB> okay
<G0SUB> I am +05:30
<G0SUB> see you tomorrow
<G0SUB> good night
<jpatrick> night
<G0SUB> jpatrick I hope I didn't bug you too much ....
<jpatrick> not at all
<G0SUB> :)
<G0SUB> bye
<Tonio_> re
<thierry> does the package mathomatic have a gui?
<jpatrick> I don't think so
<thierry> k
<jpatrick> it has libncurses5
<thierry> yeah but I mean the package itself is not a gui right?
<jpatrick> not gui deps
<jpatrick> s/no/not
<jroes> hey guys - I'm not sure if I am experienced enough to go about this - but it appears the samba package may depend on mailutils
<jroes> its panic script uses the mail binary, which is in mailutils
<jroes> I'm still getting acquainted to the whole scene, so I'm not sure my claim is even correct yet
<jroes> I put in a bug report, hopefully I don't get flamed :x
<jroes> https://launchpad.net/distros/ubuntu/+source/samba/+bug/32987
<Ubugtu> malone bug 32987 in samba "Samba depends on mailutils/mailx" [Normal,Unconfirmed] 
#ubuntu-motu 2006-03-04
<herzi> ogra: ping
<herzi> ogra: https://launchpad.net/distros/ubuntu/+source/gartoon/+bug/32995
<Ubugtu> malone bug 32995 in gartoon "Trash display is broken" [Normal,Unconfirmed] 
<ajmitch_> morning
<herzi> hey ajmitch_
<LaserJock> hi all
<fredix> hi
<fredix> there is a bug in a debian package that is not fixed. Does should we wait for a fixe in debian, or can we do an ubuntu package ?
<LaserJock> fredix: do you have a patch?
<fredix> LaserJock: http://librarian.launchpad.net/1208465/libgtk-trayicon-ruby_0.1.0-3%2Bdebianfix337395.debdiff
<fredix> LaserJock: Lucas Nussbaum did it
<LaserJock> fredix: what is the bug # ?
<fredix> LaserJock: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=337395
<Ubugtu> debian bug 337395 in libgtk-trayicon-ruby "FTBFS: Tries to install outside build directory" [<em,Fixed] 
<fredix> LaserJock: it seems that it's fixed, but not integrated into debian sid ....
<LaserJock> fredix: umm, all the bugs I found were closed
<fredix> LaserJock: maybe, but this bug is always here into dapper ...
<fredix> LaserJock: I suggest to apply the debian patch : http://bugs.debian.org/cgi-bin/bugreport.cgi/gtk-trayicon-deb.patch?bug=352277;msg=5;att=1
<LaserJock> fredix: ok, so it looks like the bug is a FTBFS but it builds in Dapper so ...
<fredix> LaserJock: so what ?
<LaserJock> Well if it is a FTBFS bug and it builds then I would think the bug has been fixed
<LaserJock> or is there another problem
<fredix> it's not fixed
<fredix> I see this bug into dapper
<LaserJock> fredix: ok, well it built ok on all arch according to https://launchpad.net/distros/ubuntu/+source/libgtk-trayicon-ruby/0.1.0-4
<fredix> LaserJock: the problem is not the build, the problem is the bad path
<fredix> LaserJock: /usr/lib/ruby/usr/local/lib
<LaserJock> fredix: ok, so then it is not a FTBFS but another issue.
<LaserJock> that is what I was trying to get at
<LaserJock> fredix: that is a pretty easy patch so I would just open a bug in Malone and attach that debdiff.
<fredix> LaserJock: ok, thanks
<ajmitch_> hi LaserJock
<LaserJock> fredix: that debdiff is for a previous version though, it might be nice to have one for the current dapper version
<LaserJock> hi ajmitch_
<LaserJock> ajmitch_: do you have time to look at a simple patch? http://librarian.launchpad.net/1208465/libgtk-trayicon-ruby_0.1.0-3%2Bdebianfix337395.debdiff
<LaserJock> or are you unable to upload over in .au?
<ajmitch_> I can, but I'm working
<ajmitch_> and I like to test things
<LaserJock> fine
<fredix> LaserJock: I don't know how doing a current debdiff
<LaserJock> fredix: I'll do it if you report the bug, ok? ;-)
<fredix> LaserJock: ok, I'll try to do a comprehensible english :)
<LaserJock> fredix: no problem, just give me the bug # when you're done
<fredix> LaserJock: I do it now
<fredix> LaserJock: https://launchpad.net/distros/ubuntu/+source/libgtk-trayicon-ruby/+bug/33000
<Ubugtu> malone bug 33000 in libgtk-trayicon-ruby libgtk-trayicon-ruby1.8 "Package places libs in incorrect directory" [Normal,Unconfirmed] 
<LaserJock> fredix: k
<fredix> LaserJock: heavy copied from the debian report ...
<LaserJock> fredix: yikes, that is bad. I wonder why the Debian maintainer hasn't fixed this
<fredix> LaserJock: sure but I can't wait him
<fredix> LaserJock: I want that my app works fine under dapper
<LaserJock> understandable for sure, we'll get it fixed ;-)
<fredix> LaserJock: thanks a lot ;)
<LaserJock> fredix: actually, the Debian maintainer just didn't apply Lucas' patch right :(
<fredix> LaserJock: in fact I suspected it
<fredix> LaserJock: damog is not interested much any more in ruby-gnome2 ...
<sistpoty> hi folks
<crimsun> 'lo sistpoty
<LaserJock> can I get one of you two to upload a bug fix for me in a sec?
<sistpoty> LaserJock: sure
<sistpoty> LaserJock: have a debdiff at hand?
<LaserJock> sistpoty: working on it :-)
<sistpoty> :)
<sistpoty> LaserJock: just ping me, when you're done ;)
<LaserJock> great thanks. just gotta run it through pbuilder
<LaserJock> fredix: actually, I don't think the patch is right either
<fredix> LaserJock: maybe I should make it ?
<LaserJock> fredix: it's ok, I think I can fix it. it just wants to install to /usr/local/
<fredix> LaserJock: great
<crimsun> (bad!)
<LaserJock> crimsun: it was worse!
<crimsun> oh my. :)
<LaserJock> it was doing /usr/lib/ruby/usr/local/lib/site_ruby/
<crimsun> stabbity.
<LaserJock> crimsun: and that is after the Debian maintainer "fixed" it
<fredix> bye
<LaserJock> hmm, it does it make sense to call $DESTDIR in debian/rules if it isn't in the Makefile?
<LaserJock> s/it does it/does it/
<crimsun> if you mean "pass it to $(MAKE)", then sure
<ajmitch_> if the makefile is going to ignore DESTDIR, it won't help much
<ajmitch_> and so you can end up with builds doing bad & nasty things
<LaserJock> yeah, that is what I'm finding
<crimsun> that's some nasty junk, then
<crimsun> 'morning, ajmitch_
<LaserJock> hmm, I guess lucus just thought it would work
<sistpoty> ajmitch_: what's the right way if I want to take over an ITP? I already wrote the itp-holder a mail, but didn't get an answer yet (270405)
<LaserJock> sistpoty: do you need to email qa or something?
<sistpoty> LaserJock: hm?
<LaserJock> sistpoty: to take over an ITP, don't you email qa for MIA maintainers? I don't know. I just threw something out.
<sistpoty> LaserJock: I'm not quite sure if he's actually MIA... (and before calling qa, I want to make sure that I did all the other parts right ;)
<LaserJock> sure
<LaserJock> how long has the ITP been out?
<sistpoty> sep 2004
<LaserJock> yikes
<g14> How do you make a debian package from the apt-gettable source after you've changed debian/rules compile options?
<g14> Something like the rpmbuild --bb command
<g14> I'm new to the debian way of things
<sistpoty> g14: in short: make -f debian/rules binary or dpkg-buildpackage -rfakeroot...
<g14> sistpoty: you rock. thanks
<sistpoty> g14 no problem... the debian new maintainer guide might be interesting if you want to go a little more in depth ;)
<g14> well I don't think the ubuntu compiz package is compiled with libsrvg support so the svg top and bottom don't work in the cube workspace switcher
<g14> That is something simple that I want to fix
<marcin`> hello MOTUs
<marcin`> got a problem
<sistpoty> hi marcin`
<LaserJock> hi marcin`
<marcin`> I cannot build backage with pbuilder because it fails to fetch some packages
<marcin`> it says that 'Failed to fetch http://...........'
<LaserJock> did you update your pbuilder?
<marcin`> LaserJock: no, how?
<LaserJock> pbuilder update ;-)
<marcin`> aaah
<marcin`> LaserJock: ok running
<crimsun> (you should be updating your pbuilder at least daily)
<tseng> should really make a hook to update pbuilder on every run
<tseng> but im not that motivated
<LaserJock> hmm, if you give a variable to a Makefile does that override hard coded variables?
<sistpoty> LaserJock: only if in the makefile there is s.th. like FOO ?= bar
<LaserJock> sistpoty: so if it is FOO = bar then you can't change it other than changing the Makefile?
<sistpoty> LaserJock: exactly
<LaserJock> darn
<LaserJock> this package has /usr/local in several places in the Makefile but unforunately the Makefile is generated at build time
<LaserJock> so I'm not sure exactly how to change the paths
<LaserJock> can you pass xmkmf options?
<sistpoty> LaserJock: sorry, no experience with xmkmf...
* sistpoty is off to bed
<sistpoty> gn8 everyone
<LaserJock> cya sistpoty
<psusi> well so far git seems like an interesting scm...
<LaserJock> psusi: scm?
<psusi> source configuration management
<psusi> first I used cvs... then svn... now I'm learning git
<psusi> because it's what the linux kernel uses
<LaserJock> psusi: I'm used to them being called rcs (revision control systems)
<psusi> that too
<LaserJock> psusi: have you tried bzr yet?
<ajmitch_> psusi: around these parts bzr is popular :)
<psusi> no, not tried that one yet
<LaserJock> I use bzr and svn, I like both of them
<psusi> what are the main ways that bzr differs from svn?
<LaserJock> for me it is great for local stuff. I don't need a repo
<LaserJock> and you don't have .svn in every directory
<LaserJock> but I'm just a basic user
<psusi> those are things I like so far about git... no central repo and only one .git directory in the root
<LaserJock> yeah, I think there are similarities
<Kyral> Jeez....how much mail have I accumulated...
<psusi> Kyral, my lkml maildir now has 20,936 messages in it... and that's just since Jan 1 ;)
<Kyral> Subscribed to the Kernel-Dev ML are we?
<Kyral> lkml lol I guess you are lol
<psusi> actually, I'm not... I made a 10 line shell script to fetch messages from lkml.org and spool them into a Maildir for me and set it to run every 15 mins as a cron job on a server at work which I access via imap ;)
<psusi> if I subscribed with my normal pop account it would blow my quota in a few hours ;)
<Kyral> psusi: use a GMail Account ;P
<psusi> does that support imap?
<Kyral> I don't think so
<psusi> then it sucks ;)
<Kyral> but FetchMail can grab it
<Kyral> and it does Pop
<Kyral> Where do you think all my ML subscribes go to ;P
<psusi> why get another pop account when I can use lkml.org for much the same purpose? ;)
<Kyral> dunno
<Kyral> if I subscribe to Linux Kernel
<Kyral> I'll make a new GMail Account just for it :P
<psusi> I love imap.... I can't believe I put up with pop3 for so many years
<Kyral> whats so good about it
<Kyral> Frankly POP does what I need it
<Kyral> grabs the email from the server to my computer
<psusi> the mail is stored on the server... this is nice for instance, because mail that I read at work is still marked as read when I get home
<Kyral> this is why I use X11 Forwarding with SSH :P
<Kyral> ssh into this box, forward Sylpheed-Claws, done :D
<psusi> and I have one sent mail folder on the server that holds all sent messages, no matter if I send them from home, work, or elsewhere via the web
<Kyral> Sylpheed is nice
<Kyral> much quicker than Evolution
<psusi> I can start composing an email at home, go to work, and finish it then send it... heh...
<psusi> Sylpheed?
<Kyral> Yah
* psusi uses Thunderbird
<Kyral> it can best be described as XFCE's mail client
<Kyral> I mean its not
<LaserJock> psusi: me too
<Kyral> but they go together well
<psusi> hrm... I see... XFCE is a simple WM right?
<Kyral> Actually I use Slypheed-Claws
<Kyral> psusi: think GNOME-Light
<Kyral> Its a full DE
<Kyral> but lighter and quicker than GNOME
<psusi> ohh, a full DE?
<Kyral> and its FreeDesktop.org complient
<psusi> with it's own set of libraries and all?
<Kyral> sudo apt-get install xubuntu-desktop :P
<psusi> so now you've got qt, gtk, and ???
<LaserJock> I like thunderbird because I can use it in Linux, Windows, and OSX and have it look pretty much the same
<Kyral> psusi: no GTK
<psusi> LaserJock, exactly
<Kyral> I mean it uses GTK
<psusi> Kyral, ohh...
<psusi> so how is it lighter than gnome?
<Kyral> faster
<Kyral> less memory
<Kyral> No MetaCity
<Kyral> ;P
<Kyral> Basically it plays nicely with GNOME
<Kyral> even can use GNOME's themes
<Kyral> well, the GTK ones
<Kyral> The SVN version even has a panel app that allows you to use GNOME Panel Applets
<LaserJock> yeah, XFCE is nice. I used it a fair bit in my Gentoo days
<Kyral> Its compositor owns :D
<Kyral> none of this XCompmgr stuff. XFCE has its own builtin that activates when it detects that you have X setup for it
<psusi> there are just too damn many window managers, desktop environments, and toolkits
<ajmitch_> Kyral: which is the intended behaviour, like kde's integrating compositing
<ajmitch_> or metacity's now
<Kyral> metacity has a compositor? Is it in Dapper?
<ajmitch_> mjg59 uploaded the spiftastic branch
<ajmitch_> and the metacity package itself should have something enabled
<Lathiat> spiftastic or spiftacity? ;p
<Kyral> "spiftasitc"?
<ajmitch_> Lathiat: the package is named spiftacity
<Lathiat> Kyral: "1337"
<Kyral> ....
<Lathiat> ajmitch_: hehe, cool
<ajmitch_> but I think the branch was named otherwise
<Kyral> eci
* ajmitch_ is currently running it
<Lathiat> does compositing work with GL yet?
<Kyral> How stable is it?
<ajmitch_> Lathiat: yes, aiglx
<ajmitch_> Kyral: stability & speed are fine
<Kyral> hmm
<Kyral> when I bounce back to GNOME in a while I'll try it (I seem to switch between XFCE and GNOME on a monthly basis :P)
<LaserJock> argghh, I wish lucas was here. This stupid extconf.rb
<ajmitch_> fine
<LaserJock> I just can't figure out how to pass xmkmf directory options
<LaserJock> ok, so if I pass a variable to a Makefile from debian/rules that is already set in the Makefile, will it override what is in the Makefile?
<LaserJock> Lathiat: ping?
<Lathiat> LaserJock: pong
<LaserJock> Lathiat: your in MOTU Ruby, right?
<Lathiat> LaserJock: yeh, but i havent actually done anything
<Lathiat> LaserJock: whats up?
<LaserJock> well, I'm trying to fix a package
<LaserJock> it's trying to install into /usr/local/
<LaserJock> I was talking with #ruby-lang and they basically said it was because Debian screwed Ruby up ;-)
<Lathiat> haha
<LaserJock> well, the problem is that $sitedir is set to /usr/local/ and it shouldn't be
<LaserJock> so the package I'm working on reads /usr/lib/ruby/1.8/i486-linux/rbconfig.rb and it sets the variables accordingly. Have you seen this before?
<Lathiat> LaserJock: youll probably find it was set like that so external packages get installed to /usr/local
<Lathiat> and debian packages go to /usr/lib
<Lathiat> look at other packages and see how they make it work?
<LaserJock> I've tried but I haven't found anything that works, I'll dig some more
<LaserJock> Lathiat: do you have any idea what would be a good package to look at?
<marcin`> hmm I would like report package bug... but I wonder if there is any sense
<ajmitch_> marcin`: why wouldn't there be any sense?
<marcin`> I reported 5 bugs to malone and 4 hangs as unconfirmed for avg. 4 weeks
<ajmitch_> marcin`: because it requires people to look at them?
<ajmitch_> it doesn't mean that just not filing bugs is the best thing to do
<marcin`> well I agree but I'm not sure if malone is good choice
<ajmitch_> marcin`: if it's a genuine packaging bug that exists in debian, file it there
<marcin`> anyway forget I'll report but I don't like 'dead bugzillas' they are depressing
<marcin`> ajmitch_: ok
<dholbach> good morning
<ajmitch_> morning dholbach
<dholbach> hey ajmitch_!
<ajmitch_> what's up?
<dholbach> a new GNOME is up :)
<dholbach> again... :-)
<dholbach> how are you?
<ajmitch_> alright, still busy working
<jsgotangco> hi dholbach
<jsgotangco> new gnome? oh wow
<ajmitch_> see you all tomorrow
* ajmitch_ detaches
* Lathiat laughs at @ http://uncyclopedia.org/wiki/Kubuntu - "Subuntu, finally allows users to harness the power of the su command"
<Tonio_> hi
<zakame> hi MOTUs
<netzmeister> hello
<netzmeister> "warning: unable to find dependency information for shared library libcodeblocks"
<netzmeister> dpkg-buildpackage -rfakeroot
<netzmeister> ?
<zakame> hey there netzmeister
<zakame> hmm that's probably because there's no libcodeblocks package yet
<netzmeister> zakame:  hi, yes i try to build one..
<netzmeister> from the codeblocks sources..
<netzmeister> i will do this every release for the Ubuntu Community
<netzmeister> but how can i create this package without these libs?
<netzmeister> hm
<netzmeister> zakame:  Any suggestions?
<sivang> hi, are there any main approved peopel here that could sponser me an upload ? :-)
<freeflying> raphink: ping
<raphink> yop freeflying
<freeflying> raphink: I've mis-upload a package to REVU, may you dle it
<raphink> which one?
<freeflying> quarry_0.1.16-1.dsc
<raphink> what do you want? to nuke an entry or to remove a file?
<raphink> ok
<freeflying> remove this, it prepared for mentors
<freeflying> thx
<raphink> I don't see it in the incoming
<raphink> I see quarry entries on REVU
<raphink> so you want me to nuke the thread ?
<freeflying> raphink: the one in REVU should be named in quarry_0.1.16-0ubuntu1
<raphink> mhm
<raphink> well just correct your mistake
<raphink> by uploading a 0ubuntu1
<freeflying> raphink: thx a lot
<raphink> I don't see the problem
<sivang> raphink: are you approved for main?
<raphink> sivang: nope :(
<sivang> ah okay :) I had the impression you are though
<raphink> sivang: how so?
<freeflying> raphink:  dev->core dev
<sivang> don't know :) had a feeling
<raphink> freeflying: what?
<freeflying> raphink: u r in the process of developer ---> core developer
<raphink> no I'm not, so far
<raphink> freeflying: unless you consider any dev is already in the process towards being a core dev
<freeflying> raphink: :) hmm
<freeflying> raphink: hope u r the first one
<raphink> hehe
<raphink> freeflying: haha I'm not good enough to deserve it :p
<marcin`> raphink: hi
<raphink> hi marcin`
<marcin`> raphink: can I report bug in revu-tools package to you here?
<netzmeister> hello
<raphink> marcin`: sure you can :)
<raphink> marcin`: you could report on malone, too
<raphink> hi netzmeister
<netzmeister> hi raphink
<netzmeister> yeah i build atm my first deb Packet..
<netzmeister> i'm really happy.. ;-)
<raphink> I guess :)
<raphink> :)
<marcin`> raphink: there is script - /usr/bin/revu-review
<raphink> \o_  \o/ _o/
<raphink> marcin`: this one is made for revu only, unless you adapt it to the way to organize your stuff
<raphink> i.e. you have your packages organized by name and date as package-yyyymmddhhss
<marcin`> raphink: and in this script there is variable: REVUREPORT=/usr/local/bin/revu-report
<raphink> marcin`: ic, that is a bug but it only matters if you can actually use it on your comp, which I doubt
<raphink> on REVU, revu-report is located in /srv/revu1/scripts/ and linked to in /usr/local/bin/
<raphink> which is the reason why it's like this
<raphink> since it's a REVU-specific script, unlike the other scripts
<raphink> maybe I should not distribute it actually
<gusaweb> hi raphink
<raphink> hi gusaweb
<gusaweb> raphink I am looking for a packager guide
<raphink> https://wiki.ubuntu.com/MOTU/Packages/Packaging/Tips
<raphink> https://wiki.ubuntu.com/MOTU/Packages/Packaging/Tips
<raphink> oops
<gusaweb> raphink thanks :)
<raphink> http://www.debian.org/doc/maint-guide/
<raphink> :)
<raphink> there
<marcin`> raphink: actually not REVUREPORT should point to /usr/bin where /usr/bin/revu-report is available
<raphink> marcin`: yes I totally got your point
<raphink> I can fix that, although I'm not sure you'll be using revu-review on your machine anyway
<Toadstool_> hi MOTUs
<freeflying> any debian DD here
<jamessan> yeah
<G0SUB> I have set up a translation project for our language in launchpad ... now how do I add the translations of different projects to our project?
<pef> hello
<desrt> pef; hello
<Gloubiboulga> hi pef
<pef> Gloubiboulga: salut :)
<netzmeister> hi
<netzmeister> dpkg-shlibdeps: warning: could not find any packages for /opt/wx/2.6/lib/libwx_gtk2u-2.6.so.0 (libwx_gtk2u-2.6.so.0)
<netzmeister> :-(
<ogra> how should it find a package ? you obviously compiled this lib yourself
<nomed> dapper is in "featurefreeze" true ?
<jpatrick> yes
<netzmeister> ogra: i build a deb package from the codeblocks sources..
<ogra> but surely not linked against something sitting in /opt :)
<netzmeister> hmm,
<netzmeister> how can i do that?
<ogra> you should use the libwxgtk2.6-0 package to link against libwx_gtk2
<ogra> u
<netzmeister> hm
<netzmeister> any Howto's?
<netzmeister> i'm new.. but i will maintance some packages which are not in the repos..
<ogra> just put it in the build dependencys and make your code not link against anything in /opt
<netzmeister> okay..
<netzmeister> dependencys are in "control"
<ogra> if you want to build packages, always make sure to only use contents of other existing packages to build them, the packaging system cant access anything apart from data in packages to build your package ...
<ogra> so manually compiled stuff in /opt or /usr/local cant work
<netzmeister> okay..
<netzmeister> codeblocks uses the libwx..
<netzmeister> in the codeblocks compile manual they write you must compile libwx.. yourself
<ogra> put libwxgtk2.6-dev to the Build-Deps: line ... and make sure your code uses the right location for the files
<ogra> that should solve it
<netzmeister> hm its in the line..
<netzmeister> Build-Depends: debhelper, autotools-dev, libc6-dev, libstdc++6-4.0-dev, libwxgtk2.6-dev, wx-common
<ogra> so your code is wrongg, adjust the configure options in the rules file to link against the right file
<netzmeister> hm
<netzmeister> i don't know.. :-(  am i a n00b ?
<netzmeister> hm no chance..
<netzmeister> fu..
<netzmeister> :-(
<netzmeister> dpkg-shlibdeps: warning: could not find any packages for /opt/wx/2.6/lib/libwx_gtk2u-2.6.so.0 (libwx_gtk2u-2.6.so.0)
<netzmeister> the file exists..
<feistel> hi
<feistel> I need generate a new translation of Ubuntu Installer for my country
<feistel> any help can I read?
<dholbach> feistel: it's enough to ask in #ubuntu-devel
<dholbach> feistel: motu is the channel for the universe package maintainers :)
<feistel> ok, thanks
<netzmeister> This package was debianized by netzmeister <netzmeister@source-code.de>
<netzmeister> Is "debianized" the right word?
<dholbach> I'd probably write a real name.
<dholbach> debianized is fine though.
<netzmeister> Copyright Holder: Matthias Gutmann <netzmeister@source-code.de>
<netzmeister> or is the Copyright Holder the Developer of the Program?
<dholbach> the latter
<netzmeister> latter?
<netzmeister> (i'm german :-( )
<ogra> the last
<dholbach> the last part of your sentzence :)
<netzmeister> ah okay..
<netzmeister> ;-)
<dholbach> the developer / author
<dholbach> the former (first part), the latter (the last part) :)
<netzmeister> latter = "das letztere" ;-)
<dholbach> Richtig! :)
<ogra> genau :)
<netzmeister> lol, you speak german??
<ogra> yes
<dholbach> we have quite a bunch of german MOTUs :)
<dholbach> or german speaking :)
<netzmeister> ah okay, i hope i'm in future one of them.
<dholbach> That'd be great! :)
<netzmeister> thx
<dholbach> netzmeister: There's enough to be done until release (7 weeks left) - so you can be sure to have some uploads done and to be more comfortable with everyting. :-)
<netzmeister> oh yes.. :-)
<jpatrick> hey LaserJock
<LaserJock> hi jpatrick
<jpatrick> I sent a patch jjesse's going to commit when he cames back from lunch
<LaserJock> jpatrick: to what?
<jpatrick> PackagingGuide
<LaserJock> jpatrick: hmm, is it the patch you sent me?
<jpatrick> I've added a bit moer
<jpatrick> more*
<LaserJock> jpatrick: can you send it to me as well?
<jpatrick> it's on ubuntu-doc
<LaserJock> oh, ok
<LaserJock> jpatrick: you mind if I take care of it? I was going to do some tweaking
<jpatrick> sure
<jpatrick> but better poke jjesse just in case
<LaserJock> I will
<netzmeister> http://www.ubuntuusers.de/paste/292/
<netzmeister> hmm
<LaserJock> lucas: ping?
<netzmeister> hm
<netzmeister> http://www.ubuntuusers.de/paste/292/
<lucas> LaserJock: pong
<LaserJock> lucas: I need some ruby packaging wisdom :-)
<lucas> yes ?
<LaserJock> I'm trying to fix libgtk-trayicon-ruby
<LaserJock> and  it keeps wanting to install into /usr/local/
<LaserJock> lucas: You provided a patch to it once
<LaserJock> and I was wondering if there were other ruby packages I could look at for help.
<LaserJock> lucas: basically I need to override $sitedir, $sitearchdir, and $sitelibdir
<LaserJock> lucas: any thoughts?
<siretart> hi
<siretart> dholbach: did you poke mdz? did he answer?
<dholbach> siretart: yes i did, no he's not awake yet
<dholbach> (... i suppose)
<dholbach> or not there
<siretart> ok
<siretart> imo we should just start, he had enough time to object ;)
<netzmeister> dholbach: http://www.ubuntuusers.de/paste/292/
<dholbach> ls Makefile*
<netzmeister> Makefile.am  Makefile.in
<dholbach> das ist kein release-tarball oder?
<dholbach> hast du das aus dem cvs?
<dholbach> oops
<dholbach> :-)
<dholbach> you got that from CVS?
<netzmeister> no
<netzmeister> Download-Sektion
<dholbach> so that's a released tarball?
<netzmeister> yes.. 1.0-RC2
<dholbach> you should talk to the upstream maintainer - to ship a proper tarball
<netzmeister> hmm
<netzmeister> can i use the Makefile from the svn?
<dholbach> does it ship a   autogen.sh   or something?
<netzmeister> no
<netzmeister> a ./bootstrap
<netzmeister> that creates the Makefile.am  Makefile.in
<lucas> LaserJock: sorry, missed your message
<lucas> I think that libgtk-trayicon-ruby from debian fixes the issue
<lucas> have you tested it ?
<LaserJock> lucas: yes, the problem is it installs to /usr/local
<LaserJock> your patch helped, but it didn't fix it completely
<lucas> http://bugs.debian.org/cgi-bin/bugreport.cgi/gtk-trayicon-deb.patch?bug=352277;msg=5;att=1
<lucas> have you tried this one ?
<lucas> from the other debian bug report on the subject
<LaserJock> ah, no. I didn't see that one. I'll try that. That is more or less what I was trying to do. I see if that works
<siretart> netzmeister: tell him to release the tarball which comes out when he issues 'make distcheck' after 'bootstrapping'
<netzmeister> k
<netzmeister> i try
<netzmeister> yeahh
<netzmeister> i have a DEB-Package..
<netzmeister> but..
<netzmeister> dpkg-shlibdeps: warning: unable to find dependency information for shared library libwx_gtk2u-2.6 (soname 0, path /opt/wx/2.6/lib/libwx_gtk2u-2.6.so.0, dependency field Depends)
<netzmeister> hmm
<netzmeister> why?
<siretart> strange lib. never heard of that
<netzmeister> libwx...
<netzmeister> wxWidget?!
<netzmeister> siretart: How can i check my DEB-Package..
<jpatrick> lintian -i *.deb
<netzmeister> on my PC it works, because i have all libs installed...
<netzmeister> ahh, k
<LaserJock> lucas: ok, that worked. What are the chances of getting the debian maintainer to fix this?
<lucas> #debian-ruby a while ago: [20:01:39]  <lucas> Mozillion: could you consider NMUing libgtk-trayicon-ruby to fix #352277 with your patch ?
<lucas> no answer yet
<LaserJock> dholbach: can I get you to upload a bugfix?
<jpatrick> or me, if you want
<dholbach> thanks jpatrick
<LaserJock> can I get any MOTU to upload a bugfix for me?
<LaserJock> lucas: so should I get jpatrick to upload a ubuntu1 fix or wait for a NMU?
<lucas> I can upload it if you want, but I'm busy tonight
<lucas> don't wait
<lucas> LaserJock: you aren't a MOTU yet ?
<LaserJock> lucas: no, I got deferred to next TB meeting, whenever that is
<lucas> arg, too bad
<lucas> tell me when it is, I'll come to support you :)
* jpatrick too
<LaserJock> lucas and jpatrick : thanks, that is why I got deferred. My sponsors couldn't make it :(
<LaserJock> jpatrick: http://tiber.tauware.de/~laserjock/libgtk-trayicon-ruby_0.1.0-4ubuntu1.debdiff
<jpatrick> and I took too long
<LaserJock> they did ask a lot of questions and got a little OT :-)
<jpatrick> fetching libgtk-trayicon-ruby
<Tonio_> re
<jpatrick> LaserJock: https://lists.ubuntu.com/archives/dapper-changes/2006-February/006960.html
<LaserJock> jpatrick: beautiful. thank you very much
<jpatrick> no problem
<LaserJock> hi thierry
<thierry> LaserJock : hi
<thierry> LaserJock : does pari-gp is a gui?
<LaserJock> thierry: haven't a clue
<thierry> LaserJock : thanks anyway...
<LaserJock> thierry: sorry, I haven't even heard of it so ...
<thierry> LaserJock : I'm just trying to clean up a little bit the list of packages that need .desktop file for the math section
<LaserJock> thierry: yeah, I know. We need that.
<lucas> LaserJock: next TB is tomorrow
<lucas> + {{{2006-02-28 at 2000UTC}}}
<LaserJock> lucas: yeah, I was just asking mdz in -devel about it
<LaserJock> lucas: it wasn't on anything so he just fixed it
<lucas> ok :)
<LaserJock> thing is I have a meeting scheduled 2000-2100 UTC
<LaserJock> hopefully I can get out early
<lucas> ok I'll try to slow things down tomorrow :)
<LaserJock> lol, yeah. get them OT for a while ;-)
<cyberix> I created a local repository. It complains about authenticating.
<netzmeister> what is TB?
<cyberix> I signed the only package of the repository with my personal gpg-key.
<cyberix> And added it in synaptic to the keys.
<dredg> you sign the Release file
<dredg> gpg -b -o Release.gpg
<cyberix> Hmm.
<cyberix> I don't have such
<cyberix> Only Packages.gz
<LaserJock> netzmeister: Technical Board, hopefully ;-)
<cyberix> How do I create a minimum release file?
<dredg> apt-ftparchive release .
<Seveas> cyberix, you may want to take a look at falcon, It's the thing I wrote for maintaining a small repository
<Seveas> works quite easy, and does things like signing for you 
<Gloubiboulga> Seveas, is falcon available on the Repositories ?
<Seveas> I've not yet asked for it to be included, you can find it in my repo
<netzmeister> LaserJock: Technical Board? What's this?
<Seveas> seveas.ubuntulinux.nl
<Gloubiboulga> thanks Seveas
<LaserJock> Seveas: that reminds me, you do the freenx builds?
<ajmitch_> morning
<Seveas> LaserJock, slh does the work, I just make them work on Breezy
<LaserJock> netzmeister: http://www.ubuntu.com/community/processes/techboard
<LaserJock> Seveas: so are there dapper packages?
<Seveas> LaserJock, not yet
<LaserJock> Sevas: ok, I've been banging my head against freenx for a while. I've just never gotten it to work in Debian or Ubuntu
<Seveas> LaserJock, according to slh his latest kanotix packages only need a rebuild to worl on dapper
<LaserJock> Seveas: but that is probably due to me and not the packages :(
<cyberix> Ign file: binary/ Release.gpg
<cyberix> Ign file: binary/ Release
<cyberix> Ign file: binary/ Packages
<cyberix> This is printed by sudo apt-get update
<cyberix> It ignores my repository?
<netzmeister> LaserJock: Thx
<Seveas> cyberix, seriously, look at falcon, then all you have to do is 'falcon update' and it does all the apt-ftparchive work and more
<thierry> LaserJock : a lot of applications have a menu entry in debian but are terminal apps, should we put a .desktop file with it and put "terminal command" as command to launch?
<LaserJock> thierry: I'm not sure. I think that is something we might want to talk to MOTU or the desktop team about
<lifeless> bug 2397
<Ubugtu> malone bug 2397 in pornview "Pornview segfaults at startup" [Normal,Confirmed]  http://launchpad.net/bugs/2397
<lifeless> I think disabling xine is sane
<lifeless> or removing the gtk2 support
<lifeless> (which is experimental)
<lifeless> I suspect someone needs to take a decision though....
<ajmitch_> morning lifeless
<lifeless> hey aj
<cyberix> Seveas: It not being in Ubuntu repositories was my bigest reason for not trying it immediately
<Seveas> cyberix, understandable
<cyberix> Seveas: And also that I'm trying to learn this so I can develop apt :-)
<cyberix> Seveas: Not to really admin a repository
<Seveas> hehe
<Seveas> in that case you shouldn't use it, it reduces all the dirty work to 'falcon update'
<Seveas> so you learn nothing 
<cyberix> I was reading the Debian Repository howto
<cyberix> But it really doesn't explain this stuff regarding release files for simple repositories.
<Seveas> apt-ftparchive release dists/
<cyberix> I have only one directory called "binary" at my repository root
<cyberix> So will it be "apt-ftparchive release binary" then
<cyberix> And should I put the Release file to root directory or binary/
<astronut> i'm the debian maintainer of a package in universe, the version in ubuntu is not in great shape (upstream), that has been fixed in debian, any way to get the new version put it through the freeze?
<Seveas> mail ubuntu-motu@lists.ubuntu.com with a short summary of the changes - this channel is a bit quiet atm
<astronut> Seveas: is it likely though?
<Seveas> depends on how bad the shape is
<astronut> upstream had THREE seperarate copies of the binary in their package, as well as a fucked up make system that i hacked around
<astronut> newer version is much more sane
<astronut> package is graphmonkey
<Seveas> sounds reasonable to get a UVF
<astronut> uvf?
<Seveas> well, uvf exception
<Seveas> upstreamversionfreeze
<astronut> UVF=?
<astronut> ah
<astronut> so is it RFUVF: graphmonkey as subject or any question/
<astronut> err, RFUVFE
<Seveas> UVF Exception request: ...
<astronut> thanks
<Seveas> but, ubuntu-motu is subscribers-only
<ajmitch_> astronut: sounds like it's worth it, and as the debian maintainer you'd know best
<astronut> ok, cool
<Seveas> ajmitch_, my thoughts exactly
<astronut> oh, damnit
<astronut> can i send to one of you, i really don't want to subscribe
<Seveas> sure
<Seveas> dennis@ubuntu.com
* astronut beats ubuntu over the head with a PUBLIC MAILING LIST CLUEBAT
<Seveas> too much spam
<astronut> SA++
<Seveas> even on a very small list like ubuntu-nl spam is flowing steadily
<Seveas> and SA only recognizes 1 in every 20 spams as spam 
<ajmitch_> at least the lists aren't (quite) as noisy as debian-devel yet
<astronut> Seveas: not for me...looks like you need better filters
<lifeless> so
<lifeless> pornview.
<lifeless> decision.
<lifeless> please.
* Seveas points to ajmitch_ 
<Seveas> he's the MOTU!
* astronut ought to try that as a normal image viewer
<astronut> i use eog, that might be better
<ajmitch_> lifeless: please, no
<lifeless> ajmitch_: please no what ?
<ajmitch_> don't start such discussions here :)
<astronut> aww
<astronut> i want to see
<lifeless> ajmitch_: erm, ??? theres a bug. There are two solutions. Neither has been uploaded.
<astronut> what's wrong with it?
<astronut> it's an image viewer
<astronut> oh
<astronut> nm
<lifeless> ajmitch_: I don't give a rats whether its default or not.
<lifeless> bug 2397
<Ubugtu> malone bug 2397 in pornview "Pornview segfaults at startup" [Normal,Confirmed]  http://launchpad.net/bugs/2397
<lifeless> ajmitch_: ^ please look at the last two comments only.
<ajmitch_> lifeless: right
<cyberix> Should I search for a Debian package maintainer for a package, and only then try to get it into Ubuntu?
<lifeless> all it needs is a 'yes, go gtk1' or 'yes go xineless'
<ajmitch_> I'd say xineless, but I haven't looked at the package at all
<astronut> Seveas: sent
<astronut> let me know if it looks ok
<lifeless> ajmitch_: well it seems to be a) only affects some users [I'm one ;)]  and in the xine detection code
<lifeless> ajmitch_: I just want a fix in the archive :)
<ajmitch_> lifeless: btw bzr seems to be quite painfully slow on cygwin - probably a common issue with cygwin :)
<Seveas> astronut, I'll forward it
<lifeless> ajmitch_: use the plain windows version then ;0
<astronut> Seveas: appreciate it
<lifeless> ajmitch_: which bits are painful though ?
<ajmitch_> mainly merging
<Seveas> argh@evolution 2.5
<lifeless> ajmitch_: over the web or local ?
<Seveas> wants to forward as attachment..
<ajmitch_> local network
<lifeless> 0.7 or 0.8pre ?
<ajmitch_> 0.7
<lifeless> heh, try 0.8
<lifeless> 50% increase in speed for merge style ops
<ajmitch_> if cygwin packages are out for it
<ajmitch_> nice
<astronut> Seveas: you pulled out my sig :-P
<ajmitch_> bzr has been very very useful for this work I'm doing though :)
<astronut> gah, i never finished the first sentance
#ubuntu-motu 2006-03-05
<lifeless> ajmitch_: just pull it
<lifeless> ajmitch_: then run path-to-it/bzr
* sivang hugs bzr for helping him to sort late night HUB madness.
<sivang> have any of your gentelmans been able to have emacs happy under Xgl?
<sivang> s/your/you/
<Seveas> sivang, if emacs can't make me happy, I wont try to make emacs happy :p
<sivang> heheh
<sivang> Well, it keeps me happy pretty well, so I rally want to try and make it comfy for him under Xgl.
<ajmitch_> lifeless: yeah, that just requires some effort :)
<lifeless> pftt
<ajmitch_> and probably about an hour or so to branch it on this link
<netzmeister> yeah..
<netzmeister> my first Ubuntu Package..
<netzmeister> jippie
* netzmeister is dancing around the table..
<netzmeister> can anyone test my package?
<koke> where are the build logs now??
<tseng> in launchpad
<koke> totem is broken on dapper for ppc :(
<koke> w0w
<koke> tseng, where exactly?
<koke> I can't find the link
<tseng> uh
<tseng> you act like *I* can find things in launchpad
<tseng> https://launchpad.net/distros/ubuntu/+builds?build_state=failed
<koke> I'v found it once I knew it was there :)
<koke> err, but it's hard without searching :(
<ajmitch_> koke: launchpad.net/distros/ubuntu/+source/totem
<ajmitch_> and select a version
<ajmitch_> https://launchpad.net/+builds/+build/171108
<ajmitch_> dep-wait
<koke> I got it :)
<koke> it's only me or launchpad is hard to use??
<tseng> i find it amazingly frustrating
<ajmitch_> koke: no, most people are confused by it
<LaserJock> somethings seem cool, others are just terrible
<koke> I think mpt is doing a great job on UI enhacements, but lp grows too fast to be reviewed by only one person
<ajmitch_> and mpt doesn't have the final say on things
<koke> who is also taking care of ubuntu usability, I presume
<koke> ajmitch_, that's another point :)
<ajmitch_> I haven't heard that he's doing ubuntu usability work
<ajmitch_> hopefully I can catch up with him again soon
<koke> ajmitch_, I just know he has filed some usability bugs I'm subscribed to
<koke> my problem is that I don't feel comfortable filing bugs agaisnt LP, being closed source
<koke> mostly because I love to file bugs with patches :)
* ajmitch_ doesn't see that changing anytime soon
<dholbach> good night everybody
<LaserJock> cya dholbach, I like your -motu email.
<dholbach> nice :)
<dholbach> *Wave*
<ajmitch_> ah, now the uvf rules have changed again
<LaserJock> of course ;p
<tseng> oh jeez
<dolson> if I have a kernel that I customize and want it to be the default kernel, what should the package name be? or in the Makefile, what should the ExtraVersion be?
<TheMuso> dolson: Are you using kernel-package to build the kernel?
<dolson> TheMuso: yeah
<dolson> the EXTRAVERSION is =.4 by default
<zakame> hi MOTUs :D
<ajmitch_> hi
<LaserJock> hi zakame
<zakame> hi ajmitch_ LaserJock!
<bmonty> evening everyone
<dolson> hey bmonty
<LaserJock> hi bmonty
<bmonty> hey LaserJock, dolson
<dolson> LaserJock: you get MOTU yet?
<LaserJock> hopefully tomorrow 20:00ish UTC
<dolson> ah, good for you
<ajmitch_> LaserJock: sorry, I can't make it to that meeting either :)
<LaserJock> well, technically I can't make it until 21:00 as I have a meeting
<LaserJock> hopefully I'll have a few more champions at tomorrow's meeting
<bmonty> LaserJock: I'll try to be there
<dolson> I know I can't help in any way, shape, or form, but I'll hopefully be there cheering you on.. :)
<LaserJock> bmonty: that would be great
<LaserJock> dolson: thanks
<LaserJock> I'm really hoping \sh or crimsun will be able to show
<bmonty> anyone working on unmet deps yet?
<ajmitch_> bmonty: sure, people have been doing that for quite awhile
<bmonty> ajmitch_: are people not updating the web page?
<ajmitch_> bmonty: btw hi! :)
<ajmitch_> bmonty: web page?
<bmonty> MOTU/WorkInProgress
<ajmitch_> do you mean the wiki?
<bmonty> ajmitch_: hi to you also :)
* ajmitch_ shudders
<ajmitch_> wikis should not have to be abused for such tasks :)
<ajmitch_> and people probably aren't updating
<bmonty> ajmitch_: yeah, the wiki, I agree that it is not the best for the task
<ajmitch_> and so the wiki pages get stale again
<bmonty> I hope that launchpad will one day support some of these tasks
<ajmitch_> 'one day'
<ajmitch_> seems to be the launchpad motto
<bmonty> :)
<bmonty> hey, its a 50% solution for about 20% of the tasks, still has a way to go
<ajmitch_> heh
<viviersf> omw
<viviersf> 510 updating packages since last night
<viviersf> 0_ol
<Kyral> Did you *just* Dist-Up?
<viviersf> yep
<viviersf> prolly cos of glibc
<ajmitch_> viviersf: and you're on a nice slow connection?
<viviersf> ajmitch_, im in south africa :P
<viviersf> should say it all
<viviersf> im getting 28.9 kb/s now
<viviersf> wait till everyone starts working :(
<viviersf> will go to 4kb/s
<viviersf> :(
<ajmitch_> impressive
* ajmitch_ needs blinkenlights
<viviersf> ajmitch_, im such an idiot
<viviersf> i found out why there are 510 updated packages :(
<ajmitch_> why is that?
<viviersf> i didnt run apt-get dist-upgrade in the chroot :(
<LaserJock> dholbach: hi
<dholbach> hello!
<LaserJock> dholbach: just got your bug comment on the copyright for ubuntu-docs
<dholbach> yeah, i haven't had coffee yet - fear me in that state :-)
* dholbach hugs LaserJock
<LaserJock> dholbach: I couldn't figure out which way to go on that. I was sorta thinking along your lines but I wasn't sure
* LaserJock hugs dholbach back
<ajmitch_> hi dholbach
<dholbach> LaserJock: I absolutely understand
<dholbach> hey andrew!
<ajmitch_> how are you this morning?
<ajmitch_> where's the rest of the german MOTU cabal this morning? ;)
<dholbach> still a bit sleepy, but I'l hopfully be awake enough soon to get the (currently) 16 gnome tarballs packages
<dholbach> packaged
<ajmitch_> great
* dholbach running to get some coffee
* ajmitch_ is still hacking away on code in .au
<dholbach> ajmitch_: you test-built and installed f-spot?
<ajmitch_> dholbach: of course
<dholbach> ajmitch_: how good does it work?
<ajmitch_> works well enough for my personal use
<ajmitch_> I'm in constant contact with upstream as well
<dholbach> ok
* ajmitch_ hasn't put it in debian yet
<ajmitch_> nor have I done something for sqlite db migration
<ajmitch_> however it's remaining in universe & so doesn't need to use sqlite 3 yet
<dholbach> ajmitch_: commented on it, let's see how the others see it
<dholbach> and now I'm back to packaging :)
<ajmitch_> thank you very much :)
<LaserJock> you guys seen wiki.ubuntu.com/Ebuntu?
<ajmitch_> yes, I have
<ajmitch_> he's been in here a few times as well
<ajmitch_> it's probably in part due to my nagging that he put a big disclaimer on the checkinstall-mangled packages :)
<LaserJock> I mean the wiki page specifically, I've talked with him but I hadn't seen any documentation yet
<ajmitch_> right
<jsgotangco> ajmitch_, that is a good thing...indicating about checkinstall
<ajmitch_> the wiki page was one of the first things he put up
<LaserJock> ah, I see
<ajmitch_> jsgotangco: sorry, checkinstall is not mentioned on the wiki page, but it was in his mail to u-users
<jsgotangco> ahh right
<ajmitch_> I think it's about time for me to go offline for the evening
<LaserJock> goodnight guys
<LaserJock> dholbach: I'll be trying for MOTU again at 20:00 UTC :-)
<ajmitch_> night all
<dholbach> nice :)
<dholbach> night ajmitch_
<G0SUB> jpatrick are you free now?
<jpatrick> yes
<G0SUB> jpatrick can we do some bug bashing?
<jpatrick> if you want :)
<G0SUB> jpatrick hey, why not!
<G0SUB> okay, let me find one ...
<jpatrick> I'll be here
<G0SUB> fine
<G0SUB> jpatrick btw, that day, you didn't put my name anywhere on your bug closing report ... how would I prove that I helped you then?
<jpatrick> because they'll go to the bug and see your patch
<jpatrick> next time I'll add
<G0SUB> jpatrick heh, the patch was not mine ... that's the issue
<G0SUB> and I didn't take credit away from the guy by putting in my name there
<G0SUB> okay, no issues
<G0SUB> jpatrick would it be okay if I put my name on the changelog and write ``patch from foo bar'' ?
<jpatrick> yes
<G0SUB> fine
<siretart> morning motus!
<Hobbsee> evening siretart
<jpatrick> guten tag siretart
<siretart> hallo jpatrick :) - Hi Hobbsee
<Hobbsee> jpatrick: wie gehts?
<Hobbsee> doesnt look to be spelt right...
<jpatrick> gut (I guess)
<Hobbsee> :)
<G0SUB> jpatrick http://zope.gnowledge.org:8080/ubuntu/rtfm/
<G0SUB> fixes Malone #32767
<Ubugtu> malone bug 32767 in rtfm "Uninstallable (missing dependency)" [Normal,In progress]  http://launchpad.net/bugs/32767
<G0SUB> jpatrick I just need 4-5 hours ... I will quash all motu-reviewers bugs today
<jpatrick> G0SUB: what's your name so I can upload?
<G0SUB> jpatrick Baishampayan Ghose
<G0SUB> brb
<G0SUB> jpatrick is it okay?
<jpatrick> G0SUB: yep, just about to upload
<G0SUB> :)
<jpatrick> done
<phanatic> hi people
<jpatrick> hi phanatic
<G0SUB> close the bugreport
<jpatrick> did
<G0SUB> ok
<siretart> dholbach: see invite
<Tonio_> hi
<G0SUB> can anyone provide me with a dapper pbuilder base.tgz ?
<G0SUB> jpatrick if I provide you with just the patch, will it do?
<jpatrick> G0SUB: https://wiki.kubuntu.org/PbuilderHowto
<G0SUB> jpatrick I know how to use pbuilder. it's just failing here for some reasons
<jpatrick> no debug?
<G0SUB> yes, it fails at vim-common or something
<G0SUB> jpatrick if I provide you with just the patch, will it do?
<jpatrick> yes
<G0SUB> ok
<StevenK_> G0SUB: I can put a dapper base.tgz on the net if you like.
<G0SUB> StevenK please do
<StevenK> i386 or amd64?
<G0SUB> i386
<G0SUB> thanks in advance
<StevenK> G0SUB: http://wedontsleep.org/~steven/base-dapper-i386.tgz
<StevenK> G0SUB: Keep in mind it's 56Mb, so it will take a little while.
<G0SUB> StevenK I am on a fat pipe :)
<StevenK> I'm not.
<StevenK> You'll average around 22KB/s, since that's what my upload rate will max out at.
<G0SUB> fine
<G0SUB> jpatrick http://zope.gnowledge.org:8080/ubuntu/libccscript3/ccscript.patch
<G0SUB> Closes Malone #32363
<Ubugtu> malone bug 32363 in libccscript3 "libccscript3-1.0-0 has an unmet dep" [Normal,In progress]  http://launchpad.net/bugs/32363
<G0SUB> StevenK I am maxing at 25kBps
<G0SUB> jpatrick got it?
<jpatrick> yep
<G0SUB> ok
<jpatrick> G0SUB: close bug report
<phanatic> siretart: if i have already filed an uvf request (some weeks ago), shall i report it as a bug on malone as well?
<G0SUB> jpatrick i closed it in the changelog
<siretart> phanatic: I'm sorry if I missed your request. Which package was it?
<jpatrick> I don't think that closes it
<G0SUB> jpatrick umm?
<G0SUB> ``Closes: Malone #32363.''
<Ubugtu> malone bug 32363 in libccscript3 "libccscript3-1.0-0 has an unmet dep" [Normal,In progress]  http://launchpad.net/bugs/32363
<StevenK> G0SUB: Let me know when you've finished, so I can remove it.
<G0SUB> StevenK ETA is 30 mins
<G0SUB> jpatrick can you explain what's the issue?
<jpatrick> nothing
<G0SUB> jpatrick all fine then?
<jpatrick> G0SUB: yep :)
<G0SUB> jpatrick :)
<phanatic> siretart: you haven't missed it :) it's gnome-rdp...
<G0SUB> jpatrick do tell me when you become bored ...  I am going to bug you a lot today
<siretart> phanatic: okay. then its approved :)
<jpatrick> G0SUB: I'm writing docs at the same time
<phanatic> siretart: shall i upload the new package to revu then?
<G0SUB> jpatrick oh, I see ... but if I get somebody else to upload, I will relieve you :)
<jpatrick> :)
<siretart> phanatic: whatever you thinks helps to get your package uploaded
<phanatic> siretart: i think i'll do it
<G0SUB> jpatrick http://zope.gnowledge.org:8080/ubuntu/xawtv/xawtv-diff.patch
<G0SUB> Closes Malone #6110
<Ubugtu> malone bug 6110 in xawtv "Incomplete .desktop file" [Normal,In progress]  http://launchpad.net/bugs/6110
<G0SUB> StevenK download done ... thanks a ton! you can remove it now
<jpatrick> G0SUB: I tried to patch that a few days ago, but I couldn't (tarball in a tarball)
<G0SUB> jpatrick what tarball?
<StevenK> G0SUB: No problem.
<G0SUB> jpatrick just apt-get source and patch it
<G0SUB> I could have given the debdiff itself ... but I am on Breezy atm
<jpatrick> G0SUB: inside the .orig.tar.gz there's a .tar.gz
<G0SUB> whoops!
<jpatrick> and I don't know how that works.....yer
<jpatrick> s/yer/yet
<G0SUB> jpatrick use pbuilder
<G0SUB> see the Makefile
<jpatrick> G0SUB: interesting
<G0SUB> do this, just patch the extracted source and build it using pubuilder ...
<G0SUB> since the patch is just for debian/ anyway, it won't affect anything
<phanatic> siretart: http://revu.tauware.de/details.py?upid=2076
<G0SUB> jpatrick are you looking at it?
<jpatrick> G0SUB: yes
<G0SUB> ok
<G0SUB> jpatrick ping me when done, I will then move onto another bug
<jpatrick> G0SUB: packaging src package now
<G0SUB> okay, so I think there were no issues
<G0SUB> done?
<G0SUB> w0000t!
<G0SUB> jpatrick all done, right?
<jpatrick> yes
<G0SUB> ok
<jpatrick> bonjour Gloubiboulga
<Gloubiboulga> bonjour jpatrick :)
<Gloubiboulga> jpatrick, thanks for the uploads
<jpatrick> no problem
<londo> hi there! I would like to ask a question regarding the configuration of DSL while installing breezy. Don't know if this is the right place for doing so, in case it isn't, would you mind pointing me in another direction? thanks!
<jpatrick> #ubuntu ?
<londo> Oops, sorry, yes ubuntu breezy.
<londo> Or rather, breezy and the upcoming dapper
<phanatic> hey Gloubiboulga :)
<G0SUB> londo please ask in #ubuntu
<phanatic> londo: this is not the appropriate channel to ask this imho
<Gloubiboulga> hi phanatic :)
<G0SUB> jpatrick http://zope.gnowledge.org:8080/ubuntu/xmoto-diff.patch
<G0SUB> Closes malone #28491
<Ubugtu> malone bug 28491 in xmoto "[patch]  X-moto has no .desktop file" [Normal,Unconfirmed]  http://launchpad.net/bugs/28491
<londo> @GOSUB, phanatic: thanks for the hint. But as it is a question on the way installation is done by ubuntu, i thought it might be appropriate. I don't have any problems with configuring dsl, but I gave ubuntu to some people which had major problems getting internet done. Could this be done easier in the process of the installation? I think it's one thing that really keeps people off using it. Mind you, if you say "no" I'll be gone in a min
<londo> ute :-)
<G0SUB> londo what exactly is the problem?
<jpatrick> G0SUB: I'm on it
<G0SUB> jpatrick great! you rock!
<jpatrick> true
<G0SUB> lol
<G0SUB> jpatrick I will be back in a while ...
<londo> hmm. I'm trying to get people to use ubuntu, because frankly, for most of them there is really *no* need to use windows, but if they encounter problems in such a basic thing as accessing the net, they might be held back. Would it be possible to integrate pppoeconf more neatly in the installation process?
<G0SUB> londo file an enhancement proposal bug in malone ...
<londo> gosub thanks, I'll try
<G0SUB> londo it's Gee-Zero btw ... :)
<phanatic> raphink: ping
<raphink> wait a min phanatic
<phanatic> okay
<G0SUB> jpatrick is it done?
<jpatrick> G0SUB: almost
<G0SUB> ok
<londo> GOSUB: It's done, thank you for your help and thank you all for the great work you're doing! Bye
<G0SUB> londo you are welcome! thanks for loving Ubuntu
<londo> well, it ain't hard to do :-)
<londo> err, gee-zero?
<G0SUB> londo G-Zero-S-U-B
<londo> GOSUB: *g* ah, i see...
<londo> 00000
<G0SUB> heh
<jpatrick> G0SUB: finish (lunch now)
<G0SUB> jpatrick okay ... I will be back in 30 mins
<janimo> Gloubiboulga: Gauvain?
<janimo> lucas make up you mind ;)
<jpatrick> this could take a while
<G0SUB> jpatrick why?
<Gloubiboulga> janimo, hi
<G0SUB> jpatrick oh, you mean lunch?
<jpatrick> G0SUB: i was talking about lucas
<G0SUB> hehe
<janimo> Gloubiboulga: hi
<janimo> I tried the packages
<janimo> I have some observations
<janimo> overall they're nice
<Gloubiboulga> janimo, I'm waiting for comments :)
<janimo> disperf does not seem to work
<janimo> in 4.2 it shows activity but here it does not
<Gloubiboulga> I tried it yesterday, it worked
<janimo> if it works for you we can assume it something local on my hd
<Gloubiboulga> janimo, I'll test again
<G0SUB> Gloubiboulga your patch for #847 is failing ... I am fixing it
<janimo> ok, packaging issues: I think it may be better to install in /usr/lib/xfce4/panel
<janimo> instead of creating dirs in /usr/lib
<G0SUB> malone #847
<Ubugtu> malone bug 847 in xsmbrowser "After installing xsmbrowser via Synaptic, no menu items in Gnome" [Normal,Unconfirmed]  http://launchpad.net/bugs/847
<janimo> I know mailwatch doers this now, I think I shlud change that
<janimo> and diskperf -s in xfce4-xfce4-disperf-plugin :)
<Gloubiboulga> GOSUB ok
<Gloubiboulga> janimo, I'll rebuild source package
<Gloubiboulga> janimo, maybe I can use alioth svn then
<janimo> like the .desktop files in /usr/share they should be under usr/lib/xfce4/panel
<janimo> janimo, that would be great if it;s not too much trouble
<janimo> I think those even use cdbs whioch is nice
<janimo> at least some do, the ones which do not you could convert them :)
<janimo> it's much cleaner and I intend to do that to the rest of the xfce packages as well
<Gloubiboulga> ok, I'll do that
<janimo> right now they're a mix of cdbs,debhelper and dpatch
<nomed> hi janimo and Gloubiboulga
<janimo> Gloubiboulga: thanks a lot
<Gloubiboulga> hi nomed
<janimo> nomed, hi
<Gloubiboulga> janimo, np
<nomed> Gloubiboulga, i can help you on those pkges
<janimo> Gloubiboulga: all in all great work it would be nice if you were a motu ;)
<nomed> if it's ok for you ..
<nomed> and debian-xfce people told me thay'll use cdbs in future ..
<nomed> there is just xfdesktop that seems will not switch
<janimo> nomed, Gloubiboulga: I will put my bzr archive of current xfce 4.3 packages somewhere so we can all work on them
<Gloubiboulga> nomed, that would be great if you could help
<janimo> nomed, what do you mean xfdesktop will not switch?
<nomed> Gloubiboulga, i can
<nomed> janimo, xfdesktop will not use cdbs
<janimo> nomed, who said that? aren't they the same maintainers?
<Gloubiboulga> nomed, let's discuss this this evening before or after the meeting, I'll have to leave soon
<nomed> janimo, not exactly ...
<janimo> nomed, it says xfce debian maintainers here
<nomed> i think the nick of the xfdesktop maint .. is KIBI
<janimo> anyway that's not a big problem
<nomed> janimo, no
<janimo> as long as most will use cdbs
<janimo> Gloubiboulga: before the meeting woudl be better to not overlap with the meetings
<janimo> let's meet in #xubuntu at 18:00 UTC?
<Gloubiboulga> ok
<janimo> good
<janimo> nomed, as for icon theme, sabdfl just posted a mail to u.announce
<janimo> https://wiki.ubuntu.com/DapperIcons
<janimo> it may not match with our color pallette
<nomed> janimo, cool
<nomed> exactly
<janimo> ok so we meet in the evening
<janimo> bye
<Gloubiboulga> cu janimo
<nomed> bye
<G0SUB> jpatrick
<G0SUB> Gloubiboulga fixed your patch
<G0SUB> http://zope.gnowledge.org:8080/ubuntu/xsmbrowser-patch.diff
<G0SUB> Closes Malone #847
<Ubugtu> malone bug 847 in xsmbrowser "After installing xsmbrowser via Synaptic, no menu items in Gnome" [Normal,Unconfirmed]  http://launchpad.net/bugs/847
<Gloubiboulga> thanks G0SUB :)
<jpatrick> currently doing #33138 which is KDE which is what I specialize in - will look at that soon
<Gloubiboulga> G0SUB, what was the issue ?
<G0SUB> Gloubiboulga it just didn't apply cleanly to the source ...
<G0SUB> Gloubiboulga I think you took a diff between an older source
<G0SUB> or an older deb
<Gloubiboulga> maybe...
<Gloubiboulga> thanks for patching the patch ;)
<G0SUB> Gloubiboulga haha
<G0SUB> Gloubiboulga :) vote for me in the next CC meet
<Gloubiboulga> For membership?
<G0SUB> Gloubiboulga if I apply, yes
<Gloubiboulga> when is the next CC?
<G0SUB> 7th march
<Gloubiboulga> 12:00 UTC...
<G0SUB> as usual
<phanatic> Gloubiboulga: i just saw, that you're a member. congratulations ;)
<Gloubiboulga> I think I won't be present
<G0SUB> Gloubiboulga whoops :(
<Gloubiboulga> thanks phanatic :)
<Gloubiboulga> G0SUB, sorry
<lucas_> oops
<G0SUB> Gloubiboulga that's okay ... no issues
<phanatic> G0SUB: i thought about applying too :)
<G0SUB> phanatic by all means do ... if you think you can
<phanatic> i'm not sure yet
<G0SUB> phanatic what's your contrib. so far?
<G0SUB> jpatrick dude, please close the bug #28491 if you have uploaded the fix
<Ubugtu> malone bug 28491 in xmoto "[patch]  X-moto has no .desktop file" [Normal,Unconfirmed]  http://launchpad.net/bugs/28491
<Gloubiboulga> phanatic is *the* hungarian ubuntu guy ;)
<G0SUB> haha
<phanatic> G0SUB: https://wiki.ubuntu.com/SzilveszterFarkas
<G0SUB> Gloubiboulga I am _the_ Indian Ubuntero
<phanatic> cool :)
<Gloubiboulga> G0SUB, yep, just saw this :)
<G0SUB> Gloubiboulga where?
<Gloubiboulga> G0SUB, on LP and wiki.u.c
<G0SUB> hehe
<jpatrick> http://wiki.ubuntu.com/PatrickDavies
<G0SUB> jpatrick yours I have seen ages back ... and I am trying to emulate that :)
<jpatrick> :)
<phanatic> jpatrick: congrats goes to you as well for becoming a member ;)
<G0SUB> phanatic he's a MOTU now
<G0SUB> he became a MOTU from a member very quickly
<Gloubiboulga> later
<phanatic> he deserves it ;)
<G0SUB> no doubt
<jpatrick> phanatic: thanks :)
<G0SUB> jpatrick I need to patch my stomach with some food ... brb soon
<raphink> phanatic: I'm sorry I was in bugfixing
<phanatic> raphink: no problem of course :)
<phanatic> raphink: i just uploaded a new version of gnome-rdp since the uvf exception was accepted
<phanatic> (uploaded to revu of course :))
<phanatic> http://revu.tauware.de/details.py?upid=2076
<raphink> good
<raphink> ok I'll look at it later ok?
<raphink> can you send me the url by email?
<phanatic> yep
<phanatic> thanks a lot
<siretart> dholbach: http://siretart.tauware.de/mldonkey/ are my new mldonkey packages. please test
<siretart> (other testers may do as well)
<siretart> dholbach: things to spot: does /etc/default/mldonkey-server really get that MLDONKEY_USER variable? is it correct?
<siretart> perhaps I should do more sophisticated checks in the init script: fail if $MLDONKEY_USER is unset to require the user to set it there
<siretart> hm
<G0SUB> jpatrick are you done with the xsmbrowser patch?
<jpatrick> I haven't finished kfocus yet
<G0SUB> oh
<G0SUB> any other MOTUs here?
<jpatrick> should be
<G0SUB> jpatrick let me find one :)
* G0SUB is fixing Malone #1299 now
<Ubugtu> malone bug 1299 in librmagick-ruby "Image.read(filename) eats characters from filename" [Major,Confirmed]  http://launchpad.net/bugs/1299
<lucas> G0SUB: what do you mean by "fixing" ?
<G0SUB> lucas I am backporting the latest version to Breezy
<lucas> please note that uploads to breezy-updates have to be reviewed
<G0SUB> lucas hmm, but that's the only way to fix it ... what to do?
<lucas> last time I asked, the infrastructure wasn't ready for uploads to breezy-updates
<lucas> but you could ask on #ubuntu-devel if you want
<G0SUB> damn!
<lucas> (soyuz, etc)
<lucas> (it was one or two weeks ago)
<G0SUB> hmm
<ogra> it should work now ... at least my update to ltsp (which was the first guinea pig upload to -updates after the change) is in the archive
<lucas> ok
<ogra> not sure hiw much manual intervention was required behind the scenes though ... might be that you have to poke somebody to trigger the copying from buildd to archive
<G0SUB> ogra any specific person to poke?
<ogra> but up to that point it whould work automatically
<ogra> G0SUB, anyway, you need to get the package revierwed first by Kamin or mdz for -updates ...
<ogra> -updates are a closed process based on approval :)
<G0SUB> ummf! too much pain ....
<ogra> if you want the quick path, use backports ...
* G0SUB drops the plan ...
<ogra> ... but that requires that the package from dapper works unmodified in breezy
<G0SUB> ogra it most probably does
<ogra> just make sure it *does* (probably isnt enough) and poke the ubuntu-backports mailing list to trigger a backport from the dapper package
<G0SUB> okay, will do that
<G0SUB> ogra are you a MOTU?
<ogra> partially, yes :)
<G0SUB> ogra partially?
<jpatrick> the boss
<ogra> since i'm main developer i dont have much time left for MOTU anymore ....
<G0SUB> ogra heh ...
<ogra> jpatrick, a boss does something actively :)
<G0SUB> jpatrick when will you be free again?
<jpatrick> ogra: right :)
<ogra> i'm rather the guy who cant leave his fingers from projects he likes, even if he has no time for them :)
<jpatrick> G0SUB: soon - pbuilder isn't happy
<G0SUB> jpatrick haha
<viviersf> lol ogra :)
<ogra> dholbach is more "boss" than me ... and even he will object that term :)
<G0SUB> any MOTU here who's a bit free now?
<G0SUB> lucas ?
<dholbach> G0SUB: what are you looking for?
<lucas> nope, I'm at work
<G0SUB> dholbach I need a patch to be uploaded
<G0SUB> I am trying to clear up all the motu-reviewers bugs
<dholbach> if it's on motureviewers, it will get processed
<netzmeister> dholbach:  I have my first Package created! I'm happy.. ;-)
<dholbach> netzmeister: ROCKNROLL :)
* netzmeister is dancing arround the table..
<netzmeister> ;-)
<G0SUB> dholbach the processing is what I want
<dholbach> G0SUB: yes, it's not something that "is lost" - it will get processed
<dholbach> G0SUB: I'm busy too.
<G0SUB> dholbach oh, okay then ... /me will wait for jpatrick :)
<dholbach> patience :)
<G0SUB> dholbach actually, I am just taking the patches from malone and then testing/cleaning them up and getting them uploaded
<dholbach> yeah, just attach your new patch to the bug and you are fine
<G0SUB> making the job easy for the MOTUs
<G0SUB> ok
<dholbach> Thanks for yout work.
<G0SUB> dholbach :)
* jpatrick pushes kfocus towards pbuilder
<jpatrick> hey zakame
<zakame> hi jpatrick
<Kyral> Morning
<zakame> hi Morning
<zakame> este Kyral :P
<freeflying> any motus here now ?
<Kyral> so what option do I have to flip to get MetaCity's compositor going?
<Mithrandir> gconftool-2 /apps/metacity/general/compositing_manager --type bool --set true
<Mithrandir> I assume you mean spiftacity
* zakame is reminded to go drag his CPU to the cafe tomorrow
<Kyral> yah that didn't work lol
<G0SUB> jpatrick
<jpatrick> hi G0SUB
<G0SUB> jpatrick is pbuilder happy?
<jpatrick> should be this time
<jpatrick> I found out what I did wrong
<G0SUB> i see
<freeflying> jpatrick: hi
<jpatrick> afternoon freeflying
<freeflying> jpatrick: may I upload package to REVU and send RFS to debian-mentors ?
<jpatrick> RFS?
<G0SUB> Sync Request
<azeem> request for sponsor
<G0SUB> oops, sponsor
<jpatrick> why not?
<freeflying> jpatrick: really?
<jpatrick> I have to get some packages sponsored too
<jpatrick> I don't see why you can't
<G0SUB> jpatrick is there any RFP equivalent for Ubuntu?
<G0SUB> Request For Package
<jpatrick> here's the wiki pages for package requests
<jpatrick> s/here's/there's
<G0SUB> let me find it
* freeflying hope that one day ubuntu needn't sync or merge anyhing from debian 
<jpatrick> it will
<G0SUB> freeflying why do you want that?
<freeflying> G0SUB: why shall merge or sync from debian ?
<jpatrick> AAH!!
<G0SUB> freeflying so that the two projects can cooperate with each other?
<freeflying> G0SUB: I think ubuntu is ubuntu ,and debain is debian , we can cooperate in other ways after all , not merge or sync package from debain
<G0SUB> freeflying well, I like to think otherwise ... let's not reinvent the wheel here
<freeflying> G0SUB: why don't debian merge or sync anything from ubuntu ?
<G0SUB> freeflying iirc they do, sometimes
<lucas> freeflying: you don't seem to have a clear understanding of the issues here.
<lucas> it isn't "debian versus ubuntu"
<G0SUB> where is the RFP page for Ubuntu?
<ogra> G0SUB, UniverseCandidates on the wiki
<jpatrick> https://wiki.kubuntu.org/MOTU/Packages/Candidates
<G0SUB> ogra thanks
<zakame> gaah, REVU borks :(
<zakame> it doesn't like lengthy replies :'(
<dolson> zakame: only use 2-digit dates plz. we need to save space
<dolson> what the? why is the Candidates page all Kubuntu-ized?
<dolson> oh, I see now, lol
<zakame> freeflying: it does, for some patches
<freeflying> zakame: I see , I just hope that we needn't sync or merge from debian
<zakame> dolson: huh?
<dolson> zakame: lame y2k joke... I'm tired...
<zakame> dolson: hehe
<G0SUB> dolson haha
<jpatrick> G0SUB: what was the thing you wanted me to look at?
<G0SUB> jpatrick http://zope.gnowledge.org:8080/ubuntu/xsmbrowser-patch.diff
<siretart> if anyone wants to earn a beer, please try to get debians current mldonkey running in dapper :/
<zakame> G0SUB: ah so you're the one who sent that
<G0SUB> zakame is that broken?
<jpatrick> siretart: what's wrong with it?
<zakame> G0SUB: I'm actually doing that now
<G0SUB> zakame oh, I see
<jpatrick> zakame: you'll upload?
<siretart> jpatrick: the postinst creates a bad downloads.ini and some helper tool parsing it fails afterwards, making postinst failing completly
<siretart> jpatrick: http://siretart.tauware.de/mldonkey is my current state
<G0SUB> zakame if you are free then I'd like to triage+fix atleast 5 more motu-reviewers bugs today
<zakame> siretart: putting that to my WorkStack
<zakame> G0SUB: it's night here, but I'll triage tomorrow ;D
<G0SUB> zakame heh, it's night here too ... but it's okay
<G0SUB> jpatrick ?
<jpatrick> I'll do it
<G0SUB> zakame are you uploading that one?
<G0SUB> zakame ?
<xerxas> hi
<G0SUB> xerxas Bon Jour!
<xerxas> bonjour G0SUB
<xerxas> :)
<G0SUB> xerxas is that one word?
<xerxas> G0SUB: right
<xerxas> it is
<G0SUB> xerxas heh, my French is b0rked
<xerxas> np
<G0SUB> jpatrick is that done?
<jpatrick> oh I thought zakame was doing it
<G0SUB> he just left
<G0SUB> done?
<jpatrick> I've just finished a patch for the PackGuide
<G0SUB> I see
<G0SUB> jpatrick I have to leave now, will you take care of it?
<jpatrick> yes
<jpatrick> right now
<G0SUB> jpatrick okay, this is one more before I leave, http://zope.gnowledge.org:8080/ubuntu/xastir-patch.diff
<G0SUB> closes malone #2184
<Ubugtu> malone bug 2184 in xastir "Xastir error on libgdal1" [Normal,In progress]  http://launchpad.net/bugs/2184
<G0SUB> jpatrick kindly upload that too ... Good Night!
<jpatrick> ok
<G0SUB> jpatrick thanks a lot ... I will be back tomorrow for more bugging :)
<dolson> woo
<dolson> another friend agreed to let me install Ubuntu on her system, all thanks to seeing an Xgl video, and learning about 8 versions of Vista :D
<jpatrick> hehe
<dolson> she is going to cook me steak to do it :) yummy
<Kyral> lol
<Kyral> Lucky BASTARD :P
<dolson> on the BBQ
<jpatrick> :9
<jpatrick> hey Gloubiboulga
<Gloubiboulga> hi jpatrick :)
<jpatrick> Gloubiboulga: I uploaded YaFix of yours
<Gloubiboulga> jpatrick, thanks
<nomed> do you know how i can generate a patch for a deb that's using dbs ?
<jpatrick> cdbs?
<nomed> jpatrick, not exactly
<nomed> there is a tar.bz2 and a debian dir ...
<nomed> then it can use even cdbs ...
<jpatrick> repackage .tar.bz2 to tar.gz
<azeem> nomed: just stick the patch into debian/patches for dbs
<azeem> and hope it applies
<chillywilly> anyone here running dapper?
<LaserJock> lol
<chillywilly> :)
<Gloubiboulga> hi LaserJock :)
<chillywilly> just wondering if I should give it a spin on my workstation
<LaserJock> I've been using it for my everyday use since November some time.
<LaserJock> chillywilly: it probably depends on what you're doing. for me it has been great since xorg and the kernel stabilized
<chillywilly> I have a shuttle SK21G w/ 1GB RAM and an Athlon 64 3400+ proc running 64Bit Breezy Badger
<chillywilly> just want a newere firefox and such because the i686 one off moz.org doesn't work ;)
<hub> wtf does t-bird start epiphany instead of firefox
<azeem> mutt does the exact opposite for me, which I hate
<chillywilly> cause of the default browser setting?
<hub> chillywilly: no
<hub> all the other application behave properly
<hub> and I check the setting
* chillywilly goes for broke and does a dist-upgrade
<chillywilly> :)
<hub> enjou
<hub> enjoy
<azeem> hub: could be mime settings
<LaserJock> hi azeem
<hub> something broke
<hub> because it was working
<azeem> hi LaserJock!
<LaserJock> I'm going to need you to sponsor a new upstream of gausssum for me soon
<chillywilly> oh I also have a 10k RPM WD Raptor in this baby
<chillywilly> :)
<chillywilly> 74GB
<azeem> LaserJock: sure
<Amaranth_> chillywilly: Better make a lot of backups.
<Amaranth_> chillywilly: WD sucks. :)
<chillywilly> I have 6 months of incremental backups on the RAID array, but I've only heard good things about the raptor
<chillywilly> only thing I don't like about it is that it's a little noisy
<dolson> LaserJock: how many hours away is your ceremony?
<LaserJock> dolson: lol, 2. but it might be a funeral ;-|
<dolson> pfft
<chillywilly> bah
<chillywilly> anyone know if there's a via unichrome driver that works with dapper's xorg?
<kyrel> hello
<kyrel> i've a question :
<kyrel> Is there a problem with the 2.6.12 kernel ? I'can't compile some programs because of the gen_crc32table.c file and/or the uint32_t type...
<LaserJock> hi fredix
<fredix> hi LaserJock
<chillywilly> nevermind
<chillywilly> thing I found it
<fredix> LaserJock: thanks for the fix
<chillywilly> xserver-xorg-driver-via
<LaserJock> fredix: np, took me a while but I figured it out ;-)
<fredix> LaserJock: hh :)
<sistpoty> hi folks
<Tonio_> yop sistpoty
<Gloubiboulga> hey sistpoty
<sistpoty> hi Tonio_, Gloubiboulga
<Gloubiboulga> salut Tonio_
<kyrel> can you help me ?
<Tonio_> salut Gloubiboulga
<sistpoty> what's your problem kyrel?
<sistpoty> Tonio_: you did the netswitch packaging, right?
<Tonio_> sistpoty: yes, although I didn't have the time to correctly test them :)
<Tonio_> Gloubiboulga helped on the gnetswitch part
<sistpoty> Tonio_: imo you should use library packaging style (-dev and lib package) for it...
<sistpoty> Tonio_: at least if there are other distinct sourcepackages, that depend on it
<sistpoty> Tonio_: otherwise the upgrade path might break
<chillywilly> looks beautiful
<Tonio_> sistpoty: I agree on that point
<sistpoty> :)
<chillywilly> weird the thunderbird help dialog is missing the logo/icon on it
<Tonio_> but the fact is that the -dev and lib might never be used, and well, I had so little time to package them..........;
<Tonio_> 3 packages in an hour........
<chillywilly> wonder if I should remove the existing profile
<Tonio_> I'll do better with the bext version :)
<sistpoty> Tonio_: great :)
<Tonio_> in fact on 22 at 16pm, the sources where completly crappy, and freeze was on 23 so..........
<kyrel> sistpoty, while I try to compile some programs (geexbox, mplayer or even the linux 2.6.12 kernel) an error occured with the gen_crc32table.c file that don't recognize uint32_t type.
<LaserJock> hi sistpoty
<sistpoty> hi LaserJock
<kyrel> sistpoty, gen_crc32table.c is a file from the kernel sources
<sistpoty> kyrel: hm...
<kyrel> sistpoty, and the mplayer compilation fails because of th uint32_t type too
<Tonio_> sistpoty: do you think that is a reason to reject them ?
<sistpoty> Tonio_: not quite sure about that... don't know the exact policy for the new-queue
<Tonio_> sistpoty: ok
<kyrel> sistpoty, do you have an idea ?
<sistpoty> kyrel: not really, I'll just try s.th.
<sistpoty> kyrel: imo uint32_t should be defined in stdint.h or sys/types.h ... and for the linux source I saw it defined in linux/types.h
<sistpoty> kyrel: maybe there's an #include missing?
<kyrel> sistpoty, I've thought about this eventuality, but i've already built the programs that fail on a debian system
<kyrel> (sorry for my english level)
<sistpoty> kyrel: maybe some semantics in gcc changed, and uint32_t isn't defined any longer by default?
<kyrel> sistpoty, maybe... i'll search
<derekS> hey, is there a priority list for universe candidates? there is one i think would be good for dapper
<sistpoty> derekS: no, there isn't... and we're in featurefreeze now, so we won't add new packages to dapper any longer
<derekS> sistpoty: good answer :)
<LaserJock> TB Meeting is about to start
<dolson> LaserJock: congrats buddy!!!
<sistpoty> hi dolson
<dolson> hi sistpoty
<sistpoty> dolson: imo you should go for motu too ;)
<LaserJock> WOOOOTTT!!!!!!!!!
<dolson> I should?
<dholbach> for your hardcore ubuntustudio efforts
<sistpoty> dolson: based on the packages you uploaded to revu, of course!
<dholbach> are you a ubuntumember already?
<jpatrick> dolson: it's true
<dolson> no, I am an ubuntero though
<dholbach> so we have something to write up for the MOTU report! :)
<jpatrick> New MOTUs:
<LaserJock> phewww, I could hardly type I was so nervous
<sistpoty> dolson: then the next step is to become a member... CommunityCouncil  approves members, just see the wiki-page for it ;)
<dolson> I'll check that out then, and maybe I can be a member :)
<dolson> you guys are encouraging
<LaserJock> umm, do I need to do anything now or is it just a flip of a LP switch?
<sistpoty> LaserJock: once you're in the LP group, you should be able to upload
<LaserJock> sistpoty: ok, thanks.
<dolson> A member is someone who's made a substantial contribution to the Ubuntu community
<sistpoty> ogra: btw.: can you make me an administrator for the LP motu group? otherwise I can't create polls
<netzmeister> hi
<LaserJock> wow, they already updated it, and I think I even got some Karma ;-)
<sistpoty> dolson: yes, and you've certainly done a substantial contribution already :)
<dolson> by whose measurement?
<dholbach> mine too
<dholbach> :)
<dolson> it hasn't been for very long yet, so I don't think it meets the "sustained" requirement yet
<LaserJock> dolson: I think the general rule is if you've been helping for >= 2 months
<LaserJock> in any way
<LaserJock> not just here
<jpatrick> I've done 7
<dolson> well it'll be almost 2 months soon since I started the wiki, even though I first contacted Mark about better music production support many months ago
<LaserJock> dolson: then I don't think you'll have much of a problem ;-)
<dolson> I guess it's close enough. if not, then I'll just re-apply at a later date
<sistpoty> LaserJock: just gave you reviewing rights on revu ;)
<LaserJock> sistpoty: very nice, I was going to ask you about that :-)
<sistpoty> hehe
<LaserJock> I would like to get more involved with REVU
<dholbach> hear hear!
<sistpoty> that's great news :)
<netzmeister> ;-)
<LaserJock> I'm more interested in fixes, etc. to existing packages than new packages but they are all important
<LaserJock> and I remember how frustrated I was with how long it can take to get reviewed
<sistpoty> yep, that's true...
<LaserJock> so now I'm in a place to help fix what frustrated me, that is what I love about Ubuntu and the MOTU community
<dolson> heh, I already signed the code of conduct
* sistpoty is off again... bbl
<ArmeBosse> LaserJock: i'm looking each mail from motu-reviewers waiting for my package ;)
<netzmeister> dpkg-genchanges: binary-only upload - not including any source code
<netzmeister> dpkg-buildpackage: binary only upload (no source included)
<LaserJock> ArmeBosse: which one?
<ArmeBosse> LaserJock: now that you're in place i can ping you ;)
<netzmeister> that is not good...
<LaserJock> netzmeister: what are you trying to do?
<jpatrick> netzmeister: -S (-sa) ?
<ArmeBosse> LaserJock: vtigercrm, kvpnc, log4cpp
<LaserJock> ArmeBosse: is marcin` uploading vtigercrm too?
<netzmeister> LaserJock: I will build a package from sources..
<netzmeister> jpatrick: i think no..
<ArmeBosse> LaserJock: probably. current package is our merge
<ArmeBosse> LaserJock: i don't know for next package ...
<LaserJock> netzmeister: where are you getting the source package?
<netzmeister> www.codeblocks.org
<netzmeister> Website.. Not SVN
<netzmeister> argh stop
<netzmeister> SVN, not Website
<netzmeister> ;-)
<LaserJock> netzmeister: so you are trying to make a package for Ubuntu?
<netzmeister> LaserJock: Yes
<LaserJock> netzmeister: have you been using the Debian New Maintainer's Guide?
<netzmeister> yes..
<LaserJock> so what are you doing when you get that error?
<netzmeister> LaserJock: Ups.. sorry.    6.5 Including orig.tar.gz for upload    :-(
<LaserJock> netzmeister: np, glad you caught it
<netzmeister> :-)
<netzmeister> re
<LaserJock> wb sistpoty
<sistpoty> re LaserJock
<Gloubiboulga> congrats LaserJock ;)
<LaserJock> thanks Gloubiboulga
<chillywilly> my terminal font is fugly now after upgrading :(
<LaserJock> so what is HCT going to do for us?
<jpatrick> hct?
<LaserJock> jpatrick: https://launchpad.net/products/hct
<LaserJock> I guess I sorta answered my own question
<jpatrick> ah right
<LaserJock> I'm just not sure how it is going to be used
<marcin`> LaserJock: hi
<LaserJock> hi marcin`
<marcin`> LaserJock: I would like to upload vtigercrm package
<marcin`> LaserJock: but I got different vision for this package
<marcin`> LaserJock: unfortunately I cannot upload alternative version so...
<marcin`> LaserJock: I only report bugs directly to maintainer
<marcin`> LaserJock: (unfortunately current upload doesn't contain fix yet so I consider this package as partially broken)
<LaserJock> marcin`: if it is broken then it should be fixed before it will be advocated
<LaserJock> dholbach: ping?
<LaserJock> sistpoty: ping?
<marcin`> LaserJock: it's partially broken - it will work until you will try to import some existing data to data base server
<marcin`> LaserJock: it has $cache set to wrong paths
<LaserJock> marcin`: ok, has ArmeBosse said that he would fix that?
<dholbach> LaserJock: pong
<marcin`> LaserJock: I think so
<marcin`> LaserJock: I reported this but to him
<marcin`> LaserJock: I could fix it but you know - I don't want to fight with him anymore
<LaserJock> dholbach: umm, I need some help. marcin` and ArmeBosse have been working on the same package on REVU. However, they can't seem to "get along". So they end up wanting to upload there own versions of the package to REVU.
<LaserJock> dholbach: is there a social solution here? or is it possible to have two branches to the same source package on REVU?
<ajmitch_> morning all
<LaserJock> hi ajmitch_
<dholbach> if they really can't get along they should start writing a wiki page or discuss the diff (best each little change) and justify it to each other, I guess they'll end up at something much closer to each other
<LaserJock> dholbach: the package is vtigercrm, btw
<dholbach> i'm sorry, I don't have the time to look at it at the moment
<LaserJock> dholbach: np, thanks for the suggestion
<dholbach> they can consider themselves as a maintenance team once they can agree on a packaging
<ajmitch_> especially as 1 of them as filed an ITP
<ajmitch_> and it's not considered polite to hijack an ITP
<LaserJock> marcin`: the problem I keep seeing is that ArmeBosse hasn't refused to make the changes, he just wants wait and do many fixes at once.
<LaserJock> marcin`: I don't think that is unreasonable
<marcin`> LaserJock: of course
<LaserJock> marcin`: if the package is truly broken then it is ok to let us know and the reviewers can take that into consideration
<marcin`> LaserJock: but the difference between us is not only about these fixes
<marcin`> LaserJock: I would like to make a lot of changes - but now I even don't want to try
<LaserJock> marcin`: I would just give it some time. If the suggestions are helpful and you provide patches I don't think your work will be in vain
<marcin`> LaserJock: I'll try to describe to you 'short history' of our collaboration
<marcin`> LaserJock: we started work on vtigercrm without any connection
<marcin`> LaserJock: then we meet on irc - it was raphink idea
<dolson> LaserJock, sistpoty, dholbach, or whoever ;) : the next CC meeting is Mar7 at 7am my time. I'm not 100% sure I can be there, so should I just defer my application until the next meeting that happens at a reasonable hour? or just apply anyhow and hope I can get out of bed early enough?
<marcin`> LaserJock: and then realized that ArmeBosse has much better scirpts that create database and different idea to generate config.php
<LaserJock> dolson: is the other meeting time (I think they switch between two different times) better?
<marcin`> LaserJock: while I had better rules (based on cdbs) better organization of package (separate vt-mysql-local that could allow to install vt in 'single click' with mysql-server etc.)
<marcin`> LaserJock: so we decided to merge best parts of our job
<marcin`> LaserJock: it was obvious - so I did it
<marcin`> LaserJock: and we had 'merge' version
<marcin`> LaserJock: that was ok but far from perfect
<marcin`> LaserJock: then I uploaded a lot of changes - different script to generate config, I polished structure, changes things and package was fully workable
<ajmitch_> lovely, people asking for 'ebuntu' source packages - they're not going to get them anytime soon ;)
<marcin`> LaserJock: then problems started - he reverted my changes and uploaded his old version
<marcin`> LaserJock: then I changed my script a bit to try compromise
<dolson> LaserJock: I'm not sure, trying to find the other time on the wiki..
<dolson> ajmitch_: lol
<LaserJock> dolson: check fridge.ubuntu.com
<marcin`> LaserJock: and then again - he uploaded his version reverting some of my changes here and there and finally uploaded broken package
<marcin`> LaserJock: because reverted my changes without care... and then he annoyed me with his decisions
<LaserJock> ajmitch_: where?
<marcin`> LaserJock: while I can understant some of them - I simple cannot accept that someone reverts my changes and does
<marcin`> these reverts in this way that package is broken (he did it twice...)
<marcin`> LaserJock: so you see we simple cannot collaborate
<LaserJock> marcin`: from what I understand some of that was by mistake, and some of it was because he wanted to wait. Is there anything that he has simply refused to do?
<marcin`> LaserJock: propably we both have good ideas
<marcin`> LaserJock: but we got a problem with communication
<ajmitch_> LaserJock: ?
<LaserJock> ajmitch_: where were you seeing the cries for ebuntu source?
<marcin`> LaserJock: well yes he changed my postinst script and few more things
<ajmitch_> LaserJock: users list
<marcin`> LaserJock: and you know... it's hard to explain...
<ajmitch_> LaserJock: ogra was telling him change the name ASAP, and provide source
<LaserJock> marcin`: ok, so I think that dholbach's suggestion was good. I think primarily you guys have a communication problem
<marcin`> LaserJock: for example: sistpoty in his review said that he want's to have some files in /doc or at least symlink to doc
<marcin`> LaserJock: so I changed .install to put these files to /doc
<dolson> LaserJock: yeah, that time is better, but I don't wanna wait two more weeks, or I'll probably forget or something. so I'll have to find an alarm clock I guess. will you be able to be there? or dholbach or sistpoty or siretart or jpatrick or someone who likes me? :)
<marcin`> LaserJock: then ArmeBosse reverted my changes - saying that he want's to wait and he likes symlink - not copying
<marcin`> LaserJock: etc. etc. everytime I do something - he has different idea
<marcin`> LaserJock: small things but simple annoying
<LaserJock> dolson: I'm sure somebody will be there, what is the UTC time? oh wait, your in Seattle right?
<dolson> I'm in Canada!
<LaserJock> oh
<dolson> UTC 1700
<LaserJock> I was thinking of somebody else
<dolson> no
<dolson> wait..
<dolson> UTC 1200
<dolson> I'm in Easten time, -0500
<marcin`> LaserJock: well I'm not sure that dholbach suggestion could change anything
<LaserJock> marcin`: but the problems are being addressed. You guys have slightly different opinions on how to go about it but I just don't see the big deal
<marcin`> LaserJock: while we already got project page for this package
<LaserJock> dolson: I can't make it, I'm -0800
<dolson> :(
<LaserJock> but sistpoty and dholbach might
<dolson> yeah, dholback is an early bird. either that, or he lives in a timezone that is earlier than me
<marcin`> LaserJock: http://vtigerforge.fosslabs.com/projects/pkg-ubuntu/
<LaserJock>  marcin`: what you guys need is a common collaboration space that is easily editable. a wiki might be good for that
<dholbach> dolson: germany
<LaserJock> dolson: they're Germans
<dolson> I used to listen to German techno... it just sounded funny. Rammstein rules though
<marcin`> LaserJock: I agree but if we cannot agree on some things we both need some ideas from outside
<LaserJock> marcin`: well, the project page doesn't help collaboration much. I think you both need to be a little more flexible
<dolson> dholbach: will you be there to say that "dolson doesn't suck" or "dolson sucks less than some others" ?
<dholbach> dolson: come on
<dholbach> :)
<dholbach> yeah, but i daresay they'll want to talk to you themselves
<LaserJock> marcin`: honestly, this is such a little thing really. I haven't seen anything but you guys arguing about how to implement virtually the same fix.
<dholbach> but I can say that
<marcin`> LaserJock: well ok - I'll try to be flexible only once more...
<dolson> I will be there too
<dolson> I have an alarm clock somewhere
<marcin`> LaserJock: but then I'll simple leave this
<dolson> but I need a cheerleader team
<LaserJock> marcin`: what is your idea of being flexible in this case?
<dholbach> i'll be there
<marcin`> LaserJock: I still think that the best option could be an ability to upload different packages
<dholbach> although I#ll be in london
<dholbach> so not sure
<marcin`> LaserJock: to revu and then reviewers should judge which one is better
<LaserJock> marcin`: I can understand that but once the package is in Universe, it won't be so easy
<dolson> dholbach:  I missed the last thing you said before "so not sure".. I cleared my buffer :\
<marcin`> LaserJock: it's not in Universe
<LaserJock> yet
<dholbach> dolson: i hope i'll be there
<dholbach> dolson: if i am, i'll cheerlead
<LaserJock> marcin`: what happens when it does go into Universe?
<dolson> if you're not, I will flee in terror
<LaserJock> dolson: don't worry, it's not that bad, just make a killer wiki page ;-)
<marcin`> LaserJock: know what? each time I'm on REVU or MOTU then I got a feeling that Ubuntu is free distro that is not free
<marcin`> LaserJock: personally I think that it sucsks... I feel like I got a 'big boss' that I have to listen to
<dolson> LaserJock: I will put "I DO NOT SUCK!!" in big <h1><b> font. that oughtta seal the deal, right?
<LaserJock> marcin`: no, but every project has to have standards.  we can't just let people willy nilly change packages for thousands of people
<LaserJock> marcin`: so that means we have to organize work
<LaserJock> dolson: "sabdfl and the CC rulz!!!" might help ;-)
<dolson> heh
<dolson> marcin`: hey, have you considering working on another package that isn't in Ubuntu yet? that way you're not duplicating work anyhow, and you can end your feud, and still contribute and be awesome and not suck and all that?
<sistpoty> LaserJock: pong? (was just afk)
<LaserJock> sistpoty: nm, I'm trying to figure out social solutions ;-)
<sistpoty> kk ;)
<LaserJock> sistpoty: marcin` and ArmeBosse again
<sistpoty> ah... *reading backlog*
<marcin`> dolson: I already uploaded 4 or 5 more packages to revu
<dolson> marcin`: if you wanna package audio apps, let me know. I'll find something for you to do
<marcin`> dolson: please review them ;)
<dolson> marcin`: I will when I become a MOTU
<ajmitch_> hey sistpoty
<sistpoty> hi ajmitch_
<marcin`> LaserJock: ok ok
<LaserJock> marcin`: the MOTU is relatively rules free compared to a lot of other places I think.
<marcin`> LaserJock: but I still think that REVU should sometimes work in different way
<sistpoty> marcin`: so you and ArmeBosse are both uploading vtigercrm to revu and you are not happy with his changes?
<LaserJock> marcin`: but you simply can't have multiple, different packages of the same program running around Universe
<marcin`> LaserJock: while REVU is for reviews it pretty sucks that you can review only one version
<marcin`> LaserJock: and cannot compare and make a choice
<LaserJock> marcin`: we could do it, but it isn't ideal
<LaserJock> I think it should be avoided
<marcin`> sistpoty: I'm not happy with his and he is not happy with mine
<sistpoty> marcin`: hm... we didn't have that problem yet...
<sistpoty> ArmeBosse: around?
<LaserJock> I saw him earlier but that was a few hours ago
<ajmitch_> marcin`: we weren't anticipating competing developers when REVU was coded
<marcin`> btw don't get me wrong - he did really great job with his scirpt
<marcin`> scripts - since he is official vtiger developer
<ajmitch_> especially as it's not an easy thing to choose one person's work over anothers
<marcin`> so he could use few tricks I didn't know about
<marcin`> but the thing is that he filed ITP in debian so he feels like 'big boss' and reverts my changes without any notice - and it's simple annoying for me
<sistpoty> revu isn't actually about competition
<marcin`> sistpoty: it's not competition in fact
<marcin`> sistpoty: first - it's about choice
<LaserJock> marcin`: again, from what I understand most of the "reversion" was a mistake or a different implantation of the fix
<sistpoty> marcin`: yes, got that... was actually referring to ajmitch_ ;)
<LaserJock> implementation I mean
<marcin`> sistpoty: second - it's about nice, clean packages that _work_
<ajmitch_> sistpoty: I know, whuch is why it doesn't support multiple branches of the same package :)
<marcin`> sistpoty: uploads that revert changes and make packages broken are annoying - don't you think?
<LaserJock> marcin`: and he has said that he is going to be uploading a working version soon
<sistpoty> marcin`: yes, they are... as I already wrote, we didn't have that problem yet
<marcin`> ok I'll wait for his upload
<marcin`> take a look at changes
<sistpoty> marcin`: my first suggestion would be to try to solve coordination/cooperation issues directly with ArmeBosse...
<marcin`> I also got a lot of changes ready to upload but I first try to put them to SVN on vtigerforge
<sistpoty> marcin`: however if that doesn't work, we need to make up a proper solution, as I don't think it generally will work out if two ppl. work on the same package w.o. really working together
<marcin`> if he will not accept them - then I'll simple upload vtiger-crm pakage to revu
<marcin`> and I hope that you will review it and make a choice ok?
<marcin`> and of course if we will be able to work together I will be more than happy
<ajmitch_> so you want us to choose either his package or  yours & bless it for upload?
<marcin`> as I said - first I will wait for his fixes and changes
<marcin`> then I will once again try to put my changes but to vtigerforge first
<sistpoty> marcin`: I guess making a choice won't solve the issue, as "competing" uploads won't solve it...
<marcin`> when he will accept them - then ok
<LaserJock> marcin`: I think perhaps your definition of "work together" needs a little tweaking. You have been working together, quite successfully from  what I've heard from you
<marcin`> if he won't then I got two choices - leave this and stop wasting my time
<dolson> I still don't understand why there has to be more than one person doing a single package... moreover, I don't know how I could possibly deal with a second person trying to make changes to my packages
<marcin`> or I'll try to upload my version and you should decide while we cannot compromise ok?
<dolson> I mean... REVU makes me a better packager - it's like my silent partner
<marcin`> ok we should end this discussion now
<sistpoty> marcin`: yes... in case you feel, that both you and ArmeBosse uploading to revu will result in a mess, please write a mail to ubuntu-motu, so that we can try to settle this issue
<sistpoty> marcin`: or better, if you don't think it will work out, that you and ArmeBosse upload the same package to revu
<marcin`> ok - because you know - I'm annoyed about his changes - but propably he is annoyed with my uploads
<marcin`> and I don't like to make ppl angry - but also don't like to waste my time and upload something that someone will replace with something different few hours later
<marcin`> so we need to find another way to resolve this
<marcin`> and now I really need to work more and talk less
<LaserJock> marcin`: are you sending him debdiffs?
<marcin`> LaserJock: no and vice versa - you already said that we got a problem with communication - right :) ?
<netzmeister> hm whats the name of the tool, to check an deb-Package?
<netzmeister> lin..
<netzmeister> hm.. (right charset) ;-)
<ajmitch_> LaserJock: debdiffs are so last year - use bzr :)
<ogra> tian
<LaserJock> ajmitch_: sure, but they can't even seem to talk together. Baby steps ;-)
<LaserJock> although really bzr might be a good tool for you guys
#ubuntu-motu 2007-02-26
<Adri2000> I wonder if I should upload the orig.tar.gz for tsmithe's package...
<LaserJock> Adri2000: if it isn't in the repos already, yes
<Adri2000> LaserJock: -0ubuntu1 is currently in NEW and I'm uploading -0ubuntu2
<LaserJock> I think you want to include the .orig.tar.gz then
<Adri2000> ok
<slomo> Adri2000: and if LP already knows about the tar.gz and you upload with it you'll get a mail and can upload without again afterwards ;)
<Adri2000> hmm
<Adri2000> tsmithe: uploaded
<shawarma> Do any of you already now know whether you'll be going to Seville?
<shawarma> Guess not. :-)
<LaserJock> I'm still trying to decide
<shawarma> LaserJock: What's the dilemma?
<LaserJock> well
<RAOF> Hm.  It seems that Specto has been stuck in NEW since the 14th.  Is there anyone I could/should prod to move it along?
<LaserJock> my brother's getting married May 12th
<LaserJock> and I keep getting sucked into Ubuntu stuff every time I go to UDSs
<shawarma> LaserJock: Ah.. Valid point. You could leave early?
<shawarma> LaserJock: You're trying to cut back?
<LaserJock> have been since dapper
<LaserJock> :-)
<shawarma> LaserJock: Get out more. :-)
<LaserJock> I'll probably try to attend UES
<shawarma> UES?
<LaserJock> Education Summit
<shawarma> When/where?
<LaserJock> it's the 3rd and 4th of May
<LaserJock> same place
<shawarma> Gah... So Education summit, Loco day, UDS all in a row?
<shawarma> Sheesh.
<ajmitch> LaserJock: I'd like to go, but I know it won't happen
<shawarma> ajmitch: time/money/both?
<ajmitch> shawarma: NZ->spain is about half way round the world
<LaserJock> maybe you can whip up a genius net auth scheme that Mark will *have* to sponsor you for? ;-)
<ajmitch> HAH
<ajmitch> LaserJock: unless it's shiny, it won't happen ;)
<LaserJock> what?!? net auth isn't sexy? :-)
<ajmitch> of course not
<LaserJock> anyway, I think I *could* go to UDS, I just don't know if I should
<shawarma> LaserJock: Heh. For me, it's the other way around. :-)
<ajmitch> LaserJock: I won't get sponsored :)
<LaserJock> you don't know if you don't try I guess
<ajmitch> there is no try
<ajmitch> they aren't putting up a page for people to ask for sponsorship
<shawarma> There's no "trying" about it. It seems sponsorships will be nominated.
<shawarma> Well, that's what Mark said at one point, anyway. 
<shawarma> Jono changed the text on the Wiki to "the specifics of this sponsorship are currently being discussed and more information will be available soon.", though.
<LaserJock> ahh
* ajmitch shrugs
<ajmitch> I never do anything
<Lathiat> ajmitch: just add some 3d effects to your network auth and it'l be fine :)
<ajmitch> Lathiat: I'll make it a beryl plugin
* Lathiat grins
<ajmitch> I reckon if I do some network visualisation on the desktop...
<shawarma> Oh, the horror! :-)
<ajmitch> who wouldn't want a 3d spinning globe with packets flying everywhere as their desktop?
<LaserJock> that would be sweet
<ajmitch> hook it into iptables, so you can see packets burn up as they hit the firewall
* Lathiat spits out his drink laughing
<shawarma> what the... Is that the time?!?
<ajmitch> no
<shawarma> Oh, good.
* Lathiat cleans his keyboard
<ajmitch> you can stay for another few hours
<shawarma> I was really worried it was really late for a while.
<ajmitch> it's only just after lunch
<shawarma> Then I forgot to eat. :-(
<shawarma> Well, I think I'll go take a nap then. 
<shawarma> Goodnight!
<ajmitch> night
<pochu> slomo: ping?
<slomo> pochu: pong
<pochu> slomo: do you know if liferea 1.2.7 will hit feisty? bug 86982
<Ubugtu> Malone bug 86982 in liferea "UVF exception: liferea 1.2.7" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86982
<pochu> slomo: it seems the archive admins have forgotten to include it :)
<pochu> as they did with 1.2.6 :)
<slomo> pochu: i would be surprised if not... i'll ask tomorrow ;) any specific reaons why you want it?
<pochu> slomo: no, I just use liferea everyday and would like to get those fixes :)
<pochu> but if finally it isn't include and I really need any of those fixes, I would make a .deb myself :)
<slomo> pochu: want the source package? or a x86 binary of 1.2.7? :)
<pochu> slomo: if you have a 1.2.7 x86... :)
<pochu> slomo: but I don't mind to wait for its inclussion :)
<pochu> slomo: just if you know it, and if you have time: do you know anything about python-mozembed, and if it's broken in ubuntu?
<pochu> slomo: gtkhtml?
<slomo> pochu: why should it be broken? (no idea)
<pochu> wasn't it deprecated?
<slomo> pochu: yes, just in case you still had it installed, that's only a transitional package
<pochu> slomo: a problem with listen (I've fixed it with a patch)
<pochu> http://www.listen-project.org/ticket/588#comment:1
<slomo> pochu: your connection is broken it seems ;) well, listen upstream is right... this is distro specific, they should look at the pkg-config output of firefox/mozilla to get the correct path
<pochu> slomo: yeah, it seems...
<pochu> I've never got a file with xchat :)
<pochu> slomo: pkg-config?
* pochu is a noob :)
<pochu> I see :)
<slomo> pochu: you should have all liferea binary packages now, no?
<pochu> slomo: yeah, ty! :)
<pochu> finally it has downloaded it :)
<slomo> pochu: and mozilla is always a pain... just keep this patch for ubuntu and tell upstream to use pkg-config to determine the correct path ;)
<slomo> pkg-config --variable=libdir firefox-gtkmozembed
<slomo> pkg-config --variable=libdir mozilla-gtkmozembed
<slomo> one of them should give the answer
* ajmitch hates mozila libs, and I'm packaging one at the moment
<pochu> slomo: lol, he already uses it
<pochu> ajmitch: which one?
<slomo> ajmitch: which one?
<ajmitch> mozldap
<slomo> poor ajmitch 
<ajmitch> yeah
<ajmitch> ugly, nasty thing
* pochu wonders if he can flood a little :)
<pochu> hehe
<pochu> GTKMOZEMBED_PATH = $(shell pkg-config --libs-only-L mozilla-gtkmozembed 2>/dev/null || pkg-config --libs-only-L firefox-gtkmozembed 2>/dev/null | sed -e "s/-L//g" -e "s/[ ] /\,/" -e "s/[  ] //g" )
<pochu> CONFIGURE_IN_MOZEMBED_HACK= sed -e 's!GTKMOZEMBED_PATH!LD_LIBRARY_PATH=$(GTKMOZEMBED_PATH)!g' 
* pochu hopes you don't ban him
* ajmitch has everything but the pkg-config file working for it, which isn't being used at all for some reason
<pochu> ^_^
<pochu> the strange thing is that listen builds fine, even without patch, with dpkg-buildpackage, however it builds, but doesn't work, with pbuilder
<pochu> (builds an works with the patch)
<slomo> jdong: i doubt MD 0.13 will get through UVF freeze ;)
<jdong> slomo: aww :(
<jdong> slomo: that'd be a shame
<slomo> jdong: the release notes sound very nice... but it will make everybody from the uvf team cry ;)
<slomo> jdong: next release... 
<jdong> slomo: yeah that's fine... you think you can find the time to make feisty-esque packages though :(
<paulproteus> Is it too late to get a new version of my tiny little Debian package (already in Debian) into Ubuntu 7.04?
<jdong> or preemptively upload it to feisty-backports? :)
<jdong> paulproteus: don't ask slomo . he's really mean. :)
<paulproteus> jdong, Well, okay, who else can I ask? (-;
<paulproteus> Should I file the appropriate Lunchpad bug?
<jdong> paulproteus: you can try filing a UVF exception
<jdong> and see what comes out of it
<paulproteus> Sounds okay, how do I do that?
<jdong> paulproteus: https://wiki.ubuntu.com/FreezeExceptionProcess
<slomo> jdong: hehe, packaging MD is always painfull, upstream likes to place all kinds of nice breakages all over the sources... i'll just wait until debian has the new version
<ajmitch> slomo: f-spot is a dream by comparison
<slomo> jdong: or do it once feisty+1 opens
<jdong> slomo: ok, sounds good... I toyed for 30 min and couldn't get it to build still :)
<jdong> so I'm glad it's not just my incompetence
<slomo> jdong: if you take less than 2 hours for updating to a new MD version you did something wrong ;P
<jdong> lol
<slomo> ajmitch: everything is a dream compared to MD... except mono maybe
<jdong> slomo: you want a stab at xserver-xgl? :D
<pochu> emilio@kiko:~$ pkg-config --libs-only-L firefox-gtkmozembed 2>/dev/null
<pochu> -L/usr/lib/firefox
<pochu> anybody can tell me what's break there??
<pochu> hehe
<slomo> jdong: sorry, not interested in bling
<jdong> lol
<LaserJock> slomo: not interested in bling?
<LaserJock> slomo: don't you do a fair amount of multimedia stuff?
<ajmitch> jdong: I've updated xserver-xgl before, it's not too hard
<jdong> ajmitch: I attempted to do so at bug 87687
<Ubugtu> Malone bug 87687 in xserver-xgl "New git snapshot required for xorg 7.2/feisty" [Wishlist,Unconfirmed]  https://launchpad.net/bugs/87687
<jdong> but I couldn't front-port that xinerama patch
<jdong> I really have no emotional attachment to it though
* ajmitch doesn't care at all anymore
<jdong> I just want a working Xgl (at least single-monitor) in Feisty
<jdong> ajmitch: are you motu-utf though?
* jdong looking for +1's
<LaserJock> oh yeah, ajmitch is very Unicode
<LaserJock> ;-)
<jdong> lol
<jdong> same (deb)diff
<slomo> LaserJock: yes, with bling i meant all the compositing stuff
* ajmitch would need a rather good reason to agree to changes
<jdong> ajmitch: current feisty version is totally broken by xorg 7.2 uploads.
<jdong> and current feisty version does not compile against new mesa and x11 libs
<LaserJock> slomo: audo bling :-)
<LaserJock> *audio
<jdong> hence there is no risk of regression.
* ajmitch may consider it
<jdong> ajmitch: .... the alternative is to ship a completely broken Xgl....
<jdong> which means you're just gonna get one terrible checkinstalled xgl deb after another post-release
<ajmitch> jdong: you could always convince slomo
<jdong> I really don't think that's the better alternative
<jdong> he's mean.
<jdong> :)
<ajmitch> I'm meaner
* jdong changes ajmitch's tag to big fat meanie
<ajmitch> excellent
<ajmitch> bddebian can back me up here
<slomo> jdong: get a package that could be uploaded and in general this sounds good... not working at all is imho a much bigger regression than any other possible regression ;)
<jdong> bddebian: is it really true that ajmitch ate babies at a Ubuntu conference?
<bddebian> Heya gang
<jdong> slomo: I have source packages for a new version attached on that bug report and I can personally attest that they work. In addition several people at the forums have tested it and reported back that it fixed their beryl issues
<bddebian> jdong: Dunno never been to one but it sounds like him :-)
<jdong> :)
<pochu> jdong: please fix that beryl issue!
<pochu> it's annoying to have dozens of beryl bugs, which we are going to reject inmediately :)
<jdong> pochu: well the AIGLX side will fix itself as more Xorg gets uploaded... but Xgl will require this UVFe to be fixed....
<jdong> pochu: and compiz is equally as effected :)
<jdong> so you can't just immediately reject it with a beryl copout :)
<pochu> hehe
<pochu> jdong: but we don't reject compiz bugs... which is worse :)
<pochu> any idea about this? --->
<pochu> root@kiko:/# pkg-config --libs-only-L firefox-gtkmozembed 2>/dev/null
<pochu> root@kiko:/#
<pochu> what package provides pkg-config?
<ajmitch> pkg-config
<bddebian> hehe
<pochu> xD
<pochu> ty :)
<ajmitch> it was a challenge to think of that one
<pochu> ajmitch: hehe
<pochu> hmm
<pochu> I have pkg-config in the build-deps...
<pochu> so the problem isn't that
<ajmitch> and you have firefox-dev in the build-deps?
<pochu> root@kiko:/# pkg-config --libs-only-L firefox-gtkmozembed 2>/dev/null
<pochu> root@kiko:/#
<pochu> that's after installing pkg-config
<pochu> ajmitch: no, I haven't
<pochu> ajmitch: do I really need it?
<ajmitch> then why are you surprised that it doesn't work?
<ajmitch> pkg-config has to get its data from somewhere
<pochu> ajmitch: because /usr/lib/firefox/gtkembedmoz is in firefox
<ajmitch> so?
<ajmitch> /usr/lib/pkgconfig/firefox-gtkmozembed.pc
<pochu> root@kiko:/# dpkg -L firefox | grep embedmoz
<pochu> /usr/lib/firefox/libgtkembedmoz.so
<ajmitch> is in firefox-dev
<pochu> hmm
<pochu> ajmitch: I hope you're right :)
<pochu> are you?
<ajmitch> this is why we have -dev packages
<ajmitch> of course I'm right, I just checked it
<pochu> ajmitch: no, I mean if that will fix the problem :)
<ajmitch> considering that the critical file is in firefox-dev, it should
<pochu> ajmitch: I'm a newbie :) I didn't know the finality of -dev packages... just I used it to compile because otherwise source packages didn't compile :)
<pochu> hehe
<pochu> ajmitch: will try tomorrow :)
<pochu> ajmitch: if it works, should I remake a package and request an uvf exception?
* ajmitch can now return to his regularly scheduled bitterness & cynicism
<ajmitch> pochu: for what?
<pochu> ajmitch: for drop 2 patches I added to skip the pkg-config step :)
<ajmitch> uvf exception is only for new upstream versions
<ajmitch> are you packaging a new upstream version?
<ajmitch> or just modifying what we have?
<pochu> ajmitch: lol, I forgot it :)
<pochu> ajmitch: ty anyway :)
<pochu> slomo: ty for the liferea package :) it works fine, at least till the moment ;)
<slomo> pochu: works since days here ;)
<pochu> night motus!
<pochu> slomo: :)
<slomo> gn8 pochu 
<pochu> ajmitch: ty for your help :)
<tonyyarusso> Anybody with a PPC machine to test build on?
<bddebian> tonyyarusso: Fix all those problems already? :-)
<tonyyarusso> bddebian: The lintian warnings you mean?  Can't really, at least not without a huge amount of nonsense.
<tonyyarusso> bddebian: unless you know how one would go about patching to move all the images.
<bddebian>  cp
<bddebian> mv
<tonyyarusso> Where?  rules?
<bddebian> yep
<tonyyarusso> What about the fact that everything will be trying to use them in the other location in the actual program?
<tonyyarusso> That's a lot of source changes.
<bddebian> Then it's stupid upstream
<tonyyarusso> I know that.
<tonyyarusso> We're working on it, slowly.
<tonyyarusso> I can ask the upstream guy to change it, but I'm kind of doubtful about this sort of change.
<bddebian> tonyyarusso: Does it set --datadir anywhere?
<tonyyarusso> bddebian: grepping...   config/autoconf.mk:datadir              = ${prefix}/share
<bddebian> I know that, I mean you aren't overriding that in rules or anything are you?
<tonyyarusso> not that I can see.
<tonyyarusso> I have no arch-indep rule right now, btw.
<tonyyarusso> I assume there should be one, but I'm not sure what it would say.
<bddebian> Something is just wrong with that package
<tonyyarusso> We've established that; I'm looking for hints of how to fix it.  If you aren't sure, that's cool - I'll keep poking, just thought you'd be good to check with though.  :)
<bddebian> I'm looking, it just looks like a lot of the dir structure is just wrong
<tonyyarusso> The main thing I need to establish first is whether that's my fault in packaging or upstream's.
<bddebian> Aye, that's what I'm looking at now :-)
<tonyyarusso> cool
<sparklehistory> tonyyarusso: okay, what now?
<tonyyarusso> sparklehistory: Look in /usr/lib and /usr/share, and tell me which has nvu directories.  If both, look for image files (gif, xpm, etc), and say where they are.
<sparklehistory> tonyyarusso: how do I do that?
<tonyyarusso> sparklehistory: Place > Computer > Filesystem > usr > share/lib
<sparklehistory> tonyyarusso: I found lib in the gui and I don't see anything referring to nvu
<tonyyarusso> examples include /usr/lib/nvu-0.77/res/html/gopher-telnet.gif
<tonyyarusso> Might be /usr/lib/0.77/ or some stupid thing on Dapper
<sparklehistory> tonyyarusso: nothing like that, there's a bunch of things like libhistory.so.5
<sparklehistory> And I don't have a share folder in the filesystem.
<tonyyarusso> sparklehistory: /usr/share, not /share
<tonyyarusso> /usr/lib and /usr/share
<sparklehistory> oh, okay
<sparklehistory> yeah, now there's a nvu-1.0 directory in /usr/lib
<tonyyarusso> is there a res/ in that?
<sparklehistory> yes
<tonyyarusso> just keep going down and holler if you find images :)
<sparklehistory> there's a whole bunch of .gif images in /res
<tonyyarusso> roger that
<sparklehistory> and in /res/html there's some .gif images
<tonyyarusso> bddebian: Maybe it's not my fault after all  ;)
<tonyyarusso> sparklehistory: is there even nvu stuff in /usr/share/ at all?
<sparklehistory> hang on
<sparklehistory> nope, don't see any
<tonyyarusso> ok
<sparklehistory> you still want me to keep looking for images in /usr/lib ?
<tonyyarusso> bddebian: That doesn't necessarily mean I couldn't hack up something to fix that - not sure how such a thing would be done.
<tonyyarusso> sparklehistory: Nah, there's like 80 of them.
<sparklehistory> tonyyarusso: okay, anything else you want me to do?
<tonyyarusso> no
<sparklehistory> 'k
<LaserJock> anybody know if we can say "this needs to be fixed upstream" in a bug report
<imbrandon> sure, then file a bug upsteam and then link it to the bug report
<tonyyarusso> LaserJock: I think I've seen things like that before.  Maybe "should be" instead of "needs" if we're worried about sounding demanding.
<imbrandon> heya LaserJock 
<ajmitch> hi imbrandon 
<imbrandon> heya ajmitch 
<LaserJock> imbrandon: I was thinking more like "somebody please file it upstream"
<LaserJock> for like a junior job or something
<imbrandon> LaserJock, hehe
<Fujitsu> LaserJock: If you create an upstream task, it will appear in listings of those needing forwarding.
<LaserJock> Fujitsu: ah
<LaserJock> does it have to be a trackable upstream (i.e. something with a bug tracker that is registered with LP)?
<Fujitsu> It will only appear on the list if it isn't linked to an upstream bugtracker (or they use Malone officially).
<LaserJock> hmm, ok
<LaserJock> it seems odd to do an upstream task if we can't track the upstream bug
<Fujitsu> How?
* ajmitch needs to forward some more bugs
<LaserJock> it seems like a good way to have a bunch of obsolete task sitting in Malone
<LaserJock> i.e. you have to close the bug twice, once upstream and once in Malone
<Fujitsu> The point of having the task unlinked is to make it appear on the list of things needed to be pushed upstream.
<Fujitsu> So it shouldn't be being closed upstream until it is reported there in the first place.
<ajmitch> Hobbsee!!!
<LaserJock> Fujitsu: right, I'm just saying we have to track the status upstream as well as in Ubuntu with that
<LaserJock> which takes a fair amount of effort
<LaserJock> I hate filing bugs upstream (debian even)
<LaserJock> but it's the best way to get things fixed for good
<Hobbsee> ajmitch!!!
<bddebian> Jesus, Mozilla's build system is atrocious
<tonyyarusso> Ya noticed eh?
<RAOF> Poor tonyyarusso, with his Komposer build
<tonyyarusso> RAOF: It runs now, on at least x86 and amd64.  Not sure about PPC, and there are some lintian issues.
<RAOF> Huzzah.  Why can't write endian and 64bit safe code?
<tonyyarusso> come again?
<jdong> tha'ts what she said.
<jdong> oops wrong channel
<jdong> actually... that kinda worked
<RAOF> tonyyarusso: Well, if it doesn't work on PPC then it's got endian-unsafe code.
<RAOF> tonyyarusso: And if you had to patch it to make it work on amd64, it's got 64bit unsafe code.
<jdong> RAOF: a lot of ALTIVEC assembly will do that too ;-)
<jdong> *cough* x264
<tonyyarusso> RAOF: It failed on one PPC that I had access too, but the owner says they've had issues too.  Yes, I had to patch for 64.  /me takes no responsibility for the upstream that's not even the current dev.
<tonyyarusso> RAOF: If you looked at the source, would you be able to patch it for PPC?
<RAOF> tonyyarusso: Eeeep, no.  Almost certainly not.
<tonyyarusso> ok
<RAOF> I mean, I could look through it, but I'm not sure I'd be able to fix it, or even identify the problem.
<RAOF> Particularly since I don't have a PPC lying around :)
<tonyyarusso> RAOF: odd thing is, I think it must have built for PPC for Edgy.  I can get you a build log from a PPC if that helps.
<RAOF> tonyyarusso: No, I'm in no way the kind of C god that can actually *fix* endianess issues.
<RAOF> tonyyarusso: I merely snipe from the sidelines :)
<tonyyarusso> RAOF: well, if you can pinpoint that might be enough - I can send your comments upstream.
<RAOF> Hm.  I'm going to lose my internet for a couple of days soon.
<bddebian> Hmm, thuban builds with wxgtk2.6 stuff.  I wonder if it actually runs.
<RAOF> tonyyarusso: You can email me the build-log if you like (chalserogers@gmail.com), but I can't promise anything!
<tonyyarusso> RAOF: Okay.
<bddebian> Gah WTF, thuban 1.1.x is in Debian.. Grr
* bddebian breaks down and weeps
<LaserJock> why?
<RAOF> Incidentally, I'll just ask this again: it seems that Specto has been stuck in NEW since the 14th.  Is there anyone I could/should prod to move it along?  Is there anywhere better than here to ask?
<jdong> cjwatson, mithrandir
<jdong> don't tell them I said that
<jdong> shhhhh....
<jdong> speaking of that I need to prod backports queue forward
<LaserJock> naughty
<jdong> tha'ts what.... never mind
* jdong is obviously catching up on missed Office episodes
<bddebian> LaserJock: It just seems like I'm constantly doing shit for nothing
* lotusleaf laughs and rubs magic backports lamp again now that it's warm
<bddebian> Now, why did thuban not automagically get merged and isn't on any merge lists?
<LaserJock> bddebian: how long has it been in Debian?
<LaserJock> bddebian: oh man, that has been a while
<bddebian> Oh, nevermind it's in experimental, duh
<LaserJock> oh, yeah
<LaserJock> I just saw that too
<bddebian> But even that was back in March of 2006, wtf? :)
<LaserJock> well, could have been like goffice
<LaserJock> and merged from experimental
<LaserJock> hmm, only 42 items in the NEW queue, not too terrible for just having FF
<RAOF> jdong: Is it kosher to prod mithrandir or cjwatson about stuff in NEW?  You seem to suggest the answer is "no" :)
<jdong> RAOF: it's not good practice to prod archive managers about their jobs
<LaserJock> depends on the mood of the archive admin
<jdong> but I've done it a few times when backports fell near a month behind
<jdong> and cjwatson was very understanding and courteous about it
<RAOF> Fair enough.  I can live with a few weeks, then :)
<crimsun> paulproteus: #87958 is a feature freeze (FF) exception request. What's the rationale?
<crimsun> ("it'd be nice to have the Ubuntu release be in as close sync to Debian as possible" is insufficient)
<paulproteus> crimsun, It's a tiny bugfix release by upstream.  It therefore doesn't violate a feature freeze.
<crimsun> paulproteus: hmm, sorry, mis-synced apt cache
<paulproteus> crimsun, I don't know what you're apologizing for, but I think I'm okay with it anyway. (-:
<crimsun> paulproteus: all that's necessary is the entry from ccd2iso (0.3-1) unstable; urgency=low
<crimsun> argh
<crimsun>  .
<Fujitsu> crimsun: We don't have FF in universe any more! It's NewPackagesFreeze these days.
<crimsun>    * New upstream release
<crimsun> I think my pointer is conspiring against me
<paulproteus> crimsun, I see! (-:
<crimsun> right, so paulproteus, just include the new debian/changelog entry
<paulproteus> crimsun, In the bug?  'Kay.
<crimsun> Fujitsu: nice
<Fujitsu> It was renamed a few nights back.
* paulproteus hopes for iceweasel in Ubuntu
<LaserJock> Fujitsu: what?
<Fujitsu> paulproteus: We have Mozilla's approval to use Firefox, so I doubt it will happen.
<Fujitsu> LaserJock: What?
<LaserJock> FF was renamed?
<crimsun> NewPackagesFreezeUniverse
<Fujitsu> LaserJock: Yep.
<Fujitsu> As it isn't like main FF.
<paulproteus> crimsun, Added, thanks.
<paulproteus> Firefox != FeatureFreeze
<LaserJock> well, that's certainly a better description but it would have nice to change that *before* I sent out the announcement ;-)
<Fujitsu> LaserJock: It was only changed a little after the announcement.
<LaserJock> paulproteus: sorry, I know
<LaserJock> Fujitsu: that's my point
<paulproteus> LaserJock, It's okay, I was taking advantage of the pun. (-:
<LaserJock> it's bad when we have clashing acronyms at the same time ;-)
<Fujitsu> The officially-sanctioned shortened Firefox is `Fx' anyway, not `FF'
<crimsun> paulproteus: ACKed, awaiting 2nd ACK.
<LaserJock> Fujitsu: ewww, I like FF much better
<Fujitsu> LaserJock: But it has an `x' in it! It must be cooler/13373r/better/etc.!
<crimsun> yep, just like high definition audio!
* ajmitch wanders in 
* Fujitsu hasn't found it to be particularly high-definition, unsurprisingly.
* Fujitsu locks ajmitch out.
* LaserJock startles
<ajmitch> fine, I'll leave
* LaserJock puts Fujitsu in the corner and unlocks the door
<tonyyarusso> crimsun: I thought the two-ack thing was gone for you?
<crimsun> err, huh?
<tonyyarusso> last MC thing - skimmed that.  haven't been quite following here though so ignore me if necessary :P
<crimsun> that's for new source packages from REVU by an ubuntu-dev/motu LP team member to enter Ubuntu
<tonyyarusso> ah
<user__> hi
<LaserJock> hi
<imbrandon> hello
<RAOF> hello imbrandon.
<imbrandon> hum does ffmpeg play 3g2 files
<RAOF> It should, I think.
<RAOF> You mean 3gp, or whatever it is that mobile phones produce?
<crimsun> no, it's the new 3g2 made just for brandon
<imbrandon> no i mean 3g2 , its close to 3gp
<imbrandon> and also made by phones
<imbrandon> and pda's
<RAOF> Probably.  It's probably just another mpeg4 + aac in almost-mp4.
<_ion> Someone should tell programmers it's actually possible to have more than 3 characters after the last dot nowadays.
<imbrandon> heya crimsun 
<crimsun> hi
<RAOF> _ion: No, that would kill DOS compatibility!
<RAOF> _ion: I get a lot of work done on my DR DOS box :P
<Fujitsu> imbrandon: Can you /please/ do a spelling/grammar check on ubuntuwire.com? It isn't exactly great at the moment... :P
<imbrandon> Fujitsu, it was a 3am blurb when i was tired, i'll get to it today lol
<Fujitsu> Heheh.
<Fujitsu> Have you had many sign up for it yet?
<imbrandon> about 200
<crimsun> although "spamed" could probably pass for a legitimate, new, opt-out thing
<imbrandon> not too bad for 24 hours
<Fujitsu> Not bad at all, imbrandon.
* ajmitch might even sign up
* Fujitsu already has an Ubuntu-related Jabber address, so won't bother.
* ajmitch doesn't really care much about having an ubuntu-related address
<imbrandon> heh yea but @jabber.org keeps dropping my connection so now i can just use my own ;)(
<imbrandon> heh
<lotusleaf> imbrandon: it's a cool idea and nice that you offer it :)
<imbrandon> lotusleaf, ;)
<lotusleaf> imbrandon: btw kubuntu rules k thx ;)
<imbrandon> ;)
<LaserJock> imbrandon: and I didn't eve get a mention? tsk tsk ;-)
<imbrandon> there fixed the spelling check
<imbrandon> LaserJock, where?
<LaserJock> imbrandon: on the blog post
<imbrandon> ohh about the name
<LaserJock> :-)
<imbrandon> yea , heheh i should add that
<imbrandon> ;)
<imbrandon> LaserJock, updated hehe, thanks, btw you dont have an index.{html,asp,php} on laserjock.us ?
<LaserJock> oh yeah
<LaserJock> I was going to fix that
<LaserJock> I was using drupal, but in the end it was just overkill for just me
<imbrandon> Fujitsu, just looked , 167 to be exact ( the number of users )
<imbrandon> but only aobut 15 logged into jabber avg
<imbrandon> some may use it just for the email
<LaserJock> I've never really had a problem with jabber.org
<LaserJock> or maybe I have but I didn't know it
<imbrandon> i seem to get disconnected every 4 or 5 hourts from jabber.org , maybe its just me
<imbrandon> no real big deal really
<imbrandon> actualy it hasent happened lately, it might have just been a spurt a few weeks ago
<Fujitsu> One of the main points of Jabber is that it's decentralised... If everybody uses jabber.org, it's silly.
<imbrandon> very true
<LaserJock> hmm, I don't think I've been on for 4-5 hrs at a time
<LaserJock> I don't use it much
<imbrandon> decentralized is good ;)
<LaserJock> sometimes
<imbrandon> any other blatent mistakes i'm missing on ubuntuwire.com ?
<imbrandon> i think i snagged them all
<Fujitsu> Ah, I've found one!
<Fujitsu> You're using PHP.
<imbrandon> heh
<imbrandon> i dont have mod_python on that server i dont think
<imbrandon> not installed atleaste
<imbrandon> guess i could but it would be overkill for a simple post script
* Fujitsu blinks.
<Fujitsu> Where'd my gnome-{terminal,panel} and Abiword (with a fair bit of work in it) go?
<Fujitsu> Curses.
* Fujitsu starts again.
<LaserJock> feisty been a little ... unstable for me ;-)
<LaserJock> especially KDE
<LaserJock> I can't use it when I'm working
<Fujitsu> That's the only instability I've had in months...
<Fujitsu> And apport didn't trigger, so it must have been a fairly strange crash.
<RAOF> Gnome hasn't been particularly unstable for me.
<crimsun> leaving apport running makes my system unusable
<Fujitsu> crimsun: How?
<crimsun> move mouse -> entire screen freezes for one second -> repeat
<lifeless> oh, interesting
<lifeless> hasve you filed a bug ?
<Fujitsu> I like lifeless' idea.
<crimsun> lifeless: I haven't had time to reproduce it with -i810 [I use -i810-modesetting] 
<lifeless> crimsun: I use modesetting too
<LaserJock> Gnome's been better for me
<lifeless> crimsun: but apport should be unrelated to that
* RAOF needs to remember to file a bug about apport and sending large reports.
<crimsun> I'll do that in the morning, and if it's still present with -i810, I'll file a bug.
<LaserJock> my only problem is really is hard freezes
<Fujitsu> Probably modesetting segfaulting every time you move your cursor :P
<Fujitsu> LaserJock: I've not had one of those.
<LaserJock> once I figured out the KDE "hard shutdown via Keyboard Shortcut"
<LaserJock> KDE is giving me lots of those
<LaserJock> have to reset my laptop
<RAOF> Owch.
<LaserJock> last time fschk had a failure
<LaserJock> fsck
<LaserJock> but a reboot seemed to work
<RAOF> Worst I've had is resuming from suspend you need to kill X (with ctrl-alt-sysreq-k) and login again.
<Fujitsu> I used to have problems with my monitor remaining off after reopening it in some circumstances, but that seems to have resolved itself now. 
<LaserJock> RAOF: I haven't had that one
<Fujitsu> Suspend on this laptop works flawlessly, which is good.
<LaserJock> suspend to ram doesn't work on mine
<RAOF> Apart from that, suspend is working awesomely.  And it seems fixed.
<LaserJock> suspend to disk does
<crimsun> the beast that is "suspend"
<Fujitsu> Suspend-to-disk used to work, but I now use crypto-swap.
<RAOF> Once Xorg gets fully merged, I'll find out if Compiz kills suspend :)
<LaserJock> I just want an X that doesn't freeze
<RAOF> I've got one of those!
<LaserJock> lucky! :p
<crimsun> the X in the upper right corner of your windows freezes?
<LaserJock> heh
<imbrandon> ;)
<LaserJock> the whole screen just freezes
<LaserJock> I've never really seen anything like it
<LaserJock> it's just dead
<lifeless> Fujitsu: does crypto swap stop it working ?
<Fujitsu> lifeless: It's a random key on each boot... So yes.
<imbrandon> RAOF, and to awnser you from earlier most new phones and pda type mobile cameras do 3g2 == 3ggp2 == 3gp second gen
<imbrandon> just FYI
<imbrandon> and yes its a form of mp4
<Fujitsu> I'm really happy with the Linux compatibility of this laptop, especially now (thanks crimsun!) the HDA stuff works properly, with microphone and all.
<crimsun> ugh, HDA scars.
<Fujitsu> crimsun: It does look really painful to work with.
<imbrandon> s/3ggp2/3gpp2/
<imbrandon> anyhow
<RAOF> And so I presume ffmpeg handles it?
<imbrandon> not gotten that far but mencoder does so i would assume its useing ffmpeg
<imbrandon> brb
<bddebian> Gnight folks
<RAOF> night bddebian
<imbrandon> night bdmurray 
<imbrandon> err
<imbrandon> and it looks to be vorbis audio not aac
<imbrandon> anyhow
<RAOF> Woah.  Someone using an open codec in a real-life device?  Crazy! :)
<dholbach> good morning
<imbrandon> 'heya dholbach 
<Fujitsu> Hi dholbach.
<dholbach> hey imbrandon
<dholbach> hey Fujitsu
<LaserJock> ok, fixed my site, thanks for reminding me imbrandon 
<LaserJock> morning dholbach 
<dholbach> hey LaserJock
<imbrandon> hehe np
<LaserJock> imbrandon: I didn't want to just leave there in mid air
<LaserJock> but I forgot that I didn't do it
<LaserJock> I was working on another website and forgot
<imbrandon> heh i have done that a few times
<LaserJock> If I get a little wild some day maybe I'll figure out how to use PHP to do something nifty
<imbrandon> ;)
<imbrandon> i might add mod_python to my webserver tonight possibly
<imbrandon> just to have it incase i wanna use it
<imbrandon> Seveas keeps preaching python for the web , he might convince me one day
<_ion> pffft
<_ion> from __future__ import ruby
<LaserJock> bah
<LaserJock> how do you know if a webserver has mod_python?
<Fujitsu> LaserJock: Where's your site hosted?
<LaserJock> somewhere
<LaserJock> not my machine
<LaserJock> but I actually can't remember the name of the place
<Fujitsu> Trinsite, perhaps?
<LaserJock> yeah, that might be it
<LaserJock> I guess I could have figured that out ;-)
<Fujitsu> Probably :P
<LaserJock> hmm, I've got PHP 4.4.2 on here
<LaserJock> aren't we getting rid of PHP4?
<imbrandon> yes 
<imbrandon> everything save drupal uses 5 now
<imbrandon> 5 has been out ages
<Fujitsu> PHP 5 has been out since '03 or so, I think.
<LaserJock> how about apache2?
<Fujitsu> What about apache2?
<imbrandon> apache2 uses 5 ( or 4 or 3 for that matter )
<Fujitsu> apache2 uses whatever, yep.
<LaserJock> but how long has it been out?
<LaserJock> I don't think my server has it
<imbrandon> how long has what been out ?
<imbrandon> apache2 ? years
<imbrandon> apache and the php verison have little or nothing to do with each other
<imbrandon> LaserJock, you can install either one, apache or apache2
<imbrandon> my servers use apache2 and php5
<LaserJock> I just wondered
<LaserJock> my home server is running Feisty so I have apache2 and php5
<imbrandon> i have dapper servers with apache2 and php5 ( or breezy )
<imbrandon> ;)
<LaserJock> well yeah
<Fujitsu> LaserJock: That's because you have libapache2-mod-php5. -php4 is the PHP4 version (which should be removed soon).
<LaserJock> yes yes, I know
<LaserJock> I was just wondering how old they all were
<imbrandon> but you can still choose to install apache 1.3 or php4 , apache and php can have diffrent versions installed side by side like python2.4 and 2.5 etc
<imbrandon> brandon@voyager:~$ dpkg -l|grep apache
<imbrandon> ii  apache-common                1.3.34-4ubuntu1             support files for all Apache webservers
<imbrandon> ii  apache2                      2.0.55-4ubuntu4             next generation, scalable, extendable web se
<imbrandon> ii  apache2-common               2.0.55-4ubuntu4             next generation, scalable, extendable web se
<imbrandon> ii  apache2-mpm-prefork          2.0.55-4ubuntu4             traditional model for Apache2
<imbrandon> ii  apache2-utils                2.0.55-4ubuntu4             utility programs for webservers
<imbrandon> ii  libapache-mod-php4           4.4.2-1.1                   server-side, HTML-embedded scripting languag
<imbrandon> ii  libapache2-mod-php5          5.1.6-1ubuntu2.1            server-side, HTML-embedded scripting languag
<imbrandon> thats why i have on my server atm
<imbrandon> s/why/what
<imbrandon> well atleaste the one that runs imbrandon.com and ubuntuwire.com ( and a few other misc sites )
<imbrandon> ...
<imbrandon> i shushed everyone
* Fujitsu has an excuse for being quiet.
<Fujitsu> Dinner required consumption.
<minghua> So "no speaking at dinner table" apply to IRC too? :-)
<Fujitsu> Pretty much. Though they allowed me to when I was chatting with sabdfl a while ago.
<imbrandon> hehe
<imbrandon> Fujitsu, do you have win32codecs installed ?
<Fujitsu> imbrandon: Certainly not.
<imbrandon> hum ok
<Fujitsu> Why?>
<imbrandon> i wanted your to play a file in mplayer and tell me what codec its trying to use, no biggie, i'm just trying to find a good way to convert these damn 3g2 ( apparently qt codec needed ) to ogg 
<imbrandon> or similar free video
<imbrandon> i recorded some videos at the club last night and ..... well yea
<tsmithe> Adri2000, thanks :)
<Fujitsu> Beryl seems to run at a reasonable speed on this i915 now... The only change is the new xorg-xserver, but that surely can't do it.
<ajmitch> StevenK: dbmail is a fairly substantial update
<StevenK> ajmitch: Indeed, but one that I think is worth it.
<sistpoty> hi folks
<ajmitch> hi sistpoty 
<sistpoty> hi ajmitch
<Hobbsee> hey sistpoty, ajmitch 
<sistpoty> hi Hobbsee
<sistpoty> ajmitch: should I file a FreezeException for supertux-stable? or any other thoughts on this topic?
<ajmitch> sistpoty: it's a mess, I haven't followed it closely
<ajmitch> have you heard from upstream, rather than from a random user?
<Hobbsee> ajmitch: yes
<sistpoty> dholbach: do you have any further thoughts on supertux? 
<sistpoty> or crimsun, gpocentek: ^^ ?
<gpocentek> I only quickly read the thread
* gpocentek reads again
<Hobbsee> gpocentek: and so they stop whinging at us for not providing it
<Hobbsee> ahh, there we go...
<gpocentek> I agree with Rocco, I'd prefer having an -unstable package... but it's not possible with the backport
<sistpoty> gpocentek: well, I guess it'd be possible with supertux-stable and supertux-unstable both providing supertux, but that would be even going more out of sync with debian
<gpocentek> true
<dholbach> there's nothing wrong with rolling back to 0.1.something
<dholbach> and leaving the bug in edgy
<sistpoty> well, there are quite some users who'd rather have the 0.3 version instead of the stable one
<dholbach> either have an epoch or a version named 0.3.is.really.0.1.<something>
<dholbach> the first thing I'd do talk to upstream and explain them the benefits of users "tracking development versions"
<dholbach> and name GNOME and others as examples for that
<dholbach> that's the most beneficial approach to the problem :)
<Hobbsee> dholbach: upstream is happy with us having both, but we need to label which is which.
<sistpoty> dholbach: so you'd disencourage of having both versions in the archive?
<dholbach> sistpoty: that's ok too - I was just poiting other possibilities
<sistpoty> dholbach: ah, k :)
* Hobbsee notes that debian hasnt been complained too yet.
<sistpoty> (or it was lost on the debian games ml *g*)
<Hobbsee> haha
<sistpoty> at least there weren't complaints on the debian-games ml *G*
<sistpoty> (though there was a longer thread about 0.3.0)
<sistpoty> ok, I'm now out for a cigarette, and then I'll upload supertux/supertux-stable, unless someone complains in the meantime ;)
<Adri2000> supertux 0.3.0backto0.1.3-0ubuntu1 and supertux-unstable 0.3.0-0ubuntu1 < why not something like that ? :)
<Adri2000> people will update to the stable version when upgrading their feisty or when upgrading to feisty from edgy (with backports or not). those who want 0.3.0 will use supertux-unstable.
<sistpoty> Adri2000: well, but I guess quite many ppl. actually want 0.3.0 so (and have it installed from backports), so they'll end up with the old version once upgraded
<sistpoty> ok, uploaded
* sistpoty heads to uni now
<sistpoty> later folks
<fernando> moin all
<giskard> slomo, again? uff 
<giskard> hey motu* when you have time could you please take a look on the beryl packages?
<ajmitch> you avoided use of the fragment shader compiler now?
<hub> oh great, python is foobared
<slomo> giskard: yes, but i fixed it now ;)
<giskard> slomo, thank you
<giskard> stupid me, btw
<slomo> giskard: oh, did i fix it? wait, this was galago-sharp that i fixed... sorry ;)
<slomo> giskard: t# stilln needs to be fixed... do you want to do it?
<giskard> what was the fix for g-sharp
<slomo> giskard: dropped libdbus-1-cil build dependency, adding new required build dependencies (libgnmoe2.0-cil) and don't buildnig tests to not use dbus
* giskard thinks slomo should commit patches directly in pkg-galago
<giskard> slomo, ah! oki
<slomo> giskard: i don't care enough about it to really maintain it... i just want to get rid of libdbus-1-cil ;)
<giskard> :P
<giskard> oki
<bddebian> Heya gang
<Adri2000> heya bddebian
<bddebian> Hello Adri2000
<Adri2000> doko: can you take a look at bug #83097
<Ubugtu> Malone bug 83097 in python-gammu "versions <= 0.16 don't work with python 2.5" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83097
<Adri2000> doko: please :)
<Adri2000> doko: I don't know if I can update it (with an UVF exception), or if you plan to do it
<doko> Adri2000: write a report to ask for an UVF exception (following the documented procedure)
<Adri2000> ok
<doko> thanks
<Adri2000> np :)
<bddebian> I wonder if it's worth filing a UVFe sync request for thuban..
<Adri2000> ERROR: Package gammu is too old!
<Adri2000>        You need version 1.9.20, but 1.9.0 is installed
<Adri2000> pbuilder: Failed autobuilding of package
<Adri2000> :(
<bddebian> Always "fun" isn't it? :)
<Adri2000> ehehe :p
<Adri2000> the solution would be to update python-gammu only to 0.17 (which includes python 2.5 support), the "Compatibility with current gammu releases" is only in 0.18. what do you think doko?
<doko> Adri2000: your decision; you are motu, arn't you? I don't know the package ...
<bddebian> Adri2000: In other words go ahead, but break it and you die ;-P
<Adri2000> ok :
<bddebian> Oh crap, I probably wasn't supposed to upload a UVF eh?
<bddebian> We have a team for that?
<Adri2000> bddebian: you uploaded a new upstream version?
<bddebian> Yeah, it was ack'd by dholbach but I suppose I wasn't supposed to
<bddebian> Oh, maybe I'm OK, we only need 1 ack from a UVF team member apparently
<Adri2000> dholbach is in motu-uvf, so...
<dholbach> no, you need two
<dholbach> if the bug is confirmed, then it's good to go
<bddebian> We do?  That's not what the Exception page says
<Adri2000> bddebian: you filed a bug for this UVFe? or just asked dholbach?
<bddebian> Adri2000: No, it was already file by tuxmaniac, I was just "helping"
<bddebian> filed even
* bddebian has a head-ache
<Lure> dholbach (or other MC members): any news regarding the mailing list for applying for MOTU? 
<tuxmaniac> err. so is there something wrong with the procedure followed now? dholbach bddebian or is it fine?
<dholbach> Lure: I'm repeatedly pinging the sysadmin team
<dholbach> Lure: i'll announce it once it's there. Sorry for the inconvenience, but I'm not blocking this. :-(
<Lure> dholbach: ok, so just a question of getting Mailman list?
<Lure> dholbach: thanks
<dholbach> Lure: yep, exactly
<bddebian> Anyone have a feisty machine that wants to test a package for me quick?
<Adri2000> bddebian: yep
<bddebian> Let me throw it on REVU quick
<tuxmaniac> bddebian, is it gnusim8085 by any chance? :-)
<Adri2000> tuxmaniac: this one is already uploaded ;)
<tuxmaniac> Adri2000, :-)
<bddebian> tuxmaniac: No, thuban
<bddebian> Adri2000: http://revu.tauware.de/details.py?upid=4504
<Adri2000> building
<bddebian> Adri2000: I know it'll build, I just need to know that it "works" :_)
<Adri2000> yep, I'm building it in order to test it :)
<bddebian> I know :)
<Toadstool> g'morning!
<Adri2000> morning Toadstool
<Toadstool> hey Adri2000 
<bddebian> Heya Toadstool
<Toadstool> hi bddebian 
<Adri2000> bddebian: bad news for you
<Adri2000> bddebian: http://paste.ubuntu-nl.org/7660/
<bddebian> Gah, wtf
<bddebian> This is supposed to handle that:  http://paste.ubuntu-nl.org/7661/
<bddebian> Oh crap, 1.1.0 is a development release
* bddebian just quits
<Adri2000> ahah :D
<slomo> bddebian: what are you doing? :)
<bddebian> slomo: Nothing constructive, that's for damn sure
<bddebian> I was trying to update/whack any packages still building with wxgtk2.4
<bddebian> Gah, maybe I just need to finally give up altogether :'-(
<imbrandon> moins all
<jwhitlark> imbrandon, 'sup.  u missed pycon.
<imbrandon> yea , we eneded up getting a new big project at work and there was a ton of overtime associated
<imbrandon> but the good news is i got Ubuntu Live tickets already and working on getting to spain too
<zul> hey imbrandon 
<imbrandon> heya zul 
<zul> imbrandon: must be nice to be independtly weatlhy :)
<imbrandon> hahaha i wish
<zul> imbrandon: heh...if you dont eat for a whole month you can fly to spain ;)
<imbrandon> independnt yes, weathty no ;)
<imbrandon> lol
<fernando> hi imbrandon 
<imbrandon> ello fernando 
<bddebian> Heya imbrandon
<imbrandon> heya bddebian 
<bddebian> Adri2000: Thanks for testing btw
<tsmithe> hi imbrandon
<tsmithe> hows the hand?
<imbrandon> good
<tsmithe> cool!
<imbrandon> almost healed
<tsmithe> great
<nixternal> boo
<bddebian> Heya nixternal
<nixternal> well hello there mister
<bddebian> Heya LaserJock
<bddebian> hrmph
<LaserJock> hmm, I missed whatever somebody said
<bddebian> Just lowly ol' me saying Hi :-)
<zul> ummm...interesting im not a motu anymore according to launchpad
<LaserJock> yeah
<LaserJock> I brought that up when sistpoty was making the changes
<zul> im free!! :)
<LaserJock> hehe, not exactly
<LaserJock> or maybe
<LaserJock> hmmmm
<zul> or fired...heh
<LaserJock> it used to be that you were a MOTU if you were a core-dev
<LaserJock> because ubuntu-core-dev was a member of ubuntu-dev
<LaserJock> but now ubuntu-core-dev isn't a member of motu
<LaserJock> so technically core devs aren't MOTUs anymore
<LaserJock> ;-)
<zul> dang..
<zul> one less emblem..
<LaserJock> "Burn 'em!"
<zul> more witches!!
<LaserJock> there should be some "Law" that states how long it will take a Linux IRC chat to reduce to Monty Python references
<zul> i happen to like monty python
<LaserJock> I love monty python
<LaserJock> somehow it seems appropriate for every occasion
<zul> indoubely
<bddebian> "A duck"
<LaserJock> do we have 61 MOTUs now
<LaserJock> *so
<bddebian> WHAT?
<bddebian> 60, take me off the list
<LaserJock> whatever
* LaserJock whack bddebian upside the head with 2 copies of the Packaging Guide he glued together for such an occasion
* bddebian falls dead
<tsmithe> add me to the list!
<bddebian> tsmithe: You can take my spot.  I'm useless anymore
<tsmithe> woohoo
* tsmithe takes a bath
<LaserJock> bddebian: stop it
<bddebian> Speaking of which, did we lose ESR already? :-)
<tsmithe> eh?
<LaserJock> maybe the doc team scared him away :-)
<bddebian> heh
<LaserJock> bddebian: maybe we just gave him too much to do greping out all the Ubuntu man pages
<LaserJock> ;-)
* fernando waits to be a MOTU some day
<bddebian> LaserJock: Aye, no kidding
<Q-FUNK> motu et bouche cousue
<bddebian> yeah, what he said
<ajmitch> morning
<tsmithe> hiya ajmitch 
<zul> heya ajmitch 
<bddebian> Heya ajmitch
<LaserJock> hola ajmitch 
<cbx33> hey ajmitch 
<fernando> moin ajmitch 
<Adri2000> any motu-uvf to give a quick +1 to bug #88042 ?
<Ubugtu> Malone bug 88042 in python-gammu "[UVF exception request]  python-gammu 0.17-0ubuntu1" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88042
<LaserJock> imbrandon: around?
<sacater> gpocentek?
<imbrandon> LaserJock, pong
* tsmithe waves his @ubuntu.com email address at Hobbsee
<tsmithe> haha!
<Hobbsee> yay, tsmithe!
<imbrandon> heya Hobbsee 
<Hobbsee> hey imbrandon 
* imbrandon waves his @kubuntu.org address at tsmithe 
<tsmithe> imbrandon, meh. mine's .com :P
* Hobbsee waves her @ubuntu.com AND @kubuntu.org addresses at imbrandon and tsmithe 
<tsmithe> mrgh
<imbrandon> oh i have a ubuntu.com one too and imbrandon.com and brandonholtsclaw.com and ubuntuwire.com and ton of others ;)
* tsmithe goes to find out how to get an @kubuntu.org address
<_MMA_> Hobbsee: tsmithe is using your stick in other channels.
<tsmithe> does that by chance mean i have to use kde?
* tsmithe hides
<Hobbsee> oh dear.
* Hobbsee thwaps tsmithe.  yes.
<tsmithe> damn
<tsmithe> can i have an address anyway just for being great?
<imbrandon> if you have a ubuntu.com one you have a kubuntu.org one iirc
<LaserJock> I've got an @edubuntu.org address so :p
<imbrandon> and edubuntu.org too
<imbrandon> ;)
<_MMA_> Hobbsee: "tsmithe: i'll just get my own stick. and it'll be longer and pointier" <- Stick envy.
<Hobbsee> hah
* tsmithe just runs away
<tsmithe> _MMA_, tell tale
<_MMA_> lol
<LaserJock> hmm
<tsmithe> mm?
<LaserJock> you can't go around stealing people's sticks
<LaserJock> it's bad form you know
<LaserJock> ;-)
<tsmithe> that's why i got my own :)
<tsmithe> and it wasn't theft damnit!
<tsmithe> just, erm, borrowing
<LaserJock> sure ....
<imbrandon> haha you stoped downloading and i went from 900kb/s upload to 10kb/s upload
<imbrandon> ;)
<imbrandon> LaserJock, ^^
<LaserJock> lol
<LaserJock> uni badwidth FTW
<LaserJock> *bandwidth
<tsmithe> pahs
<Hobbsee> uni bandwidth here sucks.
<imbrandon> work bandwidth rocks
<LaserJock> Hobbsee: I can get 4MB/s if I get a good mirror
<Hobbsee> nice...
<LaserJock> CD .iso in 1.5 mins
<Hobbsee> 6% [5 libbonobo2-common 371917/595kB 62%]  [4 supertux-data 2682577/37.0MB 7%]                                               27.9kB/s 28m53s
<imbrandon> yea i can get 100 if i get a good mirror , i've only got 60 so far ( both ways )
* Hobbsee --> class
<ajmitch> imbrandon: MB/sec? :)
<imbrandon> ajmitch, yea
<ajmitch> you suck
<tsmithe> woah
<imbrandon> thats the ones ubuntuwire.com and the buld boxes are on
<tsmithe> a whole CD in six seconds?!!!
<imbrandon> and imbrandon.com
<stgraber> tsmithe: You have to consider the harddisk speed :)
<tsmithe> haha - forgot about that
<tsmithe> i wish i was at a point where the HD was slower than the line
<imbrandon> ;)
<imbrandon> hrm lemme test it real fast
<ajmitch> tsmithe: why, I can get up around 100MB/sec on my hard drives
<tsmithe> random access?
<tsmithe> or is the contiguous data?
<ajmitch> contiguous, tested with bonnie++
<imbrandon> hum i must have picked a slow mirror , i only got about ~10mb/s this time
<imbrandon> Length: 721,965,056 (689M) [application/x-iso9660-image] 
<imbrandon> 100%[===================================================================================================================================================================>]  721,965,056    9.89M/s    ETA 00:00
<ajmitch> so a sustained write speed to the filesystem of 100MB/sec
<imbrandon> i've had it upto 60 before
<ajmitch> though that is RAID, not a single disk 
* tsmithe is envious
<imbrandon> that mirror probably had a 10mb/s upload max
<imbrandon> is why
<ajmitch> tsmithe: building packages goes a bit faster on raid 0 :)
<tsmithe> mrgh
<tsmithe> stop boasting
<ajmitch> sure, I could boast about my high speed adsl
<tsmithe> go away :P
<ajmitch> </sarcasm>
<ajmitch> I live in NZ
<ajmitch> decent connectivity is a mythic creature, not often seen
<tsmithe> i live in the UK
<tsmithe> decent connectivity is pretty much ubiquitous
<tsmithe> unfortunately, i'm about four miles from my exchange, so adsl is slow
<ajmitch> telecom are rolling out adsl2+ "real soon now"
<imbrandon> ajmitch, hehe
<imbrandon> fiber in the DC ftw
* ajmitch gets < 4Mbps 
<imbrandon> i'm not even sure how much total bandwidth we have but i know our avg out is about 200MB/s 
<imbrandon> but my 100MB/s nic is connected to a cisco thats direct to the core
<imbrandon> so i get a full 100MB/s if i can use it
<ajmitch> lucky
* stgraber only has 7x10MB/s :(
<ajmitch> though you probably wouldn't get away with saturating that
<ajmitch> management may not be happy
<imbrandon> in bursts they dont care, i've done that, if i went over 50mb/s avg they might balk
<imbrandon> ;)
<imbrandon> but as of this moment i do about 2mb/s avg total accross all my domains
<LaserJock> holy freaking cow
<LaserJock> sorry, I mean, wow!
<LaserJock> I think I use of something like 100mb/month on laserjock.us ;-)
<imbrandon> hehe
<tsmithe> imbrandon, that's not true: "
<tsmithe> Remote host said: 550 <tsmithe@kubuntu.org>: Recipient address rejected: User unknown in virtual alias table"
<tsmithe> :'(
<imbrandon> ahh maybe not then heh
<tsmithe> :)
<imbrandon> i know both of mine work, but i'm also in kubuntu-team and ubuntu members
<tsmithe> yea
<Adri2000> bddebian: how is wx2.8 going?
<imbrandon> oh snap i just realized this router i got given to me supports openwrt
<imbrandon> nice
<Adri2000> ajmitch: around? would you give a +1 for my UVFe? :) bug #88042
<Ubugtu> Malone bug 88042 in python-gammu "[UVF exception request]  python-gammu 0.17-0ubuntu1" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88042
#ubuntu-motu 2007-02-27
<animimotus> hi
<animimotus> it's here where we can ask for a backport?
<animimotus> for conky
<animimotus> I have made a bug report in bugzilla
<animimotus> some weeks ago :)
<animimotus> please, send the bits ^^
<lionel> animimotus: you have the process here https://wiki.ubuntu.com/BackportRequestProcess
<lionel> animimotus: I can not find your bug report
<Adri2000> pochu: congrats :)
<pochu> Adri2000: ty :)
<pochu> I'm aboard :)
<pochu> night motus! :)
<bddebian> Heya gang
<tonyyarusso> hey
<geser> hi bddebian
<bddebian> Hello tonyyarusso, how's it coming?
<bddebian> Heya geser
<tonyyarusso> bddebian: a little better.  I talked to the lead Ubuntu Mozilla dev and some folks from Linspire today, and got some good suggestions about the issues I've been having, so we'll see where that gets me.
<tonyyarusso> Also, it is officially going to be allowed to be Nvu, so I can stop worrying about naming nuttiness.
<bddebian> Great
<bddebian> man it's quiet in here tonight
<ajmitch> because some of us are working
<bddebian> Bah :)
<nixternal> hi, I want to be a UTOM, what do I have to do?
<bddebian> Working is over-rated :-)
<nixternal> ajmitch either lied or made a damn good funny :)
<ajmitch> lied?
<ajmitch> why you say I lie?
<LaserJock> imbrandon: pingy pingy
<bddebian> CONTENTLESS PING, CONTENTLESS PING!!
<bddebian> :)
<LaserJock> of course
<boredandblogging> whats the page on the wiki for newbies interested in MOTU? like a page describing what mailing lists to sign up and process to even be MOTU hopeful? I'm interested in packaging ArgoUML
<crimsun> https://wiki.ubuntu.com/MOTU/Hopeful/Recruitment
<RAOF> boredandblogging: First, you don't need to be a MOTU to package stuff.  Second, I think that ubotu can...
<RAOF> !packagingguide
<ubotu> The packaging guide is at http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html - Other developer resources are at https://wiki.ubuntu.com/DeveloperResources
<RAOF> !revu
<ubotu> 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
<crimsun> it's linked from the topic, of course. Please actually READ THE TOPIC.
<boredandblogging> the first thing MOTU/Hopeful/Recruitment talks says is "After working a while with the MOTU community..."
<boredandblogging> assuming I haven't worked a while, where do I go?
<RAOF> You package something, and post it on REVU?  You look at motu bugs and fix them, attaching debdiffs to the bug reports?
<crimsun> you read a bit further down the page and click the UbuntuDevelopers link.
<boredandblogging> that link to UbuntuDevelopers seems like its for if you want to go from MOTU hopeful to actual MOTU
<boredandblogging> not for beginners
<crimsun> did you actually READ UbuntuDevelopers?
<crimsun> see the leading section, Prospective Developers
<crimsun> the second and third bullets in that section are links to sections you'll want to read
* bddebian should read that
<boredandblogging> why i click on the link if the text leading up to it says "General guide lines for membership approval (which seems like its referring to becoming a MOTU from MOTU hopeful)"
<crimsun> what is your interest? packaging only?
<crimsun> if so, your first question is misleading, unclear, and serves to undermine our efforts to guide you
<crimsun> Let us wrap it up in a nutshell. Say you want to package ArgoUML. Follow the Ubuntu Packaging and Debian New Maintainers' Guides. If you'd like to be able to upload your package(s) to Ubuntu, you'll need to 1) become an Ubuntu member; 2) become an MOTU.
<boredandblogging> let me start again, I'm looking into how to be MOTU hopeful...the UbuntuDevelopers link is embedded in a paragraph about  how you want to go from MOTU hopeful to MOTU.
<crimsun> right, so you'll want to read carefully what I just typed.
<crimsun> Here's what I recommend you do:
<boredandblogging> I understand, but telling me to read the topic doesn't lead me read UbuntuDevelopers, thats all I was saying. Didn't mean to get defensive or anything.
<crimsun> 1) Read the Ubuntu Packaging and Debian New Maintainers' Guides; 2) Work with an MOTU mentor to get up to speed with REVU and general MOTU processes; 3) apply for Ubuntu membership after sustained involvement; 4) continue working with MOTU [as MOTU hopeful] ; 5) after sustained involvement in Ubuntu universe, apply for MOTU
<boredandblogging> but UbuntuDevelopers is what I was looking for
<bddebian> *cough*
<crimsun> I really don't see how that _isn't_ followed from http://wiki.ubuntu.com/MOTU
<crimsun> http://wiki.ubuntu.com/MOTU -> https://wiki.ubuntu.com/MOTU/Hopeful/Recruitment -> https://wiki.ubuntu.com/UbuntuDevelopers
<crimsun> (or)
<lotusleaf> one link to rule them all!
<crimsun> http://wiki.ubuntu.com/MOTU -> https://wiki.ubuntu.com/UbuntuDevelopment -> https://wiki.ubuntu.com/UbuntuDevelopers
<boredandblogging> the first sentence iin Recruitment is You have been a MOTU Hopeful for a while now
<crimsun> well, sure, I pasted https://wiki.ubuntu.com/MOTU/Hopeful/Recruitment _hoping_ that you had, in fact, read http://wiki.ubuntu.com/MOTU
<LaserJock> don't worry about that too much
<crimsun> I'm sorry that I assumed people actually read the topic.
<LaserJock> crimsun: want me to take this one, you seem busy? :-)
<crimsun> sure, take it all, fiic.
<nixternal> LaserJock: did you break my system with today/tonights updates?
<nixternal> ;p
<LaserJock> boredandblogging: don't worry about the MOTU Hopeful term
<LaserJock> boredandblogging: it applies to anybody who is not an MOTU but wants to do motu work
<LaserJock> boredandblogging: does that make sense?
<boredandblogging> yes, in that case Recruitment makes perfectly good sense :-)
* ajmitch returns 
<bddebian> wb ajmitch :)
<nixternal> OK, so what are the tricks to this new xorg 7.2?
<ajmitch> magic incantations?
<nixternal> I need to disable my synaptics touchpad automagically when my external is connected. how do I go about that one now seeing we don't have a xorg.conf to work with?
<superm1> xorg 7.2 scrapped xorg.conf finally?
<RAOF> nixternal: Add an xorg.conf.  It still uses it.
<nixternal> RAOF: well it didn't use mine
<nixternal> it made me use tty1-6 :)
<RAOF> :)
<nixternal> woohoo, it works. just have to remove the composite from xorg.conf
<jdong> nixternal: fglrx?
<nixternal> no no
<nixternal> Intel
<nixternal> it still runs Beryl though, but really nasty
<jdong> oh
<jdong> hmm Intels should do fine when composite is on
<nixternal> oh, when I had composite enabled it rocked
<nixternal> but with xorg 7.2 when I enable composite, x-windows won't start
<jdong> hmm
<nixternal> unless they have it enabled by default
<jdong> ick Xgl is leaking on me.
<jdong> with the newest xserver-xorg-core composite is on by default
<nixternal> ya I am going to hold off on the composite stuff anyways
<nixternal> quite useless actually
<nixternal> ahh, that is why
<RAOF> I like scale.
<nixternal> RAOF: +1
<RAOF> It's non-useless :)
<nixternal> me too, that is my favorite
<jdong> yeah I like berl/compiz usability features.
<jdong> scale
<jdong> zoom
<jdong> negative, too
<jdong> (death to bright neon colored websites!)
<jdong> transparency has also been really helpful for me
<RAOF> The switcher's not bad.  Particularly now that it has an application-window switcher.  At least on my box :)
<jdong> the ring-switcher is great
<jdong> it helps see how many more tabs you need to hit to get to your window
<jdong> and my classes distribute most of the reading material via PDF's
<jdong> I'd like to save paper...
<jdong> but not kill my eyes
<jdong> inverting the colors is a lifesaver.
<RAOF> I'd quite like to see the ring-switcher.
* RAOF uses compiz
<jdong> RAOF: the ring switcher is awesome...
<jdong> I hope they port it to compiz soon
<RAOF> Maybe I will.  I've looked at the code, and it seems fairly easy to port, at least :)
<jdong> :)
<nixternal> jdong: the ring switcher?
* nixternal starts up beryl to see
<jdong> nixternal: winkey+tab
<jdong> it's a switcher where windows are oriented in a ring
<jdong> rather than in a filmstrip line.
<nixternal> oh well, beryl won't even start up now
<RAOF> No Composite for you?
<jdong> poor nixternal .....
<jdong> fully dist-upgraded?
<jdong> need the new xserver-xorg-core appearing like 5hrs ago.
* RAOF looks forward to going home and dist-upgrading so he can hack on compiz a bit
<crimsun> nixternal: composite has been enabled by default since edgy.
<crimsun> you may have exposed a bug in 019_ubuntu_enable_composite.diff, though
<dholbach> good morning
<crimsun> hi
<ajmitch> hey daniel(s)
<dholbach> hiya andrew, hi daniel
<cypher1> dholbach, good morning !
<dholbach> hiya cypher1
<cypher1> dholbach, have you used activkey  ?
<dholbach> no, not at all
<dholbach> what is it?
<cypher1> dholbach, its a hardware for authentication
<cypher1> dholbach, like smartcards
<dholbach> no, I don't have that kind of hardware - sorry
<tepsipakki> nixternal: did you use my experimental packages?
<cypher1> dholbach, ok no problem.. i am struggling to get it work under ubuntu :(
<AnAnt> Hello
<AnAnt> did anyone manage to package nspluginwrapper ?
<AnAnt> I see that there is a package in the Debian queue
<nixternal> I got it working
<nixternal> I had a line under my graphics card that shouldn't have been there
<nixternal> although for me 7.2 is a downgrade over 7.1 w/ Beryl
<nixternal> scrolling is garbage
<Kagou> hi
<nixternal> tepsipakki: which experimental package are you referring to?
<tepsipakki> nixternal: if you don't know about them, you haven't used them ;)
<tepsipakki> nixternal: do you have the new xorg-server which was uploaded yesterday?
<LaserJock> yeah, I had to whip out xorg.conf to get X working after the updates today
<tepsipakki> LaserJock: whip out?
<LaserJock> wipe
<LaserJock> mv it aside
<tepsipakki> attach them to a bugreport ;)
<LaserJock> why?
<LaserJock> is it a bug?
<tepsipakki> could be
<LaserJock> it's just a default xorg.conf
<tepsipakki> did you use EXA?
<tepsipakki> oh
<LaserJock> I don't think I changed anything
<tepsipakki> so how could it be that, then ?
<tepsipakki> old configs should work just fine
<LaserJock> it looked like it was dying on either wacom or fonts
<LaserJock> Hobbsee!
<tepsipakki> did X fail to start and give some error?
<LaserJock> yeah, the usual
<tepsipakki> please diff the configs
<LaserJock> what configs?
<tepsipakki> duh, the old vs new
<LaserJock> there is no new
<tepsipakki> ah, so you are using it _without_ a config?
<LaserJock> that's what I would gess
<Hobbsee> LaserJock!!!
<LaserJock> I just move xorg.config to xorg.conf.bak and restarted gdm and it worked
<tepsipakki> ok
<LaserJock> is that not normal?
<LaserJock> I guess it *should* work with existing xorg.conf files
<tepsipakki> running without a config is supported with the new server
<LaserJock> that's what I assumed it wanted, that's why I mv'd my existing one
<tepsipakki> but your old one should work
<LaserJock> hmm, so that's 2 tonight that didn't work
<tepsipakki> someone else had problems as well?
<tepsipakki> the wacom errors (~"missing device") are harmless
<LaserJock> yeah, nixternal was having problems
<tepsipakki> but if there's something wrong with the fontpaths, it fails
<tepsipakki> oh, of course
<LaserJock> synaptics touchpad and composite were his issues I think
<LaserJock> tepsipakki: I think it was the fontspaths perhaps
<tepsipakki> LaserJock: do you have the latest xorg installed? (the metapackage)
<tepsipakki> it should create a link from the old path to the new one..
<LaserJock> tepsipakki: I have no idea, it's just the latest dist-upgrade in Feisty
<tepsipakki> hmm, maybe we need to make the fontpath more robust
<tepsipakki> not play with symlinks
<tepsipakki> but give the server proper config options
<slytherin> Can anyone tell me if https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-February/000249.html affects REVU uploads? I mean I will not be able to sign a package for REVU upload since I don't have ubuntu.com address. Am I right?
<lionel> slytherin: yes, you have to put  Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com> in the maintainer field and yourself in the XSBC-Original-Maintainer field
<slytherin> lionel: Ok. I will try tonight.
<tepsipakki> LaserJock: please file a bug on xorg and attach your non-working xorg.conf and Xorg.0.log
<LaserJock> tepsipakki: xorg or xorg-server?
<tepsipakki> hum, the latter
<LaserJock> tepsipakki: bug #88311
<Ubugtu> Malone bug 88311 in xorg-server "upgrade to 1.2.0-3ubuntu1 killed X" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88311
<tepsipakki> LaserJock: thanks
<LaserJock> np
<tepsipakki> just as I suspected..
<tepsipakki> for some reason there is no FontPath entry for /usr/share/fonts/X11/misc
<tepsipakki> which has been there at least since dapper
<tepsipakki> and I just noticed a dupe ;)
<Lutin> buxy: ping
<buxy> Lutin: pong
<Lutin> buxy: may I pm ?
<buxy> if you want
<Lutin> ok, thanks
<LaserJock> tepsipakki: this was a fresh Edgy install dist-upgraded to Feisty
<zakame> hmm feisty borked today? I don't have X right now :/
<LaserJock> heh
<tepsipakki> zakame: https://beta.launchpad.net/ubuntu/+source/xorg/+bug/88254 ?
<Ubugtu> Malone bug 88254 in xorg "xserver fails to start - missing FontPath in xorg.xonf" [Undecided,Confirmed]  
<LaserJock> check l-r-m or xorg.conf ^^
<zakame> tepsipakki: bingo
<zakame> hmm is ph.archive.ubuntu.com down? appears so in ping
<tepsipakki> zakame: what does 'ls -ld /usr/share/X11/fonts' show?
<zakame> hmm, /usr/share/X11/fonts
<zakame> you mean ls -lR?
<tepsipakki> so its there?
<zakame> if I do `ls -lR $font_dir` I just get encodings and scale files
<zakame> there are no font files installed
<tepsipakki> that should be a symlink
<zakame> to?
<tepsipakki> to /usr/share/fonts/X11
<zakame> oh, there we go
<LaserJock> hehe, I've managed to get KDE to look like Ubuntu, how naughty of me :-)
<tepsipakki> xserver-xorg installs that, but if there is a directory already it fails
<tepsipakki> so we need to find a cure
<zakame> hmm so I just delete the existing directory and do apt-get install --reinstall xserver-xorg?
<tepsipakki> that should work
<zakame> or would just a plain rmdir/symlink to real loc would do?
<tepsipakki> that too ;)
<zakame> heh
<zakame> thanks tepsipakki, brb :D
<shawarma> How many ACKs do we need on UVFe's? I forget.
<LaserJock> 3 I think
<Hobbsee> 2
<LaserJock> 1
<LaserJock> blast off!
<shawarma> BOOM
<shawarma> w
<shawarma> Well that didn't help much. :-)
<zakame> back
<zakame> tepsipakki: thanks for the heads-up!
<zakame> now it's the ipw3945 on 2.6.20-9 that's the problem :/
<tepsipakki> zakame: so it worked?
<zakame> yeah
<Hobbsee> zakame: what's the problem with ipw3945?
<GNUro> 'lo!
<zakame> Hobbsee: no ipw3945, doesn't seem configured per iwconfig
<Hobbsee> hrm.
<Hobbsee> zakame: oh, got l-r-m installed?
<Hobbsee> and updated?
<Hobbsee> oh, here it comes now
<zakame> exactly, there's no l-r-m-2.6.20-9-generic yet
<zakame> and ph.archive seems to be down :/
<Hobbsee> ah yep, it's here now...
<Hobbsee> pitti put it threw NEW an hour ago?
<zakame> oh, now its back up
<zakame> tepsipakki: what was the bug number again? #88254?
<tepsipakki> zakame: yep
* Hobbsee contemplates a reboot.
<LongPointyStick> done :)
<LaserJock> Hobbsee: I've managed a whole evening in KDE without a random shutdown/hibernation or freeze :-)
<Hobbsee> LaserJock: yay!
<LaserJock> and now that I turned it brown it even looks OK ;-)
<Hobbsee> haha
<LaserJock> I grabbed the Ubuntu chocolate wallpaper
<LaserJock> and some Ubuntu KDE color scheme off of kde-look
<LaserJock> and used the Human icons
<LaserJock> and it sort of works
<Hobbsee> hehe
<Hobbsee> sad :P
<LaserJock> I know
<LaserJock> I mostly did it because my wife is used to Gnome and I'm going to try to set KDE as the default for a while
<LaserJock> so if the desktop has the same colors and icons she won't really mind
<Hobbsee> ahhh
<LaserJock> tepsipakki: so do I need to have a /usr/share/X11/fonts link?
<tepsipakki> LaserJock: yes
<tepsipakki> with your old config
<LaserJock> I've got one machine that had it as a directory and one that doesn't have it at all
<tepsipakki> none of my machines have it as a directory :/
<LaserJock> the machines should be basically identical
<LaserJock> I installed edgy at the same time
<LaserJock> and I upgraded to Feisty at roughly the same time (within a few weeks anyway)
<fernando> moin all
<tuxcrafter> can someone point me to the rules of using a cvs checkout i believe in this:
<tuxcrafter> i don't want to use tarballs i want to use cvs checkouts and dependencies need to be pointed out before compiling when run the .autogen.sh or .configure.sh script not when you are installing and get errors
<Hobbsee> ...why not use a tarball?
<tuxcrafter> i em testing and helping debuggin
<tuxcrafter> using a cvs has always been my methot
<Hobbsee> tuxcrafter: are you looking to get these into the ubuntu archive at all?
<tuxcrafter> yes
<tuxcrafter> Hobbsee: what is the normal whay of getting the source and helping a testing a program?
<tuxcrafter> the cvs or a tarball
<Hobbsee> tarball
<Hobbsee> well, for getting it into the archives
<tuxcrafter> and why is that
<Hobbsee> have you seen the packaging guide?
<Hobbsee> !packagingguide
<ubotu> The packaging guide is at http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html - Other developer resources are at https://wiki.ubuntu.com/DeveloperResources
<Hobbsee> btw, you wont get it into feisty now.
<tuxcrafter> Hobbsee: it is for over 2 or 3 releasse
<tuxcrafter> it needs to mature first
<Hobbsee> right
<tuxcrafter> Hobbsee: oke so its better to use the source tarball instead of the cvs
<tuxcrafter> for testing
<Hobbsee> tepsipakki: any chance of fixing https://beta.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/40021 as well?
<Ubugtu> Malone bug 40021 in xserver-xorg-input-synaptics "Synaptics side scroll is disable by default on Dell Inspiron6400" [Medium,Needs info]  
* Hobbsee can provide a logfile, if needed
<Hobbsee> tepsipakki: seems my scrollbar didnt wnat to work without an xorg.conf file.  weird.
<tepsipakki> Hobbsee: that bug seems easy
<Hobbsee> tepsipakki: indeed.
<tuxcrafter> Hobbsee: thank you for your help, i will speak with you later for help with maintaining a new package
<Hobbsee> ok
<swarog> hellow
<gismo_> hello all
<gismo_> I have a problem with vmware-player-kernel-modules under Dapper
<gismo_> I submited a bug last week but I don't understand what's the problem
<gismo_> https://launchpad.net/ubuntu/+source/vmware-player-kernel-2.6.15/+bug/86848
<Ubugtu> Malone bug 86848 in vmware-player-kernel-2.6.15 "vmware-player-kernel-modules-2.6.15-28 still missing" [Undecided,Unconfirmed]  
<gismo_> yes
<gismo_> why it's still unconfirmed ? Is someone able to run vmware player on Dapper under 2.6.15-28 ?
<zul> dev probably hasnt gotten to it yet besides this channel isnt for support
<gismo_> oups sorry
<tuxmaniac> Heya gang
<tuxmaniac> Yesterday, bddebian uploaded gnusim8085 on to revu. But I am unable to see it listed. Any reasons? 
<lionel> gismo_: I have just confirmed the bug. Try to speak with kernel team on #ubuntu-kernel for that
<gismo_> ok thanks !
<Adri2000> tuxmaniac: he uploaded it to the archive, not revu
<tuxmaniac> Adri2000, aah ok. thanks
<tuxmaniac> :-)
<imbrandon> root@akira:~# uname -m
<imbrandon> mips
<imbrandon> bwhahahaha
<imbrandon> heya all
<zul> imbrandon: er...why?
<imbrandon> zul, just because ( its my router )
<Adri2000> hi imbrandon
<imbrandon> with openwrt
<imbrandon> ello Adri2000 
<Adri2000> imbrandon: what's the next build machine on the list? :)
<zul> imbrandon: ah ok i guess thats acceptable then :)
<imbrandon> Adri2000, definately not that mips , its only 200mhx and 16mb ram
<imbrandon> ;)
<Adri2000> hehe
<jrib> are there any plans to get rid of the use of https://wiki.ubuntu.com/MOTU/Packages/Candidates and replace it with something else?  Or can I still point people here if they want some program that isn't packaged?
<fiXXXerMet> Hey everyone.  #ubuntu sent me here.  I was asking them how to request a package to be made for/added to ubuntu.
<jrib> oh here he is :)
<imbrandon> jrib, yes point them there is fine 
<imbrandon> err yea
<fiXXXerMet> lol
<jrib> fiXXXerMet: you can request at https://wiki.ubuntu.com/MOTU/Packages/Candidates
<bddebian> Heya gang
<fiXXXerMet> thank you jrib
<jrib> imbrandon: thanks.  some motu's were telling me that it might be getting replaced and that was several weeks ago, so I wanted to make sure
<jrib> hi bddebian 
<bddebian> Hello jrib
<fiXXXerMet> Do I need to edit the wiki, or is there a submit page?
<jrib> fiXXXerMet: you need to edit the wiki
<fiXXXerMet> ok
<imbrandon> heya bddebian 
<bddebian> Hi imbrandon
* jrib wonders why a windows application is on the candidates list (SmartBlend)
* tuxmaniac is unable to find it in archives also gnusim8085 :-(
<bddebian> tuxmaniac: In NEW?
<fiXXXerMet> Thanks everyone - I added the reques tot the list.
<fiXXXerMet> How do I monitor the progress of this - keep checking the page?
<tuxmaniac> bddebian, unable to find :-(
<bddebian> It shows on LP:  https://launchpad.net/ubuntu/feisty/+source/gnusim8085/1.3-0ubuntu1
<crimsun> ouch
<crimsun> compiz is now in -desktop? That utterly broke.
<imbrandon> wha?
<crimsun> ubuntu-meta (1.36) feisty; urgency=low -> * Added desktop-effects ... -> apt-cache show desktop-effects |grep ^Dep |grep compiz >/dev/null ; echo $? -> 0
<imbrandon> wonderfull
<crimsun> I restarted gdm, logged in, and was greeted with the black screen of death
<imbrandon> i thought that was decided against
<crimsun> ended up mving ~/.gnome* and ~/.gconf*
<imbrandon> didnt sab post about that
<crimsun> I don't think it's enabled by default
<crimsun> I can't tell, though, because something definitely went wonky
<imbrandon> i guess i'll know on reboot i just updates
<imbrandon> updated*
<imbrandon> and gnome is bugging me to reboot, but i was trying to finish my openwrt upgrade first
<crimsun> I'm happy that I can properly log out now from gnome-session, though.
<imbrandon> yea that would be a good thing
<imbrandon> crimsun, are you actively using that debian image ( this moment )
<imbrandon> e.g. if i shut my router off for a little while will it effect you ?
<crimsun> imbrandon: no, and no.
<imbrandon> kk i'm gonna take it offline for a bit then
<imbrandon> to switch to this openwrt router
<larsivi> kvpnc don't work out of the box - something with kdesu
<larsivi> After entering my su password, I get "Fann ikkje kommandoen su-to-root -X -c /usr/bin/kvpnc ."
<larsivi>  which translated is "Couldn't find command ..."
<larsivi> I tried to symlink su-to-root to sudo, but -X is not an option for sudo
<larsivi> I suppose I should report this somewhere, but to which tracker?
<_ion> Launchpad
<LaserJock_> imbrandon!
<imbrandon> LaserJock_, !!
<tonyyarusso> ... someonewholovesme!!
<imbrandon> heh
<zul> hey guys
* LaserJock_ gives tonyyarusso a hug
<tonyyarusso> :)
* LaserJock_ high-fives zul
<tonyyarusso> hi LaserJock_ 
<imbrandon> heya zul 
* LaserJock_ took his happy pills this morning
<LaserJock_> imbrandon: KDE seems to be acting ok for me know. I used it all last night without a hitch
<LaserJock_> imbrandon: btw, Ctrl-C doesn't work in konsole for me, I must have messed something up
<imbrandon> hrm
<imbrandon> strange
<imbrandon> i'll definately see why tonihgt
<LaserJock_> it could be because I went in and mapped it to Shift-Del
<imbrandon> possibly, but most likely a bug
<LaserJock_> how many of you guys thing a package whiteboard would be helpful on LP?
<imbrandon> for what?
<LaserJock_> I was thinking leaving notes when we're doing stuff like merges
<LaserJock_> i'm not sure if it'd get abused and turn into bug reports or not
<LaserJock_> I was just thinking that bugs aren't really that appropriate for non-bug related stuff
<LaserJock_> we use bugs quite a bit for process related stuff
<geser> something to make comments (like sync requested, FTBFS, etc.) would be useful
<zul> heh...i would leave grafitti on it ;)
<LaserJock_> canadians *rolls eyes*
<geser> so that one wouldn't need to redo a merge to figure out that there's a problem
<zul> LaserJock_: we might be pacifists.....then again we might not
<LaserJock_> like, in my mind it'd be cool if I'm merging and first I go to the source page on LP and check the whiteboard and see that somebody else tried to merge the package but it had problem X
<LaserJock_> or we did some funky short term fix so we leave a note that the change can be dropped next time
<LaserJock_> or if we think gentoo is the suxor we can spray paint that somewhere ;-)
<imbrandon> grr
<imbrandon> anyone else good with apache2 in here?
<imbrandon> hum got it
<crimsun> LaserJock_: more and more it seems like we need a ticket system; one central place to grab merges
<LaserJock_> yeah
<LaserJock_> I was thinking it'd be interesting to have a page that showed all the packages in some activity (unmet deps, merges, etc.) and then have like a checkbox for state and a comment field for who's doing it or notes
<LaserJock_> that would be a simplistic approach
<imbrandon> yea lp becomes an erp ;)
<LaserJock_> I think an essential issue with LP is that it looks at packages from a single maintainer point of view. It's not really designed for team maintainance I don't think
<imbrandon> well upuntill ubuntu nothing was really designed for a team , package wise
<imbrandon> so that kinda makes sense
<imbrandon> but not optimal 
<LaserJock_> right
<mohammad> Hello I have uploaded a package to revu, now I am getting a lot of spam I decided to change my email adress to get rid of more spams but it seems that's impossible
<geser> crimsun: as you uploaded flashplugin-nonfree in the past: have you seen the debdiff in bug #85911? is it ok to upload it?
<Ubugtu> Malone bug 85911 in flashplugin-nonfree "Description should be Ubuntu-specific" [Low,Confirmed]  https://launchpad.net/bugs/85911
<mohammad> i uploaded once with my new email address but I could not login to revu 
<LaserJock_> mohammad: if you upload a new package with your new address (make sure it's in your gpg key too) it should work
<mohammad> LaserJock_: I added this new address to my previous gpg key then send the key to keyservers, then I uploaded the new package with new email, uploading was done successfully but 
<mohammad> LaserJock_: but i am unable to login with new address
<LaserJock_> mohammad: did you try the password recovery?
<mohammad> LaserJock_: yes but it did not give me any encrypted password
<crimsun> geser: +1, feel free to update & upload. Please consider rolling in fix for bug 80545 / bug 86089 in that upload, too.
<LaserJock_> hmm, when is the next MOTU meeting?
<Ubugtu> Malone bug 80545 in flashplugin-nonfree "Don't use /usr/lib/flashplugin-nonfree-unpackdir" [Medium,In progress]  https://launchpad.net/bugs/80545
<Ubugtu> Malone bug 86089 in flashplugin-nonfree "FHS violation, wrong install location" [Undecided,Confirmed]  https://launchpad.net/bugs/86089
<LaserJock_> mohammad: you might want to email the REVU admins
<bddebian> Gaaah I hate my job some days
<mohammad> LaserJock: thank you
<crimsun> ok, so people are now requesting that we mute all sound during install and first boot
<ajmitch> morning
<crimsun> ('morning)
<LaserJock_> what?
<LaserJock_> why?
<LaserJock_> hi ajmitch
<crimsun> stuff like "too loud/I'm installing in X's office and don't want to disturb/installing or booting while in a meeting"/etc.
<crimsun> I have no idea what any sort of majority opinion would be, so I'll take it to -discuss
<crimsun> there's no way we can please everyone with either decision
<ajmitch> ah, getting warning of a 3 hour launchpad downtime a few hours before it happens
<nixternal> crimsun: tell them to install windows then :)  Oh wait, that install is obnoxiously louder and more annoying
<crimsun> either approach will generate more bug reports
<crimsun> "omgsounddoesn't work -> I had to manually unmute"
<crimsun> "omgsoundtooloud -> I had to manually mute"
<LaserJock_> yeah
<crimsun> maybe implement crystalball() in the installer?
<LaserJock_> although I'd tell people to just turn their speakers down if they don't want the noise
<ajmitch> crimsun: tealeaves() works better
<crimsun> ajmitch: ah, true
<ajmitch> LaserJock_: harder to do that on a laptop
<LaserJock_> ajmitch: it is?
<ajmitch> LaserJock_: at least on mine it takes a little while before it'll respond to 'volume down' events from the keyboard
<ajmitch> or at least it seems to :)
<LaserJock_> oh, mine has a little wheel on the side
<LaserJock_> I don't use the keyboard for volume
<ajmitch> lucky you :)
* ajmitch has to depart for work now
<Adri2000> crimsun: can you +1 https://launchpad.net/ubuntu/+source/python-gammu/+bug/88042 please
<Ubugtu> Malone bug 88042 in python-gammu "[UVF exception request]  python-gammu 0.17-0ubuntu1" [Undecided,Unconfirmed]  
<imbrandon> later ajmitch 
<crimsun> bug 88042
<Ubugtu> Malone bug 88042 in python-gammu "[UVF exception request]  python-gammu 0.17-0ubuntu1" [Undecided,Confirmed]  https://launchpad.net/bugs/88042
<crimsun> Adri2000: ^
<Adri2000> thanks
<LaserJock_> well, I got some good LP info today
<tonyyarusso> oh?
<LaserJock_> I figured out how +bugs-text works
<LaserJock_> and +text
<LaserJock_> so we can get plain text files for bug numbers and then bug info
<LaserJock_> also got an estimate on when our +filebug tag preloading might roll out
<LaserJock_> so we can start moving package requests onto LP
<crimsun> what I really need is a big red button on LP that functions as "reassign all my bugs to Jordan"
<imbrandon> hehe
<LaserJock_> ouch
<LaserJock_> that would be entirely unproductive and a disaster
<crimsun> but _entirely_ productive and non-disastrous for me
<crimsun> I must admit that tracking development gnome snapshots really destroys any sense of muscle memory I might have had
<crimsun> System> Control Center? whateva!
<LaserJock_> lol
* ajmitch returns :)
<imbrandon> woot , ssl working 
<ajmitch> good
* ajmitch had fun with apache yesterday
<imbrandon> ubuntuwire.com is now ssl enabled for signup ( and actualy redirected there if you dont goto https by default )
<imbrandon> yea , apache is quite fun <rolls eyes>
<LaserJock_> I'm going to KILL IT!
<ajmitch> oh it is
<ajmitch> calm down LaserJock_ 
<imbrandon> heh
<imbrandon> kill what LaserJock_ 
<zul>  LaserJock_: rant...you will feel better
<LaserJock_> imbrandon: I'm trying to set up a .htaccess for mod_python
<imbrandon> ahh
<moxfyre> hi admins... I've just created an updated GTKWave package (the old one hadn't been maintained in a couple years)
<tonyyarusso> imbrandon: bah, apache's not that hard
<moxfyre> can someone ... uh ... "re-sync the REVU uploaders keyring"
<tonyyarusso> as long as you don't mind reading four thousand docs ;)
<moxfyre> i've followed all the directions in MOTU/Packages/REVU, would like to get this into universe :-)
<moxfyre> any admins here?
<imbrandon> moxfyre, yea give me justa sec
<moxfyre> excellent!
<imbrandon> moxfyre, done
<moxfyre> thanks!
<imbrandon> np
<moxfyre> the package i uploaded was already in universe, but in a very old version... should i send some kind of explanation of what I did to REVU?  there's just a couple lines on it in the changelog
<imbrandon> hum well honestly you would have been better off making a debdiff and attaching it to a bug on LP and subscribing u-u-s
<imbrandon> REVU is more for NEW packages
<bddebian> w00t, kiss my ass .NET! :-)
<moxfyre> Gotcha.  There was no maintainer for the gtkwave package on Launchpad, since it was just a package copied from debian unstable... so I thought I should put it on REVU
<Q-FUNK> moxfyre: either that or submitted a patch to the maintainer on the Debian side.
<Q-FUNK> maybe offer him to co-maintain as well
<moxfyre> okay, so if I get the Debian maintainer to update it, then that package will eventually find its way into Feisty?
<moxfyre> well... my REVU upload is still getting rejected anyway :-)
<LaserJock> zul: hehe, just can't help pit eh?
<ajmitch> yay, short TB meeting
<zul> heh...people are pissing me off
<LaserJock> it happened already?
<ajmitch> LaserJock: TB, or pissing zul off?
<LaserJock> TB
<bddebian> heh
<LaserJock> zul getting pissed off this early isn't a suprise
<LaserJock> ;-)
<ajmitch> :)
<zul> thats not nice..
<LaserJock> uh oh, I've pissed him off now
<ajmitch> LaserJock: yes, with the motu council supposedly handling new applications, it was a little shorter than most TB meetings
<LaserJock> ajmitch: anything of importance?
<ajmitch> new TB nominations announced soon?
<ajmitch> that was the only thing discussed, really
<LaserJock> anybody noticed the +text pages on LP: https://launchpad.net/bugs/43150/+text
<Ubugtu> Malone bug 43150 in wxmaxima "[SRU]  maxima frontends fail to connect" [Medium,Fix released]  
<ajmitch> I thought bughelper was using those?
<LaserJock> oh, well that makes sense
<LaserJock> I didn't know it existed
<ajmitch> I forgot about them, but they've been there for awhile I think
<LaserJock> I also figured out how to get +bugs-text to do what I want (i.e. show only open bugs)
<LaserJock> well, *I* didn't figure it out, kiko told me
<ajmitch> useful!
<ajmitch> heh
<LaserJock> I was complaining about +bugs-text to him today
<LaserJock> I also got a estimate of the 1.0 release
<LaserJock> *an
<LaserJock> which is when the +filebug tag preloading will roll out
<ajmitch> yes, I saw that
<LaserJock> I think if we decide on a tag to use we can set up a doc for a junior job to move Candidates to LP
<bddebian> Who the heck is Alexandar Sack?
<zul> he is the new mozilla maintainer
<bddebian> Ahh
<ogra> or asac
<tonyyarusso> bddebian: ya, asac in #ubuntu-mozillateam
<animimotus> lionel: [mar fv 27 2007]  [00:28:08]  <lionel>   animimotus: I can not find your bug report -----> https://launchpad.net/edgy-backports/+bug/82543    ;)
<Ubugtu> Malone bug 82543 in edgy-backports "Please a backport Conky to Edgy ?" [Undecided,Confirmed]  
<animimotus> thx Adri2000 ;)
<geser> caravena: please don't assign bugs to motu-uvf which are only about new Debian revisions but not about new upstream releases
<caravena> geser: ok.
<LaserJock> umm, so what would be the UVF exception policy for a Multiverse package?
<ajmitch> LaserJock: same as for universe, the only difference is licensing
<LaserJock> but if it's a binary there's not much code to review
<tonyyarusso> ajmitch: exemption applications are done as bugs subscribing -utf, right?
<cbx333> LaserJock, fixed the mod_python yet?
<LaserJock> cbx333: well, I just used what you gave me and am just doing 1 main .py per dir
<cbx333> hehe
<ajmitch> tonyyarusso: assigning to
<tonyyarusso> ajmitch: ah, ok
<ajmitch> geser: was it to motu-uvf, or to motu?
* ajmitch spots a bug here assigned to MOTU, which is not good
<LaserJock> why?
<ajmitch> LaserJock: it doesn't really help anything by assigning a bug to motu for a uvf exception request
<LaserJock> no, not if it's a uvfe
<geser> ajmitch: bug #88481 is assigned to motu-uvf, bug #88492 was also before my upload
<Ubugtu> Malone bug 88481 in unrar-nonfree "Please sync unrar-nonfree 3.7.3-1 from Debian unstable" [Undecided,Confirmed]  https://launchpad.net/bugs/88481
<Ubugtu> Malone bug 88492 in tiemu "Please merge tiemu 2.00-3 from Debian unstable" [Wishlist,Fix committed]  https://launchpad.net/bugs/88492
<LaserJock> I thought you just ment in general
<ajmitch> in general it's not really helping anyway :)
<jdong> can I prod bug 87687 towards motu-uvf?
<Ubugtu> Malone bug 87687 in xserver-xgl "New git snapshot required for xorg 7.2/feisty" [Wishlist,Unconfirmed]  https://launchpad.net/bugs/87687
<ajmitch> jdong: sure, by following process & assigning it :)
<jdong> ajmitch: WTF half of you guys want subscribing and the rest want assigning :)
<ajmitch> geser: ah, bug 88481, that +1 is just confusing :)
<Ubugtu> Malone bug 88481 in unrar-nonfree "Please sync unrar-nonfree 3.7.3-1 from Debian unstable" [Undecided,Confirmed]  https://launchpad.net/bugs/88481
<ajmitch> jdong: yes, and it's all documented
<jdong> ajmitch: well I apologize profusely then.
<ajmitch> that's ok, you can pay later
<ajmitch> jdong: having an additional version on top of one that's not uploaded just confuses things
<jdong> ajmitch: I'm sorry, didn't know how else to do it
<jdong> ajmitch: in my defense the original version worked at the time it was filed
<jdong> ajmitch: should I open up a 2nd report or will you cope with it :D
* ajmitch wonders why 88469 is assigned to motu-uvf
<ajmitch> jdong: why would you need a second report?
<jdong> ajmitch: reject the current one and open one with just the latest patch?
<jdong> or would that not be necessary?
<ajmitch> you're just making more work for everyone :)
<jdong> ajmitch: I'm sorry
<sacater> hey does anyone know where gpocentek is
<mr_pouit> sacater: he's sleeping :D
<sacater> mr_pouit: how long has he been asleep, i need some mentoring
<sacater> ive rebuilt a source package as he asked :P, and now hes asleep
<sacater> :(
<sacater> any idea when hell be online tomoz
<Adri2000> his tz is CET
<keescook> hmpf. anyone run into issues with the xorg 7.2 update?
* ajmitch hasn't run it yet
<ajmitch> I see holy holbach is going to be at it again
<keescook> it's weird, everything looks fine, but the logs say it can't find the "fixed" font...
<Adri2000> keescook: some fontpath is wrong in Xorg.conf
<Adri2000> fonts/X11 // X11/fonts
<keescook> Adri2000: I'll double check; the logs only complained about CID stuff being missing.
<dlenski> hi, earlier I asked an admin to re-sync the REVU keyring, so that I could upload a new package
<dlenski> but it doesn't seem to have gone through :-(
<dlenski> i've followed the complete instructions in wiki.ubuntu.com/MOTU/Packages/REVU
<dlenski> can someone sync it again?
<geser> ajmitch: ^^^
<phanatic> keescook: had the same problem, a dpkg-reconfigure xserver-xorg helped...
<keescook> phanatic: cool, thanks.  bdmurray pointed me at 88254 too.
<phanatic> bug 88254
<Ubugtu> Malone bug 88254 in xorg "xserver fails to start - missing FontPath in xorg.xonf" [High,Confirmed]  https://launchpad.net/bugs/88254
<keescook> ah-ha, success!  xorg happy again
<phanatic> great :)
<jdong> Xgl still isn't
* jdong looks at ajmitch again....
<ajmitch> dlenski: ok, doing it
<jdong> beg(): return "pretty"+beg()+"please"
<ajmitch> jdong: bug me further, and I'll ignore the bug :)
<dlenski> ajmitch: thanks!  not sure what the problem was earlier
<ajmitch> dlenski: you may have been in the keyring, but uploaded a binary package
<otherguy> ajmitch: have you looked at xserver-xgl in feisty yet? :)
* ajmitch blacklists that package
<dlenski> ajmitch: i did accidentally try and upload a binary package, that's right
<jdong> :)
<ajmitch> dlenski: ok, I'll clear it & tell you when you can upload again
<dlenski> ajmitch: thanks.  when i try to recover my password on revu.tauware.de, it gives me a GPG message which decrypts to the string "None"... seems like I confused a python program somewhere!
<ajmitch> because you don't have a successful upload
<ajmitch> dlenski: ok, what did you try & upload?
<shawarma> ajmitch: You confirmed my UVFe: https://launchpad.net/ubuntu/+source/rawstudio/+bug/88020 but did not subscribe ubuntu-archive... Is there a deeper meaning to that or did you just forget?
<Ubugtu> Malone bug 88020 in rawstudio "UVF: Please sync 0.5.1-1 from Debian" [Undecided,Confirmed]  
<dlenski> ajmitch: i tried to upload the gtkwave package, but then someone suggest i contact the Debian maintainer instead
<geser> shawarma: after an uvfe is confirmed it's up to you to continue
<dlenski> ajmitch: ... and then i tried to upload the cpuid package
<ajmitch> and did you get an email in reply?
<shawarma> geser: Oh, really? Last time they did it for me. I assumed it was the procedure.
<LaserJock> for goodness sakes
<LaserJock> I hate moving targets and Python on Mac
<ajmitch> dlenski: the cpuid package doesn't appear on tiber, so I suspect you may have uploaded to the wrong place
<dlenski> hmmm... i got "upload rejected" emails
<ajmitch> then you probably uploaded to ubuntu, not revu
<dlenski> d'oh!
<dlenski> apparently, i'm an idiot
<dlenski> i think that's what i did, i ought to learn to read the dput man page
<ajmitch> :)
<dlenski> ajmitch: sorry about that *whacks self on head*
<ajmitch> no problem
<ajmitch> ok, it appears on revu now
<dlenski> indeed!  thanks a lot
<dlenski> just one thing to clarify: lintian doesn't like the distro name feisty
<dlenski> should it be unstable?
<ajmitch> no, ignore that 
<ajmitch> that system doesn't have a recent lintian installed
<dlenski> ah, gocha
<sistpoty> hi folks
<LaserJock> hi sistpoty 
<sistpoty> hi LaserJock
<sistpoty> argl... missed TB meeting today :/
#ubuntu-motu 2007-02-28
<ajmitch> sistpoty: it's ok, the TB meeting was short & there was 1 MC rep :)
<sistpoty> ajmitch: yay... read the backlog. thanks for being there ;)
<sistpoty> ajmitch: I guess we should really start handling new member applications now. what do you think of temporarily using ubuntu-motu@l.u.c until motu-council-list is set up?
<ajmitch> sistpoty: fine by me, I've talked to a couple of people who were proposed for ubuntu-dev
<sistpoty> ajmitch: ah, cool, great :)
<ajmitch> there were only 3 or 4 people I recognised on that list anyway :)
<ajmitch> we can probably just send out a mail to them all explaining the new procedures, etc
<sistpoty> sounds sane
<ajmitch> inviting them to mail in their application if they have people to support them & they are ready
<LaserJock_> I could blog it too. Or maybe we don't want it *that* advertised
<ajmitch> not until the proper list is there
<sistpoty> yes... otherwise it might end up chaotic... or with every 3rd post to motu being please use ... for membership applications ;)
<zul> LaserJock_: liek no one reads your blog anyways
<LaserJock_> heh, true
<sistpoty> hehe
<LaserJock_> *somebody* has to read it
* sistpoty is looking forward to see the next golden pony awards *g*
<ajmitch> I read it!
<LaserJock_> oh yes, I need to start thinking about that
<ajmitch> oh, the golden ponies!
<sistpoty> I guess bddebian should get one for fixing universe... though I don't want to influence the jury in any way ;)
<LaserJock_> I had fun with that, I hope people didn't think it was too weird
<sistpoty> was great fun to read :)
<sistpoty> ok, I'm off to bed now (trying to find a sane wake/sleep rythm the recent days *g*)
<sistpoty> gn8 everyone
<LaserJock_> cya sistpoty 
* ajmitch goes & hunts for the historic golden ponies announcement
<LaserJock_> heh
<LaserJock_> I need somebody to make me a nice shiny golden pony
<ajmitch> ah, you promised the next round in april/may
<LaserJock_> my art sucks
<LaserJock_> yes, every release
* ajmitch looks forward to the next round
<LaserJock_> yeah, I'll have to scare up some good movie titles to geekify
<ajmitch> & some worthy candidates
<LaserJock_> there's always worthy candidates
<ajmitch> don't forget to mention holy holbach!
<LaserJock_> oh man, I might have some fun with Council Grayskull ;-)
<ajmitch> uh oh
* ajmitch quickly resigns
<zul> http://www.youtube.com/watch?v=fO1ChfM94yQ
<ajmitch> :P
<imbrandon> LaserJock_, should be the orco awards ;) http://store.ticklespop.com/heorbupin.html
<LaserJock_> oh, that is nice
<LaserJock_> zul: oh man, that brought back some memories
<LaserJock_> I'll defiantly have to link to that, so people get the context ;-)
<zul> LaserJock_: yeppers..
<LaserJock_> ajmitch: I'm up to 7 things compiled from source and still can't get scipy to load
<ajmitch> I'm impressed
<ajmitch> geser: what build-dep changes did you do for all those apt-using packages?
<bddebian> Heya gang
<tonyyarusso> hey
<tuxmaniac> .
<tonyyarusso> ,
<bddebian> ;
<ajmitch> very useful
<ajmitch> now get to work
<tonyyarusso> yeah yeah.  I'm waiting for my upstream to send me a new tarball (Friday)
<ajmitch> there are still plenty of bugs in universe to fix
<tonyyarusso> Any that someone who doesn't know how to write code can fix?
<ajmitch> yep
<ajmitch> there'll be plenty of packaging bugs
<ajmitch> dive in & take a look :)
* bddebian hides
<tonyyarusso> Point me to a list and I'll grep for ones within my capabilities.
<bddebian> Who gave ajmitch the whip anyhow? :)
<ajmitch> tonyyarusso: bugs.ubuntu.com
<ajmitch> grepping is somewhat out of the question there
<ajmitch> but you can use the tags, or the advanced search
<tonyyarusso> ajmitch: Is there any way to narrow down "Universe packaging bugs in feisty"?
<ajmitch> heh
<ajmitch> it's easy to narrow something down to universe
<ajmitch> far harder to know that something is packaging vs actual code bug
<ajmitch> bddebian: you want me to quit?
<tonyyarusso> all right
<ajmitch> there are plans afoot to try & identify packaging bugs & tag them as such
<bddebian> ajmitch: Nah, you pick it up, I'll quit :-)
<Adri2000> tonyyarusso: tags packaging and bitesize
<tonyyarusso> Adri2000: cool
<ajmitch> Adri2000: are they being used at all yet?
<bdmurray> speaking of bugs I'm working on a strings patch for qtparted and I am curious about what effect it will have on translations
<Adri2000> ajmitch: yes, there are some bugs tagged so, but not really a lot
* ajmitch is no i18n expert by any means
<ajmitch> Adri2000: right, a whole 3 bugs tagged as packaging so far
<ajmitch> the problem with tags, is finding people who are able & have the time to identify the bugs as such
<bdmurray> I touch a fair number of bugs so could tag them when looking at them.
<ajmitch> ok
<ajmitch> do you think the bugsquad could tag some as well when triaging?
<bdmurray> if I had some criteria
<ajmitch> that's the hard part :)
<bdmurray> After testing / trying it some I could add it to the process
<ajmitch> broken dependencies, missing files in packages, etc
<ajmitch> post/pre install script errors
<ajmitch> issues with /var/run
<ajmitch> the list would grow as you see more bugs
<bdmurray> okay, I'll keep that in mind then.  Is adding tags in beta.lp any easier?
<ajmitch> I don't think it's changed much in the new UI
* ajmitch can no longer see the old ui to compare :)
<bdmurray> In the old one you have to edit the description to reach the tags
<keescook> ajmitch: if you go to launchpad.net/ (root dir) you can click "disable redirection"
<bdmurray> which is extra step from regular work flow
<ajmitch> interesting
* ajmitch checks tagging
<ajmitch> looks like it's the same
<ajmitch> might be worth filing a bug against malone to try & smooth out the workflow
* ajmitch can think of much easier ways to add tags than this provides
<bddebian> Gads I hate what look to be video (i.e. ATI) related bugs
<jdong> UVFe fglrx!
* jdong leads the ULF campaign
<jdong> (Uvfe Liberation Front?)
<jdong> ULO?
<ajmitch> Liberation Front of UVFe, not the UVFe Liberation Front!
<ajmitch> heretics
<jdong> pffft :)
<PriceChild> "me want xgl"
<mewantXGL> haha, see it's catching on....
<zul> meh..
<lotusleaf> hey, what about xgl? :)
<bddebian> What about lgx?
<thelsdj> we've had glx for years, why can't people just settle? :)
<bddebian> Man bug triaging sucks these days
<thelsdj> i only tried triage for the first time the other day, there was a time when it didn't suck?
<bddebian> I mean we now have bugs old enough to not know what distro they were posted on, etc ,etc
<thelsdj> yea actually the first few bugs i worked on were from over 6 months ago
<thelsdj> first one the guy had actually changed companies and said he thought the company no longer used that program :)
<darkmatter> me want XGL! me want XGL! me want XGL! me want XGL! me want XGL! me want XGL! me want XGL! me want XGL! me want XGL! me want XGL! 
<darkmatter> me want XGL! me want XGL! me want XGL! me want XGL! me want XGL! me want XGL! me want XGL! me want XGL! me want XGL! 
<darkmatter> me want XGL! me want XGL! me want XGL! me want XGL! me want XGL! me want XGL! me want XGL! me want XGL! me want XGL! 
<bddebian> Heya LaserJock
<ajmitch> welcome back, LaserJock 
<LaserJock> *$%@&!)
<ajmitch> no luck yet?
<LaserJock> no, and the uni's DNS servers must have died
<ajmitch> ouch
<LaserJock> I just left and went home
<LaserJock> but I actually did get things to work
<ajmitch> good
<LaserJock> python 2.5, matplotlib, and gfortran as binaries. fftw, numpy, scipy from source
<LaserJock> I will never complain about Ubuntu/Debian python
* ajmitch will
<LaserJock> well, you're right, I probably will
<LaserJock> but it's nothing to the OS X insanity
<LaserJock> I think there was maybe only 1 package I downloaded today (I probably got like 20 total today) that had a build number or unique versioning
<LaserJock> they'd have like 3 or 4 different builds all with the same filename and no data associated
<LaserJock> so I had to try each one to figure out which one worked
<LaserJock> wow, the whole uni is down
<LaserJock> I can't even get to the website
<ajmitch> impressive
<bddebian> Is there a command line pdf reader?
<ajmitch> bddebian: pdftotext?
<bddebian> ajmitch: thx
<bddebian> Where the heck is the logfile of --logfile to pbuilder kept?
<zul> how about reading the man page
<bddebian> How about kissing my ass?
<zul> er...not tonight
<bddebian> Does this tell you where it puts it?
<bddebian>        --logfile [file to log] 
<bddebian>               Specifies  the logfile to create.  The messages generated during
<bddebian>               execution will be written to the file, instead of messages  com
<bddebian>               ing to the standard output.
<jdong> it tells you it puts it where you tell it to put it.
<jdong> --logfile /tmp/pbuilder.log puts it at /tmp/pbuilder.log
<jdong> --logfile /dev/stdout annoys the heck out of you
<jdong> --logfile /dev/dsp is more interesting for annoying coworkers.
<bddebian> So a path is required?  Because saying --logfile foo goes nowhere
<bddebian> I would expect it in the cwd
<jdong> I think by the time it transfers control cwd does not make much sense
<jdong> try with an absolute path
<jdong> that's definitely worked for me
<Adri2000> or just --pkgname-logfile
<Adri2000> it will put the .build in /var/cache/pbuilder/result/
<bddebian> jdong: Thx
* Hobbsee waves
<jdong> hi Hobbsee 
<jdong> how's Xgl? broken you may say?
<jdong> how very true
<jdong> it's a great day.
<bddebian> Heya Hobbsee
<Hobbsee> heya jdong, bddebian 
<jdong> :)
<ajmitch> hi Hobbsee 
<Hobbsee> hi ajmitch 
<gpocentek> morning
<ajmitch> hi gpocentek 
<ajmitch> how are you?
<gpocentek> hello ajmitch 
<gpocentek> I'm fine, you?
<ajmitch> good :)
<bddebian> Heya gpocentek
<gpocentek> hello bddebian 
<ajmitch> just doing some setup on a new server
<gpocentek> ajmitch: I'm a bit confused, you can ACK main UVF exceptions?
<gpocentek> I tought that only Colin and Matt could do this...
<bddebian> Gah..
<LaserJock_> for goodness sakes
<LaserJock_> I hate stupid weather
<bddebian> stupid weather?
<LaserJock_> we are getting lots of snow here (at least for this area)
<RAOF> It's just about to really, really rain here.
<RAOF> Nice thunderstorm :)
<bddebian> LaserJock_: Ah
<LaserJock_> my DSL is the most unstable I've ever seen it
<LaserJock_> and the uni internet is completly down
<LaserJock_> bddebian: how are you doing this evening?
<bddebian> OK I guess, thanks.  You?
<LaserJock_> other than this stupid internet connection I"m doing fine
<LaserJock_> you know you are addicted when your internet at work goes down and you just have to pack up and leave
<bddebian> LaserJock_: Yep :)
<ajmitch> gpocentek: no, did I accidentally do that?
<Toadstool> hi everybody
<bddebian> Heya Toadstool
<Toadstool> hey bddebian 
<LaserJock_> ajmitch: hehe, now you're on ubuntu-uvf? ;-)
<ajmitch> gpocentek: they were assigned to motu-uvf by some helpful person, I didn't realise they were in main
<ajmitch> sigh, caravena is gone so I can't tell him off *again*
<ajmitch> LaserJock_: no, I was looking at motu-uvf bugs
<LaserJock_> I know, I'm just teasing
* ajmitch really wishes we didn't have to tell overly helpful people not to do things repeatedly
<ajmitch> again & again
* bddebian hides
<ajmitch> some people can be more of a hindrance than a help
* jdong whistles
<ajmitch> some people can be just annoying & make you want to avoid irc altogether :)
* jdong whistles again?
<LaserJock> ajmitch: it'd be awesome if we could associate teams with a component
<LaserJock> so motu-uvf could only be assigned/subscribed to bugs on Universe packages
<ajmitch> yeah
<bddebian> jdong: nah, ajmitch is talking about me :-)
<jdong> bddebian: I've been kinda pushy and obnoxious today too
<jdong> I'm sorry, ajmitch 
<ajmitch> bddebian: no, it's jdong :)
<Q-FUNK> is Feisty slated to become an LTS release?
<ajmitch> no
<Q-FUNK> when is the next LTS release coming?
<Q-FUNK> any info on that?
<Q-FUNK> someone is asking me on another network :)
<ajmitch> when it's decided that upstream projects are in a suitable state for it to be useful & stable
<ajmitch> eg not when a whole lot of new stuff has just been introduced
<LaserJock> in other words, there isn't a set schedule for LTS releases
<LaserJock> it's just when Mark reads the tea leaves and says "Ah hah, this is an LTS!"
<_ion> The next LTS release will probably come before feisty+10.
* ajmitch doubts feisty+1 will be LTS
<LaserJock> I really don't think they'll want 2 LTSs at the same time
<Toadstool> "when it's ready" ;)
<LaserJock> anybody know of a really easy to setup and use wiki? like for my own use
<_ion> Tomboy :-)
<LaserJock> well,  I want to put it on my server
<Toadstool> eww, MONO... (no offence ajmitch :)
<LaserJock> it's not personal as in local, just personal as in I'm the only one using it
<LaserJock> Toadstool: not a mono fan huh?
<Toadstool> LaserJock: I'd say moinmoin
<LaserJock> that's still quite a bit of effort for 1 person's use
<LaserJock> although I do like moin
<Toadstool> true
<ajmitch> Toadstool: get over it
<Toadstool> :)
<LaserJock> I was thinking of ikiwiki
<LaserJock> that wiki compiler that's on planet Debian (Joey Hess?)
<Toadstool> never used it but it looks really good
<Toadstool> yep joeyh
<LaserJock> also phpwiki but it looks so messy
<nixternal> LaserJock: was that pkg a tad bit better this time around?
<LaserJock> building it now
<Toadstool> LaserJock: the thing I dislike in phpwiki is the php part :)
<LaserJock> well, I've been getting into it lately so I don't know that I mind so much
<Toadstool> I had so many bad experiences with PHP in the past 2 years that I totally banned it from my own server
<LaserJock> but I also figured out how to get mod_python working
<LaserJock> bad in what way?
<Toadstool> bad in that I worked on crappy PHP code and I got sick of it
<LaserJock> ah
<LaserJock> I thought bad as in security stuff
<Toadstool> maybe it was just because it was really badly coded but still...
<_ion> http://tnx.nl/php.jpg
<Toadstool> :)
<SEJeff> _ion: http://carcino.gen.nz/images/image.phpi/2b100e19/fuck_mod_perl.jpg
<g0su> Jajajajaj
<Hobbsee> g0su: ?
<g0su> Hobbsee, see one line up
<Hobbsee> oh...gotcha
* Hobbsee wonders who wrote this howto on bzr
<Hobbsee> dholbach, and another guy, it seems
<Toadstool> which one?
<Toadstool> (hi Hobbsee btw)
<Hobbsee> Toadstool: https://wiki.ubuntu.com/Bzr
<Toadstool> that's a nice FAQ
* ajmitch returns
<Toadstool> everybody, hide! :)
<Hobbsee> argh!!!
* Hobbsee runs
<ajmitch> great
* ajmitch leaves again
<Toadstool> oh come on
<bddebian> Gnight folks
* Hobbsee pokes Toadstool 
* Toadstool runs away
<Hobbsee> Toadstool: ponies got a mention in jono's community talk at LCA.
<ajmitch> yay
* Hobbsee is glad to see it's gotten so far
<Toadstool> Hobbsee: http://www.tinfc.org/pony.jpg <-- like these ponies? :)
<Hobbsee> yep :P
<dholbach> good morning
<ajmitch> hey, holy holbach!
<dholbach> hey ajmitch :)
<ajmitch> just a one off, eh? ;)
<dholbach> I'll talk to him on friday *GRRRRR* :)
<ajmitch> haha
<ajmitch> dholbach: luckily I happened to be on irc when the TB meeting was on :)
<ajmitch> so we had 1 MC rep 
<dholbach> I prodded the sysadmin team again, just now.
<ajmitch> ok
<ajmitch> sadly LP is down for a couple of hours right now
<dholbach> did somebody mail caravena and tell him not to meddle with the motu-uvf process?
<ajmitch> he was in -motu earlier
<dholbach> did somebody tell him?
<ajmitch> confused me, I ended up ACKing a couple of main UVF requests :)
<ajmitch> yes
<dholbach> ok good
<ajmitch> we'll see if he got the message
<elkbuntu> dholbach, you should ask for 'huggy holbach' instead :
<dholbach> elkbuntu: hahaha, good idea :)
<giftnudel> Is there a documentation or policy on how to pack python extensions (with .so files) in ubuntu? 
<dholbach> http://www.debian.org/doc/packaging-manuals/python-policy/
<giftnudel> ah, thanks a lot!
<giftnudel> when you are syncing from debian, you are syncing from unstable correct?
<LaserJock> giftnudel: usually yes
<LaserJock> every once in a while we grab from experimental
<giftnudel> ok
<giftnudel> I need a package in ubuntu but it would also be nice in debian, so I hope to have it in in the next release (feisty+1)
<giftnudel> but want to get it in debian first ;)
<giftnudel> what is the preferred tool to use? python-support or python-central?
<LaserJock> python-central I think
<giftnudel> yes, thanks, I now have a package which is exactly what I need, so I can look things up now
<LaserJock> man I love Python!
<RAOF> :)
<ajmitch> don't we all?
<RAOF> Python-cairo: for when you want to draw a postscript image for latex, but don't want to deal with a crazy stack-based language :)
<LaserJock> I mean, you guys know how much of a programmer I'm not
<LaserJock> but tonight I wrote a script that plots my data in a nice GUI window
<LaserJock> I click on two point of data
<ajmitch> we know you're a programmer :)
<LaserJock> and it averages the data between the two points and spits out new data normalized to that averaged value
<LaserJock> and wc -l tells me it took 63 lines
<LaserJock> probably only 40 of real code
<RAOF> Oh, yeah.  Python rocks :)
<LaserJock> that's with grabing mouse click events
<LaserJock> sweetness
<LaserJock> I should ask my advisor to do *that* in Fortran
<LaserJock> well, with that I'm done for the night/morning
<LaserJock> not even 2am
<LaserJock> ;-)
<LaserJock> even managed to install mediawiki too
* Starting logfile irclogs/ubuntu-motu.log
<jamyskis> morning everybody
<Hobbsee> heya jamyskis 
<jamyskis> im having another crack at building debian packages - can i just hang about and throw in random questions should something go wrong?
<ajmitch> sure, hopefully there'll be someone awake to answer
<jamyskis> heeh
<jamyskis> heheh
<jamyskis> thanks
<jamyskis> grr using gaim to access irc channels is not recommended
<Hobbsee> no.  xchat is far better
<Hobbsee> if you're in gnome-land
<jamyskis> ill switch over later when im finished with this
<jamyskis> yep :-)
<jamyskis> ok xchat it is then hehe
<ajmitch> night all, see you later
<Hobbsee> night ajmitch 
* Hobbsee looks into dinner
<jamyskis> night ajmitch
* jamyskis is starting to feel hungry now.
* jamyskis has nothing in his cupboards however.
<KriS83> Good morning.
<jamyskis> morning KriS83
<jamyskis> uk=
<jamyskis> ?
<KriS83> I have a short, simple and probably freaquently asked question. MOTU Packages are supported how long?
<Hobbsee> KriS83: for released versions?
<KriS83> yepp
<KriS83> e.g. Dapper
<Hobbsee> KriS83: same as thes ones in main
<dholbach> They're not supported by canonical
<Hobbsee> iirc
<Hobbsee> ie, we can still push security fixes, though
<KriS83> So we would also have LTS of MOTU packages.
<dholbach> it's as long as community members step up for fixing the issue.
<KriS83> k
<Hobbsee> KriS83: ie, they'll probably be updated, as long as someone steps up and does it, but neither canonical or MOTU commits to everything being fine, with no security vulnerabilities.
<KriS83> I'm just setting up a server on dapper. And I require some packages from universe. e.g. scponly & tripwire
<KriS83> Just donjust wanted to make sure the packages don't just "disapear" in a couple of months
<Hobbsee> no, nothing disappears from the archive, unless it has a *very* good reason to
<Hobbsee> which, iirc, doesnt exist
<jamyskis> When you're creating the rules file for a debian package, can you simply copy part of the original source distribution's makefile? The makefile for my game was actually generated automatically by Anjuta and I'm not too clear on them
<Hobbsee> jamyskis: you shouldnt need to modify the makefile at all
<Hobbsee> debhelper picks it up
<Hobbsee> (or should)
<jamyskis> ah right...because I'm creating from scratch here :-p
<jamyskis> can i do the whole thing from scratch and still let debhelper take over creating the rules file?
<Hobbsee> seen teh packaging guide?
<jamyskis> i have it printed right in front of me here
<jamyskis> at least the bit about packaging from scratch
<jamyskis> http://doc.ubuntu.com/ubuntu/packagingguide/C/basic-scratch.html
* jamyskis needs a strong cup of tea and will be back shortly.
<Hobbsee> ah :)
<Hobbsee> you dont usually need more than the files that are listed in there
* jamyskis is now armed with a fresh hot cup of tea and is ready to rumble.
<jamyskis> so can i just copy the makefile that's there?
<jamyskis> and modify that a bit?
<jamyskis> Ian Jackson's example one I mean
<slomo> giskard: hi... will you update libnotify/notification-daemon?
<Hobbsee> jamyskis: ian jackson's?
<Hobbsee> jamyskis: oh, debian/rules is not the same as the makefile, btw
<jamyskis> just figured that out hehe
<jamyskis> im just looking through each section in the tutorial and looking to see if i can understand each bit of it
<jamyskis> at least to a degree
<jamyskis> ok because I've written my game in c++ it stands to reason that i have to change cc to g++ (not gcc) and src/$(package).c to src/$(package).cpp right?
<shawarma> It seems that all the rage these days is deleting your xorg.conf after installing Xorg 7.2... What about keyboard settings? Where do they come from? Should I just be creating a xorg.conf with just that info in it?
<ScottK> shawarma: When I upgraded to 7.2 I had to reselect the video driver/monitor type in KDE system settings because they had been reset to generics, but that was it.
<shawarma> ScottK: Which keyboard layout do you use?
<ScottK> It's one of the standard US ones.
<shawarma> Ah.. That would explain it, wouldn't it? :-) 
<shawarma> ..since that's the default.
* ScottK thinks PC104
<ScottK> I have Feisty on my laptop that's packed up at the moment.
<shawarma> GNOME fixed it for me, but what if someone wasn't running GNOME or any other DE that fixes it? Maybe xorg should fetch it from the console configuration somehow.
<ScottK> Or maybe just force dpkg-reconfigure after the install.
<shawarma> Perhaps.
<ScottK> If I'd had problems I couldn't fix in KDE, I'd have tried that before I tried deleting the xorg.conf
<Lutin> doko: ping => can I reject bug #88625 as python-elementtree is included in python2.5 ?
<Ubugtu> Malone bug 88625 in listen "missing dependency" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88625
<doko> Lutin: does it work with the elementtree from 2.5?
<shawarma> ScottK: Oh, I just renamed it, of course.
<Lutin> doko: do you what part of listen use it so that I can check ?
<ScottK> Of course.  was just quoting your original post on the topic.
<Adri2000> doko: if python-elementtree is included in python2.5, shouldn't it be just removed from the archive?
<doko> Lutin: no, you may have to look at the source
<doko> Adri2000: no, we still support python2.4
<Adri2000> ok
<jamyskis> ok pbuilder is causing me as many headaches as it ever did
<jamyskis> i tried passing the extra mirrors to it and added liballegro4.2 liballegro4.2-dev as extra packages but when i come to run sudo pbuilder build ../*.dsc the makefile claims the allegro headers aren't there
<jamyskis> but the game compiles fine otherwise without pbuilder
<jamyskis> can anyone help?
<jamyskis> anyone?
<Adri2000> bigon: the team you should subscribe for your your sync requests is ubuntu-universe-sponsors
<bigon> Adri2000: oups
<bigon> I've been a little bit to quick
<chx> Hi. Is there any way to make Package drupal disappear and be replaced with Package drupal-4.7 ? Drupal 4.5 (which is the version in the 'drupal' package) is not supported for almost a year now...
<shawarma> Could someone from the motu-uvf team check if I've added enough info to bug #88642 ?
<Ubugtu> Malone bug 88642 in network-manager-openvpn "UVF: 0.3.2svn2315 -> 0.3.2svn2342" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88642
<shawarma> I looks awfully short, but it seems to fulfill the requirements laid out on the wiki.
<jdong> that's what she said?
<shawarma> Yes, she was very clear. I *does* indeed fulfill the requirements. :-)
<jamyskis> hi everybody...i have a question about pbuilder
<jamyskis> i have a game ive written which relies on the liballegro4.2-dev package
<jamyskis> ive managed to get through dpkg-buildpackage no problems
<jamyskis> but i cant get my head around pbuilder
<jamyskis> ive tried creating it, editing /etc/apt/sources.list and installing liballegro4.2-dev so it can compile from within the pbuilder environment
<jamyskis> but everytime i exit the environment it just deletes the lot again
<jamyskis> i've tried pbuilder build adding the --othermirrors and --extrapackages switches
<jamyskis> no luck
<jamyskis> it cant find the allegro headers full stop
<shawarma> jamyskis: Your debian/control should list liballegro4.2-dev as a build-depends.
<jamyskis> can anyone help here?
<shawarma> jamyskis: That will make your pbuilder pull it in.
<jamyskis> i'll give it a try - thanks shawarma
<shawarma> jamyskis: np
<jamyskis> hmmm didnt work
<jamyskis> i included liballegro4.2-dev in the rules fine
<jamyskis> *file
<jamyskis> but it didn't pull it in
<jamyskis> this is where i came unstuck both times before and after a week of trying i just gave up both times
<Adri2000> jamyskis: not in debian/rules
<Adri2000> jamyskis: add it to the Build-Depends in debian/control
<jamyskis> Adri2000: sorry my bad - i did put it in debian/control
<jamyskis> don't know why i wrote rules
<jamyskis> in any case it didn't pull it in
<Adri2000> jamyskis: pbuilder didn't download it and install it?
<jamyskis> nope
<jamyskis> Adri2000: im just completely wiping the source distribution and temp files and trying again from scratch with the debian config files
<jamyskis> Adri2000: nope - is definitely not downloading and installing it
<Adri2000> jamyskis: did you rebuild the source package?
<jamyskis> Adri2000: yep - i wiped the .dsc files and rebuilt the source package with the new debian/control and it wouldn't pull it in
<jamyskis> Adri2000: hold on, ill post a copy of my debian/control on my site so you can read it
<jamyskis> Adri2000: i dont know if im doing something wrong here
<jamyskis> http://www.jamyskis.net/control.txt
<Adri2000> jamyskis: Build-Depends != Depends
<Adri2000> Build-Depends is for the source package, in order to build it. Depends are for binary packages, they are the dependencies needed to use the program.
<jamyskis> Adri2000: so what should i put in there?
<jamyskis> So it would be Depends: ${shlibs:Depends}
<Adri2000> first, a binary package doesn't depend on a -dev package
<jamyskis> and Build-Depends: liballegro4.2 ?
<jamyskis> sorry wrong way around
<Adri2000> binary package: Depends: ${shlibs:Depends}
<Adri2000> source package: Build-Depends: liballegro4.2-dev
<jamyskis> would i include liballegro4.2 in the Depends section as well?
<jamyskis> not liballegro4.2-dev
<Adri2000> no, it's ${shlibs:Depends}'s job
<jamyskis> ok
<jamyskis> ill give that a try
<jamyskis> thanks
<Adri2000> but you are at least missing at B-D on debhelper
<Adri2000> debhelper (>= 5)
<jamyskis> what do you mean?
<jamyskis> ive not used debhelper much
<jamyskis> i've tried it from scratch
<Adri2000> jamyskis: you can't build a package without debhelper
<Adri2000> jamyskis: debhelper is not dh_make
<jamyskis> Adri2000: so the guide at http://doc.ubuntu.com/ubuntu/packagingguide/C/basic-scratch.html is a bit misleading?
<jamyskis> Adri2000: i always thought packaging with debhelper was an alternative way of doing it?
<jamyskis> Adri2000: and the new debian/control still didn't pull it in
<Adri2000> jamyskis: you can copy the build log somewhere please?
<jamyskis> Adri2000: sure - hold on
<jamyskis> Adri2000: ill upload it to my site although to save time there's one line that's caught my eye
<jamyskis> Adri2000: "dpkg-source: warning: unknown information field `Build-Depends' in input data in package's section of control info file"
<Adri2000> jamyskis: the B-D line should be just after the Standards-Version line
<ScottK> !pasetbin might be useful here...
<Adri2000> jamyskis: and your Standards-Version can be 3.7.2
<ScottK> !pastebin that is
<Adri2000> !pastebin | jamyskis 
<ubotu> jamyskis: 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 (be sure to give the URL of your paste - see also the #ubuntu channel topic)
<jamyskis> Adri2000: ill copy the build log into the paste bin and try again with the new control file
<jamyskis> http://paste.ubuntu-nl.org/7930/
<jamyskis> yeeeee-haa looks like its pulled it in this time :-D
<jamyskis> im saving printing and framing this transcript
<jamyskis> lol
<jamyskis> its failed again but i think i know why
<jamyskis> typing error on my part
<jamyskis> i think im good so far now...just a few minor problems to iron out
<jamyskis> Adri2000 and ScottK: thank you very much - you're the best
<jamyskis> pass my thanks on to Hobbsee too
<bddebian> Heya gang
<ScottK> Heya bddebian
<bddebian> Hi ScottK
<ScottK> So does it say on the wiki somewhere that just after Universe Feature Freeze is the time to upload your packages?  Seems to me like the rate jumped since the freeze...
<jamyskis_> me again - there is one more problem with pbuilder
<jamyskis_> http://paste.ubuntu-nl.org/7936/
<jamyskis_> anyone?
<ScottK> Sorry, I haven't tried pbuilder yet.  All the stuff I've done has been simple enough to do with debuild.
<jamyskis_> ok i'll give it a crack with debuild in a sec
<bddebian> jamyskis_: Did you use the default configuration?  Do you have /var/cache/pbuilder/result/ dir?
<jamyskis_> bddebian: the directory exists and i've not changed the .pbuilderrc configuration
<ScottK> jamyskis_: You do need to be careful if you use debuild that you have a clean build enviroment.  I've gotten burned on that more than once.  I should really use pbuilder.
<jamyskis_> ScottK: could it be that the same applies for pbuilder? now that i know my debian files are ok i might try wiping the pbuilder environment completely, wiping my source package and starting anew
<jamyskis_> ill get back to you on how this goes
<bddebian> jamyskis_: This is a little interesting also:  dpkg-deb: building package `naughts-and-crosses' in `debian/tmp.deb'.
<bddebian> tar: -: file name read contains nul character
<geser> ajmitch: for those apt-using packages I've changed the versioned build-depends on libapt-pkg-dev to depend on at least 0.6.46.4ubuntu8 (the last ABI change)
<jamyskis_> bddebian: why would it be writing to tmp.deb? i see in the log but that is weird
<bddebian> jamyskis_: Do you pass anything to dh_installdeb or dh_builddeb?
<jamyskis_> bddebian: not as far as im aware
<bddebian> jamyskis_: In debian/rules, you don't have dh_installdeb or dh_builddeb with -pfoo or anything?
<jamyskis_> bddebian: no but i have dpkg --build debian/tmp in there
<jamyskis_> bddebian: i think i've just spotted my mistake
<jamyskis_> bddebian: dpkg --build needs a destination directory too which i haven't declared
<jamyskis_> bddebian: it should be dpkg --build debian/tmp .. right?
<jamyskis_> bddebian: it was - it fixed it
<jamyskis_> i just need to see if the debian package works ok now
<jamyskis_> ok i screwed up the postinst file but otherwise it works fine :)
<jamyskis_> thanks very much for your help guys
<sacater> is gpocentek still asleep
* gpocentek is not asleep ;)
<imbrandon> moins all
<bddebian> Heya imbrandon
<imbrandon> ;)
<giskard> slomo, i have to fix t-sharp and upload libtp
<giskard> and the new gabble if dholbach didn't upload it.
<giskard> i can do notify+notification-d
<giskard> but not now
<giskard> maybe tonight
<dholbach> giskard: no, didn't do that yet
<dholbach> and none of the other telepathy uploads
<dholbach> i'm quite busy atm :-/
<dholbach> hey siretart
<giskard> dholbach, oki! thank you
* dholbach hugs giskard
* giskard hugs daniel back
<tsmithe> how long does a package take to get through NEW?
<bddebian> Depends
<dholbach> Accessibility Team meeting in 3 minutes in #ubuntu-meeting.
<bddebian> They are processed manually so there is no set time
<tsmithe> bddebian, ok. /me is impatient and worrying about wired and enblend
<bddebian> tsmithe: Understood, I have a couple in NEW too
<tsmithe> :)
<bddebian> Heya LaserJock
<LaserJock> hi bddebian 
<sacater> hi all i got an encrypted message about my GPG key, its encrypted
<sacater> how do i decrypt it with my key
<sacater> erm hello anyone
<sacater> me need help
<Adri2000> sacater: are you trying to decrypt your revu password?
<sacater> erm
<sacater> no
<sacater> a message sent from noreply.launchpad.net
<Adri2000> gpg --decrypt, see man gpg
<bipolar> lifeless: ping
<imbrandon> wtf
<imbrandon> The following NEW packages will be installed: compiz compiz-core compiz-gnome compiz-gtk compiz-plugins desktop-effects libdecoration0 libgdiplus
<imbrandon> ummm i thought we wernt doing copiz/beryl
<imbrandon> compiz*
* imbrandon grumbles
<Adri2000> not enabled by default but installed by default
<zul> imbrandon: you like it..
<imbrandon> that sucks 
<imbrandon> i hope to hell kubuntu dosent do it, or i might me moving to pure debian and ubuntu server only
<tsmithe> why?
<tsmithe> it's not *that* bad!
<finalbeta> it's coming sooner or later. No going around it.
<imbrandon> when its ready yes, have you used it lately ?
<finalbeta> No, it's not ready for me ;)
<pochu> imbrandon: installing it by default will give us more feedback
<finalbeta> but then again, rhythmbox totem and a bunch of other defaults are not ready also.
<imbrandon> pochu, sure if your looking for a beta release, i doubt it will be removed before final, you dont put something in for feedback in a release
<tsmithe> imbrandon, not ready here either
<pochu> imbrandon: with edgy, we shiped firefox rc :)
<imbrandon> and that was just as ignorant imho
<imbrandon> ;)
<imbrandon> and no "we" dident, we dont ship FF at all
<tsmithe> "we"?
<pochu> imbrandon: kubuntu?
<imbrandon> ;)
<tsmithe> ah
<pochu> hehe
* tsmithe larts imbrandon 
<tsmithe> gtk is like way better, innit
<finalbeta> yeah, it's just not being used to it's full potential ;)
<leonel> Hello  MOTUs    I need  python2.4-psycopg2 on dapper   I already have done the  package      how can I make it to dapper oficial ?
<tsmithe> nope
<LaserJock> leonel: what do you mean?
<leonel> LaserJock:   That if  the python2.4-psycopg2  can be included  in dapper   
<LaserJock> leonel: it isn't in it already?
* tsmithe assumed it wasn't if he was asking
<LaserJock> hehe, you never know
<LaserJock> but no, we got it in Edgy
<LaserJock> leonel: we don't add new packages to stable releases
<leonel> LaserJock: no  it isn't  that's why I build the package  
<leonel> LaserJock: how can it make to  backports ?
<LaserJock> I'm not sure you can
<LaserJock> talk to jdong or Mez 
<Mez> hmm?
<imbrandon> you can
<imbrandon> just file a backport request and /possibly/ it will get backported if it dosent require much
<imbrandon> heya Mez 
<Mez> hi imbrandon 
<leonel> imbrandon:  and  the security updates  will be done  too ?
<imbrandon> no
<Mez> !backports | leonel 
<ubotu> leonel: If new updated Ubuntu packages are built for an application, then they go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports
<leonel> This is what I like   about  Ubuntu   
<leonel> the people
<leonel> Thanks 
<leonel> I'll request  to be backported   
<leonel> Can I help with the backport ?
<imbrandon> there isnt much to do we just test it and check the deps then approve/disapprove, then everthing is done by the ftpmasters
<leonel> imbrandon: ok thanks
<imbrandon> brb
<ajmitch> morning all
<imbrandon> heya ajmitch 
<bddebian> Heya ajmitch
<ajmitch> what's up?
<imbrandon> nadda
<imbrandon> just grumbling
<imbrandon> ;)
<ajmitch> hehe
<tsmithe> imbrandon doesn't like compiz being default
<ajmitch> he can live with it
<ajmitch> nothing's forcing him to use it
<imbrandon> ;)
<doko> dholbach: do we need a UVF exception for the wxwidgets2.8 package from bddebian ? it's a new / non-conflicting package
<dholbach> doko: yes, https://wiki.ubuntu.com/FreezeExceptionProcess#head-3545adef94d4dc79d5392ddb1f51b9ac30ab0861
<lifeless> bipolar: ?
<bipolar> lifeless: are you the maintainer for the opensync packages?
<lifeless> one of, yes
<bipolar> lifeless: ah, I was wondering if updated packages are in the works for feisty?
<doko> bddebian: your task? ;-P
<sacater> hi im being MOTU mentoreed, i dont suppose anyone knows of a small package with an easy bug to fix :p
<lifeless> bipolar: oh, has a new release happened ? I can update them week after next probably
<LaserJock> sacater: you might want to check the bugs tacked packaging or bitesize
<bipolar> lifeless: yeah... two new releases. .21 is out now
<LaserJock> sacater: see https://wiki.ubuntu.com/MOTU/TODO
<lifeless> file bugs asking for updates, :)
<bipolar> lifeless: that was my next step, but in #opensync they know you :)
<sacater> Laserjock: k thanks
<ajmitch> lifeless: you'll have to get freeze exceptions 
<lifeless> bipolar: :)
<lifeless> ajmitch: right, and thus we'll need bugs :). I also need to see how big a dependency hell we're looking at, opensync is rather high up the stack.
<bddebian> doko: I think they kind of decided that they didn't want it yet, did they?
<bddebian> ajmitch: ^^  Didn't you and sistpoty think we should wait?
<ajmitch> no, I was just making sure we had a decent package, since wx is not terribly nice
<ajmitch> & that it wouldn't break anything
<sacater> how does the 'bugs assigned to me' thing work
<sacater> LaserJock: https://launchpad.net/ubuntu/+source/tea/+bug/81456 this bug looks fine, and I can make a .desktop file for it, but how do i access the main package to add it in
<Ubugtu> Malone bug 81456 in tea "No menu entry" [Undecided,Confirmed]  
<doko> bddebian: you did leave out the changelog entries from the existing 2.8 package
<LaserJock> sacater: apt-get source tea
<sacater> LaserJock: ty
<LaserJock> sacater: read the Ubuntu Packaging Guide
<bddebian> doko: Existing 2.8 package?
<LaserJock> !packaging > sacater 
<bddebian> There is also a problem with control.in and python-V.xml that I would need to fix
<nixternal> boo
<bddebian> Heya nixternal
<nixternal> hiya
<nixternal> LaserJock: I have class tonight, any ideas what we should do with the edubuntu-docs package?
<nixternal> shoot, I need to get in the shower
<LaserJock> nixternal: you get it fixed up?
<LaserJock> ajmitch: that reminds me. what would be the UVF policy for native packages?
<nixternal> oh wait, ya I removed the makefile. the only issue left was ../../../ubuntu for the xml headers
<doko> bddebian: yes, on the website
<nixternal> ubuntu-docs are installed under gnome/help/ubuntu-docs and not gnome/help/ubuntu
<nixternal> that was the only fix left iirc
<bddebian> Crap, I don't think I even used the package on that site, I grabbed the tarball
<jdong> can UVFe bug 87687 please be evaluated?
<Ubugtu> Malone bug 87687 in xserver-xgl "New git snapshot required for xorg 7.2/feisty" [Wishlist,Unconfirmed]  https://launchpad.net/bugs/87687
<jdong> and its priority should be higher than wishlist
<jdong> xserver-xgl is unusable on Feisty without it
<doko> bddebian: I think, just use the tarball, but add all patches as a diff
<bddebian> doko: iirc the only real "patch" that I could re-add was the python2.5 transition
<doko> bddebian: no, I mean the diff between the upstream tarball and the .orig.tar.gz found on that site
<sacater> whats the command to add a new entry to a changelog
<bddebian> sacater: dch -i
<jdong> dch
<bddebian> doko: Ah
<sacater> bddebian: ty
<sacater> when adding a desktop file to a package that dosnt have it, do i need to edit some sort of file that dictates where everything goes on the system
<Adri2000> jdong: that one is for ajmitch :D
<sacater> and add the desktop file
<jdong> Adri2000: I've directed that at him like 10 times within the past week already :D
<Adri2000> I know, and I know he seems to love it :p
<Adri2000> sacater: yes, first the .desktop file should be in the debian/ directory (debian/tea.desktop) and then you need to tell the package to install it in /usr/share/applications/
<sacater> Adri2000L thought so, but how do i tell it to install it there
<sacater> what file do i edit
<Adri2000> there are multiple ways to do that, so it depends on the package, let me look
<sacater> Adri2000: ok
<sacater> Adri2000: i di apt-cache source tea, and ive made a .desktop file in debian, now i Just to add in the command of where it puts it
<Adri2000> sacater: you can use debian/tea.install
<sacater> Adri2000: de jai vous, i opened that right as you said it :P
<sacater> Adri2000: thansk anyway :D
<Adri2000> now I let you try to find what to put in it ;)
<sacater> oh easy
<sacater> debian/tea.desktop /usr/share/applications
<sacater> Adri2000: 
<Adri2000> yep
<sacater> Adri2000: LD
<sacater> :D
<sacater> Adri2000: now i make my additon to the changelog?
<Adri2000> correct, dch -i (if you haven't done it before)
<sacater> Adri2000: already done actually, it reads,.....  tea (12.0-2) unstable; urgency=low
<sacater>   * tea.desktop file added
<sacater>  -- sacater <sacater@neo>  Wed, 28 Feb 2007 20:25:36 +0000
<sacater> is that correct and nice?
<Adri2000> wrong version, wrong distro
<sacater> Adri2000: how should it read?
<Adri2000> anyway, you didn't download the last version
<Adri2000> tea |   14.2.4-2 | http://archive.ubuntu.com feisty/universe Sources
<sacater> Adri2000: oh poo
<sacater> Adri2000: whats the correct URL
<Adri2000> add the feisty deb-src in your sources.list
<sacater> Adri2000: erm, last time i went to the feisty archives and downloaded the package manually
<sacater> Adri2000: know the URL
<sacater> Adri2000: ah never mind i got the latest version from here http://packages.ubuntu.com/feisty/source/tea
<siretart> huhu dh
<siretart> argl
<bddebian> huhu siretart
<siretart> huhu bddebian :)
<LaserJock> siretart!
<siretart> hi LaserJock 
<bddebian> Jesus, are there ANY wireless chipsets that aren't freakin broadcom anymore?
<imbrandon> heh
<imbrandon> a few, but they are more expensive
<sacater> Adri2000: Okay i have made the neccessary changes and tried to rebuild the package except i get the Now signing changes and any dsc files...
<sacater>  signfile tea_14.2.4-3.dsc sacater <sacater@neo>
<sacater> gpg: skipped "sacater <sacater@neo>": secret key not available
<sacater> gpg: [stdin] : clearsign failed: secret key not available
<sacater> debsign: gpg error occurred!  Aborting....
<sacater> debuild: fatal error at line 1151:
<sacater> running debsign failed
<sacater> sacater@neo:~/tea/tea-14.2.4$ 
<sacater> 
<Adri2000> sacater: you do have a gpg key I hope?
<sacater> why cant it find my gpg :S, because it works fine with everything like the code of conduct
<sacater> Adri2000: yes
<sacater> Adri2000: i signed the code of conduct with it
<Adri2000> sacater <sacater@neo>
<sacater> and?
<Adri2000> you should change that with your real name and your real email address
<tsmithe> that's a local email address, but shouldn't be the problem
<sacater> erm no thats not it, could it be it simply cant find my gpg key, because i know its there
<sacater> i reckon it used those by default
<Adri2000> <Adri2000> [...]  your real email address
<sacater> what you want my email>
<Adri2000> put your real email address in the changelog, the email address which is in your gpg key, and that will work
<sacater> Adr2000: i registered with code of conduct, and set my gpg key up fine, it worked and had my proper address there
<sacater> Adri2000: i reckon youre right :D
<sacater> Adri2000: okay lets see what happens this time....
<sacater> Now signing changes and any dsc files...
<sacater>  signfile tea_14.2.4-3.dsc sacater <sacater@btopenworld.com>
<sacater> gpg: skipped "sacater <sacater@btopenworld.com>": secret key not available
<sacater> gpg: [stdin] : clearsign failed: secret key not available
<sacater> debsign: gpg error occurred!  Aborting....
<sacater> debuild: fatal error at line 1151:
<sacater> running debsign failed
<sacater> sacater@neo:~/tea/tea-14.2.4$ 
<sacater> FAIL!
<jdong> sacater: haven't I complained about that before to you?
<jdong> or someone else?
<Adri2000> are you sure it's the same address as the one in your gpg key? maybe the name should be the same too, I'm not sure
<jdong> as long as gpg-agent could not be contacted
<sacater> jdong: not me no :P im new
<jdong> gpg will return a FAILURE code
<jdong> it's a gnupg bug
<jdong> I complained about it about 8 months ago
<jdong> and apparently it's been fixed upstream now.
<sacater> Adri2000: its the name thats wrong as well
<sacater> jdong: meh,
<jdong> and check your default key too
<jdong> and your e-mail, etc
<tsmithe> or run with '-k<your-key-id>'
<Adri2000> oh, maybe it's just that $GPGKEY is missing
<sacater> tsmithe: now you tell me
<tsmithe> :S
<sacater> tsmithe: ill try ur method first, seems less complex :P
<tsmithe> \o/
<Adri2000> tsmithe: yes, that always works
<tsmithe> i know :)
<tsmithe> that's why i suggested it ;)
<doko> bddebian: the installation of the header files in python-wxgtk2.8 looks scary
<sacater> tsmithe: Adri2000: not true.... look  gpg: skipped "MYKEY": secret key not available
<sacater> gpg: [stdin] : clearsign failed: secret key not available
<sacater> debsign: gpg error occurred!  Aborting....
<sacater> debuild: fatal error at line 1151:
<sacater> running debsign failed
<tsmithe> you've got to put in the actual code...
<sacater> i did, i just changed it so you guys couldnt see it
<sacater> :P
<Lutin> hehe, keyIDs are public anyway
<tsmithe> well, nothing bad happens if we do, but ok :)
<tsmithe> mine is 9bc84e4e
<Adri2000> sacater: what does gpg --list-key $KEYID say?
<tsmithe> ;)
<sacater> ive removed the key number
<sacater> Sam Cater (sacater meister) <sacater@btopenworld.com>
<sacater> thats whats said
<imbrandon> they are public
<imbrandon> anyhow
<sacater> oh
<sacater> well how come it dosnt work
<Lutin> sacater: would be easier if you didn't hide your actual keyID imo
<sacater> fine
<sacater> here you go
<sacater> sacater@neo:~/tea/tea-14.2.4$ gpg --list-key 6127680A
<sacater> pub   1024D/6127680A 2007-02-28
<sacater> uid                  Sam Cater (sacater meister) <sacater@btopenworld.com>
<sacater> sub   2048g/F8EF7EB3 2007-02-28
<sacater> sacater@neo:~/tea/tea-14.2.4$ 
<Lutin> sacater: try debsign -k6127680A then
<imbrandon> debuild -S -sa -k6127680A
<imbrandon> yea
<sacater> ok
<imbrandon> ( you can use your email too FYI ) e.g. "debuild -S -sa -ksacater@btopenworld.com" minus the quotes
<imbrandon> )
<sacater> YES!!!! BOOM!
<sacater> works!
<sacater> my first package made
<sacater> imbrandon: okay, i have a few files generated, now what???
<imbrandon> i came in late, what are you wanting to do?
<Adri2000> build
<Adri2000> test
<Adri2000> imbrandon: he's adding a .desktop file
<sacater> Adri2000: okies
<sacater> Adri2000: which package generated do i focus on now 
<sacater> Adri2000: 
<Adri2000> sacater: you already built the binary package?
<sacater> several items were generated when i ran the debuild -S -sa -k6127680A command, i want to know what the next command/thing to do is
<Adri2000> -S means to build the source package
<Adri2000> now you build the binary package with debuild or inside a pbuilder
<sacater> any command extensions for debuild
<sacater> Adri2000: 
<Adri2000> sacater: see man debuild please
<sacater> okies
<sacater> its building now anyways
<Adri2000> cool
<sacater> Adri2000: finished, i have a .deb file 
<Adri2000> install it, test your menu entry
<sacater> can do :P
<sacater> Adri2000: lol, oh well, dependencies work, it just reminded me i dont have tea-data installed :P
<sacater> on it goes...
<jamyskis> hi again people
<shawarma> jamyskis: Hi.
<jamyskis> shawarma: hi again - thanks for the help earlier on
<shawarma> jamyskis: np
<jamyskis> i do have one more question - is there any info anywhere on how to automatically enter an icon into the gnome applications menu post-install?
<jamyskis> i suspect that the postinst script would be responsible (as would prerm for getting rid of it) but i know things are never that simple with debian packaging
<shawarma> jamyskis: You need to add a desktop file to /usr/share/applications/ and an icon to /usr/share/icons
<shawarma> jamyskis: See in /usr/share/applications/ for examples. 
<jamyskis> shawarma: so if i created a desktop file and an xpm pixmap (easy enough) where would i store them at the time the deb package is created and which script would take care of this?
<sacater> Adri2000: when ive tested it and it works, what happens?
<LaserJock> ajmitch: around?
<shawarma> jamyskis: Just like your debian/rules installs every other file into a tmp directory and packs it up in the deb..
<sacater> Adri2000: I upload it somewhere or somerthing :D
<shawarma> jamyskis: It should do the desktop and icon file in the same way.
<Lutin> sacater: you can be happy and enjoy it
<Adri2000> sacater: debdiff(1)
<ajmitch> LaserJock: sort of
<jamyskis> shawarma: so basically i should stick the desktop shortcut and pixmap in the root of the source directory and then in debian/rules build-arch copy them to the respective directories?
<LaserJock> ajmitch: what is your opinion on if edubuntu-docs need a UVFe?
<sacater> Adri2000: ?????
<LaserJock> ajmitch: it's a native package so of course it's a new upstream version
<shawarma> jamyskis: Something like that, yes.
<zachtib> hey guys, i have a sort of problem:
<ajmitch> LaserJock: I'd be ok with it
<shawarma> jamyskis: If the .desktop and icon file didn't come from upstream, though, we usually put them in the debian/ dir, but it doesn't really matter.
<Adri2000> sacater: one "?" is enough ;)
<jamyskis> shawarma: but would they still be copied when it comes to installing the debian package? i thought postinst and prerm were responsible for that?
* jamyskis is slightly confused.
<crimsun> it's not postinst/prerm's job to handle desktop.
<sacater> Adri2000: care to explain what debdiff(1)
<Adri2000> sacater: I told you to use debdiff, a binary which has a man page (section 1)
<shawarma> jamyskis: there's nothing special about a .desktop file compared to every other file in your package.
<zachtib> i'm one of the developers on deluge, which is in feisty's repo.  problem is, the stable version has several serious bugs that lead to corrupted downloads in it.  These have been fixed in SVN, but there isn't a stable release of it yet.  Basically, I'm worried that people with just install the version from the repos, and thus wind up with the very buggy version
<Adri2000> sacater: section 1: "Executable programs or shell commands"
<sacater> Adri2000: kk, i have tested my deb file and it works, along with the newest tea data, dont suppose you want to try it
<tsmithe> zachtib, get the package updated and get a freeze exception granted
<Adri2000> sacater: I "want" a debdiff
<doko> bddebian: will you work on wxwidgets2.8?
<jamyskis> shawarma: ill give it a try and let you know what happens
<zachtib> tsmithe: that's assuming 0.5 is done before feisty is out
<Adri2000> zachtib: you can give us patches
<jamyskis> shawarma: thanks
<crimsun> doko: he's working on it; it's awaiting review IIRC
<tsmithe> zachtib, well, assuming it is done soon; https://wiki.ubuntu.com/FreezeExceptionProcess
<zachtib> Adri2000: well, it's not so much a patch.. as a complete rewrite
<sacater> Adri2000: i dont have the current 6.10 version of tea, let me get it
<bddebian> doko: If you want it in, sure.  Do you think I should base from the package they have posted instead of taking the tarball as I did?
<bddebian> doko: I was also looking at updating anything packages still deping on 2.4 but I'm struggling with that
<shawarma> jamyskis: np
<bddebian> Oh shit, I'm lying, I did base it on their package but I changed it from a native package to a non-native
<zachtib> jdong: thought you were going to do homework?
<doko> bddebian: IMO, take the "upstream" tarball, remove the debian dir from their upstream tarball, look for diffs between their upstream tarball and their .orig.tar.gz, add a patch for that; take the debian dir from the 2.6 package, apply the diffs from the last 2.6 entry and their current 2.8 entry
<jdong> zachtib: forgot to research some vector integrals first :D
<zachtib> anyways, so, What's the _absolute_ latest I could submit a freeze request and have a chance at it getting in?
<zachtib> jdong: you're doing research on IRC?
<jdong> zachtib: uhm, ASAP.
<jdong> zachtib: and no you are distracting me.
<jdong> look away.
<jdong> you're still looking at me
<jdong> I know it.
<zachtib> jdong: yeah, i know. But there's a __huge__ bug in deluge 0.4.1, so i almost don't want it in feisty's repo
<sacater> Adri2000: please join #sacater, i have some pasting to do
<ajmitch> crimsun: what do you think about edubuntu-docs?
<zachtib> i'm trying to finish 0.5 as soon as possible, though...
<jdong> zachtib: can you prepare a patch against 0.4.1?
<jdong> zachtib: there'd be nothing against that
<zachtib> jdong: maybe, but 0.5 is a complete rewrite.  i guess i could try and "backport" the fix
<jdong> zachtib: submitting a patch agianst 0.4.1 is your best bet
<crimsun> ajmitch: / LaserJock: seems acceptable to me.
<jdong> ajmitch: can I please have a verdict or ETA on xserver-xgl?
<Lutin> sacater: you can use pastebin :)
<sacater> Lutin: i like to have paste convos :D
<LaserJock> crimsun / ajmitch : so no need to file UVFe or ...?
<crimsun> LaserJock: has the doc team formalised a policy regarding such changes?
<ajmitch> jdong: you may not have noticed, but I am fairly busy, and you've done a *really* good job of nagging & annoying me :)
* tsmithe hugs ajmitch 
<jdong> ajmitch: then give me a time or another person who can look at it?
<Lutin> sacater: you mean highly unreadable convos ?
<sacater> Adri2000: erm, okay, you want me to use the official, active version, not the one i got as feisty
<Adri2000> sacater: the last version available in the developement version (feisty)
<sacater> ok
<LaserJock> crimsun: in Main they just upload as normal, no UVF required
<LaserJock> crimsun: but edubuntu-docs is a Universe package until I get the MIR done
<Adri2000> sacater: or even the last version available in debian unstable, but for tea it's the same in debian unstable and ubuntu feisty
<sacater> Adri2000: okay
<jamyskis> shawarma: i think ive finally just twigged what this is all about - everything in the debian/tmp is bascially a structure of how the package will be installed to the hard drive in real terms right?
<shawarma> jamyskis: Precisely.
<jamyskis> HAAAALELUJAH
<jamyskis> lol
<jamyskis> shawarma: thanks.
<crimsun> ajmitch: may we formalise (impromptu) policy regarding _buntu-doc in universe? I propose we follow main's lead (e.g., edubuntu-docs does not need UVFe)
<sacater> Adri2000: sacater@neo:~/tea/compare$ debdiff tea_14.2.4-2.dsc tea_14.2.4-3.dsc 
<sacater> Warning: You do not seem to have interdiff (in the patchutils package)
<sacater> installed; this program would use it if it were available.
<sacater> gpg: Signature made Fri 20 Oct 2006 10:40:07 AM BST using DSA key ID 99E81DA0
<sacater> gpg: Can't check signature: public key not found
<sacater> dpkg-source: failure: cannot read /home/sacater/tea/compare/tea_14.2.4.orig.tar.gz: No such file or directory
<sacater> debdiff: fatal error at line 425:
<sacater> cd /tmp/TwgdaddOhf && dpkg-source -x /home/sacater/tea/compare/tea_14.2.4-2.dsc >/dev/null failed
<sacater> sacater@neo:~/tea/compare$ 
<sacater> whoops
<sacater> paste sorry
<LaserJock> crimsun: this should, in fact be the last upload to Universe for edubuntu-docs
<sacater> http://paste.ubuntu-nl.org/7991/
<sacater> Adri2000: http://paste.ubuntu-nl.org/7991/
<shawarma> jamyskis: Heh. np
<Adri2000> sacater: install patchtutils, wrong version
<sacater> Adri2000: cant find it in apt-get
<Adri2000> sacater: I made a typo, read the error message
<imbrandon> brandon@hood:~$ apt-cache madison patchutils
<imbrandon> patchutils |   0.2.31-3 | http://mirror.imbrandon.com feisty/main Packages
<imbrandon> patchutils |   0.2.31-3 | http://mirror.imbrandon.com feisty/main Sources
<imbrandon> brandon@hood:~$                                                                 
<ajmitch> jdong: there are 5 people in motu-uvf. you need 2 acks
<ajmitch> crimsun: sure
<crimsun> LaserJock: (see above)
<LaserJock> k, thanks guys
<jdong> ajmitch: everyone else I've talked to just refers me back to you.
<ajmitch> jdong: probably because I've been one of the people looking at them recently
<sacater> Adri2000: http://paste.ubuntu-nl.org/7992/
<jdong> ok....
<ajmitch> jdong: I personally have no problem with the update (xserver-xgl is utterly broken right now)
<jdong> would any motu-uvf's be willing to ack bug 87687?
<Ubugtu> Malone bug 87687 in xserver-xgl "New git snapshot required for xorg 7.2/feisty" [Wishlist,Unconfirmed]  https://launchpad.net/bugs/87687
<ajmitch> most of them are probably asleep by now
<Adri2000> sacater: version and distro again
<sacater> Adri2000: what, they are wrong?
<Adri2000> yes
<sacater> Adri2000: what prat
<sacater> Adri2000: what part*
<Adri2000> the version and the distro
<jdong> ajmitch: what time are they around?
<sacater> Adri2000: what file?
<ajmitch> jdong: it probably didn't help that I was one of the last people to touch xserver-xgl
<ajmitch> jdong: it varies, look at the ~motu-uvf page
<jdong> ajmitch: I get the feeling none of the other -uvf's want to look at it....
<ajmitch> or they're just too busy
<jdong> most other UVFe's are newer and they've been commented already
<sacater> Adri2000: what file?
<ajmitch> it's a large update
<Adri2000> sacater: guess
<imbrandon> X is scary ;)
<sacater> Adri2000: changlog?
<ajmitch> imbrandon: no kidding, I see I was the last person to touch xgl
<Adri2000> sacater: yes
<imbrandon> heh lucky you
<imbrandon> means merge time you get it ;)
<sacater> Adri2000: i gtg soon, ill take the files with me and continue it at work, what should the CORRECT title be
<imbrandon> sudo killall kicker
<imbrandon> err
<jdong> Password:
<tsmithe> jdong-smells
<jdong> crimsun: would you be willing to spare any time in looking at xserver-xgl UVFe?
<Adri2000> sacater: title ?
<imbrandon> would be ok if i dident use NOPASSWD: :)
<ajmitch> jdong: the reason I complained about subscribing motu-uvf, is that they don't appear on the page I have bookmarked
* ajmitch saw you complaining about me in #k-devel
<jdong> :)
<sacater> Adri2000: what should the package be called
<jdong> I find the inconsistencies between processes to be entertaining.
<ajmitch> jdong: they were there for a reason
<ajmitch> including in the way that launchpad handles email
<sacater> Adri2000: quickly.....
<ajmitch> & various other fun things
<jdong> why does ubuntu-archive want subscribe and ubuntu-motu want assign?
<jdong> motu-uvf*
<Adri2000> sacater: I don't understand what you mean
<ajmitch> because we generally just hand back the bug once we're done with it - easier to do with assigning
<ajmitch> it's just something for us to approve, not something for us to do
<sacater> Adri2000: you say that the package name is wrong in changelog, well what should it be called
<Adri2000> sacater: I said the VERSION and the DISTRO are wrong
<jdong> ok
* ajmitch just spent the best part of an hour & a half digging through ugly code, trying to find a bug
<ajmitch> only to find that it was a setting (one of a thousand or more)
<jdong> all code is ugly when one is unable to locate the bug :)
<ajmitch> some code makes it hard to find a bug
<ajmitch> and is not clearly laid out, nor does it follow any direct path of execution to do the task efficiently
<ScottK> Somone wiser than I once said something along the lines of "Design can either be simple enough to be clearly correct or complex enough it's impossible to prove incorrect."
<neutrinomass> Hi. I added myself to the launchpad team for REVU. According to https://wiki.ubuntu.com/MOTU/Packages/REVU I should now poke the REVU admins here to resync the revu uploaders keyring .
<crimsun> neutrinomass: sync running.
<neutrinomass> crimsun: Cheers :)
<neutrinomass> Erm, I don't have an @ubuntu.com e-mail and it doesn't build....should I put universe as the maintainers or should I make a debian version ?
<crimsun> you just need to change Maintainers per the DebianMaintainerField policy
<crimsun> and XSBC-Original-Maintainer, too
<neutrinomass> Yes, I'm aware of the policy... I just wanted to make sure because technically this isn't in universe and the motus are not responsible for it
<Fujitsu> neutrinomass: Is it going to be in universe?
<neutrinomass> Fujitsu: Well, that is the ultimate goal ;) But now it's for revu
<bddebian> Later gang
<imbrandon> later
<neutrinomass> Oh, and could anybody imagine why the package makes a i386 binary?  (it's using a very very basic cdbs build system, nothing fancy)
<neutrinomass> architecture: all, figured that one out
<jamyskis> shawarma: it worked great - im off to bed, thanks again for your help
<jamyskis> shawarma: ill be uploading it to the universe repository tomorrow once my gpg key is in the revu ring
<imbrandon> no you can upload to the revu repo, not the universe one ;)
<imbrandon> err yea
<sistpoty> hi folks
<tsmithe> hiya sistpoty 
<sistpoty> hi tsmithe
<ScottK> Howdy sistpoty
<sistpoty> hi ScottK
<imbrandon> heya sistpoty 
<sistpoty> hi imbrandon
<imbrandon> zomg rick got amarok building on osx
<imbrandon> rockin
#ubuntu-motu 2007-03-01
<LaserJock> cool
<imbrandon> LaserJock, http://www.racoonfink.com/archives/000713.html
<neutrinomass> erm, when building a package from CVS (which does not provide a ./configure) should one run autogen.sh before dh_make or in debian/rules ?
<tsmithe> rules...
<neutrinomass> cool, thanks
<tsmithe> which package?
<imbrandon> neutrinomass, before dh_make
* tsmithe is unsure about the question :S
<neutrinomass> Ok, now I can sense a disagreement between the motus :p
<tsmithe> i'm not a motu
<tsmithe> :P
<neutrinomass> http://glsof.sourceforge.net/
<tsmithe> (and i'm going to go look at a package to see)
<imbrandon> its from cvs, prep it like a tarbal ( eg run autogen ) before you pakage it
<tsmithe> yeah
<tsmithe> otherwise it could have nasty cvs-deps
<tsmithe> (as i discovered with wired and autopoint)
<neutrinomass> imbrandon: Ok, cool. (good thing I didn't have the time to delete my package *grins at tsmithe* :P )
<tsmithe> imbrandon, haha - i thought dh_make was a command in rules and was getting really, really confused. now i remember what it's really for (god knows - i've used it enough times)
* tsmithe is obviously tired and trundles off to sleep
<neutrinomass> erm, the upstream author signs as "Daniele F." ... should I contact him/her and ask for a last name :-/ ?
<crimsun> which package?
<neutrinomass> I'm trying to package this : http://glsof.sourceforge.net
<crimsun> yes, you should
<crimsun> it's not absolutely required, of course
<neutrinomass> Ok, thanks
<pochu> night :)
<Adri2000> ajmitch: http://ajmitch.net.nz/~ajmitch/missing-fixes-rc.html broken
<ajmitch> oh well
<ajmitch> that's the problem of apt being upgraded
<ajmitch> Adri2000: how busy are you right now? :)
* sistpoty is off to bed now
<sistpoty> gn8 everyone
<Adri2000> I'm merging ifplugd
<Adri2000> night sistpoty
<ajmitch> I noticed that launchpad.net/~ubuntu-universe-sponsors/+subscribedbugs is rather long
<Adri2000> yep, needs some cleanup
* ajmitch won't have any time for looking at stuff until next week
<Adri2000> I can try to clean it a bit, but not now (it's 2am :))
<geser> what's the purpose to list open Debian bugs? without them the list would be one fifth shorter
<ajmitch> geser: sorry?
<ajmitch> hey LaserJock 
<ajmitch> just the person I was thinking about ;)
<LaserJock> uh oh
<geser> the u-u-s bug list lists nearly 20 bugs which are fixed in Ubuntu but still open in Debian
<LaserJock> did anybody in here ping me before I left before?
<ajmitch> geser: blame launchpad
<zul_> heylo
<LaserJock> geser: that's just a queue for you to go get them fixed in Debian I guess
<ajmitch> LaserJock: I want to see  https://beta.launchpad.net/%7Eubuntu-universe-sponsors/+subscribedbugs cleaned up :)
<ajmitch> hi zul
<LaserJock> ajmitch: in what way?
<LaserJock> getting off my butt and sponsoring stuff? or a more technical way? :-)
<ajmitch> checking & sponsoring
* ajmitch is going to be fairly busy for the next few days & away for the weekend
<ajmitch> so I'll try & push people to work on things now :)
<LaserJock> I just spent an hour with my advisor figuring out why the stupid Fortan fitting program wasn't liking me
<ajmitch> ah
<ajmitch> poor chap
<LaserJock> he figured it out though, so that's good
<LaserJock> well, maybe I can have a look
<LaserJock> there's 37 unconfirmed or needsinfo
<LaserJock> ouch
<LaserJock> bug 3393 is on the list
<Ubugtu> Malone bug 3393 in sysstat "'R' report fails" [Medium,Needs info]  https://launchpad.net/bugs/3393
<ajmitch> yes, *old* stuff on there
<ajmitch> I think we should probably do some of the trivial fixes
<ajmitch> rather than waiting for people to reply & fix them
<LaserJock> mhm
<ajmitch> educating people is good, but getting fixes in before release is great :)
<LaserJock> doing them both at the same time is awesome ;-)
<ajmitch> of course
<ajmitch> and you could even write a mail to the motu list asking for volunteers to review the bug list :)
<ajmitch> hi Arrogance 
<Arrogance> greetings ajmitch 
<geser> bug 57951 is a SRU candidate, it has a patch and also 16 duplicates. it only needs someone to do the SRU.
<Ubugtu> Malone bug 57951 in xchat "xchat crashes frequently on quit" [Medium,In progress]  https://launchpad.net/bugs/57951
<ajmitch> geser: could that someone be you?
<LaserJock> ok, I'll bbl, gotta get home
<geser> ajmitch: I would do it but I don't have an edgy system to test
<ajmitch> neither do I
<jdong> pfft you guys are all wimps
* jdong gets patch
<jdong> god finding the patch amongst the stupid crash reports
<jdong> ajmitch: is the patch just that one --disable-dbus basically?
<jdong> http://librarian.launchpad.net/5374594/changes.diff
<jdong> ?
<ajmitch> probably
<ajmitch> and insulting us all doesn't really help much
<jdong> ajmitch: I was joking.
* jdong wonders how disabling features passes as a SRU-worthy fix
<jdong> oh well, not my problem
<jdong_> buenos nachos
<jdong_> ajmitch: 5 starts and no apport files in /var/crash....
<ajmitch> that's nice
<jdong> I'd call it good
<jdong> tha'ts nice in the "Yeah whatever go DIAF" way?
<ajmitch> pretty much, it's not a bug I care about, as long as someone's taking care of it
<ajmitch> I'm not in the sru team, so I won't be approving it or need to look at it
<jdong> ok, I've done my share of guinea pigging tonight.
<jdong> tomorrow.... ugh backports testing party
<bddebian> Heya gang
<ajmitch> hello
<bddebian> Hi ajmitch
<theCore> hi LaserJock
<LaserJock> hi
<bddebian> Heya LaserJock
<LaserJock> hi bddebian
<ajmitch> hi LaserJock 
<LaserJock> hi ajmitch, I'm back
<ajmitch> LaserJock: I noticed!
<LaserJock> ;-)
<ajmitch> oh great
<ajmitch> bugs being filed about ubuntu ultimate edition
<jdong> I bet Ultimate edition has working Xgl and non-crashing xchat
<jdong> and a pony.
<LaserJock> I have a non-crashing xchat
<LaserJock> but I have no idea about Xgl
<bddebian> heh
<jdong> Xgl will work once again soon
<jdong> muahahaha
<jdong> muahahaha
<jdong> mua*cough*cough*hack*cough*
* LaserJock couldn't care less
<LaserJock> oops, did I say that out loud? ;-)
<zul> I thought you had left
<LaserJock> I'm back!
<LaserJock> grabed some Jack in the Box and now I'm at home watching the Simpsons
<theCore> by the way, is it normal that Compiz seems broken?
<LaserJock> I think so 
<LaserJock> :-)
<theCore> for example, the 4 dimensional cube and the ghost applications
<theCore> 4 dimensional cube = 4 virtual desks * 4 cube's sides
<theCore> er, 6 cube's sides
<theCore> for a grand total of 16 usable desktops
<theCore> yay!
* Hobbsee waves
<theCore> Hi Hobbsee
<jdong> wave... d^2 f / dx^2 = a^2 d^2 f/dt^2
<jdong> right?
<theCore> sin x?
<theCore> fancy calculus...
<jdong> theCore: not necessarily sin, though sin/cos fulfill the property a lot :)
<Fujitsu_> Anybody here know who I poke to get app-install-data for a package of mine updated?
<jdong> theCore: you can get wave eq's from anything... like f(x,t)= (x+at)^3
<theCore> jdong: ah, well. 
<theCore> maybe next year, I will have some headaches because of this
<theCore> (I plan my headaches in advance)
<jdong> theCore: come to #ubuntuforums and say #headon
<jdong> :)
<theCore> side note: am I acing -- 94% -- my Calculus course, right now, thanks to Wikipedia and a lot of free time :P
<theCore> jdong: can I ask why?
<jdong> theCore: you'll see... you'll get the joke if live in the US
<theCore> nah, I'm just a Canadian caveman
<bddebian> haha "Apply directly to the forehead"
<jdong> bddebian: lol we have a bot in 3ubuntuofurms that does that
<jdong> and it has #shesaid too
<jdong> for Michael Scott jokes.
<fernando> hey motus
<bddebian> Hello fernando
<theCore> It feels good to be back on my Ubuntu machine
<theCore> I been stuck in the Windows world, most of this month
<theCore> that includes VB.NET programming (ugh) and Vista
<Hobbsee> ugh
<theCore> at least, for us, Vista sucks 
<theCore> the only cool thing is the Data Execution Prevention thingy
<theCore> except it's disabled by default...
<jdong> theCore: I like C# / mono :(
<theCore> jdong: I like C#, too 
<jdong> theCore: from what I can see VB.Net is like identical to C# but different syntax
<jdong> I mean, all the .NET langs are more or less feature-equivalent
<jdong> (read: big improvement over VB6)
<theCore> jdong: well, it's the same under-pinning API 
<jdong> right
<theCore> jdong: it's just a syntax, for the most part
<jdong> yeah
<theCore> syntax change*
<jdong> I think C# supports a bit more language features though
<jdong> like generics type of stuff
<theCore> does C# supports continuations yet?
<jdong> theCore: I know C# 2.0 in .NET does
<jdong> I'm not sure the status on Mono?
<jdong> I'd expect so?
<theCore> maybe, I don't know
<theCore> I am starting to like this language feature 
<theCore> a supercharged goto :P
<jdong> theCore: yeah, generators as they're called in Python...
<jdong> very handy :)
* mode/#ubuntu-motu [+o Hobbsee]  by ChanServ
* mode/#ubuntu-motu [-o Hobbsee]  by ChanServ
<theCore> dh_install
<theCore> cp: cannot stat `./debian/tmp/etc/': No such file or directory
<theCore> what a lovely error message...
<theCore> ha ah!
<theCore> I forgot to remove /debian/tmp/etc from debian/xchat.install
<theCore> I am starting to fear updating my Emacs XFT package
<theCore> I get about 13000 APT-HTTP requests per day  
<LaserJock> wow
<Fujitsu_> Wow!
<LaserJock> why aren't you're packages in Debian?
* ajmitch is glad he doesn't host any packages
<Fujitsu_> LaserJock: Because they're so obscure that nobody would use them if they were there, of course.
<LaserJock> Fujitsu_: did you see your +packages bug got a high priority
<theCore> LaserJock: well, it is somehow in Debian
<Fujitsu_> LaserJock: I did. I was impressed.
<LaserJock> well, I told kiko to do it, so I was hoping
<Fujitsu_> Good, good.
<Fujitsu_> static unblocked that IP, which is also good.
<theCore> Average data transferred per day: 1.18 gigabytes (989.01 megabytes) -- glup
<LaserJock> yeah, I also mentioned that to kiko ;-)
<LaserJock> theCore: I don't understand why the Debian packages don't have that font stuff already
<theCore> LaserJock: because they use the main cvs branch
<LaserJock> Fujitsu_: kiko was really suprised. I might have been a little cranky about it
<LaserJock> theCore: so crappy fonts are in the main cvs?
<theCore> LaserJock: I use the emacs-unicode-2 branch which include the Unicode support and the cool fonts
<theCore> LaserJock: yep
<LaserJock> Fujitsu_: I found out some stuff about +bugs-text
<Fujitsu_> LaserJock: Anything useful?
<LaserJock> Fujitsu_: you can do any old +bugs search and add -text to get the plain text
<theCore> ok, I got the fixed Xchat for Edgy
<LaserJock> Fujitsu_: so search for only open bugs in MOTU Science then add -text
<Fujitsu_> LaserJock: Since when? I filed a bug on that a few months back.
<LaserJock> it works now
<Fujitsu_> Ah.
<LaserJock> kiko showed me
<Fujitsu_> OK.
<Fujitsu_> That's good.
<LaserJock> yeah
<LaserJock> how many MOTUs are present right now?
<Fujitsu_> Not many.
* Toadstool waves
<Fujitsu_> Hey Toadstool.
<LaserJock> imbrandon: around?
<Toadstool> hi Fujitsu_ 
<LaserJock> bddebian?
* bddebian raises hand (He can count for 1/2)
<Fujitsu_> LaserJock: Why do you want everyone?
<LaserJock> we'll take it
<Fujitsu_> Hail bddebian.
<bddebian> Heya Fujitsu_
* Fujitsu_ has to live in a few minutes.
<Fujitsu_> *leave
<LaserJock> ok, we've got 37 Unconfirmed and Needs-Info bugs for u-u-s
<Fujitsu_> Review time?
<LaserJock> I want you all to get at least half processed today
<Toadstool> yay!
<LaserJock> if you see other MOTUs let'm know
<LaserJock> we need to get those buggers done
* Hobbsee waves to LaserJock 
<Hobbsee> erk, reading the rest, 'm not here :P
<Fujitsu_> LaserJock: Add something to the topic, perhaps?
<ajmitch> Hobbsee: thanks for volunteering, oh super-MOTU ;)
* Hobbsee is not super-MOTU
<ajmitch> Fujitsu_: we intended to send a mail to the list instead
<bddebian> LaserJock: That leave me an hour? :-)
<Fujitsu_> ajmitch: Also a good idea.
* ..[topic/#ubuntu-motu:LaserJock] : 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 | https://wiki.ubuntu.com/MOTU/TODO | MOTUs - work on http://tinyurl.com/2v32u4
<LaserJock> bddebian: 24hrs
<ajmitch> Fujitsu_: also trying to send something nice "Please do some work" to inactive MOTUs :)
<ajmitch> if possible
<Fujitsu_> LaserJock: 15 of them are Debian-only bugs.
<LaserJock> then we gotta get all of them done in 24hrs
* Fujitsu_ headdesks.
<ajmitch> LaserJock: thanks for doing this :)
<Fujitsu_> How's the checking of inactive members of motu going?
<ajmitch> Fujitsu_: with a few people it'll be easy
<ajmitch> it's not
<LaserJock> lets get this busted out people!!
<Toadstool> hmm... what do we do with the .desktop only patches?
<Fujitsu_> OK, I've got to go.
<Toadstool> -the
<Fujitsu_> Toadstool: Apply them! Forward them to Debian! Rejoice!
<LaserJock> exactly
<Toadstool> ok
<bddebian> What constitutes "inactive" anyway?  I've been meaning to ask that
<ajmitch> though contacting inactive MOTUs was something I signed up for at the MC meeting
<ajmitch> bddebian: whatever we feel like, we really just want to get more people back & involved
<LaserJock> yeah, it's not about kicking people out
<LaserJock> just kicking them into activity ;-)
<bddebian> Agreed, I was just wondering how you were determining if someone was "inactive"?
<ajmitch> bddebian: as I said, whatever we feel like
<bddebian> Uploads, bug update, what?
<ajmitch> we'll run through the list, see if they've been around in the last few months, if not, politely send them a message
<bddebian> Ah
<ajmitch> eg there are some MOTUs I met at UDS, who just are too busy
<ajmitch> (working for google)
<theCore> I wonder if I could be accepted as a MOTU ...
<theCore> (yeah, I know, keep working...)
<LaserJock> you just need some more Universe work I think
<LaserJock> and speaking of that
<LaserJock> ...
<theCore> here xchat: http://revu.tauware.de/details.py?upid=4534
<bddebian> ajmitch: I work, what's my excuse? :)
<LaserJock> theCore: we've got a list of RC bugs that have been fixed in Debian since the current Ubuntu version
<Toadstool> is it me or all the .desktop patches have already been applied/forwarded to Debian by crimsun?
<LaserJock> theCore: http://ajmitch.net.nz/~ajmitch/missing-fixes-rc.html
<LaserJock> Toadstool: make sure you aren't looking at Debian tasks
<Toadstool> I am not
<LaserJock> k
<LaserJock> it could be we just need cleanup
<Toadstool> well the Debian task is still valid
<theCore> LaserJock: thanks
<theCore> okay, now I need a debdiff...
<theCore> hmm... debdiff xchat_2.6.6-0ubuntu3.dsc xchat_2.6.6-0ubuntu4.dsc | diffstat
<theCore>  71 files changed, 5748 insertions(+), 6 deletions(-)
<theCore> I am working very hard :P
<LaserJock> yikes
<theCore> nah, I should say automake is working hard 
<Toadstool> oh wow
* Hobbsee does one
<Toadstool> theCore: how about trying to keep the debdiff as little as possible? ;)
<theCore> Toadstool: yeah, I am trying to find a way...
<theCore> but building Edgy packages on Feisty is not optimal, even with a Edgy pbuilder's basetgz
<Hobbsee> gah.  can i just reject https://bugs.beta.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/45852 as they need a MIR report, and we dont have cd space?
<Ubugtu> Malone bug 45852 in Baltix "Default Ubuntu desktop can't play midi files (not Kubuntu)" [Medium,Confirmed]  
<Hobbsee> at this point, i'ts not a u-u-s bug anyway
* Hobbsee unsubscribes u-u-s as a start
<LaserJock> yes
<Hobbsee> done :
<Hobbsee> )
<Toadstool> 2 syncs ack'd, yay...
* bddebian bows to Hobbsee :)
<ajmitch> LaserJock: excellent, our plan is working... ;)
* Hobbsee does kchmviewer as well
<Hobbsee> presumably we can do new versions of software if they've been filed before the freeze?
<LaserJock> go MOTUs go!!!
<LaserJock> probably not actually
<Toadstool> you manipulative MOTU Council #@"%! :)
<theCore> I don't get it... why the .Po files are changing, they aren't even in the diff.gz
<ajmitch> Hobbsee: well, I'm not sure
<Hobbsee> ajmitch: they did that for the sync requests
* Hobbsee wonders if it can be on an "as it feels right" basis
<ajmitch> Hobbsee: I'd go for the "as it feels right"
<Hobbsee> right
<ajmitch> for sync requests it's different
<ajmitch> since this is stuff we're reviewing
<Hobbsee> yep
<Hobbsee> right, that's done too.
<ajmitch> great
* Lathiat laughs @ jdong's quit message
* ajmitch can see the list shrinking already
<Toadstool> i'm taking care of nttcp
<ajmitch> sync request?
<Toadstool> nope merge
<ajmitch> ah right
<ajmitch> yeah, I forgot that one
<ajmitch> it was mistakenly assigned to motu-uvf
* ajmitch watches firefox seize up
<theCore> Lathiat: hehe, it's a Windows' cd-key :P
<Lathiat> theCore: ya i know, thats why i was laughing ;)
<theCore> Lathiat: well, then we are two :)
<theCore> there's really a Wikipedia's article for everything: http://en.wikipedia.org/wiki/FCKGW
<Toadstool> alright, nttcp done
<Toadstool> uh only 31 remaining in the list? awesome :)
<bddebian> I'm looking at rutilt atm
<theCore> debdiff xchat_2.6.6-0ubuntu3.dsc xchat_2.6.6-0ubuntu4.dsc | diffstat
<theCore>  4 files changed, 16 insertions(+), 6 deletions(-)
<theCore> yay!
<Toadstool> that's a lot better ;)
<bddebian> OK rutilt is broken
<Toadstool> fix it! :)
<bddebian> I'm trying but I'm dumb :-(
<Toadstool> oh come on, you know you're not
<bddebian> Nope, it's true :'-(
<theCore> should I subscribe motu-sru to bug 57951?
<Ubugtu> Malone bug 57951 in xchat "xchat crashes frequently on quit" [Medium,In progress]  https://launchpad.net/bugs/57951
<theCore> (xchat)
<ajmitch> gah
<Toadstool> Looking at backstep right now
<ajmitch> I get home & there's about 20 old crappy (pentium) boxes in the living room
<Toadstool> heh
<Lathiat> what on earth are they for :P
<Lathiat> housemate salvaged them for you thinking they might be usefull? :P
<ajmitch> Lathiat: my flatmate plans to use them somehow
<Lathiat> you can run more avahi scalability tests for me
<ajmitch> not for me, I wouldn't use them
<ajmitch> haha
<Lathiat> apparently 80 UMLs don't like being schedule ALL AT ONCE
<Lathiat> on a dual 2.5ghz machine
<ajmitch> upgrade
<ajmitch> theCore: following the universe SRU process?
<Lathiat> i wonder if xen would be more effecient
<ajmitch> xen doesn't share memory like UML can
<ajmitch> theCore: https://wiki.ubuntu.com/MOTU/SRU
<Lathiat> share memory in what way?
<Lathiat> oh
<Lathiat> i know what you mean
<Lathiat> true that
<Lathiat> running 16M umls used far less memory that i thought..
<ajmitch> yes
<Lathiat> 80 UMLs were using <500M of ram
<ajmitch> xen allocates physical RAM
<Lathiat> but if i boot it with any less than 16M of ram they wont boot
<Lathiat> nod
<Lathiat> but i wonder if cpu effeciency would be better
<Lathiat>   /network io
<ajmitch> should be
<ajmitch> but UML+KVM should improve that a lot
<ajmitch> less syscall trapping
<bddebian> Toadstool: So, you and Hobbsee finish them all already?
<Lathiat> yeh didnt have a VT capable machine
<Hobbsee> bddebian: no.  keep going.
<Lathiat> for KVM
<Toadstool> bddebian: er, dunno. I'm sure there are a few more left
<LaserJock> go go go!
* ajmitch cracks the whip
<bddebian> Should I do 67260 or leave it?
<LaserJock> bug #67260
<Ubugtu> Malone bug 67260 in transcriber "transcriber does not have Menu entry in gnome" [Undecided,In progress]  https://launchpad.net/bugs/67260
<bddebian> Vassilis filed it in Debian too
<LaserJock> "I'll forward this to Debian as well, so don't subscribe universe-sponsors just yet."
<bddebian> Yeah, well obviously we were subscribed :-)
<LaserJock> is there anything in Debian yet?
<Toadstool> uhuh, got to go, my girlfriend is getting really angry, I don't want her to throw my laptop away :)
<LaserJock> np
<Toadstool> see you tommorow
<LaserJock> thanks a ton Toadstool
<ajmitch> bye Toadstool :)
<Hobbsee> ajmitch: i thought that was my job
* Fujitsu returns.
<Hobbsee> yay, Fujitsu's back.  now go fix those bugs!
<ajmitch> Hobbsee: sorry ma'am
* ajmitch returns to his rock
* Fujitsu attacks some debdiffs.
<Hobbsee> ajmitch: return to bugfixing.  go on!
* Hobbsee uncovers the rock, and cracks the whip at ajmitch 
* Fujitsu explodes the rock.
<bddebian> LaserJock: No, not in Debian yet
<LaserJock> I'd go for ith then maybe
<LaserJock> we're a bit late to wait for Debian to do it then sync
<bddebian> ok
<ajmitch> LaserJock: there are a lot more ubuntu bugs with patches attached than those that have u-u-s subscribed
<LaserJock> yeah
<ajmitch> so I guess bddebian still has a few to work on
<LaserJock> well, we gotta have something for tomorrow
<LaserJock> ;-)
<ajmitch> bddebian will have done them by then
<ajmitch> 1 - 50  of 277 results
<ajmitch> think he can get through those? :)
<ajmitch> that includes all SRUs in -proposed which are fix committed
<LaserJock> yikes
<ajmitch> lots of patches which don't help much
<LaserJock> well, we need to weed them out anyway :-)
<ajmitch> yep
<bddebian> ajmitch: Nah, I'm waaay behind on the bug stuff this cycle :-(
<ajmitch> now is a good time to catch up
<bddebian> Gah, stupid Debian tags
<theCore> ah done. https://launchpad.net/ubuntu/+source/xchat/+bug/57951
<Ubugtu> Malone bug 57951 in xchat "xchat crashes frequently on quit" [Medium,In progress]  
<theCore> now, I just have to wait
<theCore> good night all 
<bddebian> Gnight thec... grr
* Fujitsu hits Hobbsee with a check-that-the-.desktop-is-actually-installed-before-closing-the-bug stick.
<Hobbsee> Fujitsu: which one?  
* Hobbsee didnt even upload that one.
<Fujitsu> Bug #42622.
<Ubugtu> Malone bug 42622 in drscheme "Missing .desktop file" [Medium,In progress]  https://launchpad.net/bugs/42622
<Hobbsee> ah
<bddebian> Gah 1am, gnight folks
<imbrandon> hum anyone have access to a box with IE7 on it ?
* LaserJock shields his eyes
<imbrandon> heh
<Hobbsee> only if i reboot
<imbrandon> i just wanted soemone to check www.ubuntuwire.com , someone emailed me and said it pukes in ie7 and i have no boxen with ie7
<imbrandon> but ie6 and ff seems fine
<imbrandon> hell its 99% text dont see how it would puke but oh well ;)
<LaserJock> imbrandon: is that a bad thing?
<imbrandon> hahah well kinda, but not one i'm real real worried about 
<imbrandon> ;)
<LaserJock> well, I think I have IE7 installed
<LaserJock> I booted into Windows the other day
<LaserJock> and it did the "We require proof that this is a real copy of Windows ... and your firstborn"
<LaserJock> and then it was like "We notice you are dual booting Ubuntu on this machine ... can we have a copy?"
<imbrandon> hahahaha
<imbrandon> classic
<imbrandon> LaserJock, windows on the MBP or another box?
<imbrandon> heh
<LaserJock> MBP?
<imbrandon> mac book pro
<LaserJock> no, I don't have a mac book pro
<LaserJock> just an iMac at work
<imbrandon> ahh
<LaserJock> this is a toshiba
<Fujitsu> imbrandon: Wouldn't it make sense to deliberate block IE users?
<Fujitsu> *deliberately
<imbrandon> Fujitsu, nah i dont wanna block anyone, if a windows user wants to promote ubuntu , let them
<imbrandon> they might dual boot etc
<imbrandon> ;)
<imbrandon> i do need to add a capacha though to the signup, although it hasent been abused yet, dosent mean it wont
<LaserJock> imbrandon: any reasonable person will still be using FF on Windows ;-)
<imbrandon> ;)
* imbrandon yawns
* Fujitsu stifles a yawn.
<dholbach> good morning
<LaserJock> hi dholbach 
<dholbach> hiya LaserJock
<imbrandon> moins dholbach 
<dholbach> hey imbrandon
<ajmitch> hey dholbach 
<LaserJock> ajmitch: you're still around?
<dholbach> hey ajmitch
<ajmitch> LaserJock: sure, just been out with friends :)
<LaserJock> ah
* ajmitch doesn't run away from the computer until tomorrow evening
<ajmitch> but I have work tomorrow
<LaserJock> well, I'm not sure how we did with the u-u-s charge
<ajmitch> fairly well
<LaserJock> I think we got rid of quite a few
<LaserJock> it's just a bit hard to tell
<ajmitch> from 37 unconfirmed/needs info down to 30
<LaserJock> and most of those are Debian tasks
<ajmitch> it was down at 27 before, I guess a few were added
<ajmitch> yeah
<ajmitch> but the big amount of work will be going through the bugs with patches attached
<ajmitch> easy to search for those in malone (select universe, multiverse, with patches attached)
<LaserJock> how many were there again?
<ajmitch> >270, but there's a lot of duplication
<ajmitch> 1 bug with 4 patches shows up 4 times
<ajmitch> plus that's all the fix committed SRU work
<ajmitch> you want to mail the list about these bug lists?
* ajmitch cannot be as eloquent as you are
<Ademan> is there an itp for http://spring.clan-sy.com  ?
<ajmitch> check the PackageCandidates page on the wiki (iirc)
<Ademan> thanks
<Ademan> looks as though it makes use of non-free artwork (with GPLed alternatives)
<Ademan> may not be as impressive as i had hoped with the "crappy" artwork
<LaserJock> ajmitch: maybe a MOTU Bug Sprint would be helpful?
<ajmitch> we don't use ITPs as such, PackageCandidates is more for reqeusts from users
<ajmitch> LaserJock: certainly
<Ademan> ah, well either way it's in package candidates
<Ademan> but it's far past my bedtime, got 4 hours of sleep last night, gnight all
<ajmitch> heh ok
<LaserJock> hmm, so can I ask for MC decisions on something via email?
<ajmitch> sure, why not?
<ajmitch> we're not bound to irc
<ajmitch> of course there's no MC list yet, but you know our addresses, or could ask on the motu list :)
<\sh> moins
<LaserJock> well, if we decided on a tag to use there's no reason why we can't start using it for package requests
<ajmitch> hey \sh 
<ajmitch> sure
<LaserJock> I think it'll be another month or so before we get the cool tag preloading
<ajmitch> or more
<ajmitch> I don't know how long it may take to roll out the new UI
<LaserJock> RSN
<ajmitch> they were discussing 1.0 being ready by december 2005, iirc ;)
<LaserJock> of course
<imbrandon> heh
<LaserJock> it's a race between LP 1.0 and Etch
<ajmitch> hehe
<imbrandon> LaserJock, LOL
<ajmitch> they're much closer now
<ajmitch> & have a clearer picture of what they need to do
<LaserJock> which one?
<ajmitch> LP
<ajmitch> etch is just bug fixing :)
<imbrandon> etch == 2010
<Lathiat> haha
<LaserJock> I swear they have enough characters
<LaserJock> they don't need to drag it out this long ;-)
<imbrandon> lol
<LaserJock> anybody know how to "go back in time" with SVN?
<poningru_> lol
<imbrandon> svn --oops 12-3-2006 
<imbrandon> just kidding
<ajmitch> haha
<ajmitch> http://article.gmane.org/gmane.linux.debian.devel.vote/11493
<ajmitch> DPL election time
<imbrandon> lol
<imbrandon> almost as if he is kin to crimsun ;)
<LaserJock> lol
<LaserJock> "Every time you ask for a pony, a kitten commits suicide. :-) I'll give you a klingon translated Debian Operating Systems book and that's enough, isn't it?"
<imbrandon> I know I'm not going to understand women. I'll never understand how you can take boiling hot wax, pour it onto your upper thigh, rip the hair out by the root, and still be afraid of a spider. 
<LaserJock> I don't know dude
<LaserJock> spiders are creepy
<imbrandon> lol
<shawarma> imbrandon, LaserJock: That bit of conversation is going on bash.org for sure!
<LaserJock> ;-)
* shawarma can't stop laughing again.
<imbrandon> lol
<shawarma> Gah... bash.org: 19753 quotes approved; 7247 quotes pending... It's gonna take forever!
<ajmitch> hi herzi 
<herzi> hey ajmitch
<ajmitch> how are you?
<ajmitch> haven't seen you round for awhile
<herzi> fine, quite busy
<ajmitch> :)
* ajmitch was going to ping you recently about joining pkg-fedora-ds - is that team active at all?
<ajmitch> I've been doing some work recently on FDS, mainly libraries needed for it
<herzi> not active yet, just because noone had time to really start with it
<ajmitch> ok
* ajmitch has gotten started, at least
<ajmitch> so I don't want to duplicate efforts, been talking with richm who was trying to convert some .spec files
* Fujitsu wonders why the maintainer of these new Edgy binary-only uploads (can Soyuz handle them nowadays?) has been mangled to the name of the buildd...
<shawarma> Fujitsu: Binary-only uploads? wtF?
<Fujitsu> shawarma, that's what I thought.
<Fujitsu> Binary-only uploads signed and maintained by the buildd... How odd.
<shawarma> Fujitsu: Where do you see them=
<shawarma> ?
<Fujitsu> shawarma: edgy-changes
<shawarma> Fujitsu: Oh, of course. I'm only subscribed to feisty-changes.
<Fujitsu> That'd do it.
<shawarma> It's not in the mailing list archive yet. Odd. 
<Fujitsu> `Accepted slocate 3.1-1ubuntu0.1 (ia64)'
<Fujitsu> Files:
<Fujitsu>  9a7a0d2ef7ce95d5d633432886fde122 38704 utils extra slocate_3.1-1ubuntu0.1_ia64.deb
<StevenK> Fujitsu: Normal.
<Fujitsu> Since when does Soyuz allow that?
<Fujitsu> I've not seen it before...
<StevenK> Fujitsu: Except that the distribution should be autobuild, not edgy
<Fujitsu> StevenK, why?
* ajmitch wanders off for sleep
<ajmitch> StevenK: uploaded dbmail?
<StevenK> ajmitch: It's a sync
<ajmitch> even better
* ajmitch can sleep now :)
<Fujitsu> Night, ajmitch.
<StevenK> ajmitch: Do I subscribe ubuntu-archive myself?
<ajmitch> sure
<StevenK> Right.
<StevenK> ajmitch: Sleep well
<imbrandon> gnight ajmitch 
* Fujitsu wonders aloud why drscheme FTBFS on the i386 and amd64 buildds, but works here and on another machine, and on the powerpc and sparc buildds.
<StevenK> dh_gencontrol -pdrscheme 
<StevenK> du: `./usr/share/plt/doc/doc-license.txt': Not a directory
<StevenK> dpkg-gencontrol: failure: du in `debian/drscheme' gave error exit status 1
<StevenK> ..... Interesting.
<Fujitsu> Yep.
<Fujitsu> Exactly.
<Fujitsu> Works fine here, but not on x86 buildds.
* Fujitsu decides that it's the fault of the buildds.
<StevenK> Fujitsu: Beg infinity? Maybe bribe him since you live close-ish? :-)
<Fujitsu> I was thinking more along the lines of the former.
<Fujitsu> Gah, I would have at least thought that it would be nice and fail on the obscure architectures...
<StevenK> Well, it is cheaper.
<StevenK> I love it when the uploader builds it sucessfully, uploads it and it only builds on one of the buildds.
<StevenK> I've seen that in Debian.
<Fujitsu> I've done that once. But it failed on the architectures I /didn't/ test.
<StevenK> Mmmmm. What did you do to piss Murphy off?
<Fujitsu> Something big, apparently.
<StevenK> Heh. :-P
<Fujitsu> Hm, doesn't that error imply that usr/share/plt/doc is a normal file?
<white> Fujitsu: did you build with fakeroot or as root?
<StevenK> Fujitsu: ... maybe
<geser> StevenK: xmms2 is even better: it builds in pbuilder and Debian buildds but not on Ubuntu ones
<Fujitsu> white, fakeroot.
<StevenK> Fujitsu: You need to reproduce it first.
<white> Fujitsu: i am not quite sure if i remember right, but i guess there was a problem with it on alpha and if i built it as root it worked, not with fakeroot as a normal user though
<Fujitsu> It takes like 25 minutes to build, so I'll look at it tomorrow.
<StevenK> geser: It doesn't count if it doesn't build on any of them. Half a point. :-P
<StevenK> This whole school night thing.
<Fujitsu> white, I might expect something similar on uncommon architectures.
<StevenK> Fujitsu: How many times have you been told to go to bed?
<StevenK> :-P
* Fujitsu attacks StevenK with a stupid i386 buildd.
<Fujitsu> A few now.
* StevenK ducks
* Fujitsu throws the amd64 one at his parents.
<StevenK> Heh
<geser> StevenK: does uploading to get hints why it fails on the buildds count?
* StevenK ponders putting on the *cough* *hack* respected computer professional voice and telling Fujitsu's parents that he's a good guy.
<StevenK> geser: Bwahaha
<Fujitsu> geser: Hahah.
<StevenK> Although saying I'm a "respected computer  professional
<StevenK> " on the phone and then coughing a lot because I don't believe myself won't help. :-P
<Fujitsu> Probably not
<StevenK> Fujitsu: :-)
<StevenK> Fujitsu: Aren't you supposed to be in bed?
<Fujitsu> Probably.
* StevenK runs, far, far away.
<Fujitsu> I can't exactly attack you from here, StevenK.
<Fujitsu> And I already got rid of the buildds before, so you're safe.
<StevenK> Heh
* Fujitsu blinks, then curses a lot.
<Fujitsu> Building here:
<StevenK> Fujitsu: Now you have to share.
<Fujitsu> dh_compress -pdrscheme  
<Fujitsu> gzip: usr/share/man/man1/drscheme.1 is a directory -- ignored
<Fujitsu> dh_compress: command returned error code 512
<Fujitsu> make: *** [binary-fixup/drscheme]  Error 1
<StevenK> Bwahaha
<Fujitsu> Does this i386 build have some directory-file duality?
<fernando> moin all
<Fujitsu> Stupid drscheme. debuild works. pbuilder works. dpkg-buildpackage is currently in progress...
<Hobbsee> why are you touching drscheme anyway?
<Fujitsu> I was fixing up the .desktop patch.
<Hobbsee> ah
<Fujitsu> Anybody got any ideas on how to troubleshoot this build now that it builds using every conceivable method on this machine?
<geser> Fujitsu: add some output that helps you to find the problem and re-upload?
<Fujitsu> geser, it turns out it's pkg-create-dbgsyms killing it.
* Fujitsu finds a buildd admin.
<tbf> ok, joineded the contributors group... so I am asking the REVU admins here to re-sync the REVU uploaders keyring... ;-)
<enry> hi. i have a question!
<Ursinha> oh... he's gone
<\sh> wow...my oracle client package 10.2.0 works on dapper without any problems...cool
<enry> excuse me.
<enry> i have a problem with creative sb live: only 2 channels are recognized, i have read that probably the problem is driver alsa included in kernel
<enry> will this problem be fixed? how can i solve?
<tbf> ok, my package hangs arround in ftp://revu.tauware.de/incoming/ now. lets see what happens.
<enry> nobody knows if the problem will be fixed?
<crimsun> lifeless: retested that apport "issue" with -i810 and -i810-modesetting; turned out to be a red herring. The issues were caused by pulseaudio+esound bad interaction. Have a workaround in place.
<bddebian> Heya gang
<zul> hah
<zul> http://www.shelleytherepublican.com/2007/02/28/linux-the-official-os-of-the-axis-of-evil.aspx
<\sh> zul: lol
<infinito> can anyone point me where to find the python recommended packaging policy? 
<bddebian> http://wiki.debian.org/DebianPythonFAQ
<infinito> bddebian: thanks
<bddebian> NP
<infinito> should i ise pycentral or pysupport?
<bddebian> infinito: I think many are using pycentral these days but I'm not sure what our "policy" about it is
* ScottK thinks either is OK.  Up to the packager.
<infinito> ok
<giftnudel> infinito: funny enough, I asked the same things yesterday ;)
<sacater> Adri2000: okay im back...... i have changed the TEA package name and tested it on my system, it works great
<infinito> is it possible to get packages on universe before feisty?
<siretart> dholbach: re bug #88837, did you forget to put it on 'confirmed' or is something left?
<Ubugtu> Malone bug 88837 in soundconverter "UVF exception: soundconverter 0.9.3 -> 0.9.4" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88837
<dholbach> siretart: i think only one person gave the +1, no?
* dholbach looks
<dholbach> siretart: yes, only one +1, needs two
<siretart> dholbach: argl. I misread https://wiki.ubuntu.com/FreezeExceptionProcess that only one +1 was needed. :/
<dholbach> ok, np :)
<siretart> dholbach: what's the correct quorum? 2 or 3 persons?
<dholbach> it needs +2 :)
<siretart> k
<bddebian> siretart: Me too ;-)
<Toadstool> g'morning everybody!
<siretart> huhu bddebian 
<bddebian> Heya Toadstool, siretart, dholbach :-)
<dholbach> hi bddebian
<Toadstool> hi bddebian 
* Toadstool bows down before Holy Holbach too ;)
<\sh> guys, if you are a python crack, please tell me something: is it possible to send python objects via tcp, just like java does? if so, is there any tutorial on this? :)
* ScottK sits back and waits to hear the answer to that one.  Interesting.
<sacater> Adri2000: you here?
<Adri2000> yes
<Toadstool> \sh: maybe using pickle
<sacater> Adri2000: i finished the TEA package, with proper package names i think, i uploaded it to 01welp.co.uk/~sacater/MOTU/finished
<sacater> Adri2000: http://01welp.co.uk/~sacater/MOTU/finished/
<Adri2000> sacater: I don't care about the binaries, they are built on the buildds. I need the debdiff, diff between the sources packages.
<\sh> Toadstool: will have a look :)
<sacater> Adri2000: okie
<sacater> s
<sacater> Adri2000: .dsc right?
<Toadstool> \sh: http://docs.python.org/lib/module-pickle.html
<Adri2000> sacater: debdiff original.dsc your.dsc
<sacater> Adri2000: kk
<sacater> !paste | sacater
<sacater> whats the paste site
<Adri2000> paste.ubuntu-nl.org
<lionel> sacater: http://paste.ubuntu-nl.org/
<sacater> lionel: ty
<sacater> Adri2000: http://paste.ubuntu-nl.org/8102/
<Adri2000> it should be debdiff tea_14.2.4-2.dsc tea_14.2.4-2ubuntu1.dsc
<siretart> anyone in here knows about project using 'cook'? http://miller.emu.id.au/pmiller/software/cook/
<sacater> Adri2000: so i have the package names messed up
<Adri2000> sacater: maybe it would be easier to restart at the beginning
<sacater> Adri2000: what should the ubuntu package be called
<Adri2000> sacater: download the feisty source package of tea in feisty (14.2.4-2), add your .desktop file in debian/ and edit the .install file, dch -i, write the changelog entry, set the version to 14.2.4-2ubuntu1 and the distro to feisty (NOT unstable), then debuild -S, that will create the new source package, debdiff the two .dsc
<sacater> Adri2000: okay.... isnt it meant to be debuild -S -sa?
<Adri2000> debdiff tea_14.2.4-2.dsc tea_14.2.4-2ubuntu1.dsc > debdiff and upload/paste the file called debdiff somewhere
<sacater> Adri2000: how do i change the version name to feity
<sacater> feisty*
<Adri2000> sacater: -sa means that you want to upload the tarball too, here you only change things in the packaging, it's not a new upstream version. anyway it won't change anything for you since you don't do the actual upload.
<Adri2000> sacater: in the changelog
* tsmithe has forgotten :: what's the gpg command to edit my key?
<Adri2000> replace unstable with feisty
<Adri2000> tsmithe: gpg --edit-key ?
<sacater> Adri2000: okay then.... nearyl done
<tsmithe> Adri2000, but then what? i want to change the email..
<tsmithe> i know i've done it before :S
<Adri2000> dunno, man probably knows :)
<tsmithe> tried that :P
<geser> tsmithe: is the key with that uid already on the keyservers?
<sacater> Adri2000: where you said change the distro to feisty (NOT unstable) did you mean it should appear exactly like that, or it should appear as just 'feisty'
<tsmithe> geser, hmm yea...
<tsmithe> is that bad?
<Adri2000> sacater: 'feisty'
<sacater> Adri2000: can do
<geser> tsmithe: it depends how you see it, you can't delete (or edit) parts of a key once this information is on the keyservers
<tsmithe> depends?
<tsmithe> how?
<geser> tsmithe: you can only revoke that uid and add a new one
<tsmithe> cba tbh :P
<tsmithe> thanks :)
<cbx33> geser, you can update information on keyservers
<tsmithe> cbx33, ooh?
<cbx33> well i added a second email address to mine and uploaded it
<cbx33> I'm sure of it
<cbx33> http://keyserver.mine.nu/pks/lookup?search=pete+savage&fingerprint=on&op=index
<cbx33> yeh i had my gpg key before i got my ubuntu email address
<tsmithe> dholbach, ping
<dholbach> tsmithe: pong (just about to leave) - make it quick ;-)
<tsmithe> dholbach, in ubuntustudio-look (maybe others), you've set Maintainer to a non @ubuntu.com email address, and not followed the spec... why isn't dpkg-source complaining?
<geser> cbx33: adding other uid works, but not editing the ones already on the servers or even deleting old uid from keyservers doesn't work
<dholbach> tsmithe: that probably was before the dpkg change
<tsmithe> dholbach, but it's not complaining now :P
<Adri2000> tsmithe: @*ubuntu* should work I think
<dholbach> tsmithe: just change it to the motu address (as in the spec) and set cory's adress or whatever address you can agree on as XSBC-Original-Maintainer
<tsmithe> i will :)
<tsmithe> Adri2000, it doesn't have any ubuntu
<tsmithe> it's just weird that it doesn't complain
<geser> tsmithe: has the version an ubuntu in it?
<tsmithe> ah - no
<tsmithe> should it?
<dholbach> tsmithe: I guess it didn't complained for me because the change in dpkg-dev was introduced some days ago and I did the packaging before that
<dholbach> but anyway... see you guys later
<dholbach> tsmithe: see you
<tsmithe> dholbach, but i'm building it now :P
<tsmithe> dholbach, bye :)
<dholbach> rock on
<dholbach> ;-)
<tsmithe> :D
<geser> tsmithe: the package name suggest this package is only useful to Ubuntu and never will be in Debian, so you don't have to have an ubuntu in the version
<geser> the check in dpkg-buildpackage checks only for an ubuntu address if there's ubuntu in the version
<tsmithe> ah very good
<tsmithe> so i don't need to follow the spec either?
<sacater> Adri2000: 
<sacater> http://paste.ubuntu-nl.org/8105/
<sacater> Adri2000: HOPEFULLY i have it right this timne
<geser> tsmithe: no, as you don't a Debian maintainer for this package :)
<tsmithe> \o/
<Adri2000> sacater: feisty lowercase. for the bug you fix, you should use "LP: #nnnnn"
<tsmithe> faa la laaa /me's a-pbuilding
<Adri2000> sacater: '* Added .desktop file (LP: #nnnnn)"
<sacater> Adri2000: okay
<Adri2000> sacater: please clean up the debdiff so that it is easier to read, remove the config.sub stuff
<sacater> Adri2000: where (LP: #nnnnn) is. Should i put things in #nnnnn
<Adri2000> where #nnnnn if the bug number of course
<sacater> okies
<sacater> and LP should remain as it is
<Adri2000> yes, it means Launchpad
<sacater> okay
<Adri2000> sacater: also, use desktop-file-validate on your .desktop file
<sacater> Adri2000: command?
<Adri2000> desktop-file-validate
<sacater> okies
<Adri2000> desktop-file-validate file, as man desktop-file-validate says.
<sacater> okies
<sacater> its wrong as well :P
<sacater> wrong categorie
<sacater> Adri2000: Now running lintian...
<sacater> E: tea_14.2.4-2ubuntu1_source.changes: bad-distribution-in-changes-file feisty
<Adri2000> ignore that.
<sacater> Adri2000: thats okay though isnt it?
<sacater> thought so
<sacater> ty
<sacater> Adri2000: http://paste.ubuntu-nl.org/8107/
<sacater> Adri2000: how is it?
<Adri2000> sacater: /usr/bin/tea doesn't exist
<sacater> how do you mean, on my system
<sacater> where is the exact fault
<sacater> Adri2000: 
<Adri2000> /usr/bin/tea exists on your system?
<Adri2000> I have only teaed
<sacater> oh
<sacater> right
<sacater> touche
<sacater> Adri2000: but whats wrong with that
<sacater> Adri2000: should it be tea or teaed
<Adri2000> I don't know why the binary is called teaed
<Adri2000> read the changelog maybe
<sacater> so why did you complain <Adri2000> sacater: /usr/bin/tea doesn't exist
<Adri2000> ...
<sacater> Adri2000: its okay anyway, join my channel for a mo
<Adri2000> nope, here is fine
<sacater> tea (9.0-1) unstable; urgency=high
<sacater>   * New upstream release
<sacater>   * Split debian/tea.doc-base into two files. Closes: #304444
<sacater>   * debian/rules: add --enable-debian to configure options.
<sacater>   * Change /usr/bin/tea to /usr/bin/teaed (conflicts with dak package). 
<sacater>     Closes: #303352
<sacater>   * Upstream applied patch for amd64/gcc-4.0. Closes: #303416
<sacater>   * debian/control: add bzip2 & unzip to Recommends field.
<sacater>   * remove debian/tea_spell.c.patch since fixed on upstream
<sacater> it states it was changed
<Adri2000> not fine to flood, though
<Adri2000> great
<sacater> Adri2000: so what happens to my package now?
<sistpoty> hi folks
<sacater> sistpoty: hi
<sistpoty> hi sacater
<Adri2000> sacater: well, just change tea to teaed, I don't see any difficulties here
<Adri2000> hi sistpoty
<sistpoty> hi Adri2000
<sistpoty> motu council finally has his mailing list :)
<Adri2000> ah cool, sistpoty: anyone can subscribe?
<sacater> Adri2000: when you say change 'tea to tead' what 'tea' i can see several things called 'tea'
<sistpoty> Adri2000: it's a public list
<Adri2000> ok
<sistpoty> Adri2000: however there shouldn't be a need to subscribe to it, since we'll only handle new developer applications and administrativa there. the interesting discussions will still be going on at ubuntu-motu
<sistpoty> +@l.u.c
<Adri2000> I see
<sistpoty> (at least that's the plan *g*)
<Adri2000> sacater: /usr/bin/tea -> teaed
<sacater> Adri2000: okay,. then ill test it on my system
<sacater> Adri2000: you mean in tea.install right
<Adri2000> sacater: the icon is still at the same place, so no need to change, but relative path is better than absolute
<Adri2000> I'm talking of the .desktop file
<sistpoty> siretart, StevenK, crimsun: work for motu-sru: https://launchpad.net/bugs/57951
<Ubugtu> Malone bug 57951 in xchat "[SRU]  xchat crashes frequently on quit" [Medium,In progress]  
<siretart> wow: 17 dups
<sistpoty> huhu siretart btw. ;)
<ScottK> Just proves xchat users don't know how to search LP.
<sistpoty> lol
<siretart> hi sistpoty :)
* ScottK is not clear why people are so excited about a bug the causes a program to crash when you were trying to close it anyway.  Click the little X on the crash dialogue and you are exactly where you wanted to be...
<siretart> sistpoty: I'm a bit confused: how do gconf and dbus relate in that report?
<sistpoty> siretart: FWIW gconf isn't involved at all, only dbus.
<siretart> sistpoty: aah, and xchat uses dbus only for gconf integration?
<siretart> strange
<siretart> or is https://launchpad.net/ubuntu/+source/xchat/+bug/57951/comments/81 just confusing?
<Ubugtu> Malone bug 57951 in xchat "[SRU]  xchat crashes frequently on quit" [Medium,In progress]  
<sistpoty> siretart: yep... https://launchpad.net/ubuntu/+source/xchat/+bug/57951/comments/84
<siretart> aaaah. reading helps
<sacater> Adri2000: i just wondered, im doing the tea bug, how do i let people know that, so that other MOTUs dont try and to it as well
<siretart> approved
<sistpoty> siretart: btw. did you decide on LaserJock being a tiber admin yet?
<sacater> Adri2000: i just wondered, im doing the tea bug, how do i let people know that, so that other MOTUs dont try and to it as well
<LaserJock> sacater: saying so in here is a start :-)
<sistpoty> hi LaserJock
<LaserJock> hi sistpoty 
<LaserJock> hi MOTU Land!!
<sacater> NO ONE TOUCH #81456       MINE!!!! :P :P
<sacater> LaserJock: seriously, how is it done
<LaserJock> that looks pretty good
<LaserJock> sacater: you can put a comment on the bug saying you are working on it
<sacater> i may have done that....
<LaserJock> sacater: you can even assign it to yourself if you want to keep track of bugs you are working on
<sacater> LaserJock: can i do that as a simple mentoree
<sacater> im not full MOTU
<LaserJock> sure
<LaserJock> it just means you are responsible for the bug
<LaserJock> so don't just assign it to yourself and forget about it
<sacater> how do i assign it to myself, i cant see a big button saying it
<tsmithe> click on the affects line
<sacater> ah ty
<siretart> LaserJock: congrats to adminness ;)
<siretart> need to leave now, *wave*
<LaserJock> siretart: oh, thanks dude
<sacater> Adri2000: http://paste.ubuntu-nl.org/8113/
<sacater> Adri2000: tell me to god that is CORRECT!
<sacater> Adri2000: the desktop file now works also
<LaserJock> siretart: I promise I won't break anything ... to much ;-)
<cbx33> but LaserJock you're known for break......
* cbx33 shuts up
<cbx33> :p
<LaserJock> *cough*
* LaserJock sends cbx33 to the corner
* cbx33 puts his naughty hat on
<sacater> Adri2000: you here?
<LaserJock> MOTUs, we have 7 Unconfirmed u-u-s bugs left
<LaserJock> way to go!
<LaserJock> let's finish them off today
<sacater> LaserJock: you are pretty high up in the MOTU world right?
<LaserJock> well, I'm a MOTU and that's about it
<LaserJock> we don't have a lot of hierarchy other than we have a MOTU Council, which I am not a part of
<LaserJock> anyway, what do you need?
<sacater> LaserJock: dont suppose you would be willing to test my tea package
<sacater> with menu entry now :P
<LaserJock> sacater: have you created a debdiff?
<sacater> yes
<cbx33> LaserJock, just a MOTU....JUST A MOTU
<sacater> let me get the paste
<LaserJock> sacater: just attach it to the bug
<sacater> LaserJock: http://paste.ubuntu-nl.org/8113/
<sacater> oh ok
<sacater> one mo.,.,,
<LaserJock> actually, not yet
<LaserJock> I spotted a couple things, I'll save you an upload
<LaserJock> sacater: is this your first package?
<ajmitch> even the motu council isn't exactly 'high up' :)
<LaserJock> sure it is ;-)
<sacater> LaserJock: yes and no, its my first package that i know WORKS, my other was to so something with gnash, but i may have b0rked that, im gonna try again tomoz
<LaserJock> sacater: cool, well you're doing great
<sacater> LaserJock: heres the bug, and my debdiff is with it https://bugs.launchpad.net/ubuntu/+source/tea/+bug/81456
<Ubugtu> Malone bug 81456 in tea "No menu entry" [Undecided,Confirmed]  
<cbx33> hey ajmitch 
<LaserJock> sacater: ok, so first thing is the install file
<LaserJock> sacater: you've got debian/tea.desktop /usr/share/applications
<sacater> yes
<LaserJock> sacater: but you want to drop the first "/" so it becomes debian/tea.desktop usr/share/applications
<sacater> ok
<sacater> anything else?
<LaserJock> sacater: the package is really built in a tmp dir in debian/<packagename>
<LaserJock> sacater: so that path really becomes `pwd`/debian/tea/usr/share/applications
<sacater> LaserJock: ok, anything else ?? :P
<sacater> ouch
<LaserJock> you need to get rid of the config.sub stuff
<LaserJock> that's created by the clean rule autotools stuf
<ajmitch> hi cbx33 
<LaserJock> sacater: and easy way to get rid of it is to use filterdiff
<sacater> LaserJock: is there a command extension to disable that suring debuild
<LaserJock> sacater: if you have the patchutils package installed you can use filterdiff
<sacater> LaserJock: whats filterdiff?
<sacater> i have that yeah
<sacater> how do i use it
<sacater> command (extenstions)
<LaserJock> I think cat <debdiff> | filterdiff -x *config.sub  might work
<LaserJock> replacing <debdiff> with the file name of your debdiff
<sacater> ok
<sacater> one mo
<sacater> ill attach this debdiff to the bug as well
<LaserJock> hang on, there's more :-)
<LaserJock> does your new debdiff not have the config.sub part now?
<ajmitch> steak knives?
<LaserJock> 2 bug reports for the price of 1!
<LaserJock> and if you call now, we'll throw in a sync request ... absolutely free
<LaserJock> and wait! if you call within the next 5 min we'll send you a free gift
<sacater> LaserJock: hold on i havnt even run that yet
<LaserJock> "How to loose your insanity"
<sacater> *sacater calls LaserJock
<LaserJock> *sanity
<sacater> *Laserjock answears
<LaserJock> sacater: ok, let me know if the filterdiff works
<sacater> kk
<sacater> kk it worked
<LaserJock> ok, the last thing is the .desktop
<Spec> How do I delete a bzr branch that I've registered under launchpad/
<LaserJock> you don't
<LaserJock> you mark it obsolete or something
<sacater> LaserJock: whats wrong with the .desktop file
<Spec> 'Abandoned'?
<LaserJock> sacater: you don't need (and in fact it's better) to give an absolute path for the icon
<LaserJock> Spec: sounds good to me
<LaserJock> sacater: I also wonder about the Categories
<sacater> LaserJock: so youre basically telling me that all i did with building, filtering, debdiff was all a waste of time, and i should have done that
<sacater> LaserJock: look mate... its running fine on my system under accessories
<sacater> LaserJock: should Icon=/usr/share/pixmaps/tea.xpm appear as Icon=pixmaps/tea.xpm
<LaserJock> sacater: actually it should just be Icon=tea I think
<LaserJock> no need for .xpm even
<Spec> LaserJock: thanks
<LaserJock> sacater: it's just that all the editors I've got have  Categories=Application;Utility;TextEditor;
<LaserJock> not saying it has to be that, just that's the way I've seen it
<LaserJock> sacater: a final thing you can do is run desktop-file-validate tea.desktop
<LaserJock> here it complains about the Application category
<sacater> LaserJock: okay, but is it okay if i do add the .xpm bit
<sacater> LaserJock: just in case
<LaserJock> sacater: it's better not to
<sacater> if youre sure...
<LaserJock> sacater: if later on the icon is provided as a .png or something then the .desktop doesn't have to change
<sacater> LaserJock: okay let me rebuild and make you youre debdiff :P
<LaserJock> sacater: sorry for the trouble
<sacater> LaserJock: no problem, the whole point of me being here is to LEARN :P
<LaserJock> you're doing good
<sacater> :D
<sacater> just to conferm, when i did validate tea.desktop. it said that application was not valid, so i removed it and now its fine
<LaserJock> k
<cbx33> why is it that oodraw has no desktop entry
<sacater> LaserJock: building now....
<sacater> cant i just send you the debdiff, its so easier
<LaserJock> it's easier than attaching it to the bug?
<LaserJock> generally we like to keep things "in the open" so I prefer having the debdiff on Launchpad
<LaserJock> but whatever you want
<sacater> LaserJock: ok out in the open it is, 
<LaserJock> sacater: make sure to debdiff <oldpackage> <newpackage>
<sacater> LaserJock: i do :P
<sacater> LaserJock: can i do filter on the debdiff as in debdiff <old> <new> | filter
<LaserJock> yes
<LaserJock> your 2nd debdiff is reversed though
<LaserJock> and not actually a debdiff, but a copy of the shell out put ;-)
<giftnudel> why do I get access forbidden when trying to download a changes file from revu?
<LaserJock> because changes files have gpg signatures
<giftnudel> which means what?
<sacater> LaserJock: okay
<LaserJock> if a package was uploaded by a MOTU there somebody could grab the package+.changes and upload it themselves
<LaserJock> to Ubuntu
<LaserJock> it's safer if we don't show .changes
<sistpoty> giftnudel: .changes files are not part of a source package. they are only useful to determine if an upload is from you or not.
<sistpoty> giftnudel: think of them as a ticket
<giftnudel> ok, understood
<giftnudel> thanks a lot
<sistpoty> np
<ajmitch> sistpoty!
<sistpoty> hi ajmitch
<ajmitch> hey :)
<sistpoty> ah... I'm so evil :)
<sacater> LaserJock: im uploading the debdiff
<sistpoty> https://code.launchpad.net/~revu/+branch/tasks/ubuntu
<ajmitch> sistpoty: how evil?
<sistpoty> ajmitch: I've just done a rm -rf on the sftp-server
<ajmitch> ooh
* ajmitch has done that before
<ajmitch> with the smart server you won't be able to
<sistpoty> ajmitch: however you can still access the branch via http... let's see if I can trick lp into removing that as well
<ajmitch> when we initially pushed revu2 to lp, I stuffed it up & had to remove it :)
<sistpoty> yep, I remember ;)
<ajmitch> hehe
<sacater> LaserJock: https://bugs.launchpad.net/ubuntu/+source/tea/+bug/81456 i called it '3rd'
<Ubugtu> Malone bug 81456 in tea "No menu entry" [Undecided,Confirmed]  
<sacater> LaserJock: looked at it
<LaserJock> sacater: it's still going backwards
<sacater> oh
<sacater> i put the files in wrong order in debdiff right LaserJock
<sacater> LaserJock: 
<sacater> LaserJock: 
<LaserJock> sacater: what?
<sacater> [19:56]  i put the files in wrong order in debdiff right LaserJock
<LaserJock> oh sorry, didn't see the ? in that
<LaserJock> yes
<LaserJock> you did
<sacater> okay ill inverse them
<superm1> hey guys, a package that we normally pull from debian - but i have an ubuntu patch to add, i'm getting this:dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
<superm1>  What is the appropriate thing to do?
<bddebian> superm1: Change the maintainer
<bddebian> https://wiki.ubuntu.com/DebianMaintainerField
<superm1> k thx
<superm1> is there a large ubuntu-motu or such mailing list to set it to? i don't think i should put myself
<superm1> oh nvm
<superm1> i just saw it on the page
<LaserJock> :-)
* sistpoty is afk for dinner now
<sistpoty> later folks
* LaserJock wonders if dholbach really mean to link the ~revu branches to the tasks product
<sacater> LaserJock: https://bugs.launchpad.net/ubuntu/+source/tea/+bug/81456 look at the 4th one
<Ubugtu> Malone bug 81456 in tea "No menu entry" [Undecided,Confirmed]  
<sacater> LaserJock: :P
<LaserJock> sacater: so close
<LaserJock> we don't want /usr/share/pixmaps/ in Icon=
<LaserJock> sacater: I'll just fix that when I go to upload, ok?
<sacater> ok
<sacater> ok
<sacater> no
<tsmithe> anyone know when dholbach will be back?
<sacater> not okay
<sacater> LaserJock: ill do it
<tsmithe> and, erm, DON'T REVIEW *UBUNTUSTUDIO* on revu :)
<sacater> LaserJock: what do i want in icon :P
<LaserJock> Icon=tea
<LaserJock> tsmithe: what did you do?
<tsmithe> nothing!
<tsmithe> they're just erm, a bit broken, and i'm trying to fix
<LaserJock> sacater: and there's a sacater@neo:~/tea/compare$  at the bottom of the debdiff
<tsmithe> (*blames dholbach*)
<sacater> Laserjock, ill get rid of that to
<LaserJock> np, if you add a  > to the end of the debdiffing line it'll come out right
<LaserJock> so debdiff .... > debdiff.txt
<sacater> LaserJock: done! https://bugs.launchpad.net/ubuntu/+source/tea/+bug/81456
<Ubugtu> Malone bug 81456 in tea "No menu entry" [Wishlist,Confirmed]  
<sacater> number 5
<LaserJock> sacater: now that is a beautiful debdiff
<sacater> LaserJock: ALLIEHUYAH!!!!!
<sacater> LaserJock: right, now what, we upload my package to universe or something
<sacater> LaserJock: do you have jabber?
<LaserJock> sacater: sure do
<sacater> LaserJock: wanna trade addresses?
<LaserJock> launchpad.net/~laserjock has all my info
<sacater> LaserJock: in my channel of course
<sacater> oh ok
<LaserJock> it' my life in a webpage
<LaserJock> *it's
<sacater> LaserJock: so what happens to my package
<LaserJock> sacater: I apply the debdiff, look it over, test it, then upload
<sacater> LaserJock: so the .deb files on my PC are never useed
<LaserJock> sacater: nope, we do source-only uploads
<sacater> LaserJock: okies, i will get credit?
<LaserJock> sacater: yeah, I just gotta tweak something real quick
<sacater> LaserJock: okies, when will people be able to access it through universe repos
<LaserJock> well, kinda depends
<LaserJock> right now we are under the Herd5 freeze
<LaserJock> so Universe package have to be manually processed
<RainCT> Hi, how can I become a MOTU (yes, I know it's explained on wiki, but there are that much pages that I don't know what one I should look :p)?
<LaserJock> RainCT: you work and do MOTU work and after a while and you know what you are doing you can apply through the MOTU Council
<RainCT> LaserJock: yes read that but how do I get started? just do packages and submit to REVU?
<ajmitch> dholbach!!
<dholbach> hi ajmitch
<LaserJock> RainCT: depends on what you want to do
<LaserJock> RainCT: right now we aren't accepting brand new package for Feisty
<LaserJock> RainCT: we are focused on bug fixing
<RainCT> LaserJock: how can I do that (bug fixing)?
<LaserJock> RainCT: sorry, wiki.ubuntu.com/MOTU/TODO
<RainCT> LaserJock: or do I need programation knowledge for that? (I only know PHP)
<tsmithe> dholbach, aha!
<tsmithe> sorry to bug you
<tsmithe> but... :P
<tsmithe> "dpkg: error processing ubuntustudio-sounds_0.1_all.deb (--install):
<tsmithe>  trying to overwrite `/usr/share/sounds/info.wav', which is also in package ubuntu-sounds"
<dholbach> hi tsmithe
<dholbach> they need to conflicts
<tsmithe> ah ok :)
<dholbach> np
<tsmithe> also, there are a couple of issues with -theme
<tsmithe> we'd like the gtk-2.0/panel stuff to be installed, but when it is, the panel.png file causes issues.
<tsmithe> http://paste.ubuntu-nl.org/8122/ is the patch so far
<tsmithe> (also adds murrine as a dependency- is that correct?)
<pochu> do you guys know if I can setup an outgoing server for the @ubuntu account?
<LaserJock> dholbach: did you know that a tasks product exists in LP?
<dholbach> ?
<dholbach> I created it
<LaserJock> dholbach: so your example branches in ~revu link to a TODO manager ;-)
<dholbach> I know
<LaserJock> really?
<LaserJock> fine then
<dholbach> the package is 'tasks'
<ajmitch> :)
<dholbach> a 'todo manager'
<LaserJock> I just thought it was some funky LP think
<LaserJock> *thing
<RainCT> LaserJock: sorry have to go, thanks
* Toadstool waves
<Fujitsu> Hi Toadstool.
<Toadstool> hey Fujitsu 
<LaserJock> hi guys
<Fujitsu> Hi LaserJock, everyone else.
<Toadstool> be right be, need a whole load of coffee if I dont want to fall asleep on my keyboard (which is not a good idea at work...)
<Toadstool> hi LaserJock 
<Toadstool> *back
<tsmithe> dholbach, (apologies for nagging) - but do you have a suggestion? that patch leads to '/usr/share/themes/UbuntuStudio/gtk-2.0/gtkrc:212: Unable to locate image file in pixmap_path: "panel.png"' errors?
<pochu> or do I just get a redirection for the incoming mail? <- Adri2000 any idea?
<dholbach> tsmithe: no idea (for now), but I'm in a meeting currently
<tsmithe> ok thanks :)
<dholbach> tsmithe: if until later nobody answered or found it, ask me again
<tsmithe> what is "later"?
<tsmithe> (so i don't pester until then)
<Fujitsu> pochu: @ubuntu.com addresses are just incoming redirects.
<dholbach> an hour
<tsmithe> right ho
<tsmithe> danke
<pochu> Fujitsu: ok, ty :)
<ajmitch> dholbach: so we have our first candidate for the MC to handle
<dholbach> I know
<dholbach> very nice :)
<dholbach> and even without an announce
<Fujitsu> ajmitch: Good to see this happening :)
<dholbach> but luckily sistpoty will do it
<dholbach> it should get widespread attention
* ajmitch wanted to email the people who applied for ubuntu-dev, but will be away for the weekend
<dholbach> u-d-announce, fridge-devel, ...
<Fujitsu> Shouldn't motu be made moderated, not restricted?
<Fujitsu> (and shouldn't the descriptions be fixed up?)
<dholbach> restricted is fine too
<dholbach> people should only apply via the list
<dholbach> not via LP
<Fujitsu> Is that the process now? OK.
<dholbach> you always have to handle people who sign up for random teams
<Fujitsu> True.
<Fujitsu> Gah, stupid illegal instruction crashes on amd64 on Intel processors. What do we do about them?
<Toadstool> who's the first candidate if I may ask? :)
<ajmitch> and we'll pass names onto the TB anyway, who can add people to the team
* ajmitch hasn't had time to reply on the revu+bzr, but there are a few things I miss
<ajmitch> like being able to check over the .diff visually on the web, and browse files
<ajmitch> I know there'll be a bzr code browser soon
<dholbach> and we could automate that too
<dholbach> I think we should rather identify things that block "getting moving"
<dholbach> :-)
<ajmitch> yeah
<ajmitch> "confusion":
<Fujitsu> Anybody got an amd64 box with pbuilders that I can use or send stuff to (preferably with an Intel processor)?
* ajmitch only has a real amd64
<Toadstool> AMD64 with an Intel processor? weird :p
<GNUro> lo!
<GNUro> 'lo!
<LaserJock> Toadstool: you never know
<Fujitsu> Oh dear, I just heard an ABC newsreader use the word `photoshopped' in a news bulletin.
<psusi> I can't stand it when they said 'blog' or 'podcast'
<psusi> blog sounds like something you do in the bloody bathroom....
<ajmitch> they shoudl say "gimped"
<dholbach> tsmithe: sorry, I have no clue about how themes and their definitions work
<tsmithe> urgh - me neither
<dholbach> tsmithe: best to ask ubuntu-art@lists.ubuntu.com for help
<tsmithe> thanks :)
<dholbach> there are quite a bunch of people who wrote their own themes already
<tsmithe> fortunately i'm subscribed there
<dholbach> I'm sure somebody will answer
<tsmithe> thanks :)
<Fujitsu> Adobe's trademark policy explicitly forbids the use of it as a verb.
<tsmithe> i'll adobe you good Fujitsu 
<Fujitsu> I think that's OK. It's just Photoshop that is forbidden.
<Fujitsu> I was horrified when I heard it on the news... I didn't think the media would use a word like that.
<geser> Fujitsu: ask imbrandon if hood.ubuntuwire.com is ready
<Fujitsu> geser: I don't actually need one now. I've found a bug about the issue elsewhere, with a solution. Thanks for the suggestion, though.
<tsmithe> Fujitsu, @lart 37
<Fujitsu> tsmithe, #-offtopic is where that works.
<tsmithe> Fujitsu, but last time i checked you weren't there :P
<Fujitsu> This is true.
<tsmithe> :)
<tsmithe> hence my failure in -au :P
<Fujitsu> Gah, stupid unintelligent LP.
<Fujitsu> I created an Ubuntu Edgy task via email, but nooo, it had to put it under the Debian one.
<Fujitsu> Actually, I don't have the required permissions to add such a task. More bugs!
<tsmithe> poor Fujitsu 
<Fujitsu> Surely the email interface shouldn't be able to bypass the release management permissions?
<dholbach> night folks
<sacater> going offline now bye all
<Fujitsu> Night dholbach, sacater.
<sistpoty> re
<Fujitsu> Hi sistpoty.
<sistpoty> hi Fujitsu
<ajmitch> hi sistpoty 
<sistpoty> hi ajmitch
<sistpoty> Riddell, bddebian, geser, (crimsun): you've been sponsoring uploads for Lure, right? anything you'd like to say regarding his application for motu?
<Riddell> sistpoty: yes please, we want him
<sistpoty> Riddell: k, thx :)
<ajmitch> he was at UDS, wasn't he?
<sistpoty> no idea, /me wasn't
* ajmitch is sure he met Lure there
<Fujitsu> ajmitch: It seems he was there.
<sistpoty> ajmitch: what's your opinion?
<sistpoty> damn, it's tough to decide *g*
<ajmitch> sistpoty: I know he's done plenty of work, and I've seen a bit of it
<ajmitch> this is why we can do it by mail, rather than IRC :)
<sistpoty> hehe
<sistpoty> I guess I'm convinced for a +1 right now already
* ajmitch also, but it'd be good to get some discussion on the list
* LaserJock misses the grilling
<ajmitch> LaserJock: that nervous feeling, the sinking feeling in your stomach as you think they're about to decline?
<LaserJock> yep
<LaserJock> the off-the wall questions
<LaserJock> reminds me of my oral exam for PhD candidacy
<ajmitch> "what was keybuk's last hair colour?"
<sistpoty> LaserJock: have you read the application mail? any tough question you'd like to ask him? *g*
<ajmitch> (mdz grilling siretart for core-dev)
<bddebian> doh
<Fujitsu> ajmitch: I like that question.
<bddebian> Glad I ain't gonna try that again :-)
<sistpoty> hehe, I never tried for core-dev
<Fujitsu> What's the current policy with regards to bugs assigned to MOTU? Should we unassign if we're making other changes?
<sistpoty> Fujitsu: what do you mean with "other changes"?
<Adri2000> assign them to you :)
<LaserJock> sistpoty: where's the mail?
<Fujitsu> Like, I'm changing a bugs to Needs Info. Do we want bugs assigned to MOTU?
<sistpoty> LaserJock: https://lists.ubuntu.com/archives/motu-council/2007-March/000003.html
<ajmitch> sistpoty: you have to, then we'll have 5 core devs on MC :)
<sistpoty> ajmitch: I'd rather like to stay the one representing only humble motu's :P
<ajmitch> haha
* ajmitch is just a humble motu as well, so don't worry
<sistpoty> hehe
<bddebian> Later gang
<Fujitsu> Bye, bddebian.
<LaserJock> sistpoty: well, I'd personally ask him about some of the more social aspects
<LaserJock> how he feels about reviewing, mentoring, sponsoring
<LaserJock> what he adds to the "team"
<sistpoty> oh, that's a nice one :)
* ajmitch will be back later
#ubuntu-motu 2007-03-02
<tsmithe> g'night all
<sistpoty> gn8 tsmithe
<Adri2000> imbrandon: would it be possible to have feisty and debian deb-src on the build machines?
<wolfeon> well I dislike asking the same question on another channel, but I asked in the wrong channel :))
<wolfeon> cjwatson: this is free software though. Isn't the point of Ubuntu to make the distrobution the best user oritented there is? the author's rant is nothing but flame bait/a troll. 
<wolfeon> oops
<wolfeon>  I've a question about regulations and policies about software included in Ubuntu
<Fujitsu> wolfeon, what is the text of the rant?
<wolfeon> Shouldn't an author's personal rants be taken out of software when available to the user?
<wolfeon> xchm for instance, the guy goes on the "use gpl, anyone else is ignorant" spreee
<wolfeon> "If you'd like to use the code in your own stuff please figure GPL out first. Far too many people think GPL is bad out of utter ignorance.
<wolfeon> it is nice xchm was developed, but I use it all day. The rant, *and* start up text in the splash screen gets rather annoying
<Fujitsu> The author is entitled to his opinion, and I don't think removing (perfectly good) advice is worth carrying a delta from Debian.
<wolfeon> the author's copyright could go in the about box. It would be better if the start up content was blank
<Fujitsu> File a bug with upstream, perhaps?
<wolfeon> universe bugs are filed on launchpad too?
<Fujitsu> Correct.
<wolfeon> alright
<Fujitsu> Upstream is probably the best place to contact, however.
<wolfeon> I'll submit a patch as well
<wolfeon> I highly doubt the fellow will accept the patch
<wolfeon> I constantly patch my system programs against default content in programs in order for the programs to be more friendly at startup. They not only look more friendly, they look clean!
<wolfeon> 30 lines of copyright and rant is plain silly
<sistpoty> yay, I could rant sooo at rants *g*
<rmjb> Hey guys
<corevette> Hello mjb
<pochu> heya rmjb
<rmjb> a package i did has the dependencies wrong
* ajmitch rants about rants about rants
<ajmitch> rmjb: and you want to fix it?
<rmjb> so I just file a bug in launchpad, attach a deb diff and subscribe motu-sponsors?
<ajmitch> ubuntu-universe-sponsors
<rmjb> I'm fixing it, just getting the process
<rmjb> cool
<sistpoty> ajmitch: who is worse, someone who rants, or someone who rants about rants? ;)
<LaserJock> ajmitch: can I blog about bloggers who rant against ranters?
<sistpoty> lol
<ajmitch> go ahead
* rmjb head spins
<sistpoty> anyone wanting to review my anounce-ment mail about motu applications? http://paste.ubuntu-nl.org/8149/
<sistpoty> --
<sistpoty> arg... line 15 sounds bad
<sistpoty> LaserJock: btw.: now it's time to blog about it ;)
<ajmitch> heh
<ajmitch> sistpoty: you didn't tell them about the grilling they can expect? ;)
<sistpoty> ajmitch: that'll be a surprise ;)
<ajmitch> excellent...
* ajmitch needs to modify his procmail rules now
<sistpoty> kmail has a menu entry to set up a filter based on a mailing list. one of the very few occasions I really like to have a mouse around *G*
<Fujitsu> I hate KMail... Probably mostly because its IMAP support is terrible.
<wolfeon> Fujitsu: send patches
* ajmitch should probably move all the earlier MC discussions we had into that folder
<wolfeon> and no.. dpkg -r kmail is not a patch
<sistpoty> it's better than anything I've used in the past (netscape and erm... older kmail *g*)
* ajmitch tends not to use imap much
<ajmitch> except for work mail, with thunderbird
<sistpoty> back to topic... any corrections for the mail I'm about to send?
<ajmitch> CCing sponsors
<sistpoty> ah, right
<ajmitch> so that we get them into the discussion
<ajmitch> & can grill them
<sistpoty> hehe
<ajmitch> we should keep sponsors CCed
<ajmitch> hm, maybe, maybe not
<ajmitch> but CCing on the initial mail is required
<ajmitch> was the TB notified after our first meeting?
<sistpoty> not quite sure actually
<sistpoty> http://paste.ubuntu-nl.org/8152/
<wolfeon> hey, look at that. xchm without rants :))
<ajmitch> sistpoty: looks better
<sistpoty> ajmitch: yes, crimsun CC'd TB
<sistpoty> (for the minutes)
<sistpoty> ajmitch: ok, out it goes :)
<LaserJock> boy, I sure wish Ubuntu was rant-free :-)
<zul> said the king ;)
<zul> oh hey LaserJock 
<LaserJock> that was rather interesting
<rmjb> btw, while i'm fixing this dependency thing on my package, should I change the maintainer field?
<LaserJock> it's somewhat of a point to try to keep apps clean
<daviey> Hi, what web-space can i use for a launchpad registered product for ubuntu using bazaar?
<LaserJock> daviey: use bazaar.launchpad.net
<LaserJock> hi zul 
<daviey> LaserJock, makes sense eh. thanks
<pochu> anybody using dapper?
<rmjb> guess not
<sistpoty> pochu: got it installed on my laptop (needed to test a sru), but I don't actually use it ;)
<pochu> sistpoty: asac has a problem with a security update breaking some stuff in dapper ;)
<sistpoty> not quite sure if I can help... got a bug number?
<pochu> sistpoty: sure, are you in #ubuntu-bugs?
<bddebian> Heya gang
<ajmitch> hi
<tonyyarusso> hi
<rmjb> hey bddebian
<bddebian> Hi ajmitch, tonyyarusso, rmjb
<tonyyarusso> So, I started reading a C textbook last night.  Maybe I'll learn to understand a handful of code after all.
<bddebian> C syntax is fairly easy to pick up, it's putting it all together that gets tough :-(
<tonyyarusso> How so?
<LaserJock> bddebian: I agree
<LaserJock> I've read the books
<bddebian> tonyyarusso: Macros, linking, etc etc
<LaserJock> but it's very difficult to just open some code and start hacking away
<tonyyarusso> I can understand basic input/output stuff fine - I usually get lost when they try to do something actually useful :P
<LaserJock> I hear ya
<ajmitch> bddebian: pointers are fun!
<LaserJock> ugg
<bddebian> pointers aren't bad
<bddebian> pointers to functions with macros SUCK :-)
<ajmitch> heh
<tonyyarusso> pointers seem to be chapter 12 - I've done up through 4.
<sistpoty> c. a convenient way to write asm that's not CPU specific in most cases :)
<tonyyarusso> What do you folks have to say about editors/IDEs/etc?
<bddebian> hehe
<ajmitch> tonyyarusso: emacs > *
<LaserJock> emacs?
<sistpoty> tonyyarusso: vim :P
<tonyyarusso> ajmitch: It's also a two-day download.....
<theCore> tonyyarusso: don't open that can worm while I am here :)
<theCore> can of worm*
<ajmitch> sistpoty: shall we settle it outside? ;)
<tonyyarusso> sistpoty: that's what I've looked at so far, since it's pre-installed and small
<sistpoty> cage fight?
<bddebian> haha
<ajmitch> sistpoty: I'd prefer beers
<sistpoty> hehe
<tonyyarusso> I wanted to just intall a bunch and try them out, but emacs and eclipse are both friggin' HUGE
<ajmitch> first one under the table? ;)
<sistpoty> sure ;)
<bddebian> tonyyarusso: I've heard decent things about anjuta
<sistpoty> tonyyarusso: I've also used eclipse a little bit... if you like to use the mouse it's pretty neat
<sistpoty> tonyyarusso: and eric is nice for python
<theCore> tonyyarusso: really, choosing an editor is just a matter of taste and what you intend doing
<tonyyarusso> bddebian: also huge
<bddebian> all ya need is nano ;-P
<tonyyarusso> Okay, why are all of these apt-get sizes measured in MBs?  I can't just download MBs worth willy nilly here.
<tonyyarusso> KB much preferred.
<bddebian> vi?
<ajmitch> because you want something useful
<Fujitsu> vim > *
<tonyyarusso> bddebian: That's what I've been using for lots of stuff.  Probably will stick with a combo of vim and nano for now...
<Adri2000> vim > *, emacs > /dev/null
<Adri2000> (actually I've never used emacs, but vim is cool :))
<LaserJock> you've never used emacs?!?
<LaserJock> you gotta at least try it
<bddebian> Noooo
<bddebian> You
<theCore> (defun religious-sacrifice () (interactive) (mapc (lambda (x) (shell-command (concat "rm " x)) (message "All hail emacs!!!")) (cdr (split-string (shell-command-to-string "whereis vi")))))
<bddebian> 'll be scarred forever
<sistpoty> Adri2000: resist the temptation ;)
<LaserJock> I use both quite often
<sistpoty> haha theCore
<LaserJock> it's good to at least be familiar with both so if you're stuck somewhere with only one or the other it's ok
<Fujitsu> theCore: With so many parentheses, that's got to be Lisp.
<theCore> Fujitsu: of course, it is Lisp
<Fujitsu> Urgh.
<theCore> (I like programming with an Abstract Syntax Tree :-)
<sistpoty> well, I know already ~5% of vim's features, I don't want to learn that many stuff for emacs again :)
<ajmitch> sistpoty: 5% of emacs' features is the whole editor ;)
<sistpoty> hehe
<bddebian> emacs == kitchen sink
<theCore_> see I can even do IRC with Emacs :P
<ajmitch> and we love it
<RAOF> Is it worth trying to fix the compiz-extra package, which FTBFS?  It should be fairly easy to file a bug with a debdiff that fixes it.
<ajmitch> it's an editor for real hackers
<theCore_> (ok, back to work...)
<ajmitch> RAOF: sure, why not?
<sistpoty> which operating system do you use? (O) ubuntu dapper (O) ubuntu edgy (O) ubuntu feisty (O) emacs
<RAOF> ajmitch: Well, because no-one seems to have done it, and it's been FTBFS for ages.  I was just wondering whether there was a reason no-one had done it.
<bddebian> There's a compiz-extra on REVU, is that different?
<RAOF> Yes.
* Fujitsu looks with despair at the (almost) 5k MOTU bugs.
<bddebian> Fujitsu: Bah, YOU can handle it :)
<RAOF> seb uploaded a compiz-extra package, which wasn't quite the one on REVU.  That one can probably be archived, though.
<ajmitch> Fujitsu: that's fairly low, actually
<Fujitsu> ajmitch: Compared to what?
<ajmitch> Fujitsu: if you include all the bugs against no package
<bddebian> Fujitsu: Compared to ajmitch's mad sk1llz
<ajmitch> so helpful
<bddebian> that's me :)
<AstralJava> Hey guys, anyone ever stumbled across the following error message while pbuildering?
<AstralJava> Merging translations into build/share/themes/UbuntuStudio/index.theme.
<AstralJava> syntax error at line 1, column 0, byte 0 at /usr/lib/perl5/XML/Parser.pm line 187
* sistpoty is off to bed now
<sistpoty> gn8 everyone
<bddebian> Hmm RL work or break something in Ubuntu..
<nixternal> boo
<nixternal> hahah
<nixternal> speak of the devil LaserJock ^^
<bddebian> Heya nixternal
<nixternal> bddebian: I say boo all the time now, and someone asked if that is my way of saying hi in #ubuntu-docs
<bddebian> hehe
<nixternal> I GOT IT FROM THAT STINKING BDDEBIAN GUY
<nixternal> muhehe
<bddebian> Glad I'm having some impact ;-P
<nixternal> true
<nixternal> man, the FSF put up a pretty decent article on hardware free from restrictions
<bddebian> Is 0.10.10 to 0.10.11 of a native package considered a new upstream version?
<crimsun> not really, since it's native :-)
<bddebian> That was my thought but wanted to make sure
<crimsun> it's a new version; run it past the LP motu-uvf team if you're unsure
<bddebian> Gah
<crimsun> I can give you a short opinion if you'll say which source package
<bddebian> module-assistant
<bddebian> I was gonna look at the u-u-s bug for it but Debian has a newer version also
<crimsun> that's essentially a bug fix
<bddebian> Aye
<crimsun> file a UVF exception request, let me know the bug # , and I'll ACK it
<bddebian> Gah, what a PITA :-)
<crimsun> [it's pretty much a no-brainer ACK] 
<ajmitch> if it really needs 2 ACKs, you can always buy me beer
<bddebian> Damn, of course his diff doesn't apply against 0.10.11
<ajmitch> hello Hobbsee 
<Hobbsee> hey ajmitch 
<ajmitch> excellent, samba 3.0.25pre1
<Hobbsee> ajmitch: gotten all the u-u-s done yet?
<ajmitch> no, I'm leaving that up to you while I go away for the weekend
<ajmitch> I delegate
<bddebian> We need a way to keep the (Debian) bugs from showing up, it's damn irritating :)
<Hobbsee> hah
<Hobbsee> bddebian: yes, exactly :)
<bddebian> crimsun: Is this even worth filing?
<ajmitch> or you can just upload
<ajmitch> since you've got 2 ACKs on irc
<crimsun> bddebian: right, what ajmitch stated
* ajmitch is happy to see that his dapper setup at linode just got its resources (RAM/diskspace) doubled for free
<bddebian> But it would be a straight sync without the patch on LP that doesn't apply against 0.10.11
<ajmitch> bddebian: that's fine
<ajmitch> hello LaserJock 
<LaserJock> hi ajmitch 
* bddebian is confused
<bddebian> Heya LaserJock
<ajmitch> bddebian: why?
<ajmitch> bddebian: you know how to file sync requests
<theCore> how much time does it take for a package to be published, after it been uploaded to the archive?
<LaserJock> might take a while
<LaserJock> we have Herd5 freeze at the moment
<bddebian> Gah, forget this stupid package
<theCore> ah ok, thanks LaserJock 
<theCore> btw, LaserJock are you still using my Emacs package?
<Hobbsee> theCore: is it a new package?
<theCore> Hobbsee: new? Emacs or for the publishing thing?
<Hobbsee> [14:17]  <theCore> how much time does it take for a package to be published, after it been uploaded to the archive?
<theCore> Hobbsee: yeah, I was looking at supertux-stable
<Hobbsee> theCore: so probably the publishing thing.  that'll have to go thru NEW
<Hobbsee> so, ages
<Hobbsee> https://beta.launchpad.net/ubuntu/+bug/89110
<Ubugtu> Malone bug 89110 in Ubuntu "Too Many Unresolved Bugs" [Undecided,Unconfirmed]  
<theCore> Hobbsee: at least, it is on Launchpad...
<bddebian> Gah Dapper->Edgy->Feisty ought to be "fun" on this slow-arse laptop :-(
<Hobbsee> theCore: true.  an archive admin will have to accept it though, which is the long part
<bddebian> Hobbsee: Nice bug :-)
<ajmitch> Hobbsee: that's a useful bug
<Hobbsee> oh yes.
<Hobbsee> does someone want to reject that?
<theCore> "This site is accessible by launchpad admins and members of the Launchpad Beta Testers  team only." sigh...
<ajmitch> Hobbsee: do you need to take a step back from the keyboard before replying?
<Hobbsee> ajmitch: no, dont think so.  might just tell him about the bug squad, and to feel free to help out, rather than whinging about it.
<ajmitch> Hobbsee: I certainly don't think I could be diplomatic in replying :)
* Hobbsee checks what other bugs he's reporte
<Hobbsee> d
<Hobbsee> bddebian: got dapper's evolution on there now?
<theCore> I think LaserJock should reply. He is the king of diplomacy :)
<bddebian> heh
<ajmitch> Hobbsee: asac would love to have people reproduce & get some info about the evolution issue
<bddebian> Hobbsee: I'm just installing Dapper now, why do you need something?
<Hobbsee> bddebian: https://bugs.beta.launchpad.net/ubuntu/+source/evolution/+bug/89106
<Ubugtu> Malone bug 89106 in evolution "camel-WARNING **: Failed to initialize NSS" [Undecided,Unconfirmed]  
<Hobbsee> ajmitch: true
<ajmitch> Hobbsee: reassign it to evolution & mark it as duplicate, please :)
<Hobbsee> dupe of which bug?  (if you have it offhand)
<LaserJock> theCore: yes, I do use your emacs packages
<ajmitch> bug 88990
<Ubugtu> Malone bug 88990 in firefox "evolution breaks with libnss update" [High,Confirmed]  https://launchpad.net/bugs/88990
<ajmitch> just had to scroll through u-bugs logs to find the conversation from earlier
<ScottK> You mean breaking Evolution isn't a feature (says the Kubuntu user)?
<Hobbsee> ScottK: *grin*
<ajmitch> I don't know, I use mutt :)
<Hobbsee> ajmitch: i'm not sure i was there early enough
<ajmitch> oh well, as long as someone's sorting through the new bugs as they come in
<bddebian> What can I add to that bug?
* ajmitch shrugs :)
<Hobbsee> there.
* ajmitch is going to head away for a couple of days now
<ajmitch> I'll see you on sunday evening
<Hobbsee> https://beta.launchpad.net/ubuntu/+bug/89110
<Ubugtu> Malone bug 89110 in Ubuntu "Too Many Unresolved Bugs" [Undecided,Rejected]  
<Hobbsee> bye ajmitch!
<bddebian> Later ajmitch
<LaserJock> ajmitch: I think that bug should go to our special channel ;-)
<LaserJock> ajmitch: cya
<jdong> bug 89110
<Ubugtu> Malone bug 89110 in Ubuntu "Too Many Unresolved Bugs" [Undecided,Rejected]  https://launchpad.net/bugs/89110
<bddebian> Heh, I just got an e-mail asking for svk 2.0 for Edgy..
<bddebian> I don't even think I could get it in Feisty at this point.. :-)
<jdong> bddebian: ugh svk is not fun to maintain in general :D
<imbrandon> Adri2000, just use dget to get feisty and debian source packages
<imbrandon> e.g. dget http://url.to/myfav.dsc
<imbrandon> and it will get the package just aliek apt-get source
<imbrandon> like*
<LaserJock> imbrandon: we need a dget-LP
<imbrandon> LaserJock, dget-LP ?
<imbrandon> ahh yea dget dosent seem to work on lp huh
<imbrandon> that sucks
<imbrandon> i'm sure a small python package would fix it up
<imbrandon> err python script
<imbrandon> wth is with librarian sticking them in diffrent direwctorys for
<imbrandon> thats silly
<LaserJock> imbrandon: it's called an LP "feature"
<LaserJock> :-)
<LaserJock> imbrandon: I've asked about it before
<LaserJock> maybe we can get some sort of file or something that would allow us to script it better
<tbf> ftp://revu.tauware.de/incoming/rejected/vala_0.0.6-0ubuntu1_source.changes <- what have I done wrong?
<tbf> ...didn't get any notification regarding the move
* tbf jumps arround
<tbf> HELLO. HUHU. CONTRIBUTOR HERE.
<LaserJock> tbf: hi, just a sec
<tbf> LaserJock: thanks.
<imbrandon> tbf, also calm down , not all of us are at the keyboard all the time
<imbrandon> some of us are busy while still on irc ;)
<tbf> imbrandon: I am calm. just tried to get some attention. you know: those dirty tricks.
<LaserJock> tbf: well, I'm not sure exactly why it was rejected but it could be because your package is for edgy
<LaserJock> tbf: it should be at least feisty
<tbf> LaserJock: ok, that's easy to fix.
<LaserJock> tbf: I'll clean out the rejected package so you can try again
<tbf> LaserJock: thanks
<tbf> LaserJock: ok, uploaded again. also realized that lintian complained about debhelper and cdbs not being mentioned as build dependency - fixed.
<tbf> hope this time the package is fine.
<dholbach> good morning
<tsmithe> hiya dholbach 
<imbrandon> moins dholbach 
<dholbach> hiya tsmithe
<tsmithe> hi Lure  -  good luck on the motu application
<dholbach> hey imbrandon
* tsmithe waves at imbrandon
<imbrandon> lo tsmithe 
<Lure> tsmithe: thanks - just seen e-mail I need to reply... ;-)
<tsmithe> :)
<Hobbsee> heya dholbach 
<Hobbsee> Lure's going for MOTU?  yay!
* tsmithe waves also at Hobbsee 
<Hobbsee> hey tsmithe 
<dholbach> hey Hobbsee
<Lure> Hobbsee: yep, you can cheer for me ;-) - https://lists.ubuntu.com/archives/motu-council/2007-March/000003.html
<LaserJock> hi dholbach 
<LaserJock> tbf: did it work?
<dholbach> hi LaserJock
<tbf> LaserJock: package shows up on http://revu.tauware.de/ now
<LaserJock> tbf: awesome
<tbf> LaserJock: groovy
<tbf> lets see if that great tool makes it into universe
<cbx33> hi all....I'm just starting to code in C  
<cbx33> can anyone help me....what do i need to put for an include to get the gtk libs
<cbx33> and then what do i need to use on the gcc L thing.....I've managed to get the opengl libs fine
<cbx33> but can't figure out how to do the gtk ones
<cbx33> if comeone knows a simple gtk C   app i can use as a reference that'd be cool too
<cbx33> don;t worry...
<cbx33> got it
<geser> cbx33: you could probably use pkgconfig to get the include and linker flags for gcc
<cbx33> yeh i got that 
<cbx33> thanks geser
<cbx33> I found it on a tutorial somewhere
<jekil> hi
<gpocentek> hello
<AstralJava> dholbach: ping?
<dholbach> AstralJava: pong
<AstralJava> Hi, we're wrapping your bzr branches into .debs, and ran into trouble.
<dholbach> aha=
<AstralJava> Two things, metacity-theme-1.xml and index.theme don't get generated.
<AstralJava> I fixed, or think I did, the metacity thingie, I'll post a link to a diff in a second.
<dholbach> where's your branch?
<AstralJava> I haven't pushed them yet.
<dholbach> if you have, let me know and I'll take a look
<AstralJava> Wanna take a look at the diff now?
<AstralJava> http://paste.ubuntu-nl.org/8192/
<AstralJava> Okay I'll setup my branch next.
<dholbach> it's much easier to work only with bzr
<dholbach> but your patch looks good
<dholbach> just apply it to your branch
<AstralJava> Ahh.. haven't used another branch to create mine, how should I approach it? bzr init?
<dholbach> bzr branch dholbachs-local-ustudio-branch my-ustudio-branch
<dholbach> done
<dholbach> :)
<AstralJava> Okay thanks! :)
<dholbach> cd my-ustudio-branch; ... do changes ...; bzr commit -m "<message>"; bzr push sftp://<LaunchpadID>@bazaar.launchpad.net/~<team ID>/<product>/<branchname>
<dholbach> sftp://astraljava@bazaar.launchpad.net/ubuntustudio-developers/ubuntustudio-look/ubuntu  --   for example
<dholbach> if you do    bzr push --remember <...>    you only have to type the branch url once
<AstralJava> dholbach: What's this? http://paste.ubuntu-nl.org/8203/
<jekil> hi
<dholbach> ubuntustudio-developers   ->  ~ubuntustudio-dev
<dholbach> AstralJava: ^
<AstralJava> Oh crap, sorry about that. 
<dholbach> np
<AstralJava> I don't know where my eyes are today. :)
<AstralJava> It also needed a tilde (~) in front of the team name. _That_ I did catch?! Weird. :)
<AstralJava> Alright my branch is up now.
<AstralJava> But it's only got that patch applied.
<AstralJava> So we'd need to figure out why index.theme doesn't get generated.
<dholbach> AstralJava: i'll check in a bit
<AstralJava> Thanks a bunch! Here's an error I snatched from pbuilder output: 
<AstralJava> Merging translations into build/share/themes/UbuntuStudio/index.theme.
<AstralJava> syntax error at line 1, column 0, byte 0 at /usr/lib/perl5/XML/Parser.pm line 187
<AnAnt> Hello
<AnAnt> who is Andrew Mitchell ?
* elkbuntu tells ajmitch to run
* AnAnt looks @ ajmitch
* elkbuntu whistles innocently
<cbx33> hehehe
<elkbuntu> he hates me already, no love lost :
<cbx33> that was evil elkbuntu 
<AnAnt> a => andrew? mitch -> Mitchel
<AnAnt> hmmmmm
<AnAnt> ajmitch: ping !
<AnAnt> ajmitch: about that sync. request #84857 , what is the "proper info. for sync request" that is still needed
<elkbuntu> AnAnt, be aware it is 00:33 ajmitch time, so he might be asleep or heavens forbid, socialising
<cbx33> elkbuntu: what is socialising
* cbx33 hasn't heard of that before
<Hobbsee> AnAnt: he's not here.
<elkbuntu> cbx33, meh, i dont know, it's something i heard from someone who wasnt behind a computer screen
<highvoltage> the only place I've ever heard about socialising was behind my computer screen
<stgraber> elkbuntu: you know someone who isn't behind a computer screen ?
<highvoltage> (possibly because I'm rarely not behind a computer)
<elkbuntu> i still live at home. my parents use the word in a complaining tone to me reguarly
<cbx33> Can't find Qt library. No QTDIR set.
<cbx33> ?
<cbx33> I'm trying to copmile an app
<cbx33> any takers?
<Hobbsee> kdelibs4-dev as a build dep
<Hobbsee> iirc
<cbx33> thanks
<cbx33> you rock Hobbsee 
<Hobbsee> :)
<Hobbsee> cbx33: i dont think so, look at -devel
<cbx33> I'm not in there
<Hobbsee> #ubuntu-devel?
<cbx33> yeh just joined
* Hobbsee just attempted to fix 4 packages, didnt test build them all, and two failed for a totally different reason, which I would have known had i checked the damn buildlogs.
<cbx33> no you're right....I already hve that
<cbx33> :( - awww
<cbx33> well if I'd have done it I'd have broken all of them
<Hobbsee> heh
<cbx33> any other ideas?
* Hobbsee has seen the error lots before, so can quickly fix it
<Hobbsee> if it's not kdelibs4-dev, grab kdebase4-dev
<cbx33> thanks
<cbx33> already have it
<cbx33> :(
<Hobbsee> cbx33: what are you compiling?
<cbx33> pdfedit
<cbx33> from sourceforge
<cbx33> http://en.wikipedia.org/wiki/PDFedit
<Fujitsu> Shouldn't it be libqt-dev?
<cbx33> E: Package libqt-dev has no installation candidate
<cbx33> :(
<Hobbsee> bah.  i'm doubly wrong.
<Fujitsu> libqt3-dev, perhaps
* Fujitsu checks.
<Hobbsee> libqt4-dev - Qt 4 development files
<Hobbsee> libqt4-dev | 4.2.2-0ubuntu3 | http://mirror.pacific.net.au feisty/main Packages
<Hobbsee> libqt4-dev | 4.2.2-0ubuntu3 | http://archive.ubuntu.com feisty/main Packages
<Hobbsee>    qt4-x11 | 4.2.2-0ubuntu3 | http://mirror.pacific.net.au feisty/main Sources
<Hobbsee>    qt4-x11 | 4.2.2-0ubuntu3 | http://archive.ubuntu.com feisty/main Sources
<Fujitsu> That's for Qt 4, if that's what you want.
<Hobbsee> cbx33: no, it's there.
<cbx33> instlaling
* Hobbsee tries to remember where the qtdir is
<cbx33> Hobbsee: any luck?
<Hobbsee> cbx33: appears to just be /usr
<Hobbsee>     * Edit the top of kdesvn-buildrc-sample to match the settings of your system (instructions are in the file itself and the online docs). Be sure to have the qtdir and kdedir lines set to the output of `dirname $(dirname $(which uic))` and `kde-config --prefix` respectively (if you plan on using your current Qt and KDE installs). For instance, on Gentoo it might be /usr/qt/3 and /usr/kde/3.5. 
<StevenK> /bin/bash ./config.status --recheck
<StevenK> running /bin/bash /tmp/buildd/kat-0.6.3/./configure  --build=x86_64-linux-gnu ...
<StevenK> Fun
<cbx33> ARGH
<cbx33>  /bin/sh: /usr/include/qt3/bin/qmake: not found
<cbx33> it's looking for qmake in different places
<geser> cbx33: does your app needs qt4 or qt3?
<cbx33> qt3
<geser> try libqt3-mt-dev
<cbx33> already got it
* cbx33 is getting close to giving up
<cbx33> hehe
<cbx33> thanks for the help earlier geser
<cbx33> now I just need to learn how to code in C  
<cbx33> now I just need to learn how to code in C  
<cbx33> 
<cbx33> is anyone seeing plus signs ?
<elkbuntu> not i
<cbx33> hmmm
<Hobbsee> no
<Hobbsee> you're just going crazy :P
<cbx33> cgi irc....won't send plus signs
<geser> Adri2000: are going to merge jabber again?
<fernando> hey all
<Adri2000> geser: there is a new jabber?
<geser> yes, http://packages.qa.debian.org/j/jabber/news/20070302T114703Z.html
<AstralJava> dholbach_: Are you available this evening? I'm afraid I'll have to leave for some 8 hours or so...
<zul> grrr...canadian weather sucks..
<Adri2000> geser: you can merge jabber
<geser> will do
<dholbach> AstralJava: in 8h i'll be out - it will be 23:00 and I'll be in a club
<lizardking> Hello there
<lizardking> I have some questions
<lizardking> I'm still on time to put my theme in Universe ( is not a theme for the main artowork, but some like Blubuntu)? 
<cbx33> dholbach: that sounds like one of those social lives that elkbuntu was takling about
<lizardking> Should I put in the REVU procedure?
<lizardking> dholbach: hi
<dholbach> hi lizardking
<lizardking> dholbach:  I was asking about OranSun...
<dholbach> I thought so :)
<lizardking> dholbach: Next, ask the REVU admins in #ubuntu-motu
<lizardking> Is there some motu admins? ;)
<dholbach> \sh and siretart probably
<imbrandon> motu admin or revu admin ?
<dholbach> revu
<imbrandon> i can sync it , one sec
<dholbach> super, thanks imbrandon
<imbrandon> np
<lizardking> imbrandon: very very thanks
<imbrandon> lizardking, np, i'm going afk , key syncing now, it takes about ~10 minutes to finish
<imbrandon> give it ~10 minutes and try it, should be golden
<imbrandon> ;)
<lizardking> imbrandon: ok
<lizardking> dholbach: So after 10 min Can I upload the package? Should I do some more?
<dholbach> lizardking: if the document says that, then yes
<lizardking> dholbach: but I have to do something special for NewPackagesFreezeUniverse exceptions or not?
<dholbach> lizardking: get it reviewed
<dholbach> lizardking: then file a bug for that exception
<lizardking> dholbach: ok I understand. Big thanks
<dholbach> ok
<AnAnt> ajmitch: ping
<pochu> hi folks! I have a question: the debian tracker fixes some bugs which are in ubuntu, so I should request a sync. However, they have included a patch for for mips, hppa and m68k archs, so what should I do?
<pochu> the patch is to fix a FTBFS in those archs
<lionel> pochu: yes, request a sync. Keeping the gap between Ubuntu and Debian is the best way to do that
<pochu> lionel: but I say it because we don't have those archs. Is there any problem with it, or do I simply request a sync?
<lionel> I suppose their patch do not cause FTBFS on the others archs
<lionel> so including them in Ubuntu is fine
<lionel> even if we do not have those archs
<pochu> lionel: ok, ty :)
<pochu> Bug #89226 <--- if somebody can review a sync request :)
<Ubugtu> Malone bug 89226 in tracker "Please sync tracker 0.5.4-4 from debian unstable main" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89226
<bddebian> Heya gang
<lionel> Hi bddebian
<\sh> dholbach: I don't have any revu admin powers anymore...(last time I checked)
<\sh> pochu: you need an UVF exception report
<dholbach> \sh: alrighty
<pochu> \sh: it's not a new upstream version, just some changes in the same version
<jdong> dholbach: can you pretty please spare some time to look at xserver-xgl's uvfe?
<jdong> please?
<jdong> while true; do echo please; done
<dholbach> jdong: the team consists of 5 people
<dholbach> i'm quite busy atm - pretty please ask somebody else
<Adri2000> pochu: you need the debian changelog entries
<pochu> Adri2000: oh, one moment
<jdong> silly dholbach, thinking I haven't annoyed the crap out of the 4 others :D
<bddebian> Hello lionel
<pochu> Adri2000: done :)
<geser> pochu: you should include the Debian changelog entries for 0.5.4-2 to 0.5.4-4
<pochu> geser: done ;)
<pochu> hehe
<geser> what was changed in Ubuntu?
<jdong> geser: the theme is all blue now!
<jdong> lol
<pochu> geser: nothing, I uploaded it to the repos
<jdong> :)
<jdong> that's my pitched idea for the next April Fools prank.
<geser> pochu: ACKed
<pochu> ack?
<bddebian> acknowledged
<pochu> ty :)
<jdong> poor pochu....
<pochu> hehe
<pochu> btw I know some others :)
<jdong> us using all these TLA's
<pochu> wtf ;)
<pochu> ty anyway :D
<pochu> jdong: tla?
<pochu> :)
<jdong> three letter acronym.
<pochu> jdong: wow
<pochu> even for that xD
<jdong> world of warcraft.
<pochu> and what about jdong?
<pochu> what does that mean? :P
<geser> pochu: some used acronyms are listed at https://wiki.ubuntu.com/Acronyms
<jdong> geser: lol you're supposed to use w.u.c/A
<jdong> :)
<pochu> lol
<pochu> I didn't know what meant sabdlf
<pochu> s/meant/mean/
<jdong> no ubotu... come back
<jdong> grr
<pochu> bof?
<jdong> and I was just gonna collide nicks with it
<jdong> Big Open Forum
<pochu> jdong: oh, you're wrong :P
<pochu> Birds of a Feather
<pochu> ?
<jdong> pochu: no, I'm right. the other is just a eulogy for it.
<jdong> euphemism
<pochu> hehe
<pochu> ok :)
<pochu> jdong: and wtf is Big Open Forum?
<pochu> ubuntuforums.org?
<jdong> no, that's a Gigantic Open Forum
<jdong> actually Closed if you talk to VBulletin critics :)
<jdong> or people who hate our administration policy :D
<pochu> :)
<pochu> well, I think I know now everything about ubuntu tla, WDYT?
<jdong> LOL GTK LRM KVM OMG GL HF GG NR20 TVB NO ZERG
<bddebian> STFU BFD
<pochu> laugh out loud? gtk-gnome? lrm-kernel? kernel volume manager, oh my god, good luck, have fun, good game, nr20?, tvb?, no-not?, zerg?
* pochu has a lot to learn :)
<pochu> English is more difficult than python :)
<Toadstool> good morning everybody!
<x-spec-t> 'mornin
<bddebian> Heya Toadstool
<sacater> how do i make a team on launchpad
<sacater> or find an existing one
<Toadstool> hi bddebian!
<keescook> mornin'
<bddebian> Heya keescook
<keescook> hi bddebian!
<geser> fabo: about bug #85120: which version should be synced?
<Ubugtu> Malone bug 85120 in kscope "please sync kscope [universe]  from Debian unstable [main] " [Undecided,Confirmed]  https://launchpad.net/bugs/85120
* ryanakca has a dual core CPU... any way to make pbuilder use only one CPU?
<Toadstool> hmm... interesting :p
* mode/#ubuntu-motu [+o Riddell]  by ChanServ
* mode/#ubuntu-motu [+o Toadstool]  by Riddell
<Riddell> feel free to kickban him Toadstool 
* mode/#ubuntu-motu [+b *!*n=ryan@ubuntu/member/ryanakca]  by Toadstool
* ryanakca_ was kicked off #ubuntu-motu by Toadstool (Excess flood 'cause of excess flood)
* mode/#ubuntu-motu [-o torkel]  by Toadstool
* mode/#ubuntu-motu [-o Toadstool]  by Toadstool
<Toadstool> Riddell: thanks :)
<Seveas> Riddell, please unban again, he stopped
* mode/#ubuntu-motu [+o Toadstool]  by Riddell
<Riddell> go Toadstool 
* mode/#ubuntu-motu [+o Seveas]  by Riddell
<Riddell> or you can do it
* mode/#ubuntu-motu [-b *!*n=ryan@ubuntu/member/ryanakca]  by Toadstool
* mode/#ubuntu-motu [-o Toadstool]  by Toadstool
<kdefreak> Probably answer before my power/connection went haywire and konversation's autowho went bezerk, but, how would I make pbuilder use only 1 of my cpus?
<lizardking> Hi imbrandon
<lizardking> I uploaded oransun package in REVU, but I got a mail "Rejected:
<lizardking> Signer has no upload rights at all to this distribution."
<tonyyarusso> lizardking: You probably forgot to specify to use revu, so it tried to go to the Ubuntu repos instead.
<geser> lizardking: then you uploaded to Ubuntu and not revu
<lizardking> ops
<lizardking> :|
<tsmithe> edit /etc/dput.cf to switch the default
<lizardking> default_host_main = revu
<tsmithe> :S
<lizardking> Where I should put this?  default_host_main = revu. Before or after [DEFAULT] 
<lizardking> login = username
<lizardking>  ....
<lizardking> dput revu oransun-look_0.2-0ubuntu1_source.changes 
<lizardking> I thinks this works
<lizardking> I finally uploaded the code. http://revu.tauware.de/details.py?upid=4545
<lizardking> Someone can help me to do this procedure? https://wiki.ubuntu.com/FreezeExceptionProcess#head-3545adef94d4dc79d5392ddb1f51b9ac30ab0861
<jeff_> hello, I see that specto has been uploaded nearly a month ago and was accepted (http://revu.tauware.de/details.py?upid=4323), but it's still not in universe
<jeff_> what's up with that ?_?
<stgraber> according to lauchpad it was compiled this afternoon
<stgraber> https://launchpad.net/+builds/+build/305437
<stgraber> jeff_: Give it the time to be uploaded on the mirrors :)
<jeff_> stgraber: o_O thanks
<tsmithe> imbrandon, tell jdong about your 100MiB/s connection, please... he's boasting in another channel
<tsmithe> and with that, i'm going to sleep
<jdong> pfft
<jdong> I'm not comparing connection penises with a guy at a hosting company.
<crimsun> oh yeah? Well I'm sure my mobile's data transfer rate bests you all.
<tsmithe> poor crimsun 
<jdong> crimsun: oh lolz you have 3gz?
<tonyyarusso> Dialup ftw?
<jdong> crimsun: guess what you can do to bug 87687?
<crimsun> I think this phone pushes 1.1 KB/s on a good day
<Ubugtu> Malone bug 87687 in xserver-xgl "New git snapshot required for xorg 7.2/feisty" [Medium,Unconfirmed]  https://launchpad.net/bugs/87687
<crimsun> jdong: I err, have a Beta blocker that's slightly higher priority, and I've just begun to dig into it?
<jdong> siretart?
<tsmithe> crimsun, hahaha
<tsmithe> night all
<LaserJock> wahoo, library day!
<Riddell> LaserJock: what's that?
<LaserJock> I stopped by the library after lunch
<LaserJock> picked up wxPython in action, beginning PHP5, and a nifty new "How to actually use C++" book
* LaserJock is totally a book nerd
<Burgundavia> LaserJock: you got that rsync script?'
<theCore> LaserJock: and you call yourself a book nerd ... pfft
<LaserJock> Burgundavia: ogra's? yeah
<theCore> LaserJock: you should see *my* bookshelf :)
<LaserJock> theCore: Sorry, I don't think I can pick up the emacs books ;-)
<LaserJock> theCore: I've been at uni for 9 years, trust me, I have a bookcase
<theCore> LaserJock: bah, yeah true. You certainly beat on the chemistry books :)
<theCore> beat me*
<LaserJock> between my wife and I we have 3 bookcases
<LaserJock> and then at work I have one
<theCore> ouch ...
<theCore> ok, I am defeated
<LaserJock> Burgundavia: http://people.ubuntu.com/~ogra/rsyncer.sh
<Burgundavia> LaserJock: ah, rock, yes
<theCore> LaserJock: I got a full list of programming books : http://tinyurl.com/3ddpsm So, if you're looking for a good and challenging book about programming, it's probably there
<keescook> crimsun, siretart: can either of you pull the trigger on 83737 ?  (Or show me what I should do to move it to the next step?)
<crimsun> theCore: you're missing http://www.amazon.ca/Shellcoders-Handbook-Discovering-Exploiting-Security/dp/047008023X/ref=sr_1_2/702-8346405-9035255?ie=UTF8&s=books&qid=1172875887&sr=1-2 
* Fujitsu yawns.
<Fujitsu> Morning MOTUs.
<keescook> hiya Fujitsu
<crimsun> bug 83737
<Ubugtu> Malone bug 83737 in edgy-backports "Please backport Inkscape 0.45 from Ubuntu Feisty" [Undecided,Confirmed]  https://launchpad.net/bugs/83737
<Fujitsu> Hey keescook.
<theCore> crimsun: oh, never heard of this one, thanks
<theCore> oh, that seems to be a crazy one
<theCore> and looking for a good book about building secure programs. Learning how to crack programs is certainly a way to learn that...
<theCore> thanks crimsun, added to my wish list :)
<crimsun> keescook: I'm a bit uneasy about loosening the libgc-dev versioned b-d; are there absolutely no regressions by loosening it?
<crimsun> [for 6.06] 
<keescook> crimsun: that's just for Dapper.  :)
<keescook> I tested it for a bit, and didn't see any issues.
<crimsun> keescook: if so, perhaps loosen it in the next upload to feisty?
<keescook> what I'm really after is edgy; lots of people want an edgy 0.45.  :)
<crimsun> err, um, ok, so the dapper-backports task is ...?
<Fujitsu> What's so great about 0.45.
<Fujitsu> *?
<keescook> crimsun: I'll double-check it, yet.  The autoconf just wants 6.4 or better, and the "problems", iirc, were with 6.3.
<keescook> Fujitsu: blur!  :)
<keescook> Fujitsu: http://www.linux.com/article.pl?sid=07/02/23/1639217
<Fujitsu> Blurring is actually defined in SVG? I'm impressed.
<crimsun> keescook: ok, I'll +1 the edgy-backports task and leave the dapper-backports task pending
* LaserJock comes back from te Feisty forums
<LaserJock> phew
<keescook> crimsun: cool; thanks.  at what point does an upload happen for the edgy-backports task?
<LaserJock> the "OMG, this control center crap will make me move to X" has turned into "OMG, where did the control center go? Ubuntu devs stink!" so fast :-)
<crimsun> keescook: ubuntu-archive will handle the push
<keescook> crimsun: okay
<geser> crimsun: now that xserver-xorg-video-* got updated in feisty, should I file a uvfe for i810-modesetting to update it also?
#ubuntu-motu 2007-03-03
<crimsun> geser: no need, tepsipakki et al. have it under wraps
<geser> ah, ok
<crimsun> (unless you want a newer git snapshot?)
<geser> I'm happy if 1.7.2 from Debian experimental gets in
<theCore> LaserJock: so, what happened with the Control Center?
<theCore> what it removed because users complained about it?
<theCore> or it was simply a decision of the dev. to not include it? 
<geser> afaik it has some problems but I don't know exactly what problems
<tepsipakki> upstream reverted the change..
<tepsipakki> you can still use the shell, just enable it from the menu editor
<LaserJock> theCore: gnome decided not to use it as default
<LaserJock> theCore: apparently it is supposed to be default again in 2.20
<theCore> LaserJock: ah, well. That makes sense
<theCore> is it just me, or the Preference and Administrator menus switched of place?
<theCore> nevermind it is just me
<LaserJock> aww crapp
<zul> hmm?
<LaserJock> I'm buying a computer for work and I just realized it'll have Vista on it
<zul> no big deal get rid of it
<LaserJock> well, I think we're actually going to keep it
<ryanakca> lol
<zul> LaserJock: herasy
<ryanakca> when running debuild gpg: skipped "Ryan Kavanagh <ryanakca@kubuntu.org>": secret key not available ... what's wrong?
<geser> to see how bad vista compares to a linux destkop with beryl?
<LaserJock> my boss wants to try out th $1000 proprietary data acquisition program that pretty much everybody uses these days
<zul> gpg doesnt know about the email address
<zul> LaserJock: *cough* wine *cough*
<ryanakca> oops... oh well, gmail's spam filter is good enough
<LaserJock> zul: hehe, they have a Linux version if I wanted it that bad
<zul> oh you do ;)
<ryanakca> zul: I have the secret key in my keyring. I can see it in kgpg, as well as sign/encrypt files to myself
<xaraXXL> ntfs-3g gives me a very weird message on dapper: "To work at his full capability, ntfs-3g recommend a new fuse module."
<zul> not a support channel dude
<xaraXXL> my question is: why doesn't it install it by default. it's not a support question.
<ryanakca> hey Burgundavia
<xaraXXL> zul: i know what i need to do, i'm only asking about its packaging
<LaserJock> xaraXXL: look for a bug report on Launchpad
<Fujitsu> Is ntfs-3g actually in Dapper?
<Fujitsu> As far as I know it's not...
<Burgundavia> hey ryanakca
<xaraXXL> ah, ok, so it's not universe
<Burgundavia> I thought I saw it
<Fujitsu> It only appeared in Edgy. So any bug reports about Dapper will be immediately rejected.
<xaraXXL> Fujitsu: the issue appeared in edgy?
<Fujitsu> No, ntfs-3g only appeared in Edgy.
<xaraXXL> i see
<xaraXXL> thanks
<ScottK> Any suggestions on how to deal with a Universe package that won't install due to two dependencies that conflict and the dependencies are in Main?  Bug 89341
<Ubugtu> Malone bug 89341 in griffith "Griffith uninstallable in Feisty due to dependency conflicts" [Undecided,Confirmed]  https://launchpad.net/bugs/89341
<LaserJock> it deps on both?
<plugwash> what is the situation in debian?
<ScottK> Yes it deps on both
<plugwash> hmm
<plugwash> debian:~# chroot /bigdrive/sid/
<plugwash> debian:/# apt-get install Griffith
<plugwash> Reading package lists... Done
<plugwash> Building dependency tree... Done
<plugwash> E: Couldn't find package Griffith
<plugwash> debian:/#
<plugwash> seems it isn't even in debian...
<ScottK> Yes, it is - http://packages.debian.org/unstable/gnome/griffith
<plugwash> ahh i see why its a capitalisation usee (the thing i copypasted from had the first letter capitalised)
* plugwash checks if its installable on sid
<ScottK> The griffith package is the same as debian and the changelogs for the two dependencies lead me to believe they'll be the same in Debian.  I'm curious what you find.
<LaserJock> ScottK: what are the deps?
<plugwash> its installable on sid
<plugwash> i was just doing a quick check in case he didn't have sid arround i don't want to get deeply involved
<ScottK>  python-pysqlite2 and python-sqlite
<ScottK> plugwash: Thanks.  I don't have sid
<LaserJock> seems odd to dep on both
<ScottK> Yep.  And they conflict with each other (try to install the same file in pysupport because they provide the same python module name).
<ScottK> Wife just called.  I gotta run.  Be back later...
<ryanakca> how do I fix gpg: skipped "Ryan Kavanagh <ryanakca@kubuntu@org>": secret key not available       ? I can sign files with the Key, and I see it in KGPG... 
<Fujitsu> ryanakca, what is giving you that? pbuilder?
<ryanakca> debuild -S -sa
<Fujitsu> kubuntu@org?
<Fujitsu> That looks wrong.
<ryanakca> I know
<ryanakca> I put it that way because I've already pasted my real email in here
<ryanakca> it's .org in the real error message
<ryanakca> Hey Hobbsee
<Fujitsu> Make sure your key has no comment, and that the name and email address are identical.
<ryanakca> Ah, I have a comment, that's why
<LaserJock> ryanakca: and try it with -k<email/keyid>
<LaserJock> ScottK: python-sqlite and python-pysqlite2 don't have Conflicts: with each other
<LaserJock> ScottK: but I don't understand why griffith would need both
<Hobbsee> hey ryanakca 
<ryanakca> LaserJock: it works with -k, thanks
<LaserJock> ryanakca: that'll get around the problem
<LaserJock> ryanakca: do you use a gpg agent?
<ryanakca> yes
<ryanakca> It didn't ask for a passphrase, so I know gpg agent works
<LaserJock> ah, that's usually the problem
<geser> Hobbsee: as you deal with kubuntu: are there any plans to update klamav to work with clamav >= 0.90?
<Hobbsee> geser: good questoin.  didnt know it existed
* Hobbsee looks further
<geser> libclamav changed the soname from 1 to 2
<Hobbsee> geser: i'll deal with it
<Hobbsee> geser: darn, i cant sync that from debian, that'll have to be a merge
<geser> Debian bug #412856 has a patch for klamav 0.38
<Ubugtu> Debian bug 412856 in klamav "klamav: diff for NMU version 0.38-1.1" [Normal,Open]  http://bugs.debian.org/412856
<geser> there is also a new upstream version of klamav (0.41) for clamav >= 0.90
<Hobbsee> right
<Hobbsee> so there is....
* Hobbsee emails the maintainer
<ryanakca> Hobbsee: can you review my bzr-gtk?
<Hobbsee> ryanakca: we're in FF....
<Hobbsee> is there a major need to?
<ryanakca> no... is Universe frozen?
<Hobbsee> !feisty
<ubotu> The next version of Ubuntu (7.04; codenamed "Feisty Fawn"), it should be released in April 2007. At the moment it is alpha. Schedule: https://wiki.ubuntu.com/FeistyReleaseSchedule - Specifications (goals): https://features.launchpad.net/distros/ubuntu/feisty - Help in #ubuntu+1
<ryanakca> Hobbsee: It's missing a depends, aka, one of the apps in it doesn't run
<Hobbsee> yep.  only new packages which are deemed Very Important will get in
<Fujitsu> No new packages, except in exceptional circumstances.
<Hobbsee> oh, it's a bug fix, or new release?
<ryanakca> Hobbsee: bug fix in packaging
* Hobbsee notes that if it's bzr stuff, then it might be ack'd
<Fujitsu> Oh, that's OK.
<Fujitsu> Hobbsee: True.
<Hobbsee> ryanakca: got a debdiff?
<ryanakca> ack'd?
<ryanakca> Hobbsee: can I stick it on revu?
<Hobbsee> ryanakca: do you know how to do a debdiff?
<Hobbsee> is there already a bug for the packaging?
<ryanakca> yes, debuild makes one
* ryanakca filed a bug this afternoon
<Hobbsee> er, that makes a .diff.gz, which is different
<ryanakca> ok, how?
<Hobbsee> you can run debdiff foo*.dsc > debdiff, and attach that to the bug report
<Fujitsu> debdiff old.dsc new.dsc > blah.debdiff
<zul> although it would be better to give it a name other than blah ;)
<ryanakca> lol
<Hobbsee> hehe
<Fujitsu> Gah, why do people feel the need to file bugs that they need to install other libraries to get the LightScribe utilities working?
<zul> just to annoy you
<ryanakca> lol
<Hobbsee> Fujitsu: the bugs about "there are too many bugs in Ubuntu" are even better again
<ryanakca> Hobbsee: should the debdiff include changes in debian/control?
<Hobbsee> ryanakca: yes
<ryanakca> Hobbsee: basicly, the only change in the package is the addition of  python-glade2 to Depends
<ryanakca> Hobbsee: ok... because... it doesn't seem to be showing up
<Hobbsee> gotcha
<Hobbsee> did you bump the changelog versoin?
<ryanakca> Hobbsee: I added a changelog entry, yes. old: 0.13.0-0ubuntu1, new: 0.13.0-0ubuntu2
<bddebian> Heya gang
<ryanakca> hey bddebian
<pochu> hey bddebian :)
<Fujitsu> Hi bddebian.
<LaserJock> hi bddebian 
<bddebian> Hi ryanakca, pochu, Fujitsu, LaserJock :)
<pochu> bddebian, anybody else: I have requested a sync: Bug #89226. It's confirmed by geser. What's the next?
<Ubugtu> Malone bug 89226 in tracker "Please sync tracker 0.5.4-4 from debian unstable main" [Undecided,Confirmed]  https://launchpad.net/bugs/89226
<ryanakca> Hobbsee: http://paste.ubuntu-nl.org/8308/
<Hobbsee> pochu: you need a uvf exception for it, i would expect
<Hobbsee> ryanakca: what's olive-gtk?
<ryanakca> Hobbsee: it's a graphical interface for bzr. Pull, Push, Log, Diff, etc
<Hobbsee> bug 89332
<Ubugtu> Malone bug 89332 in bzr-gtk "Missing depends for bzr-gtk" [Medium,In progress]  https://launchpad.net/bugs/89332
<ryanakca> Commit, Uncommit iirc
<Hobbsee> ryanakca: it's not in bzr-gtk thoguh...
<ryanakca> It is...
<pochu> Hobbsee: but that's not a new upstream version
<ryanakca> Hobbsee: apt-get source bzr-gtk
<pochu> Hobbsee: it's the same version, but with some fixes in debian...
<Hobbsee> pochu: ah
<Hobbsee> ryanakca: which conflicts olive, yes.
<pochu> just we have 0.5.4-1 and debian has 0.5.4-4 :)
<pochu> Hobbsee: should I do anything else, or you can already upload it?
<ryanakca> Hobbsee: Well, there's the most recent version of it in the package bzr-gtk. 
<ryanakca> To run it you need to install python-glade2
<ryanakca> so, I added python-glade2 to the Depends
<Hobbsee> pochu: ahh.  it's a sync request, so no, i cant upload it, not being an archive admin.  subscribe ubuntu-archive if geser's ack'd it, and if they're not already subscribed, and wait
<Hobbsee> ryanakca: ahh, it's just not listed in debian/control
* ryanakca nods
<pochu> Hobbsee: they are subscribed. ty!
<Hobbsee> ryanakca: done
<Hobbsee> pochu: no problem
<ryanakca> Hobbsee: kk, thanks
<LaserJock> Lutin: if you keep our fearless leader running errands all day he's not going to have time for Feisty+1 genius ;-)
<bddebian> We have a fearless leader? :-)
<LaserJock> he did email opensuse-devel
<zul> again?
<LaserJock> no
<Fujitsu> zul: I hope not.
<Fujitsu> LaserJock: That does exhibit his fearlessness, certainly.
<LaserJock> but I thought that would count as "fearless"
<Fujitsu> Some people call it utter stupidity, unfortunately.
<ryanakca> bug 89332
<Ubugtu> Malone bug 89332 in bzr-gtk "Missing depends for bzr-gtk" [Medium,Fix released]  https://launchpad.net/bugs/89332
<Lutin> LaserJock: hehe :)
<LaserJock> OT: anybody got a recommendation for a backup device like and external hard drive or something?
<ryanakca> LaserJock: Tape drive?
* ryanakca wonders if those still exist
<jdong> LaserJock: I personally vulture hard drves when they're on sale
<jdong> LaserJock: and stick them in $10-$20 USB enclosures
<jdong> DVD-R's and DVD+R DL's aren't bad for backups either
<jdong> as long as it's not like a really regular backup routine
<jdong> then it gets inconvenient
<jdong> my last reel of 100 DVD-R's was $10
<ryanakca> jdong: ??? it's 20$ for 80 here...
<jdong> ryanakca: sales, buddy.
<ryanakca> ah
<ryanakca> lol
<jdong> CompUSA cheap DVD-R's are actually pretty good
<jdong> unlike their CD-R's
<jdong> their CD-r's are utter crap
<ScottK> LaserJock: Turns out someone provided a patch while I was gone: http://librarian.launchpad.net/6605274/remove_egg_support.patch
<ScottK> Now the trick is to get someone to apply it to python-sqlite (since it's in main)
<Adri2000> see you everyone in one week! (holidays with no computer/internet) :)
<Nafallo> *yawns*
<Nafallo> what kind of freezes are we in ATM? :-)
<zakame> *munches*
<jdong> Nafallo: well, flashplugin freezes on me once in a while... gspcav webcam drivers do to....
<jdong> Nafallo: so I'd say miscellaneous multimedia freezes
<Nafallo> lol
<Nafallo> jdong: not that kind of freezes, rather if ubuntuX increments are okey still :-)
<jdong> lol
<jdong> same diff :D
<Nafallo> so... are they? :-)
* Nafallo puts finger on the enter-key
<Nafallo> noone knows? ;-)
<Nafallo> hmm
* Nafallo fires then :-P
<Nafallo> lol
<Nafallo> couldn't find dput ;-)
<Nafallo> ffs
* Nafallo whips bddebian a bit to make him say something :-)
<Nafallo> damnit! now he's never going to say something... forgot he likes that kind of stuff :-P
<bddebian> :-)
<Nafallo> *s*
<Nafallo> anyway, fired. if that was wrong someone would probably have to come here and kill me or something :-)
<LaserJock> Nafallo: we are just in UVF and NewPackagesFreeze
<LaserJock> Nafallo: new -ubuntuX versions are fine
<LaserJock> interesting post on Planet Debian: http://np237.livejournal.com/15073.html
<joejaxx> lol
<bddebian> heh
<bddebian> Gnight gang
<AnAnt> ajmitch: ping
<LaserJock> I think he's gone for the weekend
<AnAnt> ok
<imbrandon> moins peeps
<imbrandon> Nafallo, long time no see
<LaserJock> hi imbrandon 
<imbrandon> heya LaserJock 
<imbrandon> LaserJock, any luck with mod_python
<LaserJock> imbrandon: oh, it's going
<LaserJock> it's just a bit weird
<imbrandon> cool
<imbrandon> i'm just now getting arround to installing it
<LaserJock> it's easy to make a .htaccess that load 1 .py
<imbrandon> just 1?
<LaserJock> but if you have more than 1 .py you want to be able to do it seems tricky
<StevenK> Get the first to be a module that loads others.
<imbrandon> cant you just 
<imbrandon>                 AddHandler mod_python .py
<imbrandon>                 PythonHandler mod_python.publisher
<imbrandon> ?
<LaserJock> that didn't work for me, I don't think
<LaserJock> StevenK's suggestion was the best I could come up with for my simple usage
<imbrandon> hum
<StevenK> mod_python is pretty crappy, anyway.
<LaserJock> I just thought it was odd
<StevenK> Use Rails. :-P
<LaserJock> nah
<imbrandon> ruby?
<StevenK> imbrandon: Yup.
<imbrandon> bah not another scripting lang to learn
<imbrandon> php or python is all for me
<StevenK> PHP is not a scripting language.
<imbrandon> i know php very well already
<imbrandon> BS
<imbrandon> i script in php everyday ;)
* StevenK denies PHP the right to exist.
<LaserJock> imbrandon: I got a PHP5 book from the library today
<imbrandon> hehe
<imbrandon> LaserJock, rockin
<imbrandon> i LOVE php
<imbrandon> i even use it for cli stuff 
<imbrandon> ;)
<StevenK> imbrandon: Insane.
<StevenK> Learn shell programming, for the love of God.
<imbrandon> nah , php-cli was made and maintained for a reason ;)
<imbrandon> i do bash stuff soemtimes, but sometimes php is just simpler
<imbrandon> specialy if i want info from say mysql
<LaserJock> cool
<LaserJock> I use python instead of shell scripts a lot of the time
<imbrandon> oh wow
<imbrandon> that was super simple
<imbrandon> i just installed it and configured it and got it working without .htaccess in less than a minute
<imbrandon> LaserJock, http://www.imbrandon.com/misc/python/test.py
<LaserJock> wahoo!
* imbrandon loves ubuntu servers sometimes
<imbrandon> given the .py was only ... 
<imbrandon> def index(req): return "Test successful";
<imbrandon> still works hehe
<LaserJock> imbrandon: http://www.laserjock.us/python/test.py
<imbrandon> hehe
<imbrandon> but thats only for one file isnt it?
<imbrandon> here is what i followed and it worked flawless in less than a minute http://www.ubuntuforums.org/showpost.php?p=792999&postcount=3
<imbrandon> on my edgy server that runs imbrandon.com
<LaserJock> what version of mod_python?
<imbrandon> i just "sudo apt-get install libapache2-mod-python" so what ever version that is in edgy
<imbrandon> umm lemme look
<imbrandon> Version: 3.2.8-1ubuntu2
<imbrandon> Depends: libapache2-mod-python2.4 (>= 3.2.8-1ubuntu2), python (>= 2.4), python (<< 2.5)
<imbrandon> is what it installed
<LaserJock> I think I've got an old mod_python
<imbrandon> you might have made the mistake that the first guy made and use apache-mod_python anot apache2-mod_python
<imbrandon> e.g. not apache2
<imbrandon> [EDIT]  WelterPelter, I just saw that you said you used libapache-mod-python2.4 which means you are using apache not apache2. I wrote this for apache2, I dont know how different they are but i guess it wont work, i suggest installing apache2 and libapache2-mod-python[/EDIT] 
<imbrandon> most likely you are using apache2 not apache ( hopefully )
<LaserJock> I'm not positive
<LaserJock> imbrandon: 1.3.36 
<LaserJock> imbrandon: also got PHP4 and a 2.4 kernel
<imbrandon> ouch
<imbrandon> not a server you have control over?
<LaserJock> not a ton, no
<LaserJock> I think it's running CentOS
<imbrandon> hum apache 1.3 you say? yea you should be using apache-mod-python
<imbrandon> wow
<imbrandon> centos os old old old
<imbrandon> heheh
<imbrandon> move it to voyager ;) hehe or linode ;)
<imbrandon> 'just teasin
<LaserJock> well, I might ask about getting it updated
<LaserJock> not sure how huge it'd be
<LaserJock> but it's kinda a drag
<LaserJock> but as they say "Don't look a gift horse in the mouth"
<imbrandon> hehe
<imbrandon> well if you ever want i'll be happy to put it on my server
<imbrandon> ( free or i wouldent be offering ) but thats upto you
<imbrandon> no hurries, or anything, its a standing offer
<imbrandon> ;)
<imbrandon> if it dont work out for you etc etc etc
<imbrandon> brb smoke break
<LaserJock> nasty habit imbrandon 
<LaserJock> almost as bad as your Mt. Dew addiction ;-)
<imbrandon> lol
<LaserJock> goodness
<LaserJock> this bug really is maddening
<LaserJock> an app can't find it's help
<imbrandon> lol
<LaserJock> but if I run it from /usr/share/Xaos/
<LaserJock> it works
<LaserJock> so it can find the help in ./
<LaserJock> but not otherwise
<imbrandon> sounds liekt he working dir isnt getting updated
<LaserJock> hmmm
<LaserJock> I have no idea how to tell
<LaserJock> but apparently it works if you build it from source
* tbf wonders how to proceed after uploading to tauware: should I create a ticket for merging my package or will someone take care automatically?
<LaserJock> what?
<tbf> LaserJock: http://revu.tauware.de/details.py?upid=4544
<tbf> LaserJock: do I have to create a launchpad ticket for discussion?
<LaserJock> no
<tbf> LaserJock: cool. :-)
<tbf> so I'll wait
<imbrandon> its a merge or NEW package ?
<LaserJock> NEW I think
<LaserJock> clashing terminology
<imbrandon> ;)
<imbrandon> you know for ogg to work so well on linux its support sucks on windows/osx
* imbrandon gets back to work
<tbf> imbrandon: its suckage on non-free platforms is exactly the reason for ogg not to take off
<sacater> tbf imbradon: ogg has taken off slightly, my mp3 player supports it, and its only 512mb, and 112
<sacater> 12*
<GNUro> 'morning!
* tbf checks if his sony-ericson supports ogg
<tbf> hmm. no. :-(
<shawarma> I've been thinking.... I maintain these network-manager-vpn plugins.. They've never been released, so the packages are based on an svn checkout. If it waas based on a release and a bug was filed, which was fixed in current svn, I'd just add that patch (using dpatch or something) and upload it, since it's not a new upstream version.. But since this is based on a svn checkout (with upstream version set to e.g. 0.3.2svn2342) it's not that easy.. Basicall
<shawarma> I *could* of course just add the relevant patches and upload a new ubuntu version, but it wouldn't really feel right not updating the upstream version..
<shawarma> Hm... tough crowd.
<Hobbsee> shawarma: well, if it's a bug fix...
<Hobbsee> shawarma: i mean, look at the point of the UVF - to only fix bugs, but not introduce things with more bugs
<stgraber> if that fix the openvpn config window which take around 2x the screen height, it's a bugfix I think :)
<shawarma> It's definitely a bugfix, but fixing it involves doing a new svn checkout which is part of the upstream versioning scheme..
<shawarma> stgraber: And yes, that's be bug it fixes.
<shawarma> I don't mind as such that I have to do a UVFe each time, but it seems like a waste of both my and the motu-uvf team's time. 
<shawarma> It makes it even more interesting that if I just take the relevant patch from svn, add it as a dpatch, but leave out other potential bug fixes from svn, it's actually *easier* to get it into the archive since it doesn't involve updating the upstream version.
<Hobbsee> it does
* Hobbsee would probably just pick the most sane solution
<stgraber> shawarma: Is this "pull" option also added in the new version ?
<shawarma> stgraber: No, I'll be adding that myself and submitting it upstream.
<stgraber> thank you
<shawarma> Hobbsee: Well, the sane solution seems to be doing the UVFe dance, but.. gah..
<Hobbsee> shawarma: wouldnt bet on that.  i mean, the sane solution woudl be to take stuff from svn but i'm not convinced that would require a UVFe in normal circumstances (ie, with a rleease tarball)
<shawarma> Hobbsee: No, it wouldn't. 
<shawarma> Hobbsee: I mean: It wouldn't require a UVFe when the package is based on a release.
<Hobbsee> exactly
<Hobbsee> so i think "use common sense" is in order, ie, just take the new bits of svn, preferably cherrypicking for any bad bits
<shawarma> Hobbsee: Maybe it would make sense to have a special policy for packages based on some RCS checkout..
<Hobbsee> true
<Hobbsee> StevenK: what do you think?
<Lutin> is there someone who could try to build a package on ppc for me ? :)
<stgraber> Lutin: is it big ?, I have access to and old G3 powerbook with Ubuntu on it but it's really slow :)
* Hobbsee keeps finding hoary cds here...
<Lutin> stgraber: took about ten minutes on the buildds, don't know how much it means for an old box :)
<stgraber> Lutin: what packages is that ?
<Lutin> stgraber: mlt
<Lutin> stgraber: I'd like to try a fix for the ppc ftbfs
<Lutin> the package I need to test in at http://dunnewind.net/~lutin/mlt
<stgraber> Lutin: ok, I've got the Mac I'm installing pbuilder and will build that package
<Lutin> stgraber: cool, thanks a lot
<stgraber> Lutin: I didn't ask but you want a Feisty package I guess ?
<Lutin> stgraber: yep :)
<stgraber> CPU: 400Mhz, bogomips 49,79 (??) :) I'm pbuilder creating right now
<Lutin> ok, thanks :)
<Sp4rKy> does anyone know why casper only set $LANG and no $LANGUAGE ?
<stgraber> Lutin: Pbuilder can't install sox-dev
<Hobbsee> stgraber: you dont have universe enabled in your pbuilder?
<stgraber> Hobbsee: checking
<stgraber> arf, commented line in pbuilderrc :)
<stgraber> thank you Hobbsee 
<Hobbsee> :)
<elkbuntu> hmm... anyone else having trouble talking to security.ubuntu.com?
<StevenK> elkbuntu: Works for me.
<elkbuntu> StevenK, yeah, i just re-updated and it didnt time out
<elkbuntu> someone must have farted on the pipe somewhere
<elkbuntu> mmmmm... x.org goodness
* StevenK continues to resist upgrading to Feisty.
<elkbuntu> StevenK, im typing from edgy, but my laptop has a few fawn installs
<elkbuntu> faun and kfaun ;)
<StevenK> I have two Feisty chroots, do they count?
<StevenK> (i386 and amd64)
<Hobbsee> StevenK: just do it
<elkbuntu> StevenK, we can pretend
<StevenK> Hobbsee: Why?
<Hobbsee> StevenK: to see breakage :P
<StevenK> I've seen enough breakage on the two Feisty installs my boss has.
<StevenK> Which reminds me, I need to neuter evms on his machine again.
<StevenK> I *think* root on LVM is broken in Feisty, but I need to find the time to test.
<Fujitsu> StevenK: I'm using it, so I hope it isn't broken.
<StevenK> Fujitsu: It fails to work for my boss.
<Fujitsu> Works for me.
<StevenK> On bootup, we get dumped into the initramfs, and I need to run lvm vgchange -a y manually and then mount the thing.
<Fujitsu> Have you got some snapshots or mirrors or similar, without the appropriate module in the initramfs? I had that problem once.
<StevenK> Neither.
<StevenK> If he's snapshoting, he isn't telling me.
<StevenK> Actually, it's root on LVM on RAID
<elkbuntu> oh poo. im certainly not updating my desktop to feisty until the tomboy panel app doesnt die
<stgraber> Lutin: around ?
<Lutin> stgraber: yes
<stgraber> I have 5 .deb after pbuilder is that normal
<stgraber> or should I have more ?
<Lutin> stgraber: 5 is perfect :)
<stgraber> ok, I also had quite a lot of warning and even an error during the compilation, but pbuilder continued his job so it should be that important
<Lutin> stgraber: ok, thanks :). at least it no longer FTBFSs :)
<stgraber> I'm uploading the result + the compilation messages if you want to have a look
<Lutin> ok, thanks
<stgraber> http://www.stgraber.org/download/ubuntu/mlt/
<Lutin> stgraber: thanks :)
<stgraber> np
<\sh> moins
<stgraber> hi \sh 
<\sh> oh guys, whoever implemented this change to dpkg, this guy needs to be crucified
<cbx33> Hi all
<cbx33> anyone got a hand to help out a newbie c++ coder?
<sacater> cbx33: why are you asking in the MOTU channel
<sacater> ask in a programming channel :P
<Hobbsee> cbx33: maybe, what it is it?
<Hobbsee> er, -it
<cbx33> well....
<cbx33> can i pastebin something
<Hobbsee> yes
<cbx33> pastebin.ca/379751
<cbx33> http://pastebin.ca/379751
<cbx33> ok, you can semi-ignore the class texture loader ;)
<cbx33> I'm just trying to understand how to use gtkpixbufloader
<cbx33> I can use it in python no troubles
<cbx33> but I just don't get c++
<Hobbsee> then you're really asking a question about how to use gtkpixbufloader, which i cant answer, as i dont know, sorry
<cbx33> well...or any gtk type class in c++
<cbx33> or just gtk in general....
* Hobbsee doesnt deal in any gtk, sorry :P
* Hobbsee is a kde person
<cbx33> ahh
<cbx33> ok np
<Hobbsee> have cleared off bed - time to sleep.  night all!
<sacater> hey guys, have they made the feisty gajim 0.11.1 release
<Nafallo> sacater: yea, and I fixed it yesterday.
<sacater> Nafallo: damn
<Nafallo> sacater: what?
<sacater> i wanted to have a go at it
<Nafallo> please ask the maintainer first. I hate it when people throw away all patches :-)
<sacater> how do i find out about the status of the xjump package, and whether its the latest version
<Nafallo> apt-cache madison xjump
<sacater> ty
<Nafallo> alt. launchpad :-)
<Nafallo> no problem
<sacater> the reason im asking all this is im Motu in training :P
<Nafallo> oki. well, generally hold of packages with a motu specfied as maintainer and you should be fine :-).
<Nafallo> if there is, and he doesn't do his job, feel free to try to contact him before making changes :-)
<Lutin> do anyone know who / what team cares for the @ubuntu.com mail adresses ?
<imbrandon> cares for in what way?
<Lutin> creates them / can change them
<stgraber> I think that's canonical sysadmins who manage that
<imbrandon> they are granted upon membership via the CC, but if you have a problem with the alias then file a bug in LP 
<Lutin> imbrandon: file a bug against what ?
<imbrandon> LP its self afaik
<Lutin> ok, thanks
<walrus> ppl, how can i know some program's dependencies ???? e.g. : "depends" on win32 ... 
<walrus> ppl, how can i know some program's dependencies ???? e.g. : "depends" on win32 ... 
<walrus> ppl, how can i know some shared library dependencies ???? e.g. : "depends" on win32 ... 
<Lutin> walrus: you can run 'objdump -p /usr/bin/foo | grep NEEDED' on the binary you want to get informations on
* ScottK thinks apt-cache depends <packagename> will also do it.
<Lutin> indeed, though it doesn't work for non-packages binaries :)
<ScottK> True.
* ScottK tries to avoid installing outside the packaging system.
<Lutin> so does /me
<walrus> all right thx, i'm not installing some package ... i just compiled my own shared library and i wanted to make sure it linked well to its dependencies
<Lutin> then the objdump thing should work fine
<walrus> Lutin, thx very much ... xD xD ... objdump gave me just what i needed ... 
<Lutin> np
<Lathiat> a
<doko> bug 86552 87917
<Ubugtu> Malone bug 86552 in python-sqlite "[apport]  package python-sqlite failed to install/upgrade: " [Undecided,In progress]  https://launchpad.net/bugs/86552
<doko> bug 87917
<Ubugtu> Malone bug 87917 in griffith "Please sync griffith 0.9.2-1 (universe) from unstable (main)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87917
<ScottK> doko: This issue is conflicting egg info in two python packages, so I don't think a sync will affect things either way.
<doko> ScottK: I know, thanks for the info anyway ;)
<ScottK> OK
<ScottK> Ah, now I see you are the person that took the bugs.
<ScottK> Thanks for attending to it.  Diagnosing the conflict was as far as my knowledge would take me on that one.
<LaserJock> Morning MOTU Land!
<stgraber> hi LaserJock 
<imbrandon> moins LaserJock 
<LaserJock> hi imbrandon stgraber 
<LaserJock> hmm, if two bugs are dups, do you mark the newer one as the dup?
<stgraber> usually that's what I do except if the new one already has a priority set
<stgraber> or has a lot more informations
<jdong> bleh any mono buffs here?
<jdong> need to figure out how to get line-by-line output from a spawned process's stdout
<jdong> I've gotten most of it done but it always ends by spewing \n in infinite loop :D
<stgraber> I only have some simple notion of C#, but can't you use something like a streamreader and readline() ?
<stgraber> that's just an idea by the way
<jdong> aha, figured it out
<jdong> peek()
<jdong> yeah, a streamreader (Process.StandardOutput) is used
<jdong> just figuring out how to determine end-of-file condition
<jdong> and it's checking peek()
<jdong> which Gtk# control would I use for a scrollable text area
<jdong> i.e. to display output from an executing program
<jdong> figured it out again :P
<stgraber> textview ?
<jdong> put textview in a ScrollableWindow thingie :P
<asantoni> hey much-revered MOTU, Mixxx 1.5.0 was just released, and the only difference between the pre-release version in Feisty and the final release is a few MINOR bug fixes
<asantoni> would an updated Mixxx package make it through UVF?
<LaserJock> perhaps
<LaserJock> might depend on how minor the bugs are
* _MMA_ waves at Jordan.
<LaserJock> if they are easy fixes would could just apply them to the existing package
<LaserJock> if they are a pain to backport and are very needed fixes then that's more grounds for a UVF exception
* LaserJock waves back to _MMA_ 
<rmjb> Hey guys
<ScottK> Hey rmjb
#ubuntu-motu 2007-03-04
<okaratas> hello
<okaratas> <i prepared a deb packet for ubuntu which is not in the archives. how can i send this to archives? what should i do?,
<Hobbsee> okaratas: see the answer in #ubuntu-deve
<Hobbsee> l
<okaratas> Hobbsee, okey
<bddebian> Heya gang
<geser> hi bddebian
<bddebian> Hi geser
<LaserJock> hi bddebian 
<bddebian> Heya LaserJock
<alex_mayorga> hi
<LaserJock> hello
<alex_mayorga> is this the place to ask for addition of components on the distro?
<LaserJock> alex_mayorga: https://wiki.ubuntu.com/MOTU/Packages/Candidates is the place to ask for a new package
<alex_mayorga> do I just edit the wiki?
<LaserJock> yes
<alex_mayorga> how do I confirm http://gsynaptics.sourceforge.jp is not there yet?
<LaserJock> packages.ubuntu.com
<LaserJock> and packages.debian.org
<Hobbsee> alex_mayorga: it's in fesity
<Hobbsee> *feisty
<alex_mayorga> coolio, what's the package name
<Hobbsee> sarah@LongPointyStick:~$ madison gsynaptics
<Hobbsee> gsynaptics |    0.9.7-3 | http://mirror.pacific.net.au feisty/universe Packages
<Hobbsee> gsynaptics |    0.9.7-3 | http://archive.ubuntu.com feisty/universe Packages
<Hobbsee> gsynaptics |    0.9.7-3 | http://mirror.pacific.net.au feisty/universe Sources
<Hobbsee> gsynaptics |    0.9.7-3 | http://archive.ubuntu.com feisty/universe Sources
<alex_mayorga> I'm on feisty already
<alex_mayorga> nice, checking and downloading
<alex_mayorga> I wonder if there's something similar for multiple button mouses?
<LaserJock> grrr
<bddebian> grr?
<LaserJock> I was looking at a couple Edubuntu packages
<LaserJock> and they are FTBFS
<LaserJock> rebuilt for python2.5 even though they are set to python2.4 only in debian/control
<cypherbios> someone here knows what is the sintax parsed by Udate Manager to create a link to an bug in the change log viewer embed on update-manager? i.e: LP:#89325 links to https://launchpad.net/bugs/89325
<Ubugtu> Malone bug 89325 in aptoncd "returns to the beggining if the user hasn't enough rights to save the folder" [Undecided,Unconfirmed]  
<cypherbios> I just need to put on changelog '* closes LP:#89325' and update manager will show an link to the corresponding bug automatically ?
<bddebian> LaserJock: :(
<LaserJock> I think they might also be trying to make python2.4-* even though it was supposedly move to new python policy
<LaserJock> I don't quite get it
<bddebian> Nice
<LaserJock> and they are Main :/
<LaserJock> darn, where is ajmitch when I need him? :-)
<bddebian> Gone for a couple days iirc
<Fujitsu> LaserJock, which packages are these?
<Fujitsu> I know of two Edubuntu-related main ones, but it's probably not them.
<Fujitsu> (the two I'm thinking of should be demoted, as they're rather broken at the moment)
<LaserJock> schooltool and schoolbell
<LaserJock> Fujitsu: which ones are you thinking of?
<LaserJock> denemo?
<Fujitsu> Those are the ones I'm talking about.
<Fujitsu> Don't try.
<Fujitsu> That version doesn't work with Zope 3.3, but trunk does.
<LaserJock> well yeah, that's what I'm saying
<LaserJock> the took them out of Etch
<LaserJock> *they
<Fujitsu> There are no release plans at the moment, either.
<LaserJock> it's supposed to be following new python policy
<LaserJock> but they are still producing python2.4-*
<Fujitsu> There's little point making it follow it.
<LaserJock> well sure, but the point is that why is it said to follow new python policy if it doesn't
<Fujitsu> Who knows...
<LaserJock> it's stuck on pyton2.4 but was rebuild for 2.5
<Fujitsu> It seems to produce python2.X-school{tool,bell} packages, which is wrong.
<LaserJock> that's what I'm saying
<Fujitsu> Ah, this is true.
<Fujitsu> I hadn't read all of the conversation, so I didn't see that line.
<bddebian> LaserJock: You think Bug #86306 should be rejected?
<Ubugtu> Malone bug 86306 in qgis "qgis" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86306
<LaserJock> bddebian: not yet
<LaserJock> I can't think of a reason to reject it, yet
<bddebian> Uhm, we don't have 0.8? :-)
<LaserJock> but I just left a note on that
<LaserJock> asking the reporter if they do indeed have 0.8
<bddebian> Look at the crash report
<LaserJock> bddebian: it's pretty much meaningless to me
<LaserJock> bddebian: what do you get out of it?
<LaserJock> ahh
<LaserJock> DistroRelease: Ubuntu 6.10
<LaserJock> Package: qgis 0.8.0-2
<bddebian> Yep :)
<LaserJock> hmm
<LaserJock> let's just see if he responds to my comment
<bddebian> NP
<LaserJock> he must have gotten it from Debian or something
<bddebian> Does Debian have 0.8?
<bddebian> Nope
<LaserJock> nope
<LaserJock> the qgis site has an edgy tarball
<LaserJock> but no .deb
<LaserJock> ah, but somebody does have a debian repo for it
<LaserJock> http://download.qgis.org/qgis/etch/README
<bddebian> How the hell is python-scipy-core a depends for python-scipy when python-scipy conflicts/replaces python-scipy-core?
<LaserJock> bddebian: which version?
<bddebian> Which version of what, python-scipy?
<LaserJock> bddebian: yeah
<bddebian>  0.5.2
<LaserJock> the current feisty version doesn't
<LaserJock> 0.5.2-0.1ubuntu1
<bddebian> Doesn't what?
<bddebian> Do and apt-cache rdepends python-scipy-core
<bddebian> Oh, I just noticed that I wrote that backwards
<LaserJock> well that's weird
<LaserJock> python-scipy doesn't dep on it
<bddebian> The only thing I can figure is he's trying to transition python-scipy-core?
<LaserJock> oh sure, but the dep isn't there
<LaserJock> python-scipy-core was replaced by python-numpy in edgy
<bddebian> WTF, python-scipy-core Recommends python-scipy
<LaserJock> sure
<bddebian> I'm confused as shit
<LaserJock> heh
<LaserJock> python-scipy used to use python-scipy-core as a core library
<bddebian> How do you recommend a package that conflicts and replaces yourself?
<LaserJock> now scipy-core has been replaced by numpy
<LaserJock> that's because scipy-core hasn't been touched since the transition
<LaserJock> it's an obsolete package
<bddebian> So what about python-f2py ? :-)
<LaserJock> well, that was a dep of older scipy
<LaserJock> but I think maybe numpy has swallowed that too
<LaserJock> because numpy has a Replaces: on f2py
<LaserJock> ok ..
<LaserJock> so f2py deps on scipy-core
<LaserJock> so that redepends makes sense
<bddebian> Except that both are obsolete?
<LaserJock> well ...
<LaserJock> basically, but some people might want to still use them because they have written code for them
<LaserJock> however, scipy does *not* depend on scipy-core
<LaserJock> so I don't get that rdepends
<LaserJock> hmm, it might be a becuase of the Conflicts
<LaserJock> apt-cache depends python-scipy
* bddebian 's head explodes
<LaserJock> bddebian: why are you concerned?
<bddebian> LaserJock: Bug #73531
<Ubugtu> Malone bug 73531 in python-scipy-core "package description does not match dependancies" [Undecided,Confirmed]  https://launchpad.net/bugs/73531
<bddebian> whooops, wrong one
<bddebian> No, that's it
* Hobbsee wonders when gnome 2.18 will go into feisty, or is it already there?
<LaserJock> I didn't think it was released yet
<Hobbsee> when is it released?
<LaserJock> March 14th
<LaserJock> we have the betas in now
<LaserJock> so we'll have 2.18 on the 14th
<Hobbsee> ahh
<Hobbsee> nice
<Hobbsee> so the beta is in now?  interesting...
* Hobbsee wonders if there's anything of interest in there
<LaserJock> seb and daniel get the packages in the same day
<Fujitsu> Hobbsee: We always have the latest GNOME version during the dev cycle...
<Hobbsee> Fujitsu: true.  must be including the betas then
<LaserJock> yes, the versions are 2.17something
<LaserJock> Hobbsee: http://live.gnome.org/TwoPointSeventeen is where I go the info
<Hobbsee> yep
* Hobbsee just found that
<LaserJock> I think we have 2.17.92
<bddebian> Damn I can't get anything done anymore.. :(
<crimsun> bddebian: is wxwidgets2.8 progressing?
<bddebian> crimsun: doko uploaded it afaik
<crimsun> bddebian: ok.
<bddebian> He made his own package
<tonyyarusso> This might be a silly question, but:  How are pretty ncurses interfaces made?  ie, how hard would it be to make a simple menu thing?
<tonyyarusso> I'm researching for some PIIs and such, 128 RAM or so.
<crimsun> not difficult at all.
<bddebian> Can you use pretty and ncurses in the same sentence? :)
<LaserJock> of course
<LaserJock> ncurses > *
<LaserJock> ;-)
<bddebian> heh
<LaserJock> creating CLI beauty
<tonyyarusso> crimsun: What are my prerequiesites of things I need to know / have?
<crimsun> tonyyarusso: at least the dev package
<crimsun> if you don't necessarily need ncurses, see whiptail.
<tonyyarusso> Is there a menu wizard, or does this involve writing code, starting from templates,... I really don't know what I might be facing.
<tonyyarusso> whiptail - I've heard of that I think
<tonyyarusso> What I'm envisioning is some system restore stuff involving a "rescue partition" like a lot of laptops come with involving a partimage image file, and a sort of "you're really sure?" menu, maybe a few other options
<crimsun> have you considered refactoring hubackup for that purpose?
<tonyyarusso> I haven't heard of that, honestly.  Just started pondering this today.  Can you tell me more?
<crimsun> sure, ``apt-cache show hubackup'', and see its bzr branch(es)
<crimsun> (hosted on LP)
<tonyyarusso> Maybe I'll do both.  hubackup looks good for data checkpoints, while the other method could be the "wow, this is really hosed - screw and start over" option
<tonyyarusso> whiptail looks really nice, btw.
<tonyyarusso> great tip
<tonyyarusso> Is there something like the UCK for alternate CDs?  That seems to be for Live ones.
<LaserJock> tonyyarusso: all I know of are wiki pages
<tonyyarusso> LaserJock: that may change soon - a sec
<tonyyarusso> LaserJock: https://blueprints.launchpad.net/ubuntu/+spec/customize-download-cd
<LaserJock> tonyyarusso: looks cool
<_MMA_> LaserJock: Reconstructor now does "Alt" disks.
<_MMA_> I should post that to the spec.
<LaserJock> cool
<_MMA_> bah. No WIKI page yet. :(
<afflux> If I have a source-package that creates two packages, one of them depends on lame, (which is in multiverse), one of them doesn't. would both go to multiverse or could one go to universe and the other to multi?
<afflux> *multiverse
<Hobbsee> afflux: they'd both go to multiverse
<Hobbsee> afflux: as the source would
<Fujitsu> Hobbsee: Why? One could go into universe, surely?
<afflux> gah. so I would need two source-packages.
<Fujitsu> Like a number of packages are partly in universe, partly in main.
<Hobbsee> Fujitsu: true, but that's a seeding issue, iirc.
<Hobbsee> which is different
* Hobbsee may well be wrong
<Fujitsu> I don't see the issue, but you'd be better of asking an archive admin.
<Hobbsee> afaik, the sources and binaries have to go into the same component, in most cases
<afflux> hm, alright. it's not that complicated here, just some copy&pasting. I'll do two packages ;)
<crimsun> afflux: is lame imperative?
<crimsun> can you get away with a 'Suggests: lame' ?
<afflux> no
<crimsun> right, then have only one binary 'Depends: lame', and that will be the one package that resides in multiverse
<afflux> I'll want to build a converter, ape2mp3 and ape2ogg.
<crimsun> oh sheesh
<crimsun> not monkey's audio
<crimsun> that whole thing will go into multiverse, then
<crimsun> last I checked, that entire pile doesn't have a Free license
<afflux> this would be basicly a shell script starting "mac" (monkeys audio console utils) and the encoder.
<crimsun> dilinger tried for ages to get upstream to use a Free license
<afflux> hm. I see.
<afflux> I wonder how they got that mac for linux package into sourcefourge.
<crimsun> well, if it doesn't pass Debian, it's equally unlikely to pass Ubuntu
<crimsun> granted, there are exceptions (e.g., firefox), but upstream has demonstrated an unwillingness to use Free
<afflux> alright...
<crimsun> have you also packaged monkey's audio?
<afflux> yes
<afflux> uploaded some time ago to revu
<afflux> http://revu.tauware.de/details.py?upid=4442
<imbrandon> sf doesnt nessesarly mean it meets the dfsg, what we follow 98% of the time
<imbrandon> ther are lots of projects on sf, including some MS shared source lic projects iirc
<imbrandon> that wouldent make it into debian/ubuntu
<afflux> oh, I thought sf is free-licenses only O.o
<Amaranth> afflux: some licenses that sf allows are open source but not DFSG-Free
<afflux> i see.
<GNUro> 'lo!
<jekil> hi
<white> lucas: hi, i had a short look at the mail you wrote to mia@ , but i could not find the two packages you mentioned and "dak ls" on merkel does not give me any information about them either :(
<LongPointyStick> heya white
<white> LongPointyStick: huhu :)
<white> LongPointyStick: how is to goin?
<LongPointyStick> white: good :)  it's hobbsee, btw
<white> s/to/it/
<white> i know, who else would have a long pointy stick? :)
<LongPointyStick> ahhh
<LongPointyStick> so you do know about that already
<white> :)
<Lutin> white: hay :). I updated kayali, it should be fine now. could you have a look at it when you have some time ?
<imbrandon> crimsun, round?
<white> Lutin: sure, sorry that i was a bit unresponsive, just send me an email with the information please
<white> lucas: fenton and mechanix according to the mail
<Lutin> white: ok
<sacater> with debdiff, do you do 'debdiff <old>.dsc <new>.dsc' or 'debdiff <new>.dsc <old>.dsc'
<imbrandon> old new
<sacater> imbrandon: ty
<sacater> in debuild, what does the -S extension do
<imbrandon> from the manpage, it says to build a source only package
<sacater> imbrandon: cool, could you look at my debdiff on https://launchpad.net/ubuntu/+source/xmms-midi/+bug/86747, and tell me whether it looks ok and can be used
<Ubugtu> Malone bug 86747 in xmms-midi "xmms-midi should have xmms as dependency" [Undecided,In progress]  
<zorglu_> q. naive question, when doing apt-get install, i got a "(Reading database ... " which is quite long and harmering the disk, why is it so long ?
<geser> sacater: in the changelog: feisty and not unstable and you need to change the Maintainer in debian/control according to https://wiki.ubuntu.com/DebianMaintainerField
<sacater> geser: ty ill get right on it
<sacater> zorglu_: slow internet? slow cpu?
<zorglu_> sacater: "reading database" is local only so it is not the internet (btw i download at 1mbyte/s), im just wondering how come it spend so much time reading a database
<zorglu_> sacater: apparently the database contains 150000 file. which is quite small
<sacater> zorglu_: erm, no thats rather large, anyway, is your HDD SATA, IDE?
<zorglu_> i dunno :)
<zorglu_> well in early 90, i was doing 10millions record in database without issue... so i guess that 17years later we can do as good :)
<zorglu_> but ok, it was just out of curiosity
<sacater> zorglu_: no no, its something to persue, it shouldnt hammer ur disk like you suggest
<sacater> just CPU
<sacater> if that
<zorglu_> ok lets me retry and i will give you the cpu usage
<sacater> ok
<zorglu_> 4%
<sacater> are you using gnome or XFCE?
<zorglu_> i run kubuntu edgy
<zorglu_> during the apt-get install it read the disk for a few second at 3-8mbyte/s
<zorglu_> i guess it is due to the format of the database
<esaym> what is the package name for the dev perl?
<sacater> geser: okay done it all but the maintainer, do i change it to my name :D?
<geser> sacater: see https://wiki.ubuntu.com/DebianMaintainerField
<imbrandon> ubuntu-motu@lists.ubuntu.com as per the wiki
<sacater> imbrandon: eh?
<bddebian> Heya gang
<geser> hi bddebian
<bddebian> Hi geser
<bddebian> Anyone familiar with mpichpython?
<zul> is it just me or is vim acting strangely?
<imbrandon> just you
<imbrandon> because your the only vim user not converted to nano ;)
<imbrandon> bwhahahah
<imbrandon> sudo rm /usr/bin/vim && sudo ln -s /usr/bin/vim /usr/bin/nano
* imbrandon takes over the world
<jdong> is it just me or is emacs being a PITA?
<jdong> imbrandon: that's something like what I did on my campus shell account...
<jdong> only with emacs and vim.
<imbrandon> ed ftw
<jdong> sweet these servers do have ed!
<sacater> can any MOTU please check my debdiff on https://bugs.launchpad.net/ubuntu/+source/xmms-midi/+bug/86747
<Ubugtu> Malone bug 86747 in xmms-midi "xmms-midi should have xmms as dependency" [Undecided,Fix committed]  
<sacater> can any MOTU please check my debdiff on https://bugs.launchpad.net/ubuntu/+source/xmms-midi/+bug/86747 and tell me whether it looks okay to be used
<Ubugtu> Malone bug 86747 in xmms-midi "xmms-midi should have xmms as dependency" [Undecided,Fix committed]  
<sacater> can any MOTU please check my debdiff on https://bugs.launchpad.net/ubuntu/+source/xmms-midi/+bug/86747 and tell me whether it looks okay to be used
<Ubugtu> Malone bug 86747 in xmms-midi "xmms-midi should have xmms as dependency" [Undecided,Fix committed]  
<geser> sacater: please read the wiki page about the maintainer again, you got it wrong
<ScottK> sacater: Looking at your debdiff, it looks like the Debian maintainer moved xmms from Debends to Enhances and you are moving it back.  Why was the Debian maintainer wrong to do that?
<sacater> ScottK: er dunno......................
<sacater> geser: i got this xmms-midi package from apt-get source xmms-midi, therefore do you have ANY idea what should go into maintainer
<ScottK> sacater: I dunno either, but I'd suggest that before you do undo what the Debian maintainer just did, you understand why he did it.
<sacater> ScottK: erm what..... i hav'nt 'undone' anything, ive just modified one file, the changelog, and i have no clue as to what i do about maintainer
<sacater> geser: i made a large modification to the latest TEA package under guidence of LaserJock, and he seemed to think that leaving the original maintainer was fine
<sacater> geser: didnt complain about it in the lest
<ScottK> sacater: The previous entry in the Debian changelog says that xmms was moved from depends to enhances.  You are moving it back.
<sacater> ScottK: ah
<sacater> oh sugar
<ScottK> So, before you (essentially) remove the Debian maintainers last change, understand why he did what he did and have an explanation of why it's wrong.
<sacater> ScottK: im new, what exactly does that mean, 
<sacater> ok go on
<ScottK> Your debdiff moves xmms from enhances to depends, correct?
<sacater> whats enhances :S, ive only ever heard of depends
<ScottK> The entry right below yours in the debian/changelog says, "* Move xmms to Enhances"
<sacater> yes
<ScottK> So, in his last upload, the Debian maintainer moved xmms from depends to enhances.
<ScottK> Your patch puts it back.
<sacater> what is enhances?
<sacater> i have nfc what that is
<sladen> sacater: then you definately shouldn't be undoing it without understanding that first :)
* ScottK is looking for a reference.
<sacater> sladen: good point, i was eager to help with that bug report
* sacater playings sorrowing music
<ScottK> sacater: I can't find a good explanation to point you at.
<sacater> ScottK: i googled and neither could it
<sacater> I*
<ScottK> It may be that enhances is just plain wrong, but I'm not experienced enough myself to know.
<sladen> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
<sacater> sladen: thank you
<ScottK> sladen: Thanks.  I looked in the policy manual and missed that.
<sladen> sacater: generally I'd be /EXTREMELY/ hesitant about reversing a change like that
<sacater> sladen: ScottK: got it, it 'enhances' xmms
<sladen> sacater: what is the package you're working on?
<sacater> sladen: agreed, ill think about closing the bug report once ive read the web page
<sacater> sladen: one mo...
<sacater> sladen: https://bugs.launchpad.net/ubuntu/+source/xmms-midi/+bug/86747
<Ubugtu> Malone bug 86747 in xmms-midi "xmms-midi should have xmms as dependency" [Undecided,Fix committed]  
<sacater> yeh look
<sacater> Source: xmms-midi
<sacater> Maintainer: Paul Wise <pabs3@bonedaddy.net>
<sacater> Section: sound
<sacater> Build-Depends: debhelper (>= 4.1.0), autotools-dev, xmms-dev
<sacater> Priority: optional
<sacater> Standards-Version: 3.6.2
<sacater> Package: xmms-midi
<sacater> Architecture: any
<sacater> Depends: ${shlibs:Depends}, xmms
<sacater> Enhances: xmms
<sacater> Recommends: freepats
<sacater> Description: MIDI plugin for XMMS
<sladen> sacater: the Maintainer field must now be  *@ubuntu.com;  or you can have the packaging system change that
<sacater>  This plugin enables XMMS to play MIDI files through Timidity.
<sacater> it has enhances
<sacater> ive added xmms to depends as you can se
<sladen> sacater: flood--
<sacater> sladen: yeh i know
<sacater> ive seen worse floods
<sacater> sladen: as it is said in 'enhances' shall i add that to the bug report, then confirm it as fix releaseed :S
<sladen> sacater: or Rejected, yes
<sacater> sladen: yeh, but thanks to you and ScottK, i now know what to look out for in the future
<sacater> thanks :P
<sladen> sacater: it might need to depend on timidity, I'm not sure
<sacater> sladen: no, earlier in the changelog it ruled that out, as xmms comes with its own version, and so does xmms-midi
<sladen> own versin of timidity?
<sacater> yeh
<sacater> what irc client are you using?
<sladen> irssi, how come?
<sacater> oh. i was going to send you the changelog but irssi dosnt support file transfer
<sacater> sladen: jabber?
<sladen> sacater: I was going to go to http://changelogs.ubuntu.com/  but it appears to be down
<sladen> +  * Use an external version of timidity instead of the internal one
<sladen> +
<sladen> + -- Paul Wise <pabs3@bonedaddy.net>  Fri, 28 Apr 2006 18:24:59 +0800
<sladen> ?
<tsmithe> hmm... kqemu is still in multiverse.. but i can't be bothered to get the now open sources to package them up
<tsmithe> so i'll be quiet now
<sladen> you should be able to pull it from Debian
<sladen> tsmithe: it was up in Debian within ~24hours I think
<tsmithe> :S
<tsmithe> they have more people :P
<sladen> tsmithe: never, ever, duplicate work
<tsmithe> very true ;)
<sladen> if a sync from Debian is what is needed, request that
* tsmithe does just that
<zorglu_> q. when i do "dpkg --build debian/tmp" in a debian/rules, i got this weird message during it "tar: -: file name read contains nul character", any idea where it comes from ?
<zorglu_> this appears just before the "dpkg-genchanges -B"
<Seveas> shawarma, you around?
<shawarma> Seveas: Oui.
<Seveas> great
<shawarma> Thank you.
<Seveas> you're the network-manager + vpnc wiz, right?
<shawarma> That't the theory, yes.
<Seveas> mind helping me with it?
<shawarma> Not at all. Shoot.
<Seveas> I can connect with vpnc to my universities network, but with exactly the same parameters, nm+vpnc fails
<Seveas> I immediately get the response that it cannot connect to the server
<shawarma> Interesting.
<Seveas> no idea how to debug
<Lathiat> lucky, vpnc never worked at my uni :( fortunately the cisco official ones worked
<shawarma> Seveas: If I'm not much mistaken, it writes its output to syslog.
<shawarma> Seveas: Hm.... Have you restarted NetworkManager since you installed the plugin?
<Seveas> rebooted
<shawarma> mkay.
<Seveas> otherwise the newly created vpn connection didn't even show up in the lsit
<shawarma> No, I've got a patch for that already.
<shawarma> Seveas: Did you set up the connectio manually or did you import a pcf?
<Seveas> tried both
<shawarma> Is the connection name by any chance really long?
<Seveas> only if 3 letters is long
<shawarma> Or contains "interesting" characters?
<Seveas> http://paste.ubuntu-nl.org/8679/
<shawarma> Seveas: Ah.
<Seveas> UvA
<Seveas> don't know how to interpret most of that log, maybe you can?
<shawarma> There's really not much to work with.
<Seveas> I'll pester the NM mailinglist :)
<shawarma> just a sec, I'll try connecting to my university to compare log files.
<shawarma> Seveas: I'll put my log file on the pastebin. Just a minute.
<shawarma> Seveas: http://paste.ubuntu-nl.org/8681/
<Seveas> DOH!
<shawarma> Is vpnc still running?
<Seveas> I swapped password and group password
<shawarma> Oh. That helped? Not a very helpful error message..
<Seveas> yeah that helped it works now
* Seveas slaps self
<shawarma> Seveas: It really should give a better error message..
<Seveas> yeah
<shawarma> Seveas: Could you do me a favour and file a bug about it? I'll look at it tomorrow evening then.
<Seveas> bug 89735
<Ubugtu> Malone bug 89735 in network-manager-vpnc "Bogus error messages in case of user stupidity" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89735
<Seveas> shawarma, --^
<shawarma> I've got a patch already. :-)
<shawarma> Seveas: Are you on amd64 or i386?
<Seveas> 386
<shawarma> Seveas: Alright. I've got an updated vpnc package that might fix it. Would you mind testing it?
<shawarma> Seveas: Check your mail.
* shawarma buggers off for a little while.
<Seveas> shawarma, sorry for the delay
<Seveas> excellent, much better error message
<shawarma> Seveas: Great. I'll upload it right away.
#ubuntu-motu 2008-02-25
<pochu> slangasek: any chance you can sponsor the debdiff in bug 194536?
<ubotu> Launchpad bug 194536 in monodoc "FTBFS in latest archive rebuild test" [High,In progress] https://launchpad.net/bugs/194536
<TheMuso> ember_: Got mousetweaks covered.
 * ScottK wonders if FTBFS of mono related stuff might be considered a good thing.
<pochu> lol
<pochu> I guess not as tomboy is shipped by default
<ScottK2> pochu: Not in any distribution I use.
<ScottK2> ;-)
<pochu> heh, you win :)
<pochu> GNOME rocks btw :P
<ScottK2> For some definition of the word rock I agree with you.
 * pochu wonders why wordreference lists so many acceptions but none of them is like "to be great"
<pochu> perhaps I didn't get the meaning of it right
<pochu> Ok, I'm off to bed
<pochu> ScottK2: feel free to upload that monodoc debdiff :P
 * pochu runs to bed
<ScottK2> slangasek: If you're around and have a moment, I'd appreciate a bit of bin New on pypolicyd-spf.  I sort of forgot the transitional package the first time around ...
<slangasek> pochu: that doesn't fix the bug in the handling of cs-errors.zip, which means the package lacks a policy-compliant clean rule (it removes stuff that can't be regenerated).
<slangasek> ScottK2: this is on what suite
<slangasek> ?
<ScottK2> slangasek: It's an arch all package
<ScottK2> https://launchpad.net/ubuntu/+source/pypolicyd-spf/0.6-1ubuntu1
<slangasek> ScottK2: accepted
<ScottK2> slangasek: Thanks.
<emgent> heya
 * jdong figures out how to dynamically have torrent clients punchthrough his firewall....
<StevenK> jdong: Not run torrent clients seems to be one solution.
<jdong> StevenK: :P
<jdong> StevenK: well to protest, I'm writing a hackish ruby script to punch open ports :D
<RAOF> jdong: You can't get your firewall to respond to UPnP requests?  Or any of the other couple of "I'd like to accept some incoming connections, thanks" protocols?
<jdong> RAOF: my firewall is a localhost iptables
<RAOF> Right.  No so much with the UPnP integration.
<jdong> RAOF: and there's a number of programs that I use which open dynamic  port numbers that I would rather not try to fix
<jdong> RAOF: now I'm just trying to figure out how the hell to maintain half-decent security and not have ports punched open everywhere
<RAOF> Surely someone has tried to get iptables to do that?
<RAOF> In fact, google says: http://gentoo-wiki.com/HOWTO_Setup_UPnP_with_IPTables
<RAOF> jdong: Or there seem to be a number of NAT-PMP daemons out there if that floats your boat.
<jdong> RAOF: I think UPnP is overkill for this, I'd rather not require my program to be modified to support UPNP/NAT-PNP
<jdong> RAOF: I'm writing a wrapper such that I can run "punchfw cmdname arg1 arg2" and any ports the child process opens will be opened by iptables
<slomo_> superm1: hm, why was it rejected? :)
<slomo_> superm1: looking at the new packages now
<superm1> slomo_, for the exact reason i fixed in  there :)
<RAOF> jdong: Aaaah.  _That_ makes more sense.
<superm1> LGPL vs GPL
<slomo_> superm1: gnar... where? i checked this :)
<superm1> slomo_, the COPYING file says LGPL
<slomo_> superm1: and the files say GPL?
<slomo_> superm1: i hope you don't mind if i remove the -2 changelog? we can upload this as -1 again
<superm1> slomo_, hm then perhaps upstream has made mistakes in throwing the package together
<superm1> sure
<superm1> well the i386 binary was rejected
<superm1> i didnt get anything about the source package
<superm1> i wasnt sure if they all came as one upload
<slomo_> they do
<superm1> ook
<slomo_> *building* :)
<slomo_> sorry that i didn't catch this last time
<superm1> not a big deal, myself and at least 3 other people missed it too :)
<slomo_> scary :)
<slomo_> superm1: gmyth uploaded
<superm1> k great thx
<slomo_> erm, not the version you put on mentos 3 minutes ago though ;)
<slomo_> what did you change?
<superm1> well it's just the -1 in the changelog instead
<slomo_> ah ok
<superm1> like you had said to do
<slomo_> now -upnp :)
<slomo_> superm1: hm, but -upnp is GPL
<slomo_> superm1: and gmyth can link to gmyth-upnp, right?
<superm1> argh, yeah it should be allowed to
<slomo_> so this would render gmyth as GPL again...
<slomo_> superm1: could you talk with upstream to get gmyth-upnp LGPL too? :)
<superm1> well wait other way around though isn't it?
<superm1> gmyth-upnp links to gmyth
<slomo_> no
<slomo_> omg
<slomo_> gmyth's configure checks for gmyth-upnp
<slomo_> and the other way around
<slomo_> wtf
<superm1> and gmyth_upnp.c lists itself as LGPL
<superm1> i'll send a few emails to upstream about this...
<slomo_> superm1: i expect that gmyth-upnp's COPYING is wrong and should be LGPL
<superm1> yeah, that's what it looks like to me too
<slomo_> superm1: please ask them why they have this circular build dependency too :) that doesn't make sense to me
<slomo_> superm1: and if we know that, ping me and i'll review and upload, ok?
<superm1> slomo_, sure will do
<slomo_> :)
<superm1> everything else look kosher?
<slomo_> superm1: from a short look, yes... will look closer when this is clarified
<superm1> ok
<jdong> RAOF: whee, done, and it seems to work :)
<RAOF> Wooo!
<slomo_> pochu, persia: would be nice if you could get gst-plugins-bad0.10 and wildmidi synced/merged with my latest changes later ;)
<superm1> pochu & slomo_, i was going to let you guys know, neither MPEG2 TS or MPEG2 PS streams track at all
<superm1> you had asked for me to try both of them
<superm1> i can't skip around the recordings in either
<slomo_> superm1: ok
<superm1> er seek is probably the better word to use
<superm1> slomo_, i can however seek in a mpeg2-ps file if its opened directly in totem.
<superm1> mpeg2-ts i can't
<slomo_> superm1: yeah, mpeg2-ts doesn't work because the demuxer doesn't support seeking
<slomo_> superm1: for ps, no idea :)
<slomo_> it should work in theory
<superm1> well once upstream gets back to me on the other stuff, maybe i'll bugger them :)
<warp10> Good morning
<dholbach> good morning
<emgent> heya dholbach :)
<dholbach> hey emgent
<elmargol> morning
<elmargol> How do I see if a package has ubuntu changes?
<dholbach> elmargol: if the version number has a *ubuntu<n> it should have Ubuntu changes
<dholbach> elmargol: apt-cache showsrc <package> | grep ^Version
<elmargol> 3.2.0-2ubuntu1
<dholbach> elmargol: or     aptitude changelog <package>        if you want to know what kind of changes it has
<dholbach> elmargol: likely to have Ubuntu changes :)
<elmargol> ok this is going to be complicated :(
<elmargol> How do I merge a changefile? Do I take the debian changefile and add the latest ubuntu change?
<dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/Merging might have all the answers
<elmargol> thanx a lot
<dholbach> keep the ubuntu changelog entries
<emgent> morning \sh :)
<_ruben> question regarding rebuilding a kernel for ubuntu (server) .. with the official kernel package, uname -r will show 2.6.22-14-server .. im kinda confused on which params to use for make-kpkg to make my package end up 2.6.22-14-server-klips
<elmargol> \sh: Hi. can I help you to merge claws-mail-extra-plugins? Some plugins are not working for me (too old)
<elmargol> The only difference I see are those sylpheed-claws dummy packages
<pochu> slomo__: yeah, I'll merge that stuff!
<\sh> elmargol: oh I didn't upload the last packages...
<elmargol> \sh: the packages are out of sanc
<elmargol> sync
<\sh> elmargol: who did the last upload? give me a min to check this
<elmargol> you did the last claws-mail update
<\sh> elmargol: nope
<elmargol> Steve Langasek
<\sh> elmargol: I merged 3.2.0-2 together with the plugins
<\sh> elmargol: the last upload of 3.3.0 came from morten kjeldgaard
<elmargol> ah ok you did the last plugins merge
<\sh> elmargol: yes for 3.2.0...the version which is not in the archives anymore...claws-mail and claws-mail-extra-plugins are belonging together, so the uploader of the last version need to take action and push the extra-plugins to the very same version
<\sh> I wonder why this wasn't the case now
<\sh> and oh wonder...morten doesn't use launchpad
<\sh> does anybody know the ircnick of morten?
<\sh> elmargol: if you be so kind, please merge the new extra-plugins...and I'll happy to discuss with motu-release a FFE
<\sh> elmargol: I'm confident that no one would object the upload
<geser> good morning
<\sh> moins geser
<geser> Hi \sh
<persia> slomo, pochu: Thanks again.  Let me know if there is anything leftover that needs attention.
<elmargol> launchpad is somehow very slow
<slomo__> tsmithe: url? :)
<slomo__> persia: sf2 support... but tsmithe was looking into that
<persia> slomo__: If I'm lucky, I'll be able to integrate that patch before you upload :)
<slomo__> persia: which patch?
<persia> Also, if you're looking at fluid-soundfont changes, there's a candidate Ubuntu debdiff at https://bugs.edge.launchpad.net/ubuntu/+source/mscore/+bug/195179 (although I don't have a URL for a debian-target update).
<ubotu> Launchpad bug 195179 in mscore "Please update mscore to 0.9.1d+dfsg-0ubuntu2 (debdiff attached)" [Undecided,New]
<persia> The sf2 patch from tsmithe.
<persia> (it doesn't exist yet)
<slomo__> persia: what's mscore?
<persia> slomo__: It's an score-editor to go with the MuSE sequencer.  Let's you edit the staff, and plays it to you with a soundfont.
<tsmithe> slomo__, i'm thinking sf2 support may be a bit outside of my expertise, but i can persevere if you like. it would just take a while...
<tsmithe> slomo__, http://mentors.debian.net/debian/pool/main/f/fluid-soundfont/fluid-soundfont_3.1-1.dsc
<persia> tsmithe: If you are willing to work on it, please go ahead.  Feel free to ask me for help (although I've a bit of a learning curve to chase as well).
<slomo__> tsmithe: if you want... :) would be a nice feature but not too important i guess
<\sh> elmargol: if you can't do it, I'm sitting this evening and do the merge myself...
<elmargol> I'm done here
<elmargol> try to upload the debdiff to launchpad
<tsmithe> persia, right. i have to leave soon, but i can take a hack at it when i get back later today
<persia> tsmithe: No big rush.  It would be nice, but having any gstreamer-midi in hardy (even with freepats) is better than none.
 * persia suspects lenny may be a more reasonable timeframe for sf2 support.
<elmargol> \sh: somehow I can not upload the diff...
<tsmithe> ok :)
<\sh> elmargol: just send it to me by email...I'm taking care of it
<\sh> elmargol: sh at sourcecode dot de
<elmargol> \sh: only the debdiff?
<\sh> elmargol: the debdiff from 3.3.0-?? <debian version> to new ubuntu version
<\sh> elmargol: afaik we only need to add the old transitional packages to -extra-plugins because of upgrade from dapper to hardy
<elmargol> launchpad did work now
<tsmithe> slomo__, would you also be willing to upload my mscore package for debian? (once fluid-soundfont is through NEW)
<\sh> elmargol: cool..bug no?
<elmargol> 195369
<\sh> elmargol: I assigned the bug to me...and confirmed it and set prio to critical...(in my opinion it is :))
<persia> Does anyone have any suggestions about who might know about the use of Ubuntu to process CT scans?
<\sh> persia: decompile "CT scans" please :)
<elmargol> \sh: yes mail is critical :D
<persia> \sh: Applied Computed Tomography to successive radial X-Rays for multidimensional rendering of internal organisation (used for either of the big devices at hospitals where you go into a tube, and the technician in the next room makes pretty pictures).
<tsmithe> \sh, i think he means "computed tomography"
 * persia gives tsmithe a gold star for successful acronym expansion
<\sh> persia: thx :) I just needed a context for it ;) medical stuff is not on my list of acronyms for this channel ;)
<tsmithe> persia, it would be very cool if there was a package to deal with that (though i personally would have no use for it, not having a personal ct scanner and all)
<persia> tsmithe: There is such a package (ctsim).  I want to disable the GUI as porting it is painful, and it is the only reverse dependency of a library I'd like to drop.  Of course, I don't want to do this if anyone uses it.
<tsmithe> ahh. is that one of your wx2.4 packages?
<persia> The last one :)  bddebian and I uploaded the other two remaining packages about 12 hours ago.
<tsmithe> wow. that's very good going! and then i suppose we'll drop wx2.4?
<persia> Right, as nobody (not even upstream) wants to support it for the next few years.
<tsmithe> ah yes, which they would have to otherwise, as hardy is lts. got it.
<persia> tsmithe: lenny too.  There are actually two packages left in Debian, but one has a patch in the BTS and is expected to upload in the next couple months.
<tsmithe> right, but lenny's not too urgent. when is it expected to be released?
<persia> tsmithe: September or so, but freeze starts in June.
<tsmithe> hmm. the cycles seem to have sped up. etch was released not that long ago, but sarge was back in 2005.
<tsmithe> anyhow, i'm off
<\sh> oh damn...wtf is going on between keybuk and mjg?
<warp10> persia: regarding ctsim, I believe we can safely drop the GUI, based on the lack of support upstream, and also since it is just a simulator and not an actual CT appliance.
<persia> warp10: Perhaps.  Upstream seems to close most of the bugs that get opened against the package though.  Maybe just for hardy, and bring it back later.
<warp10> persia: sounds like a reasonable plan
<slicer> When updating a package, should the changelog include a (LP: #xxx) for the bug I'm uploading the diff.gz in?
<persia> slicer: Ideally.
<fdr> hello! I've modified the source in a source package to fix a bug (simply modified a translation...), now how do I make a diff to upload in launchpad? Thanks
<slicer> fdr: https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue
<coolbhavi> hello when does development for 8.10 start?
<pochu_> coolbhavi: when 8.04 is released
<coolbhavi> OK
<fdr> sladen, so debdiff is the way to go?
<persia> fdr: You'll want either diff -urN or debdiff, depending on how you made your patch.  There's a few links and some guide information available from https://wiki.ubuntu.com/MOTU/Contributing
<fdr> I simply did apt-get source <packagename>, and edited one single line of one single file with vim
<persia> fdr: Well, you've a choice.  You can follow the guidance from https://wiki.ubuntu.com/Bugs/HowToFix, or you can act as a member of the maintenance team, and prepare a new revision based on MOTU/Contributing.  It depends on how much time you have, and how familiar you wish to become with the tools.  Participants in this channel would be happy to help you either way.
<fdr> thank you, I think I will go with HowToFix, since it is just a very simple fix...  But I'll get back with the other way later, since there are a couple of apps that I'd like to see in ubuntu and I'd like to try packaging
<persia> fdr: Please share the bug number here when you have a patch.  There are a number of people who may be happy to package it and prepare the new candidate.  Thanks for helping to make Ubuntu better.
<fdr> ok thanks. Is it enough to write the bug number here?
<proppy> oy
<emgent> bug #195380
<ubotu> Launchpad bug 195380 in lighttpd "lighttpd crashes in some cases and giving a remote DoS possibility" [Undecided,New] https://launchpad.net/bugs/195380
<\sh> emgent: fixing the hardy stuff the patch is trivial
<fdr> persia, it is bug LP: #194745
<fdr> anything else I should do?
<phoenix24> I'm behind the University Proxy server, How can I use => bzr push bzr+ssh://..
<phoenix24>  ?
<\sh> phoenix24: blocked outgoing port 22?
<phoenix24> \sh: yes.
<slicer> Hm. SponsorsQueue on the wiki says that the debdiff should apply cleanly with -p1. However, Recipies/Debdiff says to run debdiff on .dsc's, which will unpack to /tmp/random/package, resulting in a patch that needs -p4. Which is right?
<\sh> phoenix24: there are solution, but they could violate your university security statement ... so I think you know that you could forward port 22 from an outside server to launchpad, and listen on this very same machine on a port which could be opened on your universities FW?
<phoenix24> \sh: Yes, can be done.
 * Fujitsu normally uses an external machine with SSH on 443, and tunnels through some accessible HTTPS proxy.
<phoenix24> are the there public servers that do port forwarding ?
<Fujitsu> I doubt it.
<phoenix24> Fujitsu: How do you forward your connection ?
<Fujitsu> I use SSH's port-forwarding capability.
<\sh> phoenix24: nope...you need your own rootserver e.g.
<phoenix24> In my case, is the server to be reached is : bazaar.launchpad.net ?
<\sh> phoenix24: well, you proxy server is blocking port 22 to the outside...so eventually port > 1024 are opened as destination ports...catch your rootserver which will have an ssh listen on 1025 e.g. and forwars this connection to port 22 of bazaar.launchpad...you can then configure ssh for your rootserver to use port 1025 instead of 22 and connect via bzr to your rootserver which will forward then the very same connection to port 22 of bazaar
<\sh> phoenix24: and this way is eventually a violation of your university security laws (which could give you problems with your universities authorities, as a reminder)
<phoenix24> :)
<phoenix24> is launchpad ID, same as the launchpad login id ?
<\sh> phoenix24: yes
<persia> bug #194745
<ubotu> Launchpad bug 194745 in language-pack-gnome-it "Misleading Italian translation for UML use-case" [Undecided,New] https://launchpad.net/bugs/194745
<persia> slicer: Either you need to install patchutils, or you've encountered a native package, for which the instructions are not as optimal.
<slicer> persia: It includes a upstream version change.
<persia> slicer: Ah.  debdiff isn't very good at that.  Just attach your new diff.gz to the bug.
<slicer> persia: I did, and was told to not do that but include the debdiff.
<persia> slicer: Which bug?
<slicer> persia: So I'm confused, and will include .diff, .debdiff and .interdiff
<slicer> bug 194836
<ubotu> Launchpad bug 194836 in mumble "Update to 1.1.3 (bugfixes)" [Undecided,Confirmed] https://launchpad.net/bugs/194836
<persia> slicer: No, don't do that.  Let's figure out what you should attach, and attach the right thing.
<slicer> persia: Er. Oops. Too late :(
<slicer> persia: I thought I'd give the eventual sponsor the freedom of choice. The interdiff is much easier to read through, the debdiff includes the upstream changes, and the .diff.gz is what should be applied to the final package.
<persia> slicer: You did exactly the right thing the first time.  When someone complains, and you think you did it right, feel free to check their LP page to see if they are sponsors, and ask again here.
<persia> slicer: If the interdiff is easier to read, the sponsor can't use it, because combinediff doesn't support hunking.
<persia> The debdiff cannot reliably be applied because it needs the new orig.tar.gz, and may end up with oddities in the diff.gz that aren't in the original as a result of application of the diff.  The diff.gz is the only bit that can be used.
<persia> Putting lots of things in the bug report just confuses sponsors, who really want that first attachment of yours, and should be ignoring the rest of them.
<slicer> persia: I understood that, but if the uploader wants to check that I didn't goof up, it's much easier to read. .. Then again, chances are the sponor knows how to use interdiff.
<persia> slicer: Right, and the sponsor oughtn't trust your interdiff anyway: they should be reviewing the package themselves (as they are signing off on it being correct)
 * slicer nods.
<slicer> Ok, so I just contributed to doing something in the wrong way? Bah :)
<slicer> And no, the commenter isn't a sponsor. Shame on me for assuming such.
<persia> slicer: It's OK.  Most of the sponsors check anyway.  You just did a bit of extra work, but at least you know now, and can be more efficient in the future.
 * persia notes that many non-sponsor commentors can have good feedback, and should not be ignored, but that when the suggestion runs counter to previous experience, it may be good to get a second opinion.
<slicer> persia: *nod*. I did update the .diff.gz to close the bug though. Though it's a bit of circular logic there, as the bug with the .diff.gz in it didn't exist until the .diff.gz was uploaded :)
<persia> slicer: That would be bug #179857
<ubotu> Launchpad bug 179857 in malone "Package sponsorships involve awkward bugtracker machinations" [Undecided,New] https://launchpad.net/bugs/179857
<slicer> Yes it would :) Nice to see it's being addressed.
<phoenix24> \sh: I've forwarded a local port (2222) to bazaar.launchpad.net (22). How do I configure bzr to use 2222, instead of 22 ?
<\sh> phoenix24: in your .ssh/config normally...
<\sh> phoenix24: not knowing if bzr+ssh uses the normal ssh stack
<phoenix24> ~/.ssh/config doesn't exist ?
<\sh> phoenix24: man ssh :)
<\sh> phoenix24: actually this is a question for #ubuntu :)
<phoenix24> ok! thanks
<persia> fdr: My apologies for the long delay.  The patch itself looks good, but that source package is in main, so I believe the translations are pulled from Rosetta (but would appreciate confirmation from someone more familiar), in which case your patch may not be the fastest way to get the fix applied.
<\sh> anyone from motu-release online? :)
<\sh> claws-mail-extra-plugins needs to be updated..the merge was done by elmargol, the merge looks good, and the new upstream release would solve a bug, which prevents latest claws-mail from working with the old version plugins
<\sh> is it ok to just upload and fix this bug, or should I file a FFE for it as reference?
<persia> \sh: From what I hear of policy, I believe the new upstream is supposed to not have any new features.  If there are also new features, it needs approval.  I believe the motu-release team is still discussing whether it needs a bug anyway, but it's probably safer to open and close a bug at least, even if you don't seek approval (and it never hurts to ask).
<\sh> persia: I'll fil
<\sh> e
<\sh> one
<persia> \sh: Seems the safest way.  If you're still not sure, maybe wait ~12 hours before running dput to see if any of motu-release respond.
<fdr> persia, thanks for your remark. Anyway, I think doing the fix with Rosetta is almost impossible, since it does not have a search function and I don't feel like browsing all the messages in the language pack... Or is there any alternative I am missing?
<Fujitsu> Good old bug #44.
<ubotu> Launchpad bug 44 in rosetta "Translations should be searchable" [Medium,Confirmed] https://launchpad.net/bugs/44
<persia> fdr: My apologies, but I have no idea.  I did one translation on Rosetta several years ago, and haven't used it since.
<fdr> ok, thanks!
<\sh> motu-release was the right team to subscribe for FFEs I hope
<persia> \sh: Yes.
<\sh> ok..bug #195369 :)
<ubotu> Launchpad bug 195369 in claws-mail-extra-plugins "[FF Exception] Please merge claws-mail-extra-plugins <3.3.0+dfsg-2> (universe) from Debian <unstable> (<main>)" [Critical,Confirmed] https://launchpad.net/bugs/195369
<\sh> I adjusted the bug actually
<persia> \sh: Now you just have to wait for either two ACK's or one not-for-us :)
<\sh> persia: well, not-for-us gives many angry users, including me ;)
<persia> \sh: "not-for-us" means not-for-motu-release, meaning not--a-FFe, meaning, "Just upload, already".
<\sh> persia: ah...;) I thought "not-for-us" means "no, we don't want this in" ;)
<persia> \sh: No, I've seen a couple FFe requests that were unsub'd as not-for-us because a member of motu-release didn't think they needed an exception.
<frenchy> fdr: As I'm sure that you've already read, just download the po to find the translation that you want.  Then fix it either online or in the po and re-upload.
<fdr> frenchy, mmm... thanks, but either I am missing something, or it takes particular privileges to re-upload the .po file...
<frenchy> Would I be wrong in assuming that getting a FFe for an "extra" would be easier than an "optional" or "recommended" priority?
<frenchy> fdr: well I can on my project ... let me try someone else's ... does the "Upload a file" option come up for you?
<persia> frenchy: Assuming the package has the correct Priority, likely, but it's really a matter of avoiding possible regressions or transitions, as there's not much time left for testing.
<frenchy> fdr: Yeah, LP can sometimes be a bit confusing.  I subscribe to the Brownian motion theory of just start clicking till stuff works ... i.e. Click the "View Template & All Languages..." to get the upload link.
<frenchy> fdr: Go figure.
<fdr> on dia, when I select the "translation" tab it says that the project is not set up to manage translations with launchpad, while when I can't find the page for language-pack-gnome-it
<fdr> mmm I *hate* LP. It seems just to be trying to stand in my way and nothing more.
<frenchy> persia: Thanks again.  Your continued effort amazes and inspires me.  I'm sure that a lot of developers get caught in this pattern of minor bugs fixes that they want uploaded (80-20 rule).
<frenchy> fdr: I hear you.  Somethings it does really well and I haven't really found a better alternative.
<fdr> well, I did no real work with either, since I only reported some bugs, but I liked bugzilla much more :)
<Hobbsee> boo
<persia> frenchy: Yep.  Personally, I tend to look at different packages after the freeze starts than I was chasing beforehand.  There are lots of easy bugs and simple packaging tasks that need doing that often get missed because nobody is paying attention to some package.
 * persia turns on all the lights
<frenchy> Hobbsee: boo who
<frenchy> Hobbsee: Don't worry .. that was a joke ... I laughed, so it hit its intended audience.
<frenchy> persia: Yeah, I'm now aware of the amount of work that you guys put in to hold this thing together.  3 Cheers for MOTU.  I have enough trouble with one.
<\sh> Hobbsee: my dear release member :) could you provide your opinion to https://bugs.launchpad.net/bugs/195369 , please? :) thx :)
<ubotu> Launchpad bug 195369 in claws-mail-extra-plugins "[FF Exception] Please merge claws-mail-extra-plugins <3.3.0+dfsg-2> (universe) from Debian <unstable> (<main>)" [Critical,Confirmed]
 * Hobbsee is playing with shiny things, and is therefore distracted
<\sh> Hobbsee: diamonds? :)
<joejaxx> https://launchpad.net/~joejaxx/+packages is looking sparse :( i need stuff to do lol
<Hobbsee> nope
<persia> joejaxx: There's about 200 packages that need maintainer mangling.  There are about 750 patches that need review and new candidate revisions prepared.  There's about 40,000 bugs available to be fixed.  You might also look at the output of `apt-cache unmet -i`.  Let me know if you run out again.
<mruiz> hi all
<Iulian> Hi
<DaveMorris> I've been using the opensg libs I created for hardy, and I've just noticed that a couple of install dependencies have been missed off, whats the policy for fixing this?
<DaveMorris> File a bug, and attach a debdiff I assume
<ScottK2> DaveMorris: Yes
<DaveMorris> how do you create a deb diff?
<slytherin> DaveMorris: debdiff oldversion.dsc newversion.dsc
<DaveMorris> who do I need to subscribe to get it fixed?
<\sh> ScottK: thx
<ScottK> No problem.
<\sh> ScottK: two acks are needed, right?
<ScottK> Yes
<ScottK> \sh: Approved.
<DaveMorris> ScottK once the bugs been fixed, who do I need to subscribe to it?
<ScottK> ubuntu-universe-sponsors
<DaveMorris> thnaks
 * DaveMorris makes notes for next time :)
<sistpoty|work> hi folks
<mok1> ScottK, have you had time to cast an eye on bug 156100 ?
<ubotu> Launchpad bug 156100 in storm "[hardy] please upgrade storm to version 0.12" [Undecided,Incomplete] https://launchpad.net/bugs/156100
<mok1> ScottK: ah, you did
<ScottK> mok1: Did you see my comment?
<mok1> I will go ahead and do the update, then
<lool> Hi folks; I'm pondering pushing gstreamermm (C++ bindings for GStreamer) which is a very new module to universe; I just pushed it to Debian experimental and thought it might be nice to have it in hardy for backports, third party devs etc. but would like to hear from you
<mok1> ScottK: I will assign the bug to me, ok?
<ScottK> Sure.
<sistpoty|work> lool: any reason, why it's not yet in unstable, but only in experimental?
<lool> sistpoty|work: Because we avoid publishing unstable API in Debian unstable in pkg-gnome/pkg-gstreamer
<lool> For example we don't publish the gtk or glib dev series in unstable because of this
<ScottK> lool: If it's not stable enough for unstalbe, it seems unlikely it'd be stable enough for us to drop in late in the release cycle.
<sistpoty|work> lool: I guess it would be better to get it in hardy+1 then, and backport it to hardy from there, what do you think?
<lool> ScottK: Ok; I was wondering whether it was too late for this cycle too
<ScottK> lool: We are past Feature Freeze.  It's need good justification.  I think, without knowing a lot on the topic, it would likely be better to wait.
<lool> I think we tend to merge unstable apps and unstable which are going to stabilize before release, but as I can't tell for gstreamermm it might be best to wait after release
<lool> +libs
<lool> "we tend to merge unstable apps and unstable libs which are going to stabilize"
<\sh> Hobbsee: thx...
<\sh> elmargol: uploading
<\sh> ScottK: btw...the bug was the original merging bug, and I set it to me and confirmed it...
<sistpoty|work> \sh: we use bug states for state of an FFe, confirmed means "granted"... (and bugs being confirmed will hence not show up on the working list of motu-release)
<\sh> sistpoty|work: yepp...next time I reset the bugstates :)
<sistpoty|work> :)
<joejaxx> persia: where do i get this grand list of non-mangled maintainer packages?
<joejaxx> the funny thing is
<joejaxx> i could probably write something up to fix all of those and build source packages for them
<joejaxx> lol
<joejaxx> hello dholbach and zul
<zul> hello
<dholbach> heya
<joejaxx> :)
<sistpoty|work> hi dholbach and zul
<dholbach> hey sistpoty|work
<dholbach> sistpoty|work: awesome work on the library packaging session
<sistpoty|work> thanks dholbach... w.o. slangasek it wouldn't have been that good however ;)
<dholbach> you guys rock, both :)
<RainCT> Hi
<sistpoty|work> hi RainCT
<stani> I need help to fix pychecker. Is there someone experienced in Python around ( ScottK )?
<RainCT> stani: just ask
<stani> The problem is that the test suite of pychecker supposes a python2.4 install, which leads to a FTBS.
<geser> stani: I once looked at pychecker
<stani> I am quite familiar with Python, but don't know how I can adapt the code so that all python 2.4 references are transferred to 2.5
<geser> stani: but I don't know if patching the test output of pychecker with python2.5 is the correct way
<stani> Better would be that pychecker tests against the current python versions and that version numbers are not hard coded in the test suite.
<geser> changing the path in the test suite isn't hard, but I don't know if the other test failure are a regression or not
<stani> geser: I am willing to review and fix all the tests, if someone can explain me how the test suite works. Especially where the expected output is defined.
<geser> the development version of pychecker mentions support for python2.5 in its changelog but last I checked it, it failed in the test suite too
<stani> Some tests may be related to the python version number, other tests might be due to a bug in pychecker. Probably I can fix them, but I just need to know how the information I asked above.
<geser> stani: see test_input/ for the tests and test_expected/ for the results
<emgent> heya
<geser> stani: debian/regression.sh is the script doing the tests
<stani> ok, geser, I'll start and will ask questions here if I get stuck.
<stani> geser: is there any information you still remember, from when you looked at pychecker?
<bddebian> Heya gang
<\sh> moins bddebian
<bddebian> Hi \sh
<sistpoty|work> hi bddebian
<bddebian> Heya sistpoty|work
<geser> Hi bddebian
<geser> stani: not more than I already told you
<sistpoty|work> bddebian: /me hopes to see ufoai in debian soon... strange enough, I downloaded it on the same day, before the thread started and am currently busy testing it *g*
<bddebian> Heya geser
<bddebian> sistpoty|work: Yeah, is it good? :)
<sistpoty|work> bddebian: well, I *loved* the old ufo - enemy unknown, and ufoai is even better :)
<mok1> ScottK: I've uploaded the diff.gz file for python-storm. Should I change bug status to New?
 * mok1 wonders why LP doesn
<mok1> ' do this by itself
<bddebian> sistpoty|work: I'll have to check it out.  Though it sounds like there's going to be licensing issues and I HATE those :-(
<sistpoty|work> bddebian: yeah... license issues in *data* files are a nightmare :(
<stani> geser: ok, fixed one test already ;-)
<warp10> gpe-mixer has an unmetdep on gpe-icons  >= 0.23 since Hardy ships gpe-icons 0.20-1.1. I was wondering if this could be worth to ask a FFe, since gpe-icons 0.25-1 (in sid) isn't changed so much and I would avoid to add an ubuntu1 delta to gpe-icons.
<warp10> ("delta to gpe-mixer", of course)
<mruiz> Hi all. Where can I find information about debian/control fields supported by Ubuntu?
<sistpoty|work> warp10: if it's an unmet dependency, sounds sane to me
<warp10> sistpoty|work: good. I'll report a sync request soon, at a first look gpe-icons has just some minor changes
<sistpoty|work> warp10: since it's an icons package, it also doesn't fall under FFe's imho but rather under ArtworkDeadline. ScottK, Hobbsee, TheMuso: agreed?
<hellboy195> sistpoty|work: time for some questions about sensors-applet?
<sistpoty|work> hellboy195: what's up?
<hellboy195> sistpoty|work: as I see on the homepage currently there is only nvidia support. also ati support planned?
<sistpoty|work> hellboy195: no idea... actually... maybe asking upstream?
<hellboy195> sistpoty|work: ah thought you know it maybe .. :) nvm. and I should also ask upstream why the indicator for my graphics card is red though it's running at 47Â°?
<warp10> sistpoty|work: if we consider it under ArtowrkDeadline it should be fine syncing it before UIF, shouldn't it?
<sistpoty|work> hellboy195: yes, please ;)
<sistpoty|work> warp10: yes
<hellboy195> sistpoty|work: ^^ k, anyway. thx :)
<sistpoty|work> np
<hellboy195> afflux: ahoi ;)
<afflux> morning hellboy195! :)
<ScottK> sistpoty|work: Since it's not Ubuntu artwork, but more general, I think it needs an FFe, but I don't see a problem with giving it.
<sistpoty|work> ScottK: ok, makes sense
<bobbo> does anyone have any docs on syncing packages from Debian? I'd like to add ogre-plugins-cgprogrammanager to Universe to fix Bug #194686/Bug #195065
<ubotu> Launchpad bug 194686 in funguloids "Error installing Funguloids: ogre-plugins-cgprogrammanager doesnt exist" [Undecided,New] https://launchpad.net/bugs/194686
<ubotu> Launchpad bug 195065 in ubuntu "Please sync ogre-plugins-cgprogrammanager from debian unstable" [Undecided,New] https://launchpad.net/bugs/195065
<RainCT> bobbo: You have to do some changes in the "Please sync..." bug and then subscribe ubuntu-universe-sponsors. If a MOTU thinks that the sync is OK he will change the status to confirmed and subscribe ubuntu-archive, and then an archive admin will do the sync
<geser> RainCT: what about the needed FFe?
<RainCT> bobbo: a sync request should look like this : a) bug title: "Please sync <package name> <version> from Debian unstable (<main/contrib/non-free>)";  b) explain what the changes in Debian are and if there were any Ubuntu changes why they can be dropped (this isn't applicable in this case); c) include a rational about why it should be synced
<RainCT> and in this case as geser says you'll also need a Freeze Exception
<sistpoty|work> jdong: can you comment on bug #195389 please?
<ubotu> Launchpad bug 195389 in deluge-torrent "Please sync deluge-torrent 0.5.8.4-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/195389
<bobbo> RainCT: ok, im on it
<RainCT> geser: for the freeze exception, should contributors subscribe motu-release before u-u-s, or just subscribe u-u-s and let the sponsor subscribe motu-release?
<jpatrick> RainCT: before to allow acking
<bobbo> Ok, ive fixed up the description, im guessing i subsribe motu-release now for the FFe?
 * jdong grumbles at deluge's large diffstat
<geser> RainCT: I'd say motu-release and if the FFe got granted u-u-s (if it's still needed, perhaps the FFe counts as an ACK)
<RainCT> jpatrick, geser: thanks
<jpatrick> bobbo: yes
<bobbo> jpatrick, RainCT: right thats the title/description updated and motu-release subscribed, anything else I need to do?
<jpatrick> bobbo: wait :)
<RainCT> heh
<sistpoty|work> RainCT, geser: well, at least for what I ack with the motu-release hat, I don't consider this necessarily an ACK for sponsoring (as I don't test-build the package)
<jdong> sistpoty|work: commented...
<sistpoty|work> jdong: thanks
<jdong> sistpoty|work: though let the record show that's an ok with a grumble attached
<jdong> :)
<sistpoty|work> heh
<geser> sistpoty|work: doesn't the FFe needs a build log?
<sistpoty|work> geser: yes, though I'm not too sure why (and looking at a build log and building it myself is still a difference (e.g. buildlog outdated))
<emgent> heya blueyed :P
<blueyed> Hi emgent :)
<bobbo> sistpoty|work: in bug #195065 you said you can only sync source packages, where do i get the source package?
<ubotu> Launchpad bug 195065 in ubuntu "Please sync ogre-plugins-cgprogrammanager 1.4.6-1 from debian unstable contrib" [Medium,Invalid] https://launchpad.net/bugs/195065
<bobbo> sistpoty|work: wait, doesnt matter, found it
<sistpoty|work> bobbo: apt-cache showsrc in an unstable chroot is what works for me... others than that there is also packages.debian.org/packagename with links
<bobbo> sistpoty|work: thanks, got the package and added it to the report
<sistpoty|work> bobbo: also the necessary build log, diffstat and diff of upstream changelog?
<bobbo> sistpoty|work: not got that yet ;)
<sistpoty|work> then please add it ;)
<jpatrick> bobbo: see bug #192350 for an example
<ubotu> Launchpad bug 192350 in semantik "[Feature Freeze Exception] New upstream release" [Undecided,Fix released] https://launchpad.net/bugs/192350
<bobbo> jpatrick: thanks :D
<bobbo> jpatrick, sistpoty|work: is the diffstat etc between the Debian Version and Current Ubuntu version?
<jpatrick> bobbo: between the two releases
<\sh> DktrKranz: Re: bug #185513 -> the dh_strip in our sbuild chroot needs a fix...adding this to the amd64 part of debian/rules in wine doesn't help actually
<ubotu> Launchpad bug 185513 in wine "Wine packages overly large" [Undecided,New] https://launchpad.net/bugs/185513
<bobbo> jpatrick: the package isnt in Ubuntu though...
<jpatrick> bobbo: then no need I guess
<sistpoty|work> bobbo: ogre-contrib is in hardy?
<DktrKranz> \sh, I tested only in i386 and it worked. I haven't any amd64 boxes to test it out.
<\sh> DktrKranz: on i386 it works without any problem :)
<\sh> DktrKranz: it's only on amd64
<bobbo> sistpoty|work: it is but not building ogre-plugins-cgprogrammanager
<DktrKranz> so, it's just half-a-fix :)
<sistpoty|work> bobbo: aha... because it obviously failed to build
 * bobbo goes to check logs
<sistpoty|work> bobbo: which could be related with that old changelog entry: " * Bootstrapping will be done manually."
<DktrKranz> \sh, anyway, main issue is segfaults. I tried to look at them, but got no useful details, even with dbgsym
<\sh> DktrKranz: it looks like that something is terribly wrong...when invoking wine from != a direct wine src tree dir
<\sh> DktrKranz: there are some messages on wine-devel ml...
<sistpoty|work> bobbo: nope, looks like s.th. different is making problems: http://launchpadlibrarian.net/11901495/buildlog_ubuntu-hardy-i386.ogre-contrib_1.4.5-1_FAILEDTOBUILD.txt.gz
 * bobbo never gets the easy bugs :/
<jpatrick> bobbo: there are none
<DktrKranz> \sh, so it's not just us... this is good and bad at the same time
<bobbo> heh :)
<hellboy195> bobbo: start with merging ^^
<\sh> DktrKranz: yeah...
<geser> bobbo: there is a nvidia-cg-installer in multiverse but it won't work on the buildds as it wants net access (for downloading) and the buildds have no net access
 * bobbo is now yoyally confused over ogre-contrib bug :/
<bobbo> s/yoyally/totally
<jpatrick> bobbo: http://paste.ubuntu-nl.org/57358/ - it's missing a libraby
<geser> bobbo: the last version in Debian has "* Specify Build-Depends and Depends on nvidia-cg-toolkit (>= 2.0)" so it might work now
<bobbo> jpatrick, geser: so the original plan of merging in the current debian version might work?
<DRebellion> how can i get pbuilder to use a hardy enviroment for building packages? I have changed the DISTRIBUTION= variable in /etc/pbuilderrc but it seems to still build under gutsy =/
<DRebellion> i am running gutsy btw
<jpatrick> DRebellion: you sure it's not DIST=hardy? :)
<DRebellion> jpatrick, from /etc/pbuilderrc:
<DRebellion> # specifying the distribution forces the distribution on "pbuilder update"
<DRebellion> DISTRIBUTION=hardy
<jpatrick> DRebellion: hrmm, then I have my pbuilder set up differently
<DRebellion> :(
<HighN1> DRebellion: did you 'reinit' pbuilder after changing the distribution?
<DRebellion> HighN1, erm, no?
<HighN1> DRebellion: wait a sec...
<HighN1> DRebellion: sudo pbuilder update --distribution hardy --override-config
<DRebellion> HighN1, i did that, but when i go to build a package it starts to download all of the gutsy packages again!
<HighN1> DRebellion: hm, how do you bulid your package?
<DRebellion> HighN1, sudo pbuilder build --logfile ~/pbuilder3.log package.dsc
<HighN1> DRebellion: just a try: sudo pbuilder build --distribution hardy --logfile ~/pbuilder3.log package.dsc
<bobbo> sistpoty|work, jpatrick: What information do i need to add to the FFe/Sync request?
<DRebellion> HighN1, i'll give that a shot. its just that i shouldn't have to specify on the cmd line every time right?
<jpatrick> bobbo: the ones in the example I gave you
<HighN1> DRebellion: Right. I can't tell - I did it the other way - sudo pbulider login  gives you a full chroot environment with a bash, there you can do the debuild manually. that works for me all the time...
<bobbo> jpatrick: ive lost the link (embarrased), can you send it again?
<jpatrick> bobbo: https://launchpad.net/bugs/192350
<ubotu> Launchpad bug 192350 in semantik "[Feature Freeze Exception] New upstream release" [Undecided,Fix released]
<bobbo> jpatrick: thank you!
 * sistpoty|work heads home
<sistpoty|work> cya
<DRebellion> Hrm, still can't get this hardy pbuilder to work properly... could someone talk me through the steps to get a hardy pbuilder enviroment? HighN1?
<bobbo> jpatrick: that should be everything that needed up for Bug #195065 if you are interested
<ubotu> Launchpad bug 195065 in ubuntu "Please sync ogre-contrib (1.4.6-1) from debian unstable contrib" [Medium,New] https://launchpad.net/bugs/195065
<james_w> DRebellion: you might like to try pbuilder-dist from ubuntu-dev-tools, but I think that might mean you creating a new chroot.
<DRebellion> james_w, that's not a problem, I only need the default (and only) chroot to be hardy.
<HighNo> DRebellion: hm, I did everything according to this wiki: https://wiki.ubuntu.com/PbuilderHowto
<DRebellion> HighNo, same.
<HighNo> DRebellion: brb
<james_w> DRebellion: pbuilder login --save-after-login
<james_w> DRebellion: then edit /etc/apt/sources.list to say hard, then run update; dist-upgrade and log out
<jpatrick> bobbo: see noresetto's comment on the bug :)
<bobbo> jpatrick: just got the email, checking it out now
<tsmithe> slomo__, thanks for the upload
<bmhm> hi all
<bmhm> I'd like to mention THIS backport URGENTLY: https://bugs.launchpad.net/gutsy-backports/+bug/192751
<ubotu> Launchpad bug 192751 in gutsy-backports "Backport of network game "pioneers"" [Undecided,New]
<pochu_> bmhm: what's urgent from it?
<slangasek> wow, pioneers is urgent, how far we've come
<bmhm> pochu_: I've been waiting for... weeks =)
<bmhm> pochu_: can't I provide MY packages?
<bmhm> I can provide gutsy amd64 and edgy x86
<pochu_> no, you can't. packages are built in ubuntu buildds
<bmhm> I see. Anyway, thanks for the tipp regarding prevu. Wounderful tool.
<bmhm> Indeed.
<ScottK> bmhm: Once it's tested, set the bug to Triaged.  I don't even look at New backports requests.
<bmhm> thanks ScottK
<bmhm> ScottK: What is "Triaged"?
<ScottK> In general terms it means that the bug has been evaluated and a root cause has been determined (it's ready for a developer to look at fixing)
<ScottK> We use it in backports to mean it's fully tested and ready to be looked at for approval.
<bmhm> I didn't see the option "Triaged"
<bmhm> So i picked confirmed instead
<ScottK> Confirmed is fine.
<ScottK> Triaged has some restrictions on it.  I look at confirmed too.
<bmhm> fine
<LaserJock> RainCT: ping
<RainCT> LaserJock: pong
<LaserJock> RainCT: I had a chance to test pbuilder-dist
<RainCT> LaserJock: evil again? ;)
<LaserJock> well, kidna
<LaserJock> *kinda
<LaserJock> I needed to fix something
<RainCT> LaserJock: ya?
<LaserJock> RainCT: at the very bottom of the actual pbuilder command, it sets the aptconfdir
<LaserJock> and the quoting is incorrect I believe
<LaserJock> when I tried to do a pbuilder create it actually added a " to the path
<LaserJock> so I just made that line: $( [ $ISDEBIAN != "False" ] || echo "--aptconfdir ${BASE_DIR}/etc/${DISTRIBUTION}/apt.conf/" ) \
<LaserJock> and it seemed to work fine after that
<RainCT> LaserJock: can you try if      $( [ $ISDEBIAN != "False" ] || echo "--aptconfdir '${BASE_DIR}/etc/${DISTRIBUTION}/apt.conf/'" ) \      works, please?
<RainCT> LaserJock: I think it wouldn't work if the basedir contains spaces if it has no quotes at all
<LaserJock> hmm
<LaserJock> RainCT: no go, it still puts ' in the path
 * RainCT is pondering if rewriting the damn think in Python might help :P
<geser> RainCT: it can't get worse :)
<hellboy195> geser: quick question. I'm doing bug 195532 is bug 186130 really necessary?
<ubotu> Launchpad bug 195532 in libnxml "Merge libnxml 0.18.1-4 from Debian(Unstable)" [Undecided,New] https://launchpad.net/bugs/195532
<ubotu> Launchpad bug 186130 in libnxml "libnxml needs a versioned build-dependency on cdbs" [Undecided,New] https://launchpad.net/bugs/186130
<LaserJock> RainCT: honestly, I think it could be much simpler as well
<RainCT> LaserJock: I'm adding the original script as pbuilder-dist-simple right now ;)
<LaserJock> doing it in Python is an idea though
<geser> hellboy195: if you do the merge please also the second bug
 * ScottK2 cheers simplicity
<LaserJock> it seems like right now though it's too easy to break it
<geser> hellboy195: *fix the second bug
<RainCT> Indeed. I think I'll have a go at converting it to Python, that should make it much more robust
<hellboy195> geser: so it's necessary though he has a gutsy machine and I suppose on hardy there aren't problems?
<captlogic> quit
<geser> hellboy195: on hardy it's no problem (else it would FTBFS), only when backporting
<hellboy195> geser: . so I suppose cdbs (>= 0.4.5)
<geser> hellboy195: check the cdbs changelog when it was introduced
<hellboy195> geser: k, thank you :)
<geser> hellboy195: cdbs (>= 0.4.49ubuntu5)
<hellboy195> geser: ah. again thx :)
<mok0_> he
<ScottK2> llo
<dsop> does revu notice when the version number of an not yet approved package changed?
<LaserJock> dsop: how do you mean?
<joejaxx> LOL
<joejaxx> the next version of ubuntu is called Intrepid Ibex ?
<LaserJock> uhh, yeah, where have you been? ;-)
<joejaxx> :P
<joejaxx> hello LaserJock :)
<LaserJock> hiya joejaxx
<LaserJock> how's it going?
<joejaxx> it is going well :D
<dsop> hmm LaserJock my upload wsa rejected but i had revu upload rights two month ago
<LaserJock> dsop: did you use the same name & address in the changelog entry?
<dsop> LaserJock: in the debian changelog, yes
<LaserJock> dsop: you probably need to talk to a REVU admin
<LaserJock> if it was two months ago that you last uploaded I'd think it'd be ok
<mok0_> ScottK: I uploaded a diff.gz to bug 156100 .
<ubotu> Launchpad bug 156100 in storm "[hardy] please upgrade storm to version 0.12" [Undecided,Incomplete] https://launchpad.net/bugs/156100
<RainCT> dsop: what's your email?
<dsop> RainCT: sn_@gmx.net
<dsop> RainCT: i got Signer has no upload rights at all to this distribution.
<pochu_> dsop: are you sure you dput to revu? ;)
<RainCT> you're in the database
<pochu_> (if you just dput, it will go to the ubuntu archive)
<dsop> argg
<dsop> pochu_: okay, man i should read better the wiki nexttime
<pochu_> dsop: it once happened to me the other way round, I dput'ed to the archive instead of to revu ;)
<RainCT> pochu_: you're not the only one ;)
<HighNo> hehe - i guess one is a real motu only if you have done that at least once...
<jdong> spawn new motumedia_member()
<pochu_> jdong: who's him?
<jdong> looking for any :)
<pochu_> heh
<jdong> or anyone else who knows what happened to xvidcap
 * pochu_ hides from jdong ;)
 * HighNo is out since he still uses feisty...
<pochu_> jdong: ah, so you aren't recluiting :)
<jdong> pochu_: ha like I have the power to recruit ;-)
<pochu_> HighNo: that's old!! ;)
<jdong> hmm FFe for a FTBFS'ed package since like Feisty.
<jdong> shouldn't be hard to grant, right?
<jdong> </famous last words>
<HighNo> pochu_: true, but it is still working. Updating would be nice but only 150MB free atm. Updating would require like 1GB... :-(
<pochu_> jdong: if it builds with the new version, I don't think so :P
<jdong> Local variables:
<jdong> mode: debian-changelog
<jdong> End:
<jdong> WTF is that stuff?
<jdong> found it at the end of debian/changelog
<jdong> I'm guessing some of marillat's editor cruft?
<man-di> jdong: for emacs
<jdong> man-di: is it supposed to be at the bottom of debian/changelog or should I snip it out?
<man-di> if its there emacs uses that settings for that file
<HighNo> snip it - that should not be there
<man-di> if its not there, it uses its default settings
<bobbo> hi, ive got a fix available for Bug #195196 but dnot know whether i should forward it to Debian or add the patch to the Ubuntu bug
<ubotu> Launchpad bug 195196 in graphmonkey "graphmonkey: Upgrade to new upstream release (1.7)" [Wishlist,Confirmed] https://launchpad.net/bugs/195196
<man-di> jdong: there are many many packages with this
<jdong> man-di: so it's safe to leave in?
<man-di> jdong: yes, doesnt hurt
<HighNo> man-di: there are?
<man-di> HighNo: I have seen this a couple of times in Debian packages
<jdong> ok, then I'll leave it in. I was concerned because *cough* vim puts it in syntax error red :)
<man-di> jdong: vim is not optimal either
<HighNo> jdong: I guess vim is not debian compliant here :-)
<jdong> lol here we go... :)
<man-di> too many false positive errors for debian/control files
<jdong> yeah vim does seem to be chicken little with that
<dsop> please, is some of the motus willing to review gcutils?
<jdong> urgh I made the most retarded upload ever
<Fujitsu> Does anybody else find that Thunderbird hangs when gnome-settings-daemon crashes?
<hellboy195> Hi, I want to merge nspluginwrapper 0.9.91.5-2 from Debian. With the -1ubuntu1 version people suffer from crashes like bug 195170 . The problem is that I have no idea if new Debian revision fixes these issues. So merge or wait?
<ubotu> Launchpad bug 195170 in nspluginwrapper "npviewer.bin crashed with SIGSEGV in g_slice_free_chain_with_offset()" [Undecided,New] https://launchpad.net/bugs/195170
<Fujitsu> Neither. Test.
<hellboy195> Fujitsu: well, personally I don't usw nspluginwrapper. Maybe I find a person who is willing to test :)
<hellboy195> *usw
<hellboy195> *use
<hellboy195> argh
<albert23> RainCT: Thanks for sponsoring gcal. Regarding forwarding the changes to Debian, can I send them the Ubuntu debdiff or should I make a Debian version?
<RainCT> albert23: You're welcome :). You choose, the main thing is that they get the changes.
<albert23> RainCT: OK, thank's, I will make a Debian version then
<Flare183> What does this mean: create all leading components of DEST except the last, then copy SOURCE to DEST
<Flare183> I don't get it
<Flare183> bug 175404
<ubotu> Launchpad bug 175404 in ubuntu "[needs-packaging] Nemo" [Wishlist,In progress] https://launchpad.net/bugs/175404
<Flare183> exactly
<Flare183> that is the one I am working on
<LaserJock> Flare183: I think you need to describe your question more, I can't quite figure out what you're asking
<Flare183> LaserJock: ok on the Man page for Install it says that the "-D" syntax means this: create all leading components of DEST except the last, then copy SOURCE to DEST; What does that mean?
<Flare183> esp. the part about except the last
<Flare183> correction "except the last"
<LaserJock> I guess it's just "create the directory structure, then copy"
<Flare183> LaserJock: ok thanks
<macd> whats the best way to take an existing package, add an init script to it and repackage? I've read a bit about dh init but I can't seem to discern howto use it, I've looked at a few packages that have init scripts, but they're pretty big can someone recommend a smaller package to peep out?
<mok0_> macd: look what's in /etc/init.d
<macd> Im not sure how that helps me use dh init?
<mok0_> macd: all you need is to put it in debian and call it <package>.init
<macd> if its that simple I feel like a fool
<macd> thx :)
<mok0_> macd: you just call dh_init in debian/rrules and it takes care of it
<mok0_> dh_init is in the rules template, iirc
<macd> ok, another question, if a package exists, and the only thing it needs is an init script to add alot of functionality, is it better to just repackage with included script, or package the script seperate?
<macd> I should mention, it has an init script already, but this gives the ability to start one or more instances, so it really expands the existing one
<LaserJock> slangasek: your sync bugmail always munges the title of the email to be [Bug #] Synced, would it be possible to have it not do that?
<slangasek> LaserJock: to what mail are you referring?
<LaserJock> when you do syncs
<slangasek> I don't send mail when I do syncs
<LaserJock> well, I'm assuming the script you use does
<geser> slangasek: but you add a comment to the sync bug which gets then mailed
<LaserJock> take bug #195032
<ubotu> Launchpad bug 195032 in starplot "Please sync starplot 0.95.4-3 from Debian(Unstable)" [Wishlist,Fix released] https://launchpad.net/bugs/195032
<LaserJock> that's the one I got today
<slangasek> yes, all I'm doing is adding comments to the bug in launchpad. If that generates mails with wrong subjects, I would think that's a LP issue?
<LaserJock> hmm
<LaserJock> odd
<LaserJock> I was assuming it was a script
<slangasek> there is a script.  but it works by adding comments to LP, not by sending email.
<LaserJock> sure
<LaserJock> ahh, perhaps it sets the "Subject" line in the comment
<geser> that's what it does
<LaserJock> I remember seb128's sync seemed to do that when he first became and archive admin
<slangasek> well, ok, so what are you suggesting the subject should be instead?
<LaserJock> no subject
<slangasek> (anyway, pitti maintains this script, not me)
<LaserJock> then it just get's the bug's subject
<slangasek> ok
<LaserJock> I need a MOTU for a huge favor
<StevenK> LaserJock: You're all out of favours
 * geser hides
<LaserJock> dang
<LaserJock> I actually need somebody to look over 5 Multiverse packages I'm going try to upload
<LaserJock> I think they should be pretty ready to go
<LaserJock> but I'd like to get a 2nd opinion
 * geser says good night
<LaserJock> heh
<Legendario> what am i supposed to do to pack a source which has only an install script?
<RAOF> Legendario: Write a debian/rules file which has an empty build: target, and call the install script in the install: target?
<Legendario> RAOF, what is an empty build?
#ubuntu-motu 2008-02-26
<azeem> an empty build target, not an empty build
<Legendario> azeem, what is it?
<azeem> what is what?
<Legendario> azeem, an empty build target
<azeem> Legendario: what is a non-empty build target?
<azeem> or rather, what is a build target?
<Legendario> azeem, maybe both
<azeem> no, I'm asking you
<Legendario> azeem, sorry. English is my second language, i don't program, and that does not make sense to me...
<azeem> Legendario: why do you want to pack the source yourself then?
<azeem> Legendario: or maybe otherwise asked, what would you do if the source had more than just an install script?
<Legendario> azeem, because I want to learn... and help
<azeem> ok, then what kind of research did you do so far about "debian/rules build target"?
<Legendario> azeem, i have created 3 packages so far by following the packaging guide
<Legendario> that's all i know
<azeem> ok
<azeem> Legendario: the Debian Policy Manual probably discusses the various debian/rules targets, including the build target
<azeem> gotta go now, bye
<tsmithe> Legendario, a target in a makefile is a name for the collection of commands it runs
<tsmithe> if you look in a debian/rules (or and Makefile), you will see it is formatted like this:
<tsmithe> <target>: <dependencies>
<tsmithe>   <rules>
<tsmithe> if <dependencies> have not been run when <target> is called, they are run first, in the order listed, and then <rules> are executed
<tsmithe> "build" is one of the targets required in a debian/rules file, and it generally builds the sources into binaries
<tsmithe> it could have a "configure" rule as a dependency, which would configure the build process to run
<tsmithe> if the package has no sources that need building, you need not specify any rules, or any dependencies, but the target must still exist to comply with policy.
<Legendario> tsmithe, thanks for such a detailed explanation!
<tsmithe> no problem. it's good to have new contributors willing to learn :)
<pochu> slomo__, superm1: gmyth out of Debian NEW \o/
<pochu> next step --------> syncing!
 * tsmithe can't wait to go through the same process for fluid-soundfont. that would be my first debian package :D
<Legendario> tsmithe, is there an easy way to edit the debian/rules in order to achieve it, or a model to follow. My bash scrit habilities are few...
<tsmithe> Legendario, just do some research on makefiles, look at the debian policy and debian/ubuntu packaging guides/new maintainers guides, and play around with the files that are already there
<tsmithe> i presume you used dh-make?
<tsmithe> (to create a skeleton package)
<RAOF> Legendario: Also, try some non-CDBS packages.  CDBS conceals all these targets.
<Legendario> use dh_make
<Legendario> RAOF, i realized that
<tsmithe> yeah, don't use cdbs until you know how the system works ;)
<Hobbsee> morning all
<LaserJock> hola Hobbsee
<Legendario> thanks tsmithe
<Legendario> and RAOF
<tsmithe> no problem
<nixternal> hiya Hobbsee and LaserJock
<Legendario> any suggestion on a makefile "tutorial"?
 * nixternal pets kdevelop for doing the makefiles for me
<Legendario> tsmithe, a good one...
<tsmithe> Legendario, sorry, but i'm sure google can
<LaserJock> Legendario: what specifically are you having trouble with?
<tsmithe> each line is a command executed in its own shell
<tsmithe> the rest seems self-explanatory...
<Legendario> tsmithe, google has lots of those. I was hoping there is a reference one
<Legendario> LaserJock, i am trying to pack a program that has only an install script
 * tsmithe just learned by example, so he doesn't have much to recommend
<Legendario> got to know i have to learn more about makefiles...
<LaserJock> Legendario: it's really easy thought
<LaserJock> *thought
<LaserJock> bah
<tsmithe> hehe
<LaserJock> *though
<LaserJock> there
<tsmithe> ;)
<LaserJock> Legendario: as azeem said you need an empty build rule
<MECU> I'm new and I read that I could help out by compiling programs, where do I find the programs (packages) that need to be compiled?
<tsmithe> Legendario, what don't you get about makefiles? i explained the structure...
<nixternal> MECU: are you familiar with Debian/Ubuntu packaging? If not, check out https://wiki.ubuntu.com/PackagingGuide for some information on that
<LaserJock> Legendario: each rule (the unindented part that has a :, like configure:, build:, etc.) has the lines that are need to build the package
<Hobbsee> sigh.  how does one make wine behave now?
<nixternal> MECU: https://wiki.ubuntu.com/MOTU has a todo list and more information as well for you
<MECU> yes, I just read though that, okay, thanks nixternal
<nixternal> Hobbsee: you think you are jesus or something? You think you can make wine do whatever you want? :p
<Hobbsee> hehe
<Hobbsee> or at least run
<MECU> wouldn't that be: cp water wine ?
<nixternal> I haven't tried running the ie4linux stuff..let me see
<ScottK2> Hobbsee: You browbeat \sh until he fixes it.
<nixternal> yup, wine isn't working here
<Legendario> LaserJock, it has a build and a build-stamp section. How do i call the install script?
 * Hobbsee sighs
<Hobbsee> why give me an executable to unzip something, anyway...
<LaserJock> Legendario: you do that in the install: rule
<tsmithe> could someone upload https://bugs.edge.launchpad.net/ubuntu/+source/mscore/+bug/195179 please? (to clarify, i don't think it requires a FFe)
<ubotu> Launchpad bug 195179 in mscore "Please update mscore to 0.9.1d+dfsg-0ubuntu2 (debdiff attached)" [Undecided,New]
<Legendario> LaserJock, like adding $(CUR_DIR)/install.sh
<LaserJock> right
<Legendario> LaserJock, should i erase the build and build-stamp sections?
<LaserJock> keep build: it's required
<RAOF> Hobbsee: By installing the Gutsy package from winehq, sadly.  Or possibly rebuilding our package locally with an older gcc.
<LaserJock> but it can be empty
<Hobbsee> RAOF: right
<RAOF> Hobbsee: It hasn't been all bad.  I learnt about aptitude forbid-version :)
<StevenK> RAOF: Wine doesn't like gcc 4.2?
<Legendario> LaserJock, what about the build-stamp one?
<RAOF> StevenK: Apparently building with an older gcc makes wine not segfault immediately.
<LaserJock> Legendario: you can remove it and any references to it
<RAOF> StevenK: I haven't tested this personally.
<RAOF> Legendario: The build-stamp target is there to make sure the source gets built exactly once; you'll notice that the last thing it does is to create a file called "build-stamp".
<RAOF> Legendario: This means that if someone calls the build: target again, build: will see that the build-stamp file already exists, and so won't call the target again.
<Legendario> LaserJock, thanks... I learn a lot every time i get here. And by packaging, i learn a lot of computing too... ;-)
<Legendario> LaserJock, but i think this could be added on the packaging guide
<LaserJock> well, it's a wiki, everybody is more than welcome to help :-0
<LaserJock> :-) rather
<Legendario> LaserJock, after i get good on it... I may try it. :-P
<slangasek> geser: bug #195453 - should xen-unstable also be blacklisted for sync?
<ubotu> Launchpad bug 195453 in xen-source "Please remove xen-{source,unstable} from hardy" [Undecided,Fix released] https://launchpad.net/bugs/195453
<Legendario> LaserJock, the install section has a build option. Am I supposed to erase it too?
<RAOF> Legendario: By "build option" you mean "declares a dependency on build", right?  Since you don't actually need to build anything, you can either leave that in (since build is empty), or preferably remove it.
<RAOF> Legendario: As in: the makefile contains a line "install: build", right?
<Legendario> RAOF, that's it
<RAOF> Right.  So that says "you have to run the build target before the install target".  Since your build target does nothing, this is harmless but unnecessary.
<Legendario> ok
<LaserJock> dang, I can't figure out why my old laptop is sooooo slow
<LaserJock> I did a fresh Gutsy install and it seems way slower than before
<mok0_> huh? qa.ubuntuwire.com is still not operational
<nixternal> haven't seen imbrandon around either for a bit
<ScottK> He was seriously sick in bed a few days ago (I called him).
<tbf> superm1: so someone really run gnome-lirc-properties. seems i've got a victim of having a symlink to my working copy in /usr/lib/python2.5/site-package
<tbf> superm1: so i forgot to update Makefile.am, when renaming the module
<tbf> superm1: strange that automake didn't complain
<superm1> tbf, well the project is of particular interest to me :)
<superm1> tbf, so i wanted to see how well it worked
<superm1> tbf, you had some comments somewhere in the package about the confusion about only debian/ubuntu using lirc.hwdb
<superm1> that's because we (Ubuntu) are the first to adapt using it
<superm1> the idea is supposed to be that eventually everyone will though
<tbf> https://code.fluendo.com/remotecontrol/trac/browser/trunk/data/receivers.conf
<superm1> yup that's where I was reading :)
<tbf> superm1: lirc.hwdb was a good idea, but it doesn't provide the information needed for auto-detection
<superm1> tbf, well the spec can still be changed upstream
<superm1> have you talked to Chris B. about it already?
<superm1> on the lirc-list
<tbf> superm1: currently i try to get code package ready before the hard beta freeze... :-/
<superm1> tbf, ah.
<tbf> superm1: but the file format i have now seems to work for me...
<superm1> well if you need some help, someone on my team (~mythbuntu), will probably be willing to help
<superm1> he wanted to do a similar spec
<superm1> but never got around to it
<tbf> https://code.fluendo.com/remotecontrol/trac/browser/trunk/bin/build-receiver-list
<superm1> tbf, you should know though, inside ubuntu we have a special patch (that upstream hasn't accepted yet)
<superm1> tbf, that allows a lircd.conf to be "included" in the system wide one
<tbf> this script generates a slight variation of that receivers.conf by scaning the source code of lirc
<tbf> superm1: guess i really should send a mail about that script and the file-format to the lirc-list tomorrow
<superm1> tbf, yeah, sometimes Chris is a little slow responding
<superm1> so that would be worthwhile
<tbf> superm1: i'd also highly appreciate (manual?) updates to the receivers.conf file....
<tbf> superm1: currently it is quite empty
<tbf> superm1: i say "manual", cause of the timeframe needed, to get annotations into the lirc code
<superm1> tbf, well let me put you in touch with the chap on my team that was looking to work on this
<superm1> tbf, if hang around #ubuntu-mythtv-dev and idle for a bit, his name is foxxbuntu
<bddebian> Heya gang
<TheMuso> ember_: I've got orca covered.
<superm1> TheMuso, ah you were the one that pre-empted all the changes to ubiquity not running as root right :)
<superm1> for orca?
<TheMuso> superm1: Yep, haven't been able to test them so far, but hope to do that this afternoon.
<superm1> TheMuso, well they broke the mythbuntu frontend i found out :)
<TheMuso> superm1: So I saw, but it was an easy fix, again from what you wrote to -installer.
<superm1> yeah it was
<superm1> just had to track down any possible points of failure
<TheMuso> Yeah.
<bddebian> Why isn't libgnutls26 in Hardy?
<TheMuso> Wow! The motu release bug list is quite long.
<mok0_> TheMuso: Are you in the release team?
<mok0_> TheMuso: Ah! You are!
<TheMuso> mok0_: Yes I am, and I'm having a look over it, after neglecting it for a while, due to other work.
<TheMuso> mok0_: I'm assuming that collect4 has not yet been uploaded yet?
<mok0_> TheMuso: I have 2 acks on 194219 but I don't know why it's still on the list, or what has happened to it
<TheMuso> gah bad english
<TheMuso> bug 194219
<ubotu> Launchpad bug 194219 in collectd "[needs-merge] collectd  (4.3.0-1)" [Undecided,Confirmed] https://launchpad.net/bugs/194219
<mok0_> Heh two minds...
<TheMuso> ah yes, looking atht ath now
<TheMuso> I'll review and upload it then.
<TheMuso> mok0_: ummm. No bug number in teh changelog, there is a placeholder for one, but... Its not there.
<mok0_> Ach.
<mok0_> Forgot, can you put it in?
<TheMuso> mok0_: And, the only two files touched by the debdiff are debian/control, and debian/changelog. Should there be more?
<mok0_> TheMuso: That's it iirc
<TheMuso> Well what is being changed?
<mok0_> TheMuso: It is basically taking over Debians new pacakge
<TheMuso> So shouldn't it be a sync?
<mok0_> Well, yes, if possible at this time
<TheMuso> mok0_: Well, I suggest you re-examine the bug, and the package, and if so, change the package description to a sync request.
<mok0_> TheMuso: arair I noted in the changelog that it should be synced next time
<TheMuso> mok0_: I'm confused... Why next time?
<mok0_> I assumed this was the way to do a FFE
<mok0_> I didn't know I could just do a sync request
<TheMuso> An FFE can still be a sync, as long as the requested information is given, and 2 acks are given. It doesn't have to be a merge/upload.
<mok0_> TheMuso: and I need some uploads :-)
<TheMuso> An FFE is just that, an FFE, a request to change the package in a major way, whether it be via a sync, or a upload/merge etc.
<TheMuso> mok0_: When a package is synced, you still get credit for requesting it.
<mok0_> TheMuso: cool :-)
<mok0_> TheMuso: How does the sync happen in practice?
<mok0_> TheMuso: someone has to fetch it and upload
<TheMuso> mok0_: The archive admins have powers to directly copy the package from Debian.
<TheMuso> Nobody uploads it.
<TheMuso> mok0_: I'm assuming you have never requested a sync before.
<mok0_> TheMuso: that's right
<mok0_> TheMuso: so, I just change the bug description? Is there a tag?
<TheMuso> mok0_: No. Let me find the wiki page describing the sync process.
<mok0_> Thx
<TheMuso> mok0_: https://wiki.ubuntu.com/SyncRequestProcess
<mok0_> TheMuso: looks easy enough... most of the requested info is already attached to the bug
<TheMuso> mok0_: Well, have a look over the bug as it is now, and change the description to a sync request and you'll find out soon enough whether you've given enough information.
<mok0_> TheMuso: ok
<mok0_> TheMuso: I have 1 ack on another package: 156100	
<TheMuso> bug 156105
<ubotu> Launchpad bug 156105 in moblin-multimedia "prompt error message when start playbacking wma media" [Medium,Fix released] https://launchpad.net/bugs/156105
<TheMuso> mok0_: Ok will have a look now.
<mok0_> TheMuso: great, I can answer questions
<TheMuso> mok0_: err, is that the correct bug number?
<TheMuso> oh i got it wrong
<TheMuso> bug 156100
<ubotu> Launchpad bug 156100 in storm "[hardy] please upgrade storm to version 0.12" [Undecided,Incomplete] https://launchpad.net/bugs/156100
<mok0_> yes
<TheMuso> heh
<mok0_> TheMuso: 0.12 closes a bunch of bug reports
<mok0_> TheMuso: ... and besides, when we bitch at Canonical for not opensourcing their stuff, we should be on top of it when they publish updates to storm
<TheMuso> mok0_: You need to attach everything else relating to an FF, diffstat, changelog, build and install logs...
<mok0_> TheMuso: ok
<mok0_> TheMuso: install logs?
<TheMuso> mok0_: Yes. We need to know that the package installs and updates correctly.
<TheMuso> mok0_: https://wiki.ubuntu.com/FreezeExceptionProcess explains everything.,
<mok0_> TheMuso: thx
<mok0_> TheMuso: it's getting time for bed for me, I'll do it tomorrow
<mok0_> TheMuso: but the other bug I will change in a minute
<TheMuso> mok0_: Ok thanks.
<mok0_> Well goodnight, see you later!
<LaserJock> persia: around?
<Legendario> hello.
<Legendario> how do i use dh_intallman?
<Legendario> how do i use dh_installman?
<RAOF> man dh_installman and man debhelper will give useful pointers, but generally the answer is to just call dh_installman in the appropriate debian/rules target.
<RAOF> And like the rest of debhelper, having a debian/$packagename.manpages should make it just work.
<Legendario> RAOF, i've read the man pages, but it didn't make any clear. There is even a bug about it (Bug #184156). I am calling it on debian/rules but the package created doesn't have the man page.
<ubotu> Launchpad bug 184156 in debhelper "man page of dh_installman incomplete for newbie" [Undecided,New] https://launchpad.net/bugs/184156
<Legendario> RAOF, am i the one supposed to create the packagename.manpages or does the dh_installman the one who handles it?
<TheMuso> leonel: You create that file.
<TheMuso> gah
<ScottK> pochu: I just uploaded a (hopefully) fixed pychecker.  Your turn to work on SPE.
<slomo__> pochu: i'll upload new gst-plugins-bad tomorrow probably... i want the things available everywhere to prevent failing builds again and get it into testing soonish
<slomo__> superm1: http://buildd.debian-ports.org/status/package.php?p=gmyth  <--- fails on kfreebsd, might want to notify upstream about that or give a patch ;)
<superm1> kfreebsd?,  didn't even know that it would automatically be added to different ports
<superm1> i'll bring it up with upstream
<superm1> still waiting to hear back on the -upnp stuff
<slomo__> superm1: the kfreebsd patch is probably easy, will take a look at it later if you didn't before :)
<superm1> slomo__, do you have a kreebsd env to work from?
<superm1> can one be created in a pbuilder directly?
<slomo__> superm1: no idea, i assume it's an obvious bug :)
<superm1> hehe
<dholbach> good morning
<nixternal> good morning to you sir
<dholbach> hey nixternal - how are you doing?
<nixternal> not to shabby...coming down off of my busy spell at the uni
<nixternal> installing Ubuntu on my desktop so I can test some of the Gnome/KDE4 issues that I have been reading about
<dholbach> oh... what are they about?
<dholbach> nixternal: great to see you're in 5-a-day as well :-)
<nixternal> some reason people are seeing klauncher crashes when logged into Ubuntu
<dholbach> ugh :/
<nixternal> oh ya, trying to take the lead in 5-a-day :)
<dholbach> I noticed :-)))
<nixternal> it started out as 5-a-day, but as I sat in on classes at the uni, I started doing 20 to 60 a day listening to boring lectures :)
<dholbach> it seems the project grew so much that committing bugs you've worked on takes a while :)
<nixternal> I noticed that today
<dholbach> I'll try to work something out to fix that
<dholbach> so everybody commits to their own branch
<dholbach> which will make the statistics a bit more complicated, but it's going to befine
<nixternal> actually, I did my add-5-a-day, and it updated the branch, and between the time it finished updating the branch and committing mine, someone had committed, which caused add-5-a-day to crash out because the branch was out of date
<nixternal> in 5 seconds I would say
<dholbach> oh... crash?
<nixternal> yup
<dholbach> wasn't it just bzr complaining?
<dholbach> please give me the backtrace if that happens again
<nixternal> it was
<nixternal> wasn't a backtraceable crash
<Fujitsu> Why not have people commit to their own branch, then have some script running somewhere that watches lots of branches and merges them into the main one?
<dholbach> ah ok
<nixternal> someone had committed in between the update and my commit, in between the 1st and 2nd stage of add-5-a-day
<dholbach> Fujitsu: probably not even necessary to merge them into a main branch
<warp10> Good morning!
<dholbach> Fujitsu: but yeah, that'S the basic idea
<dholbach> we could even make it so that people push their changes to multiple branches (I'd commit to dholbach and ubuntu-berlin for example) so that teams could compete against each other :)
<dholbach> it makes statistics a bit hard to figure out, but I somehow like the general idea :)
<nixternal> that sounds like fun
 * Fujitsu declares universe to be too big.
<HighN1> according to einstein there's nothing bigger...
<Fujitsu> Heh.
<HighN1> you may splitt it up into multiple galaxies, but their number would be endless
<HighN1> :-)
<HighN1> </posermode>
<cokehabit> can someone help me with a booting problem?
 * Hobbsee suggests #ubuntu for support
<cokehabit> i've asked in there and no-one seems to be responding
<cokehabit> i've asked questions before and got directed here so i thought i would cut out the middleman
<Hobbsee> for packaging?
<cokehabit> yes, before it was a .deb packaging problem
<Hobbsee> which is why that was on topic.  this isn't, sorry...
<cokehabit> this time though, no kernel since 2.6.24-2 has got past "loading kernel drivers"
<cokehabit> i didn't know this was a packaging channel, sorry
 * Hobbsee suggests reading the /topic
<cokehabit> just read the wiki, sorry
<geser> slangasek: re xen-unstable: it should probably be also added to the sync blacklist as it build-depends on linux-support-* which isn't available in Ubuntu (and xen-3.0 and xen-3 are also on the sync blacklist)
<Balise> hi
<slomo_> superm1: kfreebsd fixed ;)
<Hobbsee> TheMuso: ping
<TheMuso> Hobbsee: Yes, what can I do for you?
<Hobbsee> TheMuso: how do you want to handle https://bugs.edge.launchpad.net/ubuntu/+source/ubuntustudio-icon-theme/+bug/192535 which now has it's MOTU-uvf ack?
<ubotu> Launchpad bug 192535 in usplash-theme-ubuntustudio "FF: General exception for Ubuntustudio packages." [Wishlist,Confirmed]
<Ng> pochu: I finally filed the freeze exception, sorry for the delay. #195733
<TheMuso> Hobbsee: What do you mean exactly?
<persia> Don't bugs of that class just get closed at BetaFreeze / ArtworkFinalDeadline?
<persia> Ng: I'm not in motu-release, but I'd like the updates: remember to include the installation log and testing report.
<Hobbsee> TheMuso: in particular, i'm about to unsubscribe us - are you intending to mark it as fix released or anything?
<\sh> guys...netbeans is crashing on hardy amd64...can someone prove this?
<persia> \sh: Give me a test case, and I'll give it a shot (and try to arrange a patch).
<\sh> persia: just start it with sun-java6 installed
<\sh> /usr/share/netbeans/6.0.1/bin/../platform7/lib/nbexec: line 440:  4491 Aborted                 (core dumped)
 * persia tends to avoid multiverse java, but tests
<TheMuso> Hobbsee: No, was just hoping to get a standing freeze exception, and its also documented on the wiki page, so feel free to close/unsubscribe.
<persia> \sh: Do I need the jdk, or just the bin & jre?
<Ng> persia: is the installation log literally just the output of me installing the build and it not doing anything out of the ordinary?
<persia> Ng: Yes.  For extra points, provide logs for all of install, upgrade from current hardy, remove, and purge.
<\sh> persia: just jre
<\sh> and who forced me to upload xdebug?
<Hobbsee> TheMuso: that's what i'm thinking we're giving, yeah
<persia> \sh: Got it: that's bug #87947
<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
<Hobbsee> right, from 51 to 42.  excellent
<Hobbsee> and down to 28.
 * persia isn't convinced 87947 should be "Fix Released" as I'm currently finding about 8 dupes.
<Ng> persia: what would be useful for the testing report? I'm not sure that "well there are probably half a dozen people using 0.8.1 or later and in regular contact with the project who haven't reported any serious bugs" will do ;)
<persia> Ng: Depends on the nature of the update.  My previous testing reports have varied from "doesn't segfault on startup for me" to arranging for people with three different architectures to follow two use cases and report the results (odd issue with failing to render only some Youtube videos).
<Ng> hmm
<persia> My understanding (and I'm not authoritative on this) is that you want to include enough information to convince the release team that the updates package (and any dependencies) work well enough to be released after the update.  For terminator, it ought be fairly easy.
<Ng> persia: ok thanks, I'll whip something up
<persia> Ng: I usually just cat all of the install/upgrade/remove/purge logs together in a single attachment.
<Ng> persia: very wise, I realise I'm spamming the motu-release folks, for which I apologise
<Iulian> Hi
<thekorn> hey Iulian
<Iulian> Hi there thekorn
<pochu> ScottK: nothing to do in spe, it just was uninstallable as it depends on pychecker >= someversionthatwasftbfs ;)
<pochu> ScottK: thanks for fixing pychecker
<pochu> slomo_: re: gst-bad - no hurry, that's fine :)
<pochu> ScottK: I setted it as high importance because it was uninstallable and not because it was spe. we do the same for ftbfs independently of the package
<persia> pochu: For everything?  I thought most universe packages couldn't qualify for "High" except for license issues.
<pochu> persia: hmm, I don't know, but infinity's MBF was done at high importance I think. Perhaps his check was done for main only
<persia> pochu: For main, failure-to-install or FTBFS is typically High.  For universe, typically Medium, although some packages might have enough users to qualify for high.
<pochu> persia: ok, thanks
<persia> pochu: Reviewing https://wiki.ubuntu.com/Bugs/Importance, I'd think that for universe it would have to be something like a significant component of one of the universe derivatives being broken in order to qualify for "Has a severe impact on a small portion of Ubuntu users", as I don't think anything is really popular enough for "Has a moderate impact on a large portion of Ubuntu users".
<pochu> persia: wxwidgets ftbfs would qualify ;)
<persia> pochu: Ah.  Maybe, at least for 2.6.  There's likely a few other major universe libraries as well.
 * ScottK thinks clamav and spamassassin would potentially qualify.
<ScottK> pochu: In that case (for spe) after you test it, I'd suggest it's fix released, not invalid.
<persia> Probably.  There's a lot of dependencies, and a fair number of users.  On the other hand, it's not likely true for spe :)
<bigon> http://www.paeps.cx/weblog/Linux/fuck_ubuntu WTF
<ScottK2> He's entitled to his opinion.
<mok1> I was asked to submit an install log to LP. Any particular way that needs to be done?
<amarillion> Hey
<amarillion> Do you know any good tools to import ~150 signed gpg keys reasonably quickly?
<broonie> amarillion: Depends on what format you have the keys in... what problems does gpg --import give you?
<vivia> hello there... i just saw tcl/tk 8.5 entering the repositories lately and an updated amsn compiled against 8.5 ... (first thing, make sure latest amsn package is marked incompatible with tcl/tk 8.4, ok?) but i found a problem
<amarillion> Ah I forgot to tell you, they are in my email right now, thunderbird
<persia> mok1: I've generally used the script command to capture my entries and the output.  I typically do all of install, upgrade, remove, and purge to demonstrate that all the maintainer scripts do the right thing.
<vivia> if someone has tcl/tk 8.5 and tcllib from the gutsy repositories, amsn won't start
<amarillion> Is there a tool that can sort them out from a mbox or something?
<vivia> it's a bug in snit 2.1 that is contained in the current tcllib package
<broonie> mutt should be able to do it (open the mbox, tag everything and tell it to snarf the keys)
<vivia> they told me that the latest snit release fixes it. but snit 2.1 contained in tcllib 1.9.dfsg1-1 is VERY problematic with tcl/tk 8.5
<amarillion> snarf? Ok I'll look into it
<vivia> so it should cause problems to other applications too, not just amsn
<persia> vivia: You likely want either #ubuntu-bugs, or to report a bug from https://launchpad.net/ubuntu/+source/tcllib/+bugs
<vivia> persia: sure, going to report it there... thanx ;)
<persia> vivia: Thanks for tracking it down, it's just that we're ill prepared to handle bug reports in IRC.
<vivia> persia: it's ok, we often have it on amsn too, and amsn is a MUCH smaller project.. :)
<mok1> persia: the script command, thank you! Never heard of it before. You're never to old to learn something new..
 * persia thinks the script command is older than several developers :)
<vivia> how can i check whether my current amsn package is incompatible with tcl8.4 ?
<emgent> heya people
<vivia> https://bugs.launchpad.net/ubuntu/+source/tcllib/+bug/195785 there you go, i filed it... i'd appreciate it if anyone could check it and tell me quickly whether more info is needed
<ubotu> Launchpad bug 195785 in tcllib "snit 2.1 contained in tcllib 1.9.dfsg1-1 incompatible with tcl/tk 8.5" [Undecided,New]
<vivia> wow, thanx ubotu
<vivia> nice bot you've got there :)
<amarillion> broonie, did you ever participate in a key signing party?
<amarillion> Has anyone here participated in a key signing party?
<broonie> amarillion: yes
<amarillion> So how did you learn how it works?
<amarillion> I don't really understand it
<amarillion> I mean, I understand the theory, but the documentation is very skimpy on the details
<broonie> You mean the actual process for doing things? That differs depending on how the event is organised. Whichever way it's just a way to do an individual signing in bulk.
<amarillion> If I'm going to do this with thunderbird, I now have to open 150 emails, save the attachment, (type in a different name for each of them or thunderbird will overwrite) unencrypt and then import
<amarillion> Probably I can find a way to automate things with mutt but then I'd have to learn to use mutt first
<geser> amarillion: the main problem with KSPs is: how do you get a bulk of people to check each others identities in an ordered way and in a minimum of time
<amarillion> geser, yeah, it was reasonably efficient at fosdem this year
<emgent> heya geser :)
<broonie> amarillion: mutt has a direct command for "import key from this e-mail"
<amarillion> I hear it was a mess in previous years
<amarillion> broonie, ah, which is it? I can't find it in the help
<geser> amarillion: Debian people have expierence at doing a KSP, I was at the FOSDEM KSP last year
<amarillion> There is a command in mutt to decrypt it
<broonie> amarillion: C-k
<geser> amarillion: ^K          extract-keys           extract supported public keys
<amarillion> great, thanks
<amarillion> I suppose everybody uses mutt for this? Doing this in thunderbird seems impossible
<\sh> whoever proposed php5-xdebug THANK YOU SOO MUCH !
<\sh> amarillion: enigmail is your friend I think
<geser> \sh: is it with enigmail as easy as in mutt to import keys from a KSP?
<man-di> amarillion: install signing-party and use caff
<amarillion> man-di, I used caff to send out the signed keys
<geser> yes, for sending out signatures caff is really good
<\sh> geser: for this you use caff and a local smtp
<\sh> geser: and for importing keys...I'm using a shell script...adding sigs to my key I do it manually...
<amarillion> Ok, I have everything imported. Thanks broonie
<geser> amarillion: don't forget to update your key on the keyservers
<ScottK> stani: Is everything in good shape for SPE in Hardy now?
<amarillion> geser, I will, thanks
<sistpoty|work> hi folks
<stani> ScottK: You confirmed pychecker works, which was the biggest blocker. Right now I have a bug fix release ready, which fixes an important CPU leak. I haven't yet had the possibility to put a Hardy machine to test SPE.
<stani> ScottK: I was planning to release it in the beginning of march, but can do it earlier. (The only reason I am waiting is to be sure nothing else pops up which I have to fix.)
<stani> ScottK: I am also working on a bug fix release of Phatch, which should be ready this week as well.
<ScottK> stani: Well beginning of March is next week.  I don't see any harm in waiting.
<Ng> ScottK: thanks for the terminator sync ack. I take it we need a second one?
<ScottK> Ng: Yes.
<Ng> ok, thanks :)
<stani> ScottK: You can give me a deadline which should be comfortable for you to upload Phatch and SPE. Than I have a target. Will we follow the same procedure, upload with POX or pochu to Debian and you sync from there?
<ScottK> That last alpha release is sched for March 6.  Can you make that?
<ScottK> stani: ^^
<stani> ScottK: Of course, does it need to be one day in advance?
<ScottK> stani: Not really.  What I really want is it in well before the beta freeze a week later.
<hellboy195> LucidFox: checking for C compiler default output file name...
<hellboy195> configure: error: C compiler cannot create executables
<hellboy195> See `config.log' for more details.
<hellboy195> make: *** [configure-stamp] Error 77
<hellboy195> dpkg-buildpackage: failure: debian/rules build gave error exit status 2
<stani> ScottK: OK
<vivia> hellboy195: you do have build-essential installed, right?
<hellboy195> vivia: that was an error of the build machine on LP. https://edge.launchpad.net/ubuntu/+source/starplot/0.95.4-3
<sistpoty|work> hellboy195: sounds like you have a CC="something" ./configure call somewhere where something doesn't start with gcc?
<bddebian> Heya gang
<hellboy195> sistpoty|work: well, I did an sync request from Debian
<hellboy195> sistpoty|work: https://bugs.edge.launchpad.net/ubuntu/+source/starplot/+bug/195032
<ubotu> Launchpad bug 195032 in starplot "Please sync starplot 0.95.4-3 from Debian(Unstable)" [Wishlist,Fix released]
<mib_hg7jf8fu> I have a simple and naive question: what is the relationship between debian unstable packages and ubuntu universe? that is, are debian unstable packages, in general, included in ubuntu universe?
<sistpoty|work> hellboy195: and it worked in your pbuilder?
<albert23> hellboy195: that error is caused by the quoting of CFLAGS in debian/rules
<hellboy195> sistpoty|work: I'm afraid. I never test sync requests :( first time such a thing happended
<stani> I'd like to include the information of the copyright file in debian of Phatch in the upstream release (of course without "this package was debianized by..."). Is this possible and can than the debian/copyright file just refer to it instead of repeating the information?
<sistpoty|work> hellboy195: please always testbuild stuff you want to get in the archives... likewise use Hobbsee's long point stick against your sponsor not test-building as well ;)
<hellboy195> sistpoty|work: yeah. I'm sorry :( but also the grabmerge ubuntu patch doesn't show such a thing with CFLAGS or something similar ...
<RainCT> hey
<sistpoty|work> hi RainCT
<slytherin> mib_hg7jf8fu: Ubuntu packages are synced/merged with packages from Debian unstable at the start of every Ubuntu development cycles. And sync/merge continues till feature DebianImportFreeze. After that it is done on case by case basis.
<mib_hg7jf8fu> Thanks slytherin!
<LucidFox> Speaking of syncs...
<LucidFox> I have a couple of packages that I maintain in both Debian and Ubuntu. In Ubuntu they're -0ubuntuX and the Debian versions are identical except for changelog. Would it warrant a sync?
<LucidFox> Or would it be better to wait until intrepid?
<slytherin> LucidFox: If you can provide enough proofs that there are no changes then I don't see a problem.
<slytherin> But then I am not a developer.
<sistpoty|work> LucidFox: if only the changelog is different, I'd rather sync now (then these will get autosynced when intreped starts)
<Ng> sistpoty|work: thanks for the second terminator sync ack :D
<hellboy195> sistpoty|work: btw. package is building in pbuilder!!
<sistpoty|work> Ng: you're welcome ;)
<sistpoty|work> hellboy195: up to date hardy pbuilder?
<hellboy195> LucidFox: I suppose you build it too in pbuilder without problems?
<hellboy195> siretart: yep
<hellboy195> siretart: argh sry
<LucidFox> hellboy195> haven't tried
<hellboy195> sistpoty|work: yes. I also update pbuilder before building anything
<LucidFox> (and I don't run Hardy anyway, even in pbuilder)
<hellboy195> LucidFox: shouldn't you or do you trust me when I request syncs ^^
<sistpoty|work> LucidFox: ahem... if you test-build a package meant for *hardy* your pbuilder must be hardy as well
<LucidFox> sistpoty|work> Yes, I know
<LucidFox> I use PPA for hardy test-building
<geser> LucidFox: even for sync requests?
<LucidFox> Well, I admit that I didn't test-build this one
<hellboy195> Speaking form PPA. I can't upload something because I can't sign my packages
<hellboy195> Enter passphrase: gpg: problem with the agent - disabling agent use
<hellboy195> debsign: gpg error occurred!  Aborting....
<hellboy195> debuild: fatal error at line 1174:
<hellboy195> running debsign failed
<hellboy195> LucidFox: I did it now and it built fine
<slytherin> LucidFox: Why is using PPAbetter than using pbuilder?
<LucidFox> slytherin> It isn't - it's simply too expensive for me to have a constantly updated Ubuntu release on my local machine, as I'm billed for traffic
<slytherin> LucidFox: update it once a day. That should be sufficient I guess.
<LucidFox> The frequency of updates doesn't matter - there's simply too much to download
<geser> hellboy195: which release do you use? which program do you use for signing?
<LucidFox> Russia. Screwed up ISP prices. $0.02/MB
<LucidFox> (and I'm lucky to have even that)
<jdong> LucidFox: ideally, you should find someone who would offer you ssh access to a build box
<jdong> LucidFox: because with pbuilder you still have to continuously upload and download source packages
<hellboy195> geser: gpgp . actual hardy release. well I did a debuild -S, or also tried "debsign" on the .changes
<LucidFox> jdong> Oh, this is a neat idea.
<jdong> yeah, ssh is always cheap :)
<geser> hellboy195: normal signing with gpgp works?
<hellboy195> geser: havn't tried yet. I'm a total newbie to that because for merging I don't need signing
<hellboy195> geser: http://pastebin.com/m4b78c4b8 O_o
<geser> nice, please file a bug if none exists. /me uses plain gpg/gpg2
<hellboy195> geser: k
<\sh> #
<\sh> gpgp: xcb_xlib.c:73: xcb_xlib_lock: Assertion `!c->xlib.lock' failed.
<sistpoty|work> LucidFox: btw.: any news on bug 194256 ?
<ubotu> Launchpad bug 194256 in kmyfirewall "[FFe request] Please sync kmyfirewall 1.1.1-1 from Debian unstable (main)" [High,Incomplete] https://launchpad.net/bugs/194256
<\sh> hmmm..this error message is known to me ,-)
<hellboy195> \sh: wine? xD
<\sh> hellboy195: nope...netbeans a couple of hours before now ;)
<hellboy195> \sh: ^^
<hellboy195> \sh: btw, any progress?
<\sh> hellboy195: nope...0.9.56 crashes too...there is a solution coming up
<hellboy195> \sh: the problem is/was?
<\sh> hellboy195: problem looks like, that wine can't be started out of the wine source tree in the moment...
<hellboy195> \sh: ah, k
<LucidFox> sistpoty|work> I would have checked if it's reproducible, but I don't know how. I have no idea what "script" the upstream changelog is talking about.
<geser> \sh: but gpgp isn't a java programm, is it? so this should be a different error
<\sh> geser: but it was the same error and persia mentioned a bug report about it in LP...and there was a export VAR which solved my case...there are other workarounds...
<hellboy195> \sh: still have the link?
<\sh> https://bugs.edge.launchpad.net/ubuntu/+source/libxcb/+bug/185311 was it IMHO
<ubotu> Launchpad bug 185311 in libxcb "hardy, locking assertion failure, xorg/libsdl" [High,Confirmed]
<hellboy195> \sh: well. as geser said. no java program - no solution
<sistpoty|work> LucidFox: ok, NACK from me on the sync then
<LucidFox> All right, I'll wait until intrepid.
<LucidFox> If someone identifies the specific issue, we can always backport the fix for hardy.
<LucidFox> (backport to 1.1.0, I mean)
<sistpoty|work> LucidFox: yes, or thoroughly test the package, as I wrote in the bug report ;)
<hellboy195> geser:  gpg -s *.changes ?
<\sh> hellboy195: when you read the bug report, the very first comment is not about java
<\sh> hellboy195: it's about libxcb
<\sh> hellboy195: the workaround actually is for java
<geser> hellboy195: I use debsign but no gpgp/seahorse/... as agent (only the gnupg-agent)
<hellboy195> \sh: yeah but I tried also export LIBXCB_ALLOW_SLOPPY_LOCK=1
<\sh> hellboy195: yeah this is java only ;)
<hellboy195> \sh: damn! ^^
<geser> hellboy195: try unset GPG_AGENT_INFO and the debsign *.changes again
<\sh> geser: I can't use seahorse
<\sh> seahorse agent can't work with my cardreader
<geser> \sh: I use the normal gnupg-agent (also as a ssh-agent)
<\sh> geser: yes, that works :)
<geser> but unfortunately gnome-keyring insists on overwriting my SSH_AUTH_SOCK everytime
<hellboy195> geser: howto unset GPG_AGENT_INFO ?
<\sh> LucidFox: Re: kmyfirewall the "IT DOES NOT INSTALL A VALID SCRIPT!"
<geser> type "help unset" in a terminal (with bash)
<\sh> LucidFox: can it be, that it's the server script firewall source to read the kmyfirewall data?
<\sh> hellboy195: user@host: > unset GPG_AGENT_INFO
<slicer> dholbach: Re bug 194836, it was my understanding that a feature freeze was not needed when there are only bugfixes involved?
<ubotu> Launchpad bug 194836 in mumble "Update to 1.1.3 (bugfixes)" [Undecided,Confirmed] https://launchpad.net/bugs/194836
<LucidFox> I don't know
<hellboy195> \sh: Successfully signed dsc and changes files
<hellboy195>   thx :)
<\sh> LucidFox: build new upstream and make DESTDIR=<somewhere> with version in ubuntu and new upstream...you can see what's being installed and what not, so you know what "script thingy" means ;)
<slicer> dholbach: If my understanding is wrong, would a link to the PPA buildlog satisfy the need for build logs? .. And should I file a new bug report, or just subscribe motu-release to the existing one?
<hellboy195> Is my hardy crazy or did somebody remove gpgp from the repo xD
<dholbach> slicer: no, you're right - I just read the changelog again and I think it'd qualify
<geser> hellboy195: nope, it got removed
<hellboy195> geser: why?
<LucidFox> \sh> Or I can just run debdiff on deb files :)
<geser> hellboy195: "(From Debian) RoQA; orphaned, uses gtk 1.x, has better alternatives
<geser> "
<geser> from http://people.ubuntu.com/~ubuntu-archive/removals.txt
<slicer> dholbach: So. Er.. What do I do? Just ignore your comment? :)
<hellboy195> dholbach: you forgot to thank me for my libdvdread merge. now I'm sad ^^
 * dholbach hugs hellboy195 :-)
<hellboy195> geser: ah. now I can't install it and report the seg fault
<hellboy195> dholbach: :D
<\sh> LucidFox: yepp
<geser> hellboy195: if it isn't in hardy anymore we can't fix it anyway
<geser> hellboy195: try an other gpg frontend (if you need one)
<\sh> LucidFox: but DESTDIR comparison is much better, because it doesn't give you package maintainer bugs ,-)
<hellboy195> geser: k
<LucidFox> http://paste.ubuntu.com/5013/ <-- Hmm, might be worth syncing for the paths alone (top is Ubuntu, bottom is Debian)
<LucidFox> actually, vice versa
<LucidFox> top is Debian, bottom is Ubuntu
<\sh> LucidFox: a script is still missing
<\sh> LucidFox: or it means the "export" function for the scripts
<LucidFox> This might be interesting: http://paste.ubuntu.com/5014/
<LucidFox> (I deleted everything related to include files from the diff, to make the diffstat conscise)
<LucidFox> and finally: http://paste.ubuntu.com/5015/
<huats> am I the only one with an upgrade pb of my pbuilder ?
<huats> it yells about a problem with python2.5 and python2.5-minimal
<\sh> LucidFox: I'm convinced of the sync...just convince motu-release ;)
<\sh> huats: yepp...I had to "apt-get -f install" after that
<huats> \sh ok
<huats> \sh just to wanted to be sure
<huats> thanks
<emgent> bug #176931
<ubotu> Launchpad bug 176931 in lookup-el "[lookup-el] [CVE-2007-0237] possible local symlink attack" [Low,In progress] https://launchpad.net/bugs/176931
<mruiz> hi all
<sistpoty|work> dholbach: got a minute for a query?
<dholbach> sistpoty|work: yes
<nxvl_work> if a DM merges a package into ubuntu (an has done the changes) the maintainer is still MOTU or it doesn't need to change?
<slicer> 16:47 < slicer> dholbach: If my understanding is wrong, would a link to the PPA buildlog satisfy the need for build logs? .. And should I file a new bug report, or just subscribe motu-release to the existing one?
<slicer> Er.
<slicer> Cut&paste major error. Sorry.
 * slicer is noting things down in his dev-log :)
<\sh> going home now
<geser> nxvl_work: in Ubuntu every changed source package should have an Ubuntu email address as maintainer
<nxvl_work> geser: yes, but i mean, if the DM is also an Ubuntu developer/contributor
<geser> nxvl_work: if he has an ubuntu address he can put it in
<bobbo> do new upstream versions require an FFe?
<nxvl_work> geser: thnx :D
 * nxvl_work HUGS geser
<jpatrick> bobbo: yes
<geser> bobbo: yes, unless it's a bug fix release
<nxvl_work> bobbo: yup
<bobbo> thanks
<nxvl_work> what should i do with the "Uploaders:" field on debian/control?
<geser> nxvl_work: Ubuntu doesn't use the Uploaders field
<nxvl_work> geser: so remove it?
<geser> it's only relevant for Debian
<geser> nxvl_work: has the Debian package that field?
<nxvl_work> geser: yep
<geser> then leave it, gives a smaller delta between Ubuntu and Debian
<nxvl_work> i have a doubt
<nxvl_work> terminator was included in ubuntu before that on debian
<nxvl_work> now we need to "sync" it from debian
<nxvl_work> BUT, there is a change that must be done for it to work on ubuntu, do i need to make it as a bug fix or as a merge?
<nxvl_work> (on the changelog)
<geser> nxvl_work: terminator got uploaded as -0ubuntu1 to Ubuntu and Debian has it now as -1? then merge all still needed changes (or new changes) into -1ubuntu1
<nxvl_work> geser: on ubuntu we have 0.7-0ubuntu2 and i'm merging 0.8.1-1 from debian
<nxvl_work> (there is a problem with 0.7.orig.tgz)
<geser> nxvl_work: then check the packaging of 0.7 for changes which should be kept for 0.8.1 in Ubuntu
<nxvl_work> geser: i'm the DM and have package it for ubuntu, so i know the changes :D but do i write it on the changelog as a merge or as a bug fix?
<geser> as a merge
<Ng> nxvl_work: thanks for the debdiff :)
<nxvl_work> :D
<slangasek> geser: ok, blacklisting xen-unstable, thanks
 * sistpoty|work heads home
<sistpoty|work> cya
<volksman> is this the right channel for packaging support? (IE I'm trying to package something and I'm having n00b issues)
<RainCT> volksman: yes
<RainCT> (for packaging support related to Ubuntu packages)
<volksman> sweet...I managed to package Tomboy 0.9.4 for gutsy today.  I was pretty happy (second package ever)...but then I found a bug in the app and the developer told me to try 0.9.7
<volksman> so I went about packaging it the exact same way....cept now once I get my deb I get this error when I try to install:
<volksman> trying to overwrite directory `/usr/share/pixmaps' in package xfce4-appfinder with nondirectory
<volksman> I have two icons that get installed in /usr/share/pixmaps but where is xfce4 getting involved?
<RainCT> volksman: can you paste the output from "dpkg-deb --contents tomboy*.deb" somewhere?
<volksman> yep...give me a sec
<slangasek> volksman: that error indicates an error in your package that caused /usr/share/pixmaps to end up as a file within your package, not a directory
<volksman> http://pastebin.ca/919214
<volksman> slangasek: I was thinking along those lines but I haven't changed anything in the rules that affect the icons or anything to do with that path (I'm basically using the same rules as I used for the 0.9.4 build)
<volksman> lintian dumps this:  E: tomboy: file-directly-in-usr-share usr/share/pixmaps
<RainCT> yep, it's a file
<RainCT> how are you installing the icon?
<volksman> uudecode debian/tomboy-16.xpm.uu && mv tomboy-16.xpm debian/tomboy/usr/share/pixmaps
<volksman> in install in rules
<volksman> and that was taken from the 0.8.0 source
<slangasek> yes, but you haven't created debian/tomboy/usr/share/pixmaps as a directory first
<volksman> so a line like mkdir debian/tomboy/usr/share/pixmaps above that last one I posted would work for that?
<RainCT> volksman: add a / at the end
<RainCT> uudecode debian/tomboy-16.xpm.uu && mv tomboy-16.xpm debian/tomboy/usr/share/pixmaps/
<volksman> it's weird this didn't present an issue with the 0.9.4 build I did earlier
<RainCT> without the slash mv takes "pixmaps" as the name for the file and renamed "tomboy-16.xpm" to that..
<RainCT> volksman: perhaps you had a mkdir before but removed it, or forgot the debian/dirs file or something?
<slangasek> RainCT: and adding the slash will only change the error to "no such directory"
<volksman>  mkdir debian/tomboy/usr/share/pixmaps
<volksman>         uudecode debian/tomboy-16.xpm.uu && mv tomboy-16.xpm debian/tomboy/usr/share/pixmaps/
<volksman> that should do it right?
<RainCT> volksman: yes
<volksman> sweet...thanks guys...I'm hoping to figure out this stuff then start helping with the MOTU team...packaging is very new to me though... :)
<jeromeg> ls
<jeromeg> oups :)
<Iulian> Wrong window ;)
<jeromeg> yep :)
<jeromeg> pochu: hello, you are maintaining anjuta in Ubuntu ?
<pochu> jeromeg: I update it from time to time, why?
<pochu> jeromeg: although huats has done the latest one (2.3.5)
<jeromeg> pochu: I was thinking about an SRU for gutsy, we are shipping 2.2.0 and 2.2.1 and 2.2.2 are bugfixes only releases, and really correct a LOT of issues
<pochu> jeromeg: hmm, that would need a lot of testing...
<pochu> jeromeg: what does upstream think about it?
<jeromeg> pochu: did not ask, but 2.2.0 seems to be flagged as obsolete
<jeromeg> it has really many issues, crashes, memory leaks...
<pochu> that's weird
<jeromeg> pochu: and 2.2.1 and 2.2.2 are bugfix only
<jeromeg> pochu: changelog -> http://pastebin.com/m2a6f5cec
<pochu> jeromeg: but upstream's input would be really helpful.  naba isn't on irc right now though
<jeromeg> ok
<pochu> jeromeg: are you confident updating packages?
<jeromeg> pochu: I don't understand, you mean if I can do it ?
<pochu> jeromeg: yeah, updating to 2.2.2 and uploading to a ppa for testing
<jeromeg> pochu: yep, no problem, I should be able to do this
<pochu> if testing in a ppa goes fine, we can ask for uploading to -proposed
<pochu> and then asking for wider testing (perhaps an announce in the forums)
<jeromeg> pochu: ok, I'll do this
<jeromeg> pochu: on LP I can see there was a 2.2.3 release, but this release is not on the upstream website, how can that be ?
<jeromeg> pochu: ok i found it :) sorry
<volksman> thanks guys!  that new build worked for me....
<jeromeg> pochu: in fact, I can take the previous hardy packaged version, no ?
<pochu> jeromeg: yeah, should work
<jeromeg> pochu: great
<emgent> uhm
<emgent> http://menpro.blogspot.com/2008/02/mark-shuttleworth-reveals-definitive.html
<emgent> true news ?
<emgent> "And so I'd like to introduce you to the monikers for our future release cycles," Mark announced, referring to the following list:
<emgent>     * 9.04 - Jovial Jackal
<emgent>     * 9.10 - Kissy Kipunji
<bobbo> emgent: "Yodeling Yellow-spotted Rock Hyrax" i certainly hope not! that will be a mission to type out
<anthony> Bother.  I just realized a flaw in my upgrade path scheme.
<emgent> (:P
<emgent> for me it's a fake list
<bobbo> yeah it looks really fake
<bobbo> like that announcement for Hardy saying it was going to be Hungry Hippo etc.
<sweeny> considering it's filed under "humour"...
<emgent> :P
<ScottK> Is JeffreyRatcliffe here?
<ScottK> Since when do we have a rule to open a new special bug if a candidate revision closes multiple bugs?  Anyone?
<slangasek> ScottK: ...never?
<slangasek> (is that the right answer? :)
<ScottK> slangasek: That's what I thought, but reading https://wiki.ubuntu.com/MOTU/Contributing it appears either I'm wrong or the documentation is on crack.
<ScottK> Seems silly to me.
<ScottK> I always just told people to pick one bug to attach the debdiff to.
<slangasek> ScottK: well, that line dates back to the initial version of that page, 2007-05-25; it's not something I've ever seen people insisting on though, and I agree that it's spurious
<ScottK> slangasek: I'm adding a discussion of it to the agenda for the next MOTU meeting now.
<ScottK> Unfortunately the next MOTU meeting is at 1200 UTC and I'll be in -0800 on that day, so I probably won't make it.
<mok0> I feel my good old self now
 * jpatrick hugs mok0 
 * mok0 hugs back
<mok0> I just checked out the submissions to the LP logo contest. Amazing! Too bad only one can win!
<james_w> Anyone have an ftp server with SSL support running?
 * slangasek shudders and runs away :)
<james_w> slangasek: :)
<mok0> james_w: why not use sftp?
<james_w> mok0: it's not me, it's bug 175930
<ubotu> Launchpad bug 175930 in gnutls13 "SSL_ERROR_ZERO_RETURN for no reason" [Undecided,New] https://launchpad.net/bugs/175930
<mok0> ah
<james_w> I can't seem to get the right setup to reproduce, so I wondered if someone had one ready to try, but I realise it is a longshot.
<mok0> james_w: It's a pretty unusual setup
<broonie> james_w: gnutls tends to have interop errors, it may well depend on the particular server.
<james_w> broonie: that's true.
<slangasek> what interop errors?
<slangasek> short of "no we won't support encryption algorithms that I can break on my handheld calculator", I'm not aware of any protocol interop problems with it...
<Nafallo> :-)
<broonie> slangasek: TBF, the interop problems are often as much the fault of the remote end as of gnutls itself.
<james_w> slangasek: there are a few, but yes, it is often with closed source implementations at the other end.
<slangasek> huh, ok
<slangasek> any references?
<broonie> eg, none of the Nokia internet tablets can talk to Debian exim with TLS.
<slangasek> neat
<james_w> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402861
<ubotu> Debian bug 402861 in libgnutls13 "errors establishing TLS session from Nokia and SE mobile phones" [Normal,Open]
<james_w> slangasek: this is the sort of fun you'll be letting yourself in to.
<slangasek> james_w: mm?
<james_w> slangasek: with openldap
<slangasek> james_w: ah, I think we've already weathered all of that fun :)
<bobbo> are there any spare MOTUs that could review Bug #195806 for me?
<slangasek> no new bug reports about TLS incompatibilities since the first round were fixed
<ubotu> Launchpad bug 195806 in purrr "please update purrr to version 0.8" [Undecided,In progress] https://launchpad.net/bugs/195806
<Nafallo> damnit! forgot my laptop at work :-/
<james_w> slangasek: ah, great.
<tbf> broonie: huh?
<slangasek> tbf: "To be Fair", not meaning to highlight you :-)
<anthony> Nafallo: No fun.  I once forgot my power adapter at school, and didn't realize it until my lappy started beeping at me to say I had 10 minutes left.
<tbf> slangasek: afaik "TBF" is not useful as acronym. just look there: http://acronyms.thefreedictionary.com/Tbf
<slangasek> it was clear enough to me :)
<Nafallo> anthony: I forgot my charger at work last Friday, and I was on-call that night :-P
<mok0> Total Body Failure
<mok0> :P
<secretlondon> where is a good place to get help with a main inclusion report that is needed to fix a ftbfs bug?
<Nafallo> anthony: at least I'm not on-call tonight :-P
<anthony> Nafallo: that's helps, yes
<geser> secretlondon: I'd ask the people processing them in #ubuntu-devel. IIRC pitti is doing MIRs.
<secretlondon> geser: thanks. I'm a beginner so don't know how to fill out the packaging stuff so I'm not sure it's ready for pitti yet
<geser> secretlondon: I haven't done a MIR yet, but I'd try to understand the wiki page and the ask in #ubuntu-devel for help
<geser> secretlondon: btw: which FTBFS are you trying to fix?
<secretlondon> geser: they have sections which need packaging experience I think to answer
<secretlondon> geser: tuxtype - it needs the promotion of sdlpango
<jpatrick> secretlondon: which sections, we can help :)
<geser> secretlondon: perhaps also ask ogra (the last uploaded). Last I asked him about tuxtype he wanted to look at it (move sdlpango to main).
<secretlondon> geser: I know another package in edubuntu main will need sdlpango promoted once the current version is synced
<emgent> heya pople
<secretlondon> geser: as tuxpaint 0.9.18+ has it as a dep too
<geser> Hi emgent
<emgent> heya geser :P
<emgent> keescook, ping
<geser> secretlondon: you were talking about you don't know how to fill out the packaging stuff? You mean point 5 of the MIR template?
<secretlondon> geser: 5 is fine (thats just the build deps), it's 4 I can't do
<secretlondon> geser: to do with standards compliance
<secretlondon> geser: this is my work so far https://wiki.ubuntu.com/MainInclusionReportTemplateSDLPango?action=show
<geser> secretlondon: you are off-by-one :) you use 1. twice
<secretlondon> argh
<secretlondon> yeah it's the standards compliance bit anyway ;)
<geser> let's start with the easy part: packaging system
<geser> I assume you have the source package ready
<secretlondon> no i'll just get - though cdbs and quilt are deps
<secretlondon> oh I do have actually
<geser> secretlondon: if you know that cdbs is a packaging system and quilt a patch management system then you can already answer two questions from that bullet
<secretlondon> geser: no I thought they were both patching
<bmhm> hi, I'd like to request this backport once again :)
<bmhm> https://bugs.launchpad.net/gutsy-backports/+bug/192751
<ubotu> Launchpad bug 192751 in gutsy-backports "Backport of network game "pioneers"" [Undecided,Confirmed]
<jpatrick> bmhm: why is --force needed?
<bmhm> jpatrick: this was when using original packages
<bmhm> I should clearify it
<geser> secretlondon: if you look into debian/rules you will see that it includes files from /usr/share/cdbs -> cdbs packaging system
 * secretlondon looks
<secretlondon> ok
<geser> secretlondon: if you then also check which files are included you'll see /usr/share/cdbs/1/rules/patchsys-quilt.mk which is also pretty obvious from the name
<secretlondon> yep
<geser> it uses quilt for patch managing
<secretlondon> ok
<secretlondon> oddities - there's something to do with autotools in there somewhere as a patch
<bmhm> jpatrick: I hope its a little more clearly described by now
<geser> I wouldn't count that as oddities, that's normal use
<secretlondon> ok
<geser> I just looked at the diff.gz but I can't find any oddities
<geser> a packaging oddity would be for me a part from the packaging I can't understand on the first look (or at all)
<geser> but I see that it's a library, so let's check the Debian library packaging guide as next
<geser> secretlondon: from debian/libsdl-pango1.install
<geser> you can see that it will contain only the lib itself -> ok
<geser> from debian/libsdl-pango-dev.install you'll see that it includes the headers, the files needed for linking and some documention -> everythin ok
<geser> the package names follow the usual packaging scheme -> ok
<geser> secretlondon: so after a quick look the package follows the library packageing guide
<geser> secretlondon: and also the FHS as there are no unusual dirs in the debs
<geser> what's left? the Debian policy compliance
<geser> I would check it with linda and lintian and when both doesn't scream loud (many errors) say that it follows the policy (perhaps include the output of both)
<geser> secretlondon: any questions?
<geser> secretlondon: where have I lost you?
 * secretlondon curses her flaky hsdpa modem
<secretlondon> my last thing was asking about whether 6 patches was a lot
<secretlondon> I didn't get a reply
<geser> secretlondon: last I've seen from you is [22:30:02] secretlondon | ok
<secretlondon> ah ok
<geser> 6 patches aren't many (they aren't even big)
<secretlondon> 21:32 secretlondon> is 6 patches quite a lot - does that indicate that upstream is a bit slow?
<secretlondon> ok
<geser> the changes from config.{sub,guess} come from using an new version of those files from autotools-dev
<geser> secretlondon: the one that would trouble me at most from all is api_additions.patch
<geser> patching the api of a library can call for trouble later
<secretlondon> it apparently closed debian bug #437865
<ubotu> Debian bug 437865 in libsdl-pango-dev "libsdl-pango-dev: Please add #define's to identify API extension patch" [Wishlist,Fixed] http://bugs.debian.org/437865
<secretlondon> ah - its a patch on a patch
<secretlondon> that actually dates back to 2006 "api_additions.patch: patch from Guillaume Cottenceau to add some
<secretlondon>     missing functions"
<geser> secretlondon: http://paste.ubuntu.com/5023/ is the log of what you have missed
<secretlondon> geser thanks
<geser> no problem
<secretlondon> but the fact that we have an api that upstream don't have worries me
<geser> yes, me too
<slangasek> is it an ABI difference, or just an API difference?
<geser> I'd list it somewhere in the report but don't know where
<geser> slangasek: API addition according to the patch name
<secretlondon> I'm going to add it in background info
<slangasek> so it doesn't break ABI compatibility with upstream?
<slangasek> I wouldn't worry overly much about that
<secretlondon> ok
<geser> slangasek: doesn't look like, the modified header file has only additions (no replacements)
<slangasek> geser: uhm, but additions of what?
<slangasek> geser: if it's adding new entry points into the library, that's an ABI difference, and something to be wary of (though not necessarily in this context)
<geser> slangasek: some code it moved into there own functions but the the old functions call the new ones
<slangasek> perhaps you could point me to the patch in question?  I think looking at it would be easier
<geser> api-additions.patch in sdlpango
<persia> ScottK: I'm running off, but I added the request to file a new candidate bug when there were multiple fixes because when I was a contributor, I had several complaints from both bug reporters and sponsors that I was confusingly combining things in patches.  This was intended to avoid that.
<persia> I've no strong attachment to the practice, if it is consensus that it is incorrect.
<ScottK> persia: OK.  It was the first I heard of it when I say a diff of the related page.
<ScottK> persia: At most I'd say it's a may not a must.
<persia> ScottK: Agreed.  Definitely "may".  The only intention was to avoid confusion.  Feel free to adjust phrasing if you like (I'm not sure must -> may for that needs a meeting item)
<ScottK> persia: Will do.  Thanks.
<geser> slangasek: or should I pastebin it?
<slangasek> geser: nope, looking already; the patch looks to me like an ABI change
<slangasek> I'm double-checking the binary package
<geser> slangasek: if I understood libraries correctly, it's only a problem if a Debian/Ubuntu binary linked against this lib is used with an plain upstream version, correct?
<geser> programms linked with the "clean" lib should also continue to run with our version, also correct?
<slangasek> geser: it's also a problem if upstream later adds functions under these same names but with a different prototype, without changing the soname, which they're entitled to do
<geser> true
 * persia notes that this is the sort of change that upstream can make without an ABI transition, but cannot be made by a distribution without confusion.
<ScottK> persia: Updated and removed from the agenda.  Thanks.
<persia> ScottK: Thanks for the review.  The wiki is often behind current usage, and in cases where this isn't a result of lax compliance, the updates are exceedindly helpful
<secretlondon> http://sourceforge.net/tracker/index.php?func=detail&aid=1882228&group_id=110621&atid=657085 may refer to the api patch
<ubotu> Gaim bug 1882228 "API extension for Frozen Bubble" [Pri: 5,Open]
<secretlondon> that claims that freebsd also have the same patch as debian, and it is for frozenbubble
<pochu> superm1: do you work for dell?
<mario_limonciell> pochu, yes
<mario_limonciell> pochu, i attached a debdiff to the debian bug of gst-plugins-base0.10 since it looks like we sync from there normally, but they haven't shown up in the BTS for the last 30 minutes for some reason or another
<pochu> mario_limonciell: Debian bug 468073 ?
<ubotu> Debian bug 468073 in gst-plugins-base0.10 "gst-plugins-base0.10: Gstreamer inputs default to outdated V4L,and require to be changed to V4L2 on first run" [Normal,Open] http://bugs.debian.org/468073
<mario_limonciell> pochu, yeah
<pochu> mario_limonciell: did you send it to 468073@bugs.debian.org?
<mario_limonciell> pochu, yeah
<pochu> mario_limonciell: you can attach it to the ubuntu bug too, slomo is subscribed there so he'll receive it
<mario_limonciell> sure
<pochu> thanks
<mario_limonciell> pochu, weird, i attached a debdiff to an ekiga debian bug 5 minutes ago and it showed up immediately.
<crimsun_> how large was the gst-plugins-base0.10 debdiff vice the ekiga one?
<mario_limonciell> 2k each
<mario_limonciell> crimsun_, did you get a chance to look over bug 193823?
<ubotu> Launchpad bug 193823 in alsa-utils "HDA Intel cards with "Digital" capture mixers default to a  very low volume" [Medium,In progress] https://launchpad.net/bugs/193823
<crimsun_> mario_limonciell: no, thanks for the heads-up.  (I travel without reliable 'net access, so I'm no longer in the bug contact group)
<mario_limonciell> crimsun_, ah okay.  thanks :)
<mario_limonciell> rtg was going to apply it, but then got scared of bzr
<crimsun_> mario_limonciell: mm, on which codecs?
<crimsun_> mario_limonciell: just Sigmatels?
<mario_limonciell> well i've only verified it on sigmatels
<crimsun_> mario_limonciell: there are some Conexant and Realteks that will do nasty things if that and PCM are set higher than 50%
<mario_limonciell> but do they have a mixer entitled "Digital"
<mario_limonciell> or is it named different?
<crimsun_> the name string really isn't terribly important
<crimsun_> which node id is it?
<mario_limonciell> give me a sec
<crimsun_> some do have "Digital", but the node id is more important, since you can just whack the name string
<pochu> mario_limonciell: if I renew my laptop, I'll consider switching to a dell so I can bug you if something doesn't work :P
<mario_limonciell> crimsun_, looks like it should be 0x20
<mario_limonciell> pochu, hehe
<crimsun_> mario_limonciell: ok, I'll check the Realteks tonight
<mario_limonciell> crimsun_, well actualyl there are two digital inputs, hopefully that's the right one, 0x22 is marked as a pin complex, but 0x20 is marked as an Audio Input
<crimsun_> mario_limonciell: otherwise, it looks fine - just need to verify it doesn't break others
<mario_limonciell> crimsun_, okay, let me know if you need anything more
<mario_limonciell> ah a little more detailed, the node info on 0x20 lists a connection to 0x22.
<secretlondon> geser: I've done some digging and it looks like many distros have added the patch. upstream may be dead tho
 * secretlondon is finally going to bed and will continue tomorrow..
<crimsun_> mario_limonciell: excellent, thanks.
<crimsun_> mario_limonciell: merged tentatively as revision 4
<mario_limonciell> crimsun_, great
<emgent> superm1, ping
<mario_limonciell> emgent, that's my second name, what's up?
<emgent> heya mario_limonciell
<emgent> vlc patch is out for CVE-2008-0984
<emgent> i saw that you are debian maintainer
<slangasek> mario_limonciell: "ping" is your second name? :)
<emgent> please consider
<emgent> http://www.videolan.org/security/sa0802.html
<emgent> for upload :)
<mario_limonciell> slangasek, yup :)
<emgent> it's a security issue
<mario_limonciell> emgent, did you file a bug for it already in LP?
<emgent> yep
<emgent> wait
<emgent> https://bugs.edge.launchpad.net/ubuntu/+source/vlc/+bug/195949/
<ubotu> Launchpad bug 195949 in vlc "VLC Arbitrary memory overwrite in the MP4 demuxer" [Medium,In progress]
<emgent> i'm patching it now.
<emgent> pbuilting test
<mario_limonciell> emgent, sure i'll be glad to help push  that around to the correct builds.  just subscribe me to the bug and let me know when you've made sure the builds don't break
<emgent> ok sure
<emgent> Thanks
#ubuntu-motu 2008-02-27
<blueyed_> doko: do you mind if I upload a fixed pyopengl package (bug 195270)?
<ubotu> Launchpad bug 195270 in pyopengl "RuntimeError: Unable to find an implementation for the 'linux2' ('posix') platform" [Medium,In progress] https://launchpad.net/bugs/195270
<doko> blueyed: please go ahead
<emgent> superm1, vlc pbuilted fine. patch is avaiable on Bug #195949
<ubotu> Launchpad bug 195949 in vlc "VLC Arbitrary memory overwrite in the MP4 demuxer" [Medium,In progress] https://launchpad.net/bugs/195949
<emgent> someone can upload this in hardy?
<emgent> debdiff is attached.
<emgent> blueyed, have you time? :P
<blueyed> emgent: please subscribe u-u-s, I'm doing my last fix for today..
<emgent> ok
<blueyed> Any ideas why you would do "sed -i -e '/setup\.cfg/d' PyOpenGL.egg-info/SOURCES.txt" in the clean target?
<LaserJock> any MOTUs about who are feeling like doing a little reviewing for me?
<geser> LaserJock: still those 5 multiverse packages?
<LaserJock> yeah
<geser> where are they?
<LaserJock> http://laserjock.us/files/edubuntu/squeak/
<LaserJock> the debdiff's aren't useful
<LaserJock> 3 of them are basically trivial
<geser> complete new packages or are those updates?
<LaserJock> well
<LaserJock> they are completely new packaging
<LaserJock> we have squeak packages but I'm redoing them
<LaserJock> I just wanted a 2nd MOTU eye
<geser> first note: please don't use native packages, especially with this size
<geser> I wouldn't like to upload 7 MB for every bugfix
<LaserJock> well, that can't be helped much
<LaserJock> but is an idea I can talk with upstream about
<geser> LaserJock: aren't you the packager?
<LaserJock> actually not completely
<LaserJock> I have an upstream
<LaserJock> I'm getting things fixed up for Ubuntu
<geser> an orig.tar.gz and a diff.gz would be really nice
<LaserJock> perhaps
<LaserJock> the native packages don't really change much
<LaserJock> but I'll add that to my list to ask upstream about
<geser> will the packages go also to debian?
<LaserJock> nope
<LaserJock> that's why it's a mess ;-)
<geser> what about the version? wouldn't a -0ubuntu1 be better? so it's obvious it isn't from Debian
<LaserJock> because that's actually the version
<LaserJock> my upstream is an "official" unoffical Debian repo
<Nafallo> eeeh
<Nafallo> that sentance calls for explaination :-)
<geser> LaserJock: the tar.gz for squeak-image is missing a verbatim copy of the license
<LaserJock> upstream has a Debian repo
<Nafallo> aah
<LaserJock> Nafallo: ^^
<Nafallo> that explains :-)
<LaserJock> so it's official
<LaserJock> but since it's not in Debian it's unofficial
<LaserJock> ;-)
<LaserJock> geser: hmm, I think I've got it about as good as it gets
<LaserJock> debian/copyright has the complete license
<geser> LaserJock: yes, but the archive admins want also a verbatim copy of the license, but given that debian/copyright is inside the tar.gz and not the diff.gz it might pass
<LaserJock> yeah, plus a license isn't shipped so I'm not sure I should just add one
<LaserJock> it's not shipped as a tarball
<geser> LaserJock: squeak-image3.9 looks ok, looking at the next one now
<ScottK2> LaserJock: If the upstream licensing is clear, you can repack the tarball to add the verbatim license copy (I've done it and had it accepted).
<LaserJock> ScottK2: yeah, it just is kinda silly
<LaserJock> as it's a native package it'd be the same thing, just in a different dir
<ScottK2> LaserJock: I disagree.  Pointers to web sites aren't static.
<LaserJock> there is a verbatim copy in debian/copyright
<LaserJock> all I'd be doing is adding another copy in the root dir.
<ScottK2> Ah.  If it's a native package, then I agree it's different.
<ScottK2> Dunno how the archive feels about it, but that makes sense.
<LaserJock> well, I'm *greatly* improving the situation with these packages so I'm hoping they'll find them ok ;-)
<mib_u3hwzal9> LaserJock: quick question, are their alternative links that describe the science packages on the MOTU science team wiki other than those provided (e.g. other than http://qa.ubuntuwire.com/multidistrotools/science.html#outdatedinB)?
<LaserJock> mib_u3hwzal9: unfortunately no
<LaserJock> at least not at this moment
<mib_u3hwzal9> k, thanks!
<LaserJock> I'm hoping qa.ubuntuwire.com will be back up soon
<geser> LaserJock: squeak-plugin-image looks also ok
<mib_u3hwzal9> LaserJock: i'm looking forward to it
<geser> LaserJock: why two different squeak-sources packages?
<mib_u3hwzal9> LaserJock: I'd also like to know if anyone on the science MOTU team has thought about a better way to package comedi...
<LaserJock> geser: because two of the other packages dep on one or the other of them
<mib_u3hwzal9> LaserJock: Sorry... I just realized that you are already in the middle of a conversation...
<LaserJock> mib_u3hwzal9: no problem
<LaserJock> mib_u3hwzal9: well, honestly we just basically pull from Debian
<LaserJock> mib_u3hwzal9: are there some things you'd like to improve?
<geser> LaserJock: dpkg-source: failure: cannot read ./squeak_3.9.8.orig.tar.gz: No such file or directory
<LaserJock> geser: there's actually quite a few -sources packages, I'm only taking the newest and necessary ones
<LaserJock> geser: oh, I didn't upload it, gimme a sec
<mib_u3hwzal9> LaserJock: At the moment, the comedi package (which is comedi-source) is the comedi source code... I think, but it in reality that is just a little bit better than having to download the tarball...
<mib_u3hwzal9> LaserJock: I have to run!
<mib_u3hwzal9> take care!
<LaserJock> geser: ok, it's there
<geser> LaserJock: squeak: debian/control: remove g++ (>> 1:3.3.5-13) from Build-Depends, even dapper has g++ 4:4.0.3
<geser> LaserJock: Sun Microsystems, Inc. is missing in listing the copyright holders
<geser> LaserJock: ./platforms/Cross/plugins/SoundCodecPrims/sqSoundCodecPluginBasicPrims.c is missing the mentioned COPYRIGHT file
<nxvl> did anyone has make update-manager work on openbox?
<geser> LaserJock: and what is the Squeak-L license mentioned in ./platforms/Cross/plugins/QuicktimePlugin/QuicktimePlugin.h?
<nxvl> (i mean to make it show a warning when there are updates
<LaserJock> geser: I thinks the just the Squeak license
<geser> LaserJock: and ./platforms/Cross/plugins/JPEGReadWriter2Plugin/* doesn't tell the license (a mentioned README is missing)
<LaserJock> doesn't surprise me, the whole thing is a bit messy
<geser> LaserJock: it would be good to add the other copyright holders to debian/copyright, like University of Cambridge or Thomas G. Lane
<geser> and ./platforms/unix/npsqueak/include/jri* doesn't seem to allow redistribution "Copyright (c) 1996 Netscape Communications Corporation. All rights reserved."
<geser> LaserJock: all packages except squeak look good, squeak needs some work on the copyright holders and check if all files are really redistributable
<LaserJock> alrighty, sounds good
<LaserJock> I really can't figure out how OLPC thinks it's ok to ship this stuff
<LaserJock> *shrug*
<LaserJock> ScottK: still around?
<ScottK2> Yes
<LaserJock> ScottK2: ok, so I think I'm ready to upload these squeak packages
<LaserJock> I basically need a UVFe/FFe
<ScottK2> OK
<LaserJock> I'm not sure how you'd like it
<LaserJock> I'm replacing packages, etc. so I'm not sure what to file the bug against
<LaserJock> diffstats aren't gonna be much use
<LaserJock> neither are .diff.gzs , etc.
 * Hobbsee squeaks
<ScottK2> Right, so just file a bug against Ubuntu (like needs-packaging bug) and convince me it's worth it to trouble the archive admins for this late in the cycle.
<LaserJock> k, gimmie a minute
<ScottK2> If you're really persuasive, maybe Hobbsee will ack it too and you'll be approved.
<LaserJock> awesome
<Hobbsee> LaserJock: so is this planning to go into debian proper too?
<LaserJock> Hobbsee: no, Debian won't take it
<LaserJock> as in, the packages
<Hobbsee> LaserJock: licencing?
<LaserJock> they are non-free
<LaserJock> yeah
<Hobbsee> so they won't even take it into non-free?  wow
<LaserJock> supposedly it's gonna eventually be MIT or Apache
<LaserJock> Hobbsee: yeah, Apple owned a lot of it
<Hobbsee> LaserJock: i'd tend to go for upstream supported new crack over not-supported crack.
<LaserJock> well, that's basically what I'm doing actually
<LaserJock> the Squeak people have a Debian repo
<LaserJock> and so I'm sort of syncing up with that
<LaserJock> so we have better supported packages
<LaserJock> our current ones were taking from some Spanish distro around Breezy and never really updated
<Hobbsee> LaserJock: probably a good exception then, in terms of long term support crack
<LaserJock> yeah
<LaserJock> and I think I'll close ~ 11 bugs in doing it
 * ScottK2 looks forward to reading the bug.
<Hobbsee> damn.
<LaserJock> ScottK2: I sure wouldn't ;-)
 * ScottK2 is glad he doesn't have to write it.
<LaserJock> yeah, I gotta look some more at this
<LaserJock> I gotta get dummy packages in there
<LaserJock> make sure all the bugs are done
<LaserJock> then describe this whole mess ;-)
<ScottK2> Actually that illustrates what I think the real purpose of the FFe is.  Not so much for motu-release to be a gate keeper, but to make sure the developer has really thought through what they are doing.
<LaserJock> yep
<LaserJock> lets me sort of "put the package together" in a coherent way
<LaserJock> this is like a 5 package deal so it's good to get all written down
<emgent> jdstrand, ping
<emgent> argh big idle :Â°
<protonchris> I am working on bug 190744 and a reviewer asked for a diff of the symbols between the old and new version.  What is the best way to do that?
<ubotu> Launchpad bug 190744 in libgdamm3.0 "Request: Upgrade libgdamm3.0 to upstream version 2.9.81" [Undecided,Confirmed] https://launchpad.net/bugs/190744
<bddebian> Heya gang
<ScottK> heya bddebian
<bddebian> Hi ScottK
<LaserJock> gah, is debian.org down?
<StevenK> debian.org could mean many things
<LaserJock> sorry, www.
<StevenK> Which is klecker. It looks like xs4all is still having issues
<emgent> netsplit
<jdong> vorian: when you get time, please comment on $ktorrent_kde4_bug
<vorian> jdong, will do
<vorian> jdong, I just got home
<jdong> vorian: how dare you have a life outside Ubuntu?!
 * vorian hides
 * jdong scavenges his room for junkfood
<vorian> jdong, we got a white out before I took off for home
<vorian> a 30 min drive quickly turned in to an hour and a half
<vorian> jdong, are you talking about the ktorrent final?
<jdong> vorian: I've heard weather is nasty in your part
<jdong> vorian: yeah I commented on the bug that I could not get a wrapper to show up with your diff.gz
<vorian> aye, I hate this winter
<vorian> right
<vorian> ok, I got that message
<vorian> I'll rebuild the upgrade w/ your revision
<jdong> alright, awesome
<vorian> :)
<jdong> wait... is the wrapper created in postinst or something?
<jdong> I only ar x unpacked the deb's data.tar.gz looking for the wrapper :)
<jdong> too lazy to chroot
<vorian> no
<vorian> well, it's in debian/cdbs
<jdong> ok, because after I built (making sure I applied all your patches correctly) /usr/bin failed to exist
<vorian> hmmmm
 * ScottK2 makes a note to continue the practice of ask jdong when torrent related FFe's come up.
<vorian> jdong, do you want a debdiff?
<jcastro> persia: ScottK2: thanks for taking care of the glassfish folk.
<ScottK2> jcastro: Well they need to get their packages advocated before they actually get anywhere.
<jcastro> yeah, I know they have problems
<jcastro> I more am happy with the fact that there are discussions. :)
<ScottK2> K
<jdong> vorian: did you get it to work?
<vorian> yep
<jcastro> they're in prague afaik, so will probably be at UDS
 * jdong cries
 * ScottK2 would be more happy if klamav would build twice in a row.
<vorian> jcastro, what's up man!
<jdong> vorian: just put up the entire dsc-orig-diff.gz triplet
<jcastro> hi vorian
<vorian> jdong, ok
<ScottK2> jcastro: OK.  Just don't confuse doing motu-release stuff with actually caring about Java stuff.
<jcastro> ScottK2: it's ok, I'm accustomed to no one caring about java stuff, heh
<emgent> ScottK2, heya
<emgent> have you time for sponsorize one upload?
<jcastro> ScottK2: I think the java-db guys were too late, I think what happened is we had talked to the netbeans guys for a while and persia got them up to shape before FF, then it looks like to me that the java-db guys heard about it from coworkers and were late to the party.
<ScottK2> emgent: Maybe.  What is it?
<emgent> VLC security fix (for hardy)
<emgent> mailed keescook for gutsy, feisty, edgy, dapper
<ScottK2> jcastro: Understand.  I also understand good relationships with Sun aren't a bad thing.
<ScottK2> emgent: What bug?
 * ScottK2 will look.
<emgent> bug #195949
<ubotu> Launchpad bug 195949 in vlc "VLC Arbitrary memory overwrite in the MP4 demuxer" [Medium,In progress] https://launchpad.net/bugs/195949
<jcastro> ScottK2: well, that's why I hope they come to UDS, if we can "train" them to be self sufficient and take of their stuff I think that would be best for everyone.
<emgent> ScottK2, if you can open task too.
<emgent> i can only nomine it :(
<emgent> s/nomine/nominate/
<ScottK2> emgent: Is there a CVE for this?
<emgent> nope, it'snt avaiable now
<emgent> only avaiable in http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-0984
<emgent> but no in mitre
<ScottK2> jcastro: If they want to be part of the community and earn their spurs, that's great, but I'm not fan of sabdfl's plan to give limited upload rights for upstreams.
<jcastro> I've not heard of this
<ScottK2> emgent: If you know what the CVE number will be, you can put it in the changelogs.  Did you?
<jcastro> I've been pushing upstreams to become MOTUs themselves
<emgent> ScottK2, sure
<ScottK2> Great
<emgent> ScottK2, see http://launchpadlibrarian.net/12245485/hardy_vlc_0.8.6.release.d-0ubuntu3.1.debdiff
<emgent> it's in.
<emgent> see also http://www.videolan.org/security/sa0802.html
<ScottK2> Periodically someone will whine MOTUs aren't responsive enough and then sabdfl will show up here and pontificate about how we should give package specific upload rights.
<ScottK2> emgent: OK.  Please link the CVE in the bug too.
<emgent> i cant with references
<emgent> only in comment
<emgent> linkcve accept now only mitre
<emgent> and it'snt out now.
<ScottK2> I see.
<ScottK2> OK.  Hardy version should be ubuntu4, not 3.1
<emgent> ups, true there arent -security in hardy
<emgent> true.
<vorian> jdong, I made an archive of the whole darn tree for you
<emgent> ScottK2, i change it now or you can edit and upload ?
<ScottK2> emgent: I'm going to let you redo it.  also  instead of "when using crash the player instance."  How about "when the player crashes."
<ScottK2> I think that's what you meant.
<emgent> i was copy it to http://www.videolan.org/security/sa0802.html
<emgent> original advisory
<emgent> ScottK2, i should change or i can use original advisory text ?
 * ScottK2 looks
<superm1> emgent, i'm back did you still need a sponsor?
<ScottK2> emgent: Use the full text of both sentences.
<ScottK2> superm1: If you would do so, I'd appreciate it.
<emgent> :D
<jdong> vorian: I'll look at it soon
<superm1> emgent, okay i'll look in a sec
<vorian> take your time jdong
<vorian> :)
<emgent> thanks ScottK2 && superm1
<superm1> ScottK2, you want to grab two of the releases and i'll do the other two?
<ScottK2> superm1: He's got to do some rewriting anyway.
<superm1> ScottK2, oh okay, i haven't looked yet
<ScottK2> superm1: If you could do it, I'd really rather.
 * ScottK2 is finally trying to get klamav ready to be sponsored in Debian and would rather keep on it.
<emgent> superm1, just a moment i will send to you debdiff with correct changelog version
<superm1> ScottK2, "did you mean if you could all four, i'd really rather not"
<superm1> that sentence didn't read right
<jdong> superm1: You know I have that phrase highlighted :)
<superm1> which phrase?
<jdong> "didn't (read|sound) right"
<superm1> haha really
<ScottK2> superm1: What I meant was please do it all.  I'm busy and would prefer to do the other thing I was working on.
<superm1> ScottK2, okay that's what I thought
<superm1> no prob
<bddebian> Does gnomefreak still come around?
<ScottK> It's been some time since I remember seeing him.
<bddebian> Know of anyone else within Ubuntu or Debian looking at enlightenment DR17?
<ScottK> No.
<bddebian> Well you're no use. ;-P
<ScottK> Depending on how badly you want to know the answers to both those questions, I suggest judicious use of wget and grep on the site that hosts the Ubuntu IRC logs.
<ScottK> There you go.  Use.
<bddebian> heh
<LaserJock> anybody know offhand the syntax for closing multiple bugs in a changelog
<LaserJock> can you just comma separate them?
<bddebian> You can in Debian, not sure about LP
<LaserJock> hehe, I have to word-wrap the Closes: line, awesome
<StevenK> dpkg-genchanges would tell you
<StevenK> Try to wrap it, run dpkg-genchanges, and look for the Launchpad-Bugs-Fixed tag
<LaserJock> I just added another Closes: line
<LaserJock> but it worked
<LaserJock> wahoo, I even got a nice transition
<LaserJock> Hobbsee: around?
<LaserJock> TheMuso: ping?
<bddebian> Gnight folks
<LaserJock> dang, I finally get the bug done and nobody's around :-)
<LaserJock> ScottK2: seemed ok to you?
<Hobbsee> LaserJock: yeah
<LaserJock> Hobbsee: I wondered if you could have a look at bug #196016
<ubotu> Launchpad bug 196016 in ubuntu "FF exception request for Squeak packages" [Undecided,New] https://launchpad.net/bugs/196016
<Hobbsee> LaserJock: done
<LaserJock> Hobbsee: awesome
<Hobbsee> you're welcome
<LaserJock> man, this has taken like 6+ months
<LaserJock> it'd be nice to get it over with :-)
<LaserJock> dholbach!
<dholbach> good morning
<dholbach> hi LaserJock
<superm1> morning dholbach
<dholbach> hiya superm1
<superm1> hmmm so if something is looking for firefox-config now in its configure script, that's not going to work anymore is it
 * LaserJock starts the "big dput"
<superm1> what other apps had to be xulified?
<superm1> so i can see what's involved with the conversion
<RAOF> superm1: Miro did.
<RAOF> I think monodevelop has, but I'm not sure.
 * superm1 apt-get source's 
<superm1> not what i call a pretty patch
<RAOF> No.  I didn't write it myself; that was asac.
<superm1> did he pull that from miro trac?
<superm1> or write it?
<RAOF> I think he wrote it.
<LaserJock> wow, and the NEW queue is really cleaned out
<superm1> maybe aught to have him do one for VLC too then :)
<RAOF> Why does VLC need to embed gecko?!
<superm1> well it builds a firefox plugin, but i dont think it embeds gecko...
<RAOF> Then it'll need a very different patch, IIUC.
<superm1> i'll check VLC trac, it's very possible someone already started to approach this
<superm1> slomo, i tried to attach a patch to debian bug 468073, but for some reason it never showed up, so i ended up putting in on the launchpad equivalent of the bug (but the patch is targeted to debian)
<ubotu> Debian bug 468073 in gst-plugins-base0.10 "gst-plugins-base0.10: Gstreamer inputs default to outdated V4L,and require to be changed to V4L2 on first run" [Normal,Open] http://bugs.debian.org/468073
<slomo> superm1: hi :) which bug?
<superm1> hi slomo
<superm1> let me grab the number in lp, sec
<superm1> bug 195914
<ubotu> Launchpad bug 195914 in gst-plugins-base0.10 "Ekiga & gstreamer inputs default to outdated V4L, and require to be changed to V4L2" [Wishlist,In progress] https://launchpad.net/bugs/195914
<slomo> superm1: that patch is not good... we still have to ship the v4l plugin as much hardware is only supported by the old one
<superm1> slomo, how can any hardware be supported on the old one if the interface isn't present in the kernel though?
<slomo> superm1: v4l is not present in the kernel anymore? hm
<superm1> slomo, per http://linuxtv.org/v4lwiki/index.php/Development:_Video4Linux_APIs
<slomo> when was it removed? :)
<superm1> "http://linuxtv.org/v4lwiki/index.php/Development:_Video4Linux_APIs"
<superm1> oops "Support for the v4l API was dropped from the 2.5.x branch with the 2.6.15 kernel release, but remains in the 2.4.x branch. "
<slomo> ok, ubuntu only supports 2.6 so that's not a problem
<slomo> hm
<superm1> same for debian sid though is it not?
<slomo> yes
<slomo> i wonder why it is still possible to compile it, i.e. why are the headers still there
<slomo> and last time i heard something about v4l it was said that most drivers are still not ported to v4l2
<slomo> i'll investigate, thanks :)
<superm1> slomo, no prob.  let me know what you find out.
<superm1> slomo, i dont see any kernel headers installed in the package build: http://launchpadlibrarian.net/12103867/buildlog_ubuntu-hardy-i386.gst-plugins-base0.10_0.10.17-3_FULLYBUILT.txt.gz
<slomo> superm1: linux-libc-dev or how it's called is in build-essential
<superm1> slomo, right, but no linux-headers-*
<superm1> linux-libc-dev doesn't include any V4L headers in itself from what it would appear
<slomo> hm
<slomo> how is it built then?
 * superm1 looks closer at the source
<superm1> slomo, okay look at /usr/include/linux/videodev.h
<slomo> ok
<slomo> there's videodev.h and videodev2.h
<slomo> so it's both, right?
<superm1> yeah videodev2.h is used by the -good
<superm1> plugins
<superm1> which does v4l2
<slomo> v4l1 is obsolete but still there it seems
<superm1> yeah that's what it would appear
<slomo> ok
<slomo> so what's the problem? ;)
<superm1> well the problem attempting to solve is that when apps first start to use gstreamer, they default to the obsolete V4L driver
<slomo> ok but that can be changed in the app, no?
<slomo> the problem is, that the v4l2 plugin is still marked as experimental and doesn't seem to be complete and good working yet
<superm1> well yes, but as a first user usability sort of thing
<superm1> the V4L one flat out doesn't work with any of the webcams i've tested it with
<superm1> only V4L2 does
<superm1> the alternative solution to disabling it entirely would be to change the schema default in gconf
<superm1> to start at V4L2
<slomo> that's better imho
<superm1> okay, i'll work out a patch for that
<superm1> ignore the current one for now then :)
<superm1> Thanks
<slomo> superm1: did you forward the kfreebsd patch upstream?
<superm1> slomo, i was still waiting to hear their response to the licensing stuff
<superm1> i was going to as soon as I heard back on that
<superm1> it's uncharacteristic for them to not respond within a day or two, so hopefully hear back todayish
<liri> lintian complains about extra-license-file which is included for a library I use (I didn't receive it so I don't violate any gpl rights). what should I do about it?
<\sh> blueyed_: ping php5-xdebug :)
<\sh> moins jono
<geser> good morning
<jono> hey \sh
<Iulian> Hi
<tbf> ho
<\sh> if someone from the release team has time, please review bug #196086
<ubotu> Launchpad bug 196086 in zend-framework "[FFe Exception] zend-framework 1.0.4" [Wishlist,New] https://launchpad.net/bugs/196086
<\sh> _czessi: moins :) looks like I'll get my free time for LinuxTag 2008
<Nightrose> \s
<Nightrose> \sh: yay
<Nightrose> :)
<\sh> Nightrose: :)
<geser> \sh: afaik you don't need a FFe for a bug fix release
<Nightrose> \sh: maybe we can get there together somehow (sven, you and me)
<\sh> geser: well, it's a new upstream release (officially)...and better one more report then no paperwork and getting hit by hobbsees long pointy stick :)
<\sh> Nightrose: would be cool :)
<Nightrose> :)
 * Hobbsee attacks \sh with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! â¢ anyway
<persia> Hobbsee: Bah.  Isn't the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! â¢ intended to provoke appropriate behaviour?  How is \sh to learn?
<Hobbsee> persia: it depends
<persia> (Long Pointy Stick of DOOM!!!!!!!!!!!!!!! â¢ is a trademark of Hobbsee, and used with limitd permission by reference)
<Hobbsee> i'm sure it can be a belated provoking
<persia> Ah.  "pout encourages les autres"...
<persia> s/pout/pour/
<\sh> emgent: ping cacti bug #194687
<ubotu> Launchpad bug 194687 in cacti "cacti web frontend fails with 'Invalid PHP_SELF Path' after upgrade" [Medium,Confirmed] https://launchpad.net/bugs/194687
<\sh> emgent: emgent I can see the fix in the debdiffs I provided for cacti while fixing CVE-2008-0783 CVE-2008-0784
<ubotu> Multiple cross-site scripting (XSS) vulnerabilities in Cacti 0.8.7 before 0.8.7b and 0.8.6 before 0.8.6k allow remote attackers to inject arbitrary web script or HTML via the (1) view_type parameter to graph.php, (2) filter parameter to graph_view.php, and (3) action and login_username parameters to index.php/login. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0783)
<ubotu> graph.php in Cacti 0.8.7 before 0.8.7b and 0.8.6 before 0.8.6k allows remote attackers to obtain the full path via an invalid local_graph_id parameter and other unspecified vectors. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0784)
<Hobbsee> jdong: can you backport bip please?
<ScottK> \sh: Did you see claws-mail has a 3.3.1 version?
<\sh> ScottK: hmm..no
<\sh> or
<ScottK> It's in Debian.  I thought you might want to have a look and see if we want it.
<jdong> Hobbsee: is there a backport bug open for that?
<Hobbsee> jdong: no
<Hobbsee> jdong: it's called bug-reporting-over-irc
<\sh> ScottK: i will check upstream what was changed...
<jdong> Hobbsee: :)
<\sh> brb
<\sh> ScottK: I'll do a merge this evening when I'm home...it seems good to have this :) especially Forbid attaching anything containing "../" or ".ssh/" in mailto:
<\sh> URIs.
<\sh> ;)
<ScottK> Yes.
<ScottK> \sh: Don't forget the extras package like that one guy did last time '-)
<\sh> ScottK: for sure :)
 * \sh needs a todo list plugin for drupal ;)
<ScottK> \sh: Does your zend update have just bug fixes or new features too?
<mruiz> hi all
<Iulian> Hey mruiz
<\sh> ScottK: only bugfixes...new features are introduced in 1.5.x release, later in march
<ScottK> \sh: Then it didn't need an FFe.  Please see sistpoty's comment in the bug though.
<\sh> ScottK: yepp..I read about this, but as it's a draft...I'll introduce this binary package for hardy+1 ... let's go with this now for hardy...
<\sh> ScottK: it prevents me from going through NEW again
<ScottK> OK
<ScottK> Fair enough.
<\sh> ScottK: the good thing is, Zend will work with us towards a good release for their libs :)
<jdong> anyone mind if I backport the latest git to Gutsy?
<tbf> jdong: yeah! latest git for gutsy - rock on.
<jdong> I just noticed in an upgrade audit the dapper-backports version is > feisty-backports, feisty, gutsy, gutsy-backports
<tbf> jdong: how bizare
<tbf> jdong: well, but git-svn still sees major enhancements with each new git release - since: the new the better
<tbf> erm... newer
<jdong> tbf: indeed, I've noticed Gutsy's git-svn was out of line with modern docs
<jdong> particular with the way to set up branches/tags/trunk
<jdong> I'll attempt the backport on everything back down to Edgy...
<persia> jdong: What would such a backport break?  Is bit like bzr in that backporting makes repositories incompatible for those not using -backports?
<jdong> maybe Dapper too
<persia> s/bit/git/
<jdong> persia: almost all the git-core rdepends seems like stuff already in the git-core source package
<jdong> persia: but there are a few rdepends that are not... hence why I asked here first
<jdong> grumble FTBFS on <gutsy
<persia> jdong: Makes sense. There do seem to be just a few rdepends :)
<persia> jdong: Is it really "frontporting" rather than "foreporting"?
<jdong> persia: haha I thought front::back::::pre::fore :)
 * persia was thinking of "forwards" vs. "backwards", rather than "forequarters" vs. "hindquarters".
<jdong> lol
<jdong> maybe it is foreport :)
<jdong> I've never actually had to use the term before now
<persia> Also, just out of curiosity, what becomes of edgy-backports when hardy and feisty are supported, but edgy is dropped?
<Hobbsee> it stops being supported, i expect
<jdong> persia: I'd expect active testing/processing to stop, though nothing precludes revisiting the repo if someone cares enough
<jdong> persia: generally the most active backports testers seem to focus on the current stable release; even Feisty is light on attention atm
<ScottK> Personally I stopped looking at Edgy Backports to approve stuff a couple of months ago.
<ScottK> I may yet try to shove clamav in there as a dry run for Feisty/Gutsy
<persia> Hmm.  Maybe it might make sense to have an announcement, and ask for archiving of the project.  Also, you may want to check with the LP team to see what happens when the archives get archived.
<mruiz> Vcs-* fields are supported by Ubuntu packaging?
<persia> mruiz: Yes.
<mruiz> and XS-* stuff ?
<persia> mruiz: Well, Yes, but I suspect you're asking a different question.
<persia> What are you seeking to accomplish?
<mruiz> persia, I'm reading a debian/control file and I tried to figure out about fields differences between Debian/Ubuntu packaging
<jdong> Wishlist: screen needs compiz style effects... scale, spaces, cube....
<persia> mruiz: No real difference.  Vcs-* became non-experimental a few months ago, so lots of packages still have XS-Vcs-* (which also works, but takes more characters to type)
<jdong>    rebase        Forward-port local commits to the updated upstream head
<jdong> persia: ^^ git likes to call it forward-port :)
<persia> That's a good word.  Clear to everyone :)
<jdong> still asymmetric with backport (backward-port)? :D
<mruiz> persia, but I think that "XS-DM-Upload-Allowed" is just for Debian...
<persia> mruiz: There's no advantage to having it for an Ubuntu package, but it doesn't hurt anything.
<mruiz> persia, great
<bddebian> Heya gang
<geser> Hi bddebian
<bddebian> Heya geser
<raphink> hi guys
<thekorn> dholbach, hi, you can merge and release a hardy version of the 5-a-day-applet when you want,
<thekorn> it's basically working so no objections from my side
<bddebian> Hi raphink
<raphink> what's up bddebian?
<bddebian> Nuttin'  You?
<dholbach> thekorn: ROCK ON - I'll dive into it later
<thekorn> dholbach, maybe the login dialog needs some more work
<raphink> bddebian: trying to build a static libc6 in debian... but it won't build a static libnss_nis.a
<raphink> :(
<ScottK> mok0: I uploaded storm for you, but look at debian/changelog for the adjustment I made in the package.
<mok0> Thanks, ScottK
<ScottK> mok0: No problem.  Thanks for contributing.
<huats_> hum hum
<mok0> ScottK: It's good to be uptodate with Canonicals stuff
<huats_> is there no vmware in hardy ?
<ScottK> huats_: You'll probably be able to get it from partner after release.
<ScottK> It usually lags.
<huats_> ScottK
<huats_> ok thanks
<huats_> ScottK in fact I remember now, it is now even in gutsy...
<huats_> and I have to install it with a dirty stuff (using alien and an rpm...)
<huats_> thanks anyway :)
<ScottK> Ah not for gutsy you don't
<\sh> huats_: if you need a vmware-server install now, just use the tar.gz ... you need to adjust some stuff anyways
<\sh> huats_: (e.g. libpng12 and some other libs which needs to be write over with the ubuntu ones)
<huats_> \sh: hum ok
<huats_> I'll have a look then
<huats_> thanks
<\sh> huats_: and install the vmware update
<ScottK> Isn't that still built against openssl 0.9.7?
<ScottK> or did they fix that?
<huats_> ScottK no idea
<\sh> vmware update == vmware-any-any update because of the kernel patches
<\sh> or much better, just buy a vmware-esx server ;)
<mruiz> I requested a sync for hipo and I obtained 2 ACKs... Do I need to do something extra to concrete the sync?
<mok0> dholbach: What happens with collectd?
<ScottK> mruiz: From there it's the normal sponsorship process.  Is uus subscribed?
<dholbach> mok0: Sorry, I'll be in a bunch of calls today - do you think you can ask somebody else to take a look at it?
<mok0> dholbach: It's just that you ack'ed the sync, and I was wondering if I had to do anything
<dholbach> mok0: oh... if ubuntu-archive is subscribed - it's all good then :)
<dholbach> some archive admin will take care of it during their archive day
<mok0> dholbach: they are :-)
<dholbach> rock on!
<dholbach> thanks mok0
<mok0> Cool
 * mok0 can't handle to many things at once...
<mruiz> ScottK, I'll subscribe u-u-s
<mruiz> thanks
<sistpoty|work> hi folks
<bddebian> Heya sistpoty|work
<sistpoty|work> hi bddebian
<huats_> \sh: do you advise to use the vmware server 2.0 beta or not ?
<\sh> huats_: well, for testing purposes yes, for production services no..(well using vmware-server for production services, a joke ;))
<hellboy195> hey folks. do you agree that we need a transition because of bug 195913
<ubotu> Launchpad bug 195913 in dialog "Please sync dialog 1.1-20071028-3 from Debian(Unstable)" [Undecided,New] https://launchpad.net/bugs/195913
<sistpoty|work> hellboy195: if there was really only a Provides added for the dialog binary package to provide libdialog-dev, then we don't need a transition
<sistpoty|work> (actually, it would even be wrong then, to build-depends on libdialog-dev, as you cannot build-depend on a virtual package alone, at least not some time ago)
<hellboy195> sistpoty|work: dunno. debian folks mentioned "must now depend on libdialog-dev" so it's a little bit wired
<sistpoty|work> hellboy195: can you pastebin a diff of debian/control from the current ubuntu package and the new debian package?
<hellboy195> sistpoty|work: in a minute :)
<sistpoty|work> hellboy195: 5 minutes is fine as well (because I"ll be afk for that time ;)
<huats_> \sh: :)
<huats_> \sh: It is clearly for testing, since it is to valid my packaging...
<Laney> Is there a commandline tool to view package changelogs?
<hellboy195> \sh: http://pastebin.com/m6a929bd2
<hellboy195> \sh: ah sry
<hellboy195> xD
<hellboy195> sistpoty|work: http://pastebin.com/m6a929bd2
<sistpoty|work> hellboy195: yep, no transition needed (yet, but I assume the next debian version will need one)
<ScottK> Laney: apt-listchanges perhaps?
 * jdong kicks the tracker icon
<jdong> stop blinking at me
<hellboy195> sistpoty|work: so. you can ACK my sync request ;)
<jdong> it's the curse of the eye
<sistpoty|work> hellboy195: not from work (as I cannot testbuild it here)
<hellboy195> sistpoty|work: It's building fine ^^. nvm. no stress :) thx for you help
<sistpoty|work> np
<bobbo> are there any MOTUs in here that could check my debdiff for Bug #195806?
<ubotu> Launchpad bug 195806 in purrr "please update purrr to version 0.8 [FFe-granted]" [Undecided,In progress] https://launchpad.net/bugs/195806
<ScottK> bobbo: If you subscribe ubuntu-universe-sponsors to the bug, someone will look at it.
<bobbo> ScottK: u-u-s are assigned, was just wondering if anyone in here had any time to look at it now
<linux__alien> hi LucidFox
<linux__alien> was not at station and am back after more than a week :)
<niemeyer> Hey there Masters
<niemeyer> Is there a way to make a package in such a way that it will not ask to overwrite a configuration file and instead just leave the one installed, if it exists?
<niemeyer> (without postinst tricks, that is)
<nxvl_work> niemeyer: that way you can experience incompatibility problems
<niemeyer> nxvl_work: I'm all for breaking incompatibility
<niemeyer> nxvl_work: More seriously, we're the upstream in this case
<nxvl_work> heh :P
<nxvl_work> mmm
<nxvl_work> yes you can
<nxvl_work> on the rules file
<nxvl_work> but i don't think it is the right way to do things
<nxvl_work> niemeyer: which package are we talking about?
<niemeyer> nxvl_work: Any pointers to documentation about it (or a keyword maybe)
<niemeyer> ?
<niemeyer> nxvl_work: landscape-client
 * nxvl_work checks
<niemeyer> nxvl_work: We know the configuration is compatible, and don't want to give the user the chance of screwing things up
<niemeyer> (the old file has data that should remain)
<nxvl_work> oh
<nxvl_work> it uses debhelper
<ScottK> niemeyer: If the user hasn't changed the file, they shouldn't be prompted.
<jdong> asac: btw, have you considered upgrading the mozilla packaging bzr branches to the packs format?
<niemeyer> ScottK: The file has been changed, and has data on it.. that's why we don't want it to be overwritten
<ScottK> niemeyer: You'll lose any changes the user has made.
<niemeyer> ScottK: I think you're getting things backwards
<ScottK> And I think you are.  Try and explain why user customizations to the conffile should be thrown away?
<niemeyer> ScottK: :-)
<ScottK> Wait.  I think I got it now.
<niemeyer> ScottK: Can you please read what I said, with more calm? :-)
<nxvl_work> why is only a debian/ directory on the source and nothing else?
<niemeyer> ScottK: Thank you.
<ScottK> niemeyer: Why not ship the same data in the new file then?
<nxvl_work> ScottK: he has the package installed with the personalized configuration, and he want that the package uses that configuration and don't gave the chance to the user to overwrite those changes
<nxvl_work> niemeyer: i'm i right?
<niemeyer> nxvl_work: Precisely
<ScottK> niemeyer: If the upstream conffile is unchanged, then they shouldn't be prompted.
<asac> jdong: yes. the branches are small enough to keep them in the current format for a while.
<ScottK> niemeyer: They should only be prompted for a combination of user changes to the old conffile and a modified conffile from the new version.,
<niemeyer> ScottK: We want to be free to chose the best default values over time, and these may change
<mok0> qa.ubuntuwire.com still down :-(
<nxvl_work> ScottK: it has changed, but it also has backwards compatibility
<jdong> asac: btw it looks like FF3 beta testing is going pretty well for gutsy-backports. I will prepare some debdiffs for you to glance over soon-ish :)
<asac> thanks
<ScottK> niemeyer: I'm unclear what you want.  You want the new conffile, the old one, or a merger of the two installed?
<niemeyer> ScottK: Just the old one.. no changes to what the user did
<nxvl_work> scottK: the old one
<sistpoty|work> niemeyer: if the user changed the file, the conffile mechanism is the only sane thing according to policy. if the file was changed by a program, then I guess it shouldn't be a conffile but only a configuration file
<nxvl_work> scottK: he want's the new one to be ignored
<ScottK> niemeyer: dpkg has an option to force the oldconffile, but I think that has to be set globally.   pre or postinst is your best bet I think.
<ScottK> niemeyer: If you look in the Debian wiki for the recipe for moving conffiles, I think it has the bits you need to do what you want.
<niemeyer> sistpoty|work: We're the upstream, and can ensure that there are no incompatibilities, and know that if the user removes his old file information will be lost
<niemeyer> ScottK: You mean not per-package then
<sistpoty|work> niemeyer: why would information get lost?
<niemeyer> ScottK: Cool, I'll look for these, thanks
<ScottK> niemeyer: http://wiki.debian.org/DpkgConffileHandling
<niemeyer> sistpoty|work: Because a file got overwritten, and the program will run with a blank setup
<nxvl_work> niemeyer: why don't you use a conf.d/ directory where all the user data will be stored and change the config file without worries?
<sistpoty|work> niemeyer: ah, so the user needs (or needed) to specify some setup data there, right?
<niemeyer> sistpoty|work: Right
<sistpoty|work> niemeyer: that's what the conffile mechanism is designed for... ;)
<niemeyer> nxvl_work: That would be a solution, but right now it looks more complex than simply keeping the user setup
<nxvl_work> niemeyer: i think the best way to do this is with a separate config file, so you have the main cf (included on the package) and the personalized one (made by the user and NOT included on the package)
<niemeyer> sistpoty|work: Yep.. I assumed that there should be a simple way to say "don't overwrite, your setup is good".. but it doesn't seem to be the case so far
<nxvl_work> so you don't have to worry about the old config files
<sistpoty|work> niemeyer: iow, if a user choses to want the new file, he is aware that it means that his setup changes are lost
<niemeyer> sistpoty|work: We've just had a beta tester losing his setup.. ;-)
<niemeyer> sistpoty|work: and reporting "hey, it's not working"
<nxvl_work> niemeyer: but IIRC dpkg shows a message asking if you want to overwrite or not AND warning you that some changes are going to be lost
<nxvl_work> niemeyer: so the problem is that users don't read and just hit "Yes"
<niemeyer> nxvl: Yes yes.. he said to use the new file..
<niemeyer> nxvl: Yep.. and we'd love to prevent users from hitting themselves in the foot, and reporting strange errors
<niemeyer> Anyway.. thanks for your support.  I think I understand where we stand now, and can figure what the final solution will be.
<nxvl_work> niemeyer: the best way is to split the config files
<niemeyer> nxvl_work: "Best" involves several variables, including development time, release date, etc.
<nxvl_work> cause now you have backwards compatibility, but at some point maybe you will want that it will be merged to add some new features
<sistpoty|work> the best thing were, if the package would just work ootb ;)
<sistpoty|work> (though getting this right can be quite hard)
<nxvl_work> niemeyer: i have done it before and is not a hard work
<nxvl_work> niemeyer: which is the project's vcs hosted? on LP?
<nxvl_work> s/which/where/
<niemeyer> nxvl_work: Yes, but not public
<nxvl_work> mmm
<nxvl_work> ok i will check the source
<nxvl_work> let me check
<nxvl_work> we are talking about landscape-client.conf, right?
<niemeyer> nxvl_work: It's not about being hard.. we have an impending release, and have been testing that code for a while.  We won't change the way the configuration works now.
<niemeyer> nxvl_work: Yeah
<\sh> _czessi: done
<emgent> heya \sh && nxvl_work
<nxvl_work> emgent: :D
<\sh> emgent: did you get my ping about cacti this afternoon?
<\sh> emgent: the fix was in the patch I added to the first two CVEs...I rechecked it
<ScottK> niemeyer: Personally I consider it quite rude to come into a free software development channel and ask for help on developing proprietary software without making that clear.
<emgent> \sh, ok cool
<\sh> emgent: but the users reporting the bug against the -security release..that's weired somehow
<nxvl_work> ScottK: is GLP
<emgent> ok \sh i have to go, see you later
<\sh> emgent: np..if you have time please check again...I wonder if it's really a bug or not
<ScottK> nxvl_work: GLP?
<\sh> nxvl_work: GLP?
<nxvl_work> GPL, sorry
<ScottK> nxvl_work: Is it?  I don't see any code?
<Czessi> \sh: cool  :-)
<\sh> Czessi: depending on my GF she will go with me this year...but we have to wait for an ack of her employer
<Czessi> \sh: ok, i'll searching for a big holiday flat or two in one house
<jdong> asac: debdiffs uploaded to bug 191796 and bug 191800 for your review whenever convenient
<ubotu> Launchpad bug 191796 in gutsy-backports "Please backport firefox-3.0 3.0~b3 final" [Undecided,Confirmed] https://launchpad.net/bugs/191796
<ubotu> Launchpad bug 191800 in gutsy-backports "Please backport xulrunner-1.9 1.9~b3 final" [Undecided,Confirmed] https://launchpad.net/bugs/191800
<\sh> Czessi: I think the amarok people will join this year the kubuntu people, right? :)
<Czessi> \sh: yes
<\sh> Czessi: cool
<Czessi> \sh: mister amarok (markey) is also comming
<Nightrose> he said he will... - which might not be what he really is going to do ;-)
<nxvl_work> ok found it
<nxvl_work> niemeyer: you only need to add a few lines to make it happend
<nxvl_work> (maybe not for this release, but for the future)
<niemeyer> nxvl_work: Oh?
<\sh> Nightrose: just tell him: beer, wine, and other fun stuff available ;)
<nxvl_work> niemeyer: the conf.d thing
<Nightrose> \sh: nah - he might get strange ideas :P
<\sh> well, wine is not good...champagne is better and doesn't clash with the piece of broken software ;)
<niemeyer> nxvl_work: Ahh, cool
<emgent> back
<emgent> \sh, have you builted drupal6?
<niemeyer> ScottK: Personally I found you quite rude on your own, so we're good.
<niemeyer> landscape-client is GPL.. for whatever it's worth.
<\sh> emgent: nope..I just installed manually...which I do normally with webapps
<ScottK2> niemeyer: Well the difference is you're coming here on your work time (while paid) asking for my volunteer help.  Where's the source?
<emgent> oh ok :P
<niemeyer> ScottK2: http://landscape.canonical.com/packages
<ScottK2> niemeyer: Fair enough.  Sorry for the misunderstanding then.  I wasn't aware they'd released the source.
<ScottK2> Landscape as announced by Canonical didn't sound like it would be Free.
<niemeyer> ScottK2: Indeed I'm paid to work on this software, but there's no such thing as "work time" for me.
<jeromeg> jdong: there seems to be quite a bunch of issues with our amsn backport
<nxvl_work> niemeyer: please stop it, you want our help or our hate? we are volunteers here, so be more respectful when you come here please
<niemeyer> ScottK2: You may also be interested in checking http://niemeyer.net , and then reconsider the whole "volunteer" and "free software" thing.
<jdong> jeromeg: I'm not at a location that I can verify what's going on with gutsy-backports... can you try to investigate it and report back?
<ScottK2> niemeyer: I already said I was sorry.  You showed up asking for help on a project that has not been announced as being FOSS.  I made a bad assumption.  However, just because you also do FOSS development, doesn't really enter into it.
<jeromeg> jdong: for me it doesn't work without installing wavesurfer
<niemeyer> ScottK2: Heh
<ScottK2> niemeyer: Lots of LP developers are FOSS developers by background and inclination, but that doesn't make LP any less a priorietary Canonical product.
<jdong> jeromeg: so is this a hardy or gutsy-backports bug?
<jeromeg> jdong: took me quite a lot of time to notice it, and strangely this isn't listed as a dep in our package
<jeromeg> jdong: not sure about this
<ScottK2> For some more accurate spelling of proprietary.
<niemeyer> ScottK2: Ok.. that's very offtopic.. I'll be glad to discuss this with you privately if you're interested to know why I disagree.
<\sh> ok...time to rush home
<\sh> bbl
<jeromeg> jdong: we have at least bug 195104, bug 195555 and a third one I did not reported yet ( i've a solution for it)
<ubotu> Launchpad bug 195104 in amsn "Amsn won't start. It initialization script fails." [Undecided,New] https://launchpad.net/bugs/195104
<ubotu> Launchpad bug 195555 in gutsy-backports "aMSN won't start: tkcximage can't load" [High,Confirmed] https://launchpad.net/bugs/195555
<jeromeg> jdong: Adri2000 found something that explains one of the bugs: bug 195785
<ubotu> Launchpad bug 195785 in tcllib "snit 2.1 contained in tcllib 1.9.dfsg1-1 incompatible with tcl/tk 8.5" [Undecided,New] https://launchpad.net/bugs/195785
<jeromeg> jdong: we should backport tcllib 1.10
<jeromeg> 1.9 conflicts with 1.9
<jeromeg> oups
<jeromeg> with tk/tcl8.5
 * sistpoty|work heads home
<sistpoty|work> cya
<mruiz> hi all
<mruiz> I got an error with the last update of add-5-a-day: bzr: ERROR: No WorkingTree exists for "bzr+ssh://mruiz@bazaar.launchpad.net/%7E5-a-day/5-a-day-data/main/". Any suggestion?
<\sh> ScottK: working on new claws-mail
<\sh> well, after the shower ;)
<james_w> mruiz: I get the same thing.
<mruiz> it was the last update ...
<james_w> mruiz: I've got a fix
<mruiz> james_w, go on...
<james_w> line 19 of /usr/bin/add-5-a-day should be err = os.system("cd %s; bzr update" % (branch_dir))
<james_w> rather than err = os.system("cd %s; bzr update %s" % (branch_dir, remote_branch))
<james_w> Is it daniel that writes this code?
<mruiz> I don't know
<mruiz> :-)
<mruiz> james_w, it works
 * mruiz hugs james_w 
 * james_w hugs mruiz back
<\sh> oh damn
<\sh> why is fix for #191920 not in a quilt patch?
<jpatrick> Lutin: can you please take another look at bug #195806 and tell me if it's okay to upload?
<ubotu> Launchpad bug 195806 in purrr "please update purrr to version 0.8 [FFe-granted]" [Undecided,In progress] https://launchpad.net/bugs/195806
<CarlFK> what is the upstream source for the kernel?
<CarlFK> trying to find why this line is //ed:
<CarlFK> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=blob;f=drivers/media/video/vivi.c;hb=053fcb6014eef31c2674d344c704118e0ac229ef#l1125
<warp10> Regarding the libgraphviz3 -> libgraphviz4 transition, some packages buil-dep on libgraphviz3-dev. Should it be changed to libgraphviz-dev?
<ScottK> Without actually looking into the specifics, as a general rule that's correct.
<slangasek> warp10: must be, yes
<warp10> slangasek, ScottK: I am wondering this because the last uploader for ggobi changed build-dep form libgraphviz-dev to libgraphviz3-dev
<ScottK> Who was the last uploader? (hoping it wasn't me)
<warp10> ScottK: looks like he was sh
<slangasek> then \sh_away erred
<slangasek> or, it was uploaded before graphviz had transitioned in Ubuntu
<jscinoz> if a package as uploaded to revu long before feature freeze (back in december) and it is still in progress, can it be included or should i just wait and try again with Intrepid
<warp10> Whatever the reason, I am going to fix that with the transition. I was just afraid to make a disaster. :-) Thank you.
<ScottK> jscinoz: Unless there's a really compelling reason why it has to be in Hardy (almost certainly not), then wait and try again.
<ScottK> jscinoz: In the mean time you might want to try and get it into Debian.  If it's in Debian, it'll automatically be included in Intrepid.
<jscinoz> ScottK, thanks, does debian have a system similar to revu?
<jscinoz> i.e. where can i upload my source package for review
<pochu> mentors.debian.net
<pochu> there
<jscinoz> thank you :)
<jscinoz> one quick query
<jscinoz> the packages in question are urbanterror and urbanterror-data (for the game urban terror obviously :P) with the data package a licensing issue exists that may cause problems,
<jscinoz> one file "zpak000.pk3" is under a non-free license (the Quake 3 SDK EULA) at the moment i'm getting aroudn this by having a prompt on package installation displaying the license then downloading this file as its small (1.2mb) but could this cause problems?
<Arwen> the latest vlc packages are b0rk3d in case any of you guys are
<Arwen> care*
<emgent> heya people
<crimsun_> Arwen: have you filed a bug using Launchpad?
<Arwen> yes
<Arwen> https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/196315
<ubotu> Launchpad bug 196315 in vlc "files in vlc-nox are linked against libX11 [hardy]" [Undecided,New]
#ubuntu-motu 2008-02-28
<Arwen> though maybe that's gcc's fault now that I think of it..
<LaserJock> mok0: ping
<emgent> heya
<mok0> LaserJock: pong
<LaserJock> mok0: regarding rasmol
<mok0> yes
<LaserJock> are you gonna do a new debdiff?
<mok0> LaserJock: eeerr, I kinda think my icons are prettier
<LaserJock> I think perhaps linking to the 32x32 icon might be better than the 48x48
<LaserJock> mok0: eeerr, I don't really care ;-)
<LaserJock> you're creating a 300+KB diff because you think the icons are "prettier"?
<mok0> LaserJock: Well, I spent time on the icon, and generated it in all the different sizes so I think that is the correct solution
<LaserJock> no, it's not
<LaserJock> we only need 1 icon, and we already have it
<LaserJock> it's creating a lot more work for us
<mok0> LaserJock: ?
<LaserJock> there's  already and icon
<mok0> LaserJock: I've already done the work
<LaserJock> it works just fine
<LaserJock> mok0: yeah, I'm sorry about that
<mok0> LaserJock: attention to detail?
<LaserJock> but there's just no way we should upload that
<mok0> LaserJock: lots of packages populate the /usr/share/apps directory
<LaserJock> *if* there currently isn't anything
<LaserJock> we have an icon
<LaserJock> and we don't need a 300KB diff
<mok0> LaserJock: ok, well invalidate the bug then
<LaserJock> well, there is a bug, in that we need to add a symlink
<LaserJock> because the icon isn't showing up
<mok0> LaserJock: right
<LaserJock> but you probably should have looked at that before doing all the work to create all those new icons
<LaserJock> you could also send them to the rasmol authors
<LaserJock> although rasmol is basically a dead upstream
<mok0> LaserJock: I have a script creating the icons, it's gimping the largest one that took the time.
<mok0> I could perhaps replace the xpm
<LaserJock> anyway, I'm not upset or anything, and I'm sorry about the work you've done
<LaserJock> but when we've already got an icon it's a good idea to use it
<mok0> LaserJock: I accept the decision, but I don't agree with it
<mok0> When the icon gets enlarged it looks really bad
<mok0> That
<LaserJock> when should they get enlarged?
<mok0>  that is why you need all those sizes
<mok0> That is up to the user.
<mok0> You can choose icon size in konqueror
<LaserJock> yeah, but I doubt you're gonna get a menu icon over 48x48
<mok0> right
<mok0> There's a lot of talk about scalable icons on d-d
<mok0> Well, I'll change it to a link. *sigh*
<LaserJock> hmm
<LaserJock> the icons are done by Debian I guess
<LaserJock> perhaps send an icon to the Debian maintainer
<mok0> LaserJock: Sure
<mok0> LaserJock: they are talking about a transition towards SVG icons
<LaserJock> sure
<LaserJock> who knows how long that'll take ;-)
<mok0> LaserJock: good question :)
<LaserJock> do they want to create pngs at build time?
<mok0> LaserJock: No, they want SVG icons that are scalable
<mok0> real time scaling
<LaserJock> yikes
<LaserJock> that's a bit of a performance hit
<LaserJock> hopefully we can do both
<mok0> LaserJock: that was the discussion :)
<LaserJock> we've been talking a bit about that for Edubuntu because there's a new icon theme that'd be great
<LaserJock> but it's mostly svg
<mok0> LaserJock: OS X does some kind of real time scaling of icons
<LaserJock> and on thin clients or old hardware it seems like there might be a significant amount of performance issues
<mok0> LaserJock: yeah
<mok0> what's the new icon theme for edubuntu?
<LaserJock> well, we haven't moved over yet or anything
<LaserJock> it's called Ubuntoon
<LaserJock> based on Gartoon
<mok0> For applications etc?
<LaserJock> the icons are in a bzr branch at https://edge.launchpad.net/ubuntoon/
<LaserJock> yeah
<LaserJock> it's a decently full theme now
<mok0> Cool.
<mok0> I'd like to see a Kedubuntu :-)
<LaserJock> yes, we've had work on that
<LaserJock> there's an edubuntu-desktop-kde package for that
<mok0> It'd be cool to get away from the dull blue KDE themes
<LaserJock> since like half of our edu apps are KDE anyway ;-)
<mok0> LaserJock: I'll upload another debdiff for rasmol tomorrow. It's getting late in my timezone
<mok0> LaserJock: Please unsubscribe u-u-s
<LaserJock> I did
<LaserJock> rasmol is in Main
<LaserJock> :-)
<mok0> Oh
<LaserJock> feel free to ping me and I'll sponsor it for you
<mok0> LaserJock: Thanks
<mok0> There are several other apps that lack icons
<mok0> Is there an effort to go through them?
<LaserJock> I think it's a good idea
<LaserJock> we need to make sure that there actually isn't an icon
<LaserJock> sometimes they just don't get installed or stuff like that
<mok0> Perhaps we should make a list on the wiki?
<LaserJock> and then working well with upstream to get the icons included
<LaserJock> since that's really not diff we want to maintain
<mok0> I think the priority is getting them working in hardy, then we can contribute upstream once hardys window has closed
<LaserJock> right
<LaserJock> set up a wiki page if you want
<mok0> OK, will do
<LaserJock> I think it'd be worthwhile
<mok0> Me too. It makes the ui look much better
<mok0> It looks kludgy when a fourth of the icons are missing
<mok0> sloppy
<LaserJock> yeah
<LaserJock> just make sure
<mok0> yes?
<LaserJock> that it actually needs an icon
<LaserJock> rather than having an installation issue
<LaserJock> or something like that
<mok0> LaserJock: hmmm, I will make the list of the icons missing on my system, but I don't think I have time to check them all. The folks who fix the particular ones need to help with the checking
<LaserJock> sure
<LaserJock> just having a candidate list would be good
<mok0> Right. I will make a note on the wiki re: your concerns
<mok0> LaserJock: Does this work have to be finished before the artwork FF?
<mok0> Or can it be treated as bugs?
<LaserJock> mok0: I would think as a bug
<LaserJock> depending on the package though a little
<LaserJock> if it's gonna be in screenshots or something we might need to do something more
<mok0> So, bugs can be fixed right up to the official release right?
<LaserJock> well
<LaserJock> you might need to do some notifications
<LaserJock> most all the Main packages should have icons so it shouldn't matter too much
<mok0> LaserJock: Fine. I think a couple of weeks to do this project is enough
<LaserJock> yeah, if we have a nice list and hit it it should be fast
<mok0> LaserJock: I'll get on these things tomorrow. Right now I am fading
<LaserJock> yeah
<mok0> See you later!
<LaserJock> cya
<bddebian> Heya gang
<LaserJock> hi bddebian
<bddebian> Heya LaserJock
 * ScottK2 ponders: Does he upload the patch the shows the final U/I to meet the U/I freeze, but crashes all the time or hold off so the obsolete U/I is still there, but the program at least doesn't crash ...
<slangasek> or get a waiver for uploading it after the UI freeze so you don't have to worry? :)
<LaserJock> ScottK2: it's an either or?
<LaserJock> you can't have a final U/I that works? :-)
<slangasek> he probably can't have a final UI that works by tomorrow... :)
 * ScottK2 is leaning towards the waiver.  He's building with debugging enabled now, so maybe he'll get lucky.
<ScottK2> Upstream removed on-access scanning from Klamav, but then conveniently left the U/I in place but non-working to give end users and obvious targe for filing bugs.
<ScottK2> slangasek: Does U/I freeze apply to Universe?  We don't have a process for that listed for Universe.
<slangasek> ScottK2: logically, it would apply to anything the documentation team is writing documentation for, or the translators are translating for
<ScottK2> Logically.
<ScottK2> OTOH, I'm just subtracting, so there's no risk that they'll have to translate something extra.  Urgh.
 * ScottK2 cheers for helpful error messages: KCrash: Application 'klamav' crashing...
<bddebian> heh
<effie_jayx> what does a dsl stand for in the package version
<bddebian> dsl in a package version?
<emgent> heya people
<emgent> someone can open task for Gutsy, Feisty, edgy, Dapper in Bug #195949 ?
<ubotu> Launchpad bug 195949 in vlc "VLC Arbitrary memory overwrite in the MP4 demuxer" [Medium,Fix released] https://launchpad.net/bugs/195949
<emgent> i can only nominate, only >=MOTU can open task :P
<LaserJock> hmm, any math/physics nerds about?
<RAOF> Yo!
<RAOF> Less of the physics, more of the pure maths, but let's see where this goes.
<RAOF> LaserJock: ^^
<emgent> LaserJock, heya
<emgent> can you open task for Gutsy, Feisty, edgy, Dapper in Bug #195949 ?
<ubotu> Launchpad bug 195949 in vlc "VLC Arbitrary memory overwrite in the MP4 demuxer" [Medium,Fix released] https://launchpad.net/bugs/195949
<emgent> i can only nominate, only >= MOTU can open task
<RAOF> LaserJock: I also prefer the term "geek", but whatever :)
 * somerville32 wishes the meanings of geek and nerd were reversed.
<LaserJock> sorry, was afk
<LaserJock> RAOF: so do I
<LaserJock> but I'm a nerd, plain and simple
<emgent> lol
<LaserJock> I've got an equation and it's got a : in it
<LaserJock> something like a dot product, but not
<LaserJock> or something
<RAOF> An inner product?
<RAOF> Some more context might be nice?  I can parse latex if necessary.
<LaserJock> hmm, let me see if I can put something together
<LaserJock> something along the lines of: P = \chi^2 : E_vis E_IR
<LaserJock> where they're all vectors
<LaserJock> I've not seen just a " : " sitting in an equation before
<RAOF> E_vis & E_IR are both vectors?  There doesn't seem to be an operator between them?
<LaserJock> probably just a dot product
<RAOF> Hm.  It doesn't ring bells, although it could be "proportion".  Which I use an awful lot.
<RAOF> ":" is such a nice, easy to write character it's probably overloaded several times in different fields/papers to mean different things.
<LaserJock> bah
<RAOF> Could also be a probability distribution?
<LaserJock> I've got a presentation tomorrow and I get stuck on what ":" means :-)
<LaserJock> I don't think so
<RAOF> I don't suppose they go so far as to _define_ the ":" operator? :)
<LaserJock> of course not
<LaserJock> that would be too easy
<LaserJock> "he's getting his PhD, he can sweat for it"
<RAOF> "Colon" is unlikely to be the easiest thing to google for, either.
<somerville32> http://en.wikipedia.org/wiki/Table_of_mathematical_symbols
<somerville32> :P
<somerville32> "For matricies, the colon notation may be used."
<LaserJock> ah ha!
<LaserJock> idiots
<RAOF> Right.  Inner product!
<LaserJock> pfft, and the say math is the universal language ;-)
<LaserJock> *they
<RAOF> That doesn't make a whole lot of sense still.
<LaserJock> well, the \chi is a tensor
<LaserJock> but the E_* should be just vectors
<LaserJock> so whatever, as long as I know it's an inner product I'm cool with it
<LaserJock> thanks RAOF and somerville32
<somerville32> no problem :)
 * RAOF grumbles about physicists not understanding how simple tensors are, and fiddling with crazy indicies.
<LaserJock> dude, I'm a chemist. I hear "tensor" and I run
<RAOF> LaserJock: Bah!  It's just the cartesian product of a couple of rings modulo a fairly simple equivalence relation :P
<LaserJock> mmmmhm
<RAOF> True, tensors as used in, say, a GR course are crazy arcane objects involving a hojilion indicies.
<RAOF> But that's because physicists tend to suck at maths.
 * LaserJock raises his hand for the "suck at maths" part
<StevenK> And LaserJock isn't even a physicist!
<LaserJock> StevenK: yeah, I suck so bad at math they wouldn't let me in ;-)
<StevenK> Haha
<LaserJock> of *course* I had to pick the paper to present that has all the scary math
<LaserJock> :/
<ScottK2> Anything that doesn't kill you makes you stronger.
<jml> or gives you a hangover
<ScottK2> There is that.
<RAOF> Or possibly cuts of your hands.
<StevenK> "cuts of your hands" ...
<RAOF> Oh, yeah.  Absolutely.
<RAOF> That's clearly not in relation to the previous statements; it's merely meant to provide an existential statement from which conversation can naturally crystalise.
<StevenK> Hah
 * LaserJock wonders if he should stop his presentation while he still has hands :s
<ScottK2> Conversation that doesn't require math.
<StevenK> They're wheeling in the bone saw now
<RAOF> Maybe you'll get choice cuts of someone else's hands?
<LaserJock> ok ...
<LaserJock> so we went from ":" to "physicists suck" to "I'm a cannibal"
<RAOF> Via a spelling mistake, yes.
<jml> mmmmm handrump
<dholbach> good morning
<nxvl_work> :D
<Hobbsee> mornign dholbach!
<dholbach> hiya Hobbsee
<dholbach> hey nxvl_work
<dholbach> nxvl_work: you're always '_work', right? :)
<nxvl_work> heh
<nxvl_work> nop, just when i'm at work
<nxvl_work> :P
<nxvl_work> here i use xchat, everywhere else irssi
<nxvl> and i have always my irssi running logging everything :D
<Hobbsee> nxvl_work: proxies ftw.
<nixternal> looking for a RegEx junky :)
<nixternal> convert %f "`echo %f | perl -pe 's/\.[^.]+$//'`.gif"
<nxvl_work> Hobbsee: heh, i used to use it, but i'm fine this way for now :D
<nixternal> if I have a file named    'No. 22.jpg'    then that RegEx obviously will not work..is there a way to modify that regex so it will work?
<nixternal> or am I wasting time because someone filed a bug against a damn servicemenu and has retarded filenames?
<dholbach> hi tmarble
<dholbach> hi nixternal
<tmarble> dholbach: hello
<jml> nixternal: so, you want to remove extensions from filenames?
<nixternal> hiya dholbach
<nixternal> jml: don't want to remove the extension, what it does is replace the extension
<nixternal> convert is an imagemagick program to convert from one image format to another, all the regex does is take the original name, replace the .jpg with .gif and rock on :)
<jml> shouldn't in be this: convert %f "`echo %f | perl -pe 's/\.[^.]+$/.gif/'`
<jml> err, maybe with a " at the very end.
<nixternal> I will give it a shot
<jml> nixternal: because, afaict that regex should work for 'No. 22.jpg', shell quoting issues aside
<nixternal> jml: that worked
<nixternal> you da man
<jml> nixternal: you have no idea how much soul I had to lose in order to gain that knowledge
<nixternal> I am afraid to learn it :)
<nixternal> I have a great book by O'Reilly, I just need to go through it
<jml> nixternal: it's a great read.
<jml> nixternal: the first two chapters are enough to give you kick-ass regex skills
<jml> and then it keeps going
<nixternal> ya, I just split the book in half and looked, and fainted
<liri> how often do developers check newly added packages or changed packages in the revu archive?
<dholbach> liri: at the moment not that much - we're in Feature Freeze (http://wiki.ubuntu.com/HardyReleaseSchedule) so NEW packages are only allowed with a special exception
<geser> liri: currently not very often as new packages aren't added to hardy anymore
<liri> well I uploaded my first package to revu at the beginning of January (2008)  but I only got around to fix the reported errors recently and uploaded the changed package yesterday...
<persia> liri: The issue is that Hardy is frozen for new packages.  If the package is in good shape, it will likely get reviewed early, and included in the next release.
<liri> what does it mean in terms of time table? :)
<persia> liri: Roughly speaking, late May or early June.
<liri> persia: so only by that time will the package get more reports on if it's ok or would it need more changes? kinda long time to wait :)
<persia> liri: Most likely.  There are exceptions, but Beta Freeze is in about a week, so from then exceptions are unlikely.  Also, the REVU Coordinator for the next release may start activities as early as late April, although this is sooner than has been done in the past.
<liri> persia: bummer... I thought I could get some feedback much before that
<persia> While it's a bit of a wait, that is in part because it is just two weeks past the freeze deadline.  While there is considerably more complexity involved, release schedules often consist of about three months for new stuff (new versions, new applications, new functions, etc.) and three months of testing and polish,
<dholbach> liri: that's the crux of time-based releases: at some stage you have to focus your efforts on fixing the stuff that is in the archive alaready
<liri> alright well, I guess I'll just have to wait
<persia> liri: You may be able to get feedback, but the vast majority of developers are concentrating on other things.  If you really want to work on that package rather than distribution polish, you might consider working to get it into Debian: I think their freeze cycle doesn't start until next month, and Ubuntu will automatically sync in April or May.
<liri> I want to continue with Ubuntu
<liri> this is just about getting it into the motu repository, isn't it?
<persia> Well, there's not really a "MOTU" repository, but getting it into the universe component of the Ubuntu repository, yes.
<liri> persia: thanks
<\sh> hmm..tomcat5.5 seems uninstallable
<\sh> grmpf...
<\sh> tomcat5.5 needs a dependency on a java jdk
<\sh> or icedtea-java7-jdk needs a provides: java-virtual-machine
<Iulian> Hi
<ScottK> So apparently the launchpad approach to bug triage for the developer to edit your bug into something different and then file a new bug that's what your original bug is about and then tell you you did it wrong.
<ScottK> https://bugs.launchpad.net/malone/+bug/194601
 * ScottK is done with them.
<ubotu> Launchpad bug 194601 in malone "Inline bug attachments aren't attached" [High,Confirmed]
<RainCT> Hi
<emgent> heya
<bddebian> Heya gang
<emgent> gang ? :O
<bddebian> Sure :)
<emgent> lol
<tbf> RainCT: duh, seems i overwrote your advocation for gnome-lirc-properties, by uploading a bugfixed version?
<tbf> (note to myself: don't put symlinks to your working copy into /usr/lib/python2.5, and remember that pylint doesn't check automake files)
<bobbo> lutin: Did jpatrick speak to you about Bug #195806 yesterday?
<ubotu> Launchpad bug 195806 in purrr "please update purrr to version 0.8 [FFe-granted]" [Undecided,In progress] https://launchpad.net/bugs/195806
<Lutin> ah, yes, maybe
<bobbo> Lutin: he wanted a second opinion on whether it was good to upload (Im the person working on it)
<Lutin> bobbo: as I said in the bug report, I'm wary given the upstream tarball name. I'd check with him whether it's sure or not (as it seems to me that he rather forgot to update the link, or something like that)
 * rainct_ would apreciate if someone could check if he is missing anything on bug #195913
<ubotu> Launchpad bug 195913 in dialog "Please sync dialog 1.1-20071028-3 from Debian(Unstable)" [Undecided,New] https://launchpad.net/bugs/195913
<bobbo> Lutin: ok will talk to the upstream author then get back to both of you
<Lutin> bobbo: thanks
<jeromeg> hello
<jeromeg> jdong: I think we can process the pidgin backport now, it has been tested a lot
<jeromeg> without any issues
<RainCT> bobbo: why is bug 186121 set to "In Progress"?
<ubotu> Launchpad bug 186121 in ed "Typo in man page of 'ed'" [Wishlist,In progress] https://launchpad.net/bugs/186121
<bobbo> RainCT: because ive submitted a debdiff, is that not the right thing to do?
<RainCT> bobbo: I think it should be confirmed when it's ready for review ('in progress' would mean that you are working on it)
<bobbo> RainCT: ah, ok didnt know that :)
<bobbo> RainCT: want me to change it now?
<RainCT> bobbo: nah, it's not necessary :)
<bobbo> RainCT: ok thanks
<RainCT> bobbo: just wanted to check if it should be reviewed or not
<bobbo> RainCT: yeah its ready, just a tiny fix though..
<RainCT> bobbo: ok.. the version is wrong
<RainCT> bobbo: should be 0.7-1ubuntu1, and you've to modify the Maintainer field
<bobbo> RainCT: ok thanks :)
<LaserJock> RainCT: ping
<RainCT> LaserJock: pong
<LaserJock> RainCT: regarding rasmol, it's in Main, btw
<RainCT> LaserJock: oh, well, my comment applies anyway heh
<LaserJock> yeah, except sub'ing u-u-s
<LaserJock> it doesn't work in Gnome either, btw
<RainCT> it's the second package I see today that has u-u-s but is in main then :/
<RainCT> LaserJock: ah right. ok, thanks
<LaserJock> they changed the icon name and forgot to change the .desktop ;-)
<RainCT> LaserJock: commented about this :)
<bobbo> RainCT: new debdiff up for Bug #186121 if you aren't busy
<ubotu> Launchpad bug 186121 in ed "Typo in man page of 'ed'" [Wishlist,In progress] https://launchpad.net/bugs/186121
 * RainCT looks
<RainCT> bobbo: ok, now the distro is wrong :P (gutsy -> hardy)
<RainCT> (sorry for not noticing that before)
<bobbo> RainCT: no problem :) will go and make *another* debdiff
<RainCT> bobbo: well, I'll just change that myself if you don't want to create another one :)
<bobbo> ive got nothing better to do
<RainCT> heh
<bobbo> might aswell save you the effort :)
<RainCT> well, isn't really any effort at all.. I'd need the same time to download a new debdiff again :P
<bobbo> RainCT: did it anyway, new debdiff: http://launchpadlibrarian.net/12277409/ed_0.7-1ubuntu1.debdiff
<jpatrick> pochu: hola
<pochu> buenas jpatrick
<bobbo> jpatrick: Spoke to Lutin about the purrr update (the debdiff i showed you yesterday) and he told me to email upstream
<RainCT> bobbo: well, if you have nothing better to do.. want to create yet another one? :P
<jpatrick> bobbo: I saw
<bobbo> RainCT: Might as well, what have i done wrong this time?
<RainCT> bobbo: well, the package is using a patch system (dpatch), so it would be best to use a patch to fix that
 * bobbo goes to dig out log of that patch session pitti did last week
<bobbo> RainCT: theres already an ed.1 spelling mistake dpatch, *embarrased*
<bobbo> doesnt fix the current bug though (obviously)
<RainCT> bobbo: yes, but it fixes another problem
<RainCT> right..
<hellboy195> LucidFox: around?
<LucidFox> yes
<RainCT> bobbo: so better you create a new one.. (08_ubuntu-doc-typo-fixed.dpatch or whatever)
<bobbo> RainCT: ok
<RainCT> bobbo: (because a) so it's easier to use again if Debian isn't responsive, and b) the existing patch refers only to ed.1, not the other files)
<hellboy195> LucidFox: you remember the problem with starplot? pitti built it again on LP for me but it fails with the same strange error :\
<RainCT> bobbo: to create the patch just run "cdbs-edit-patch 08_ubuntu-doc-typo-fixed.dpatch", do the changes, and then "exit 230"
<bobbo> RainCT: thanks :D
<LucidFox> I have no idea about it, sorry
<hellboy195> RainCT: what's for ACK'ing dialog. in the evening I would have written the same. so thx so far :)
<RainCT> hellboy195: no problem :)
 * RainCT notes that if someone is bored it would be great if he could test open-invaders 0.3 from Debian unstable (especially the sound)
<CarlFK> I am having trouble building on hardy - hoping you build experts can help
<CarlFK> build error that others don't get on gentoo:  http://dpaste.com/37229/  "expected specifier-qualifier-list before 'size_t'"  Who's problem is this? :)
<bobbo> RainCT: ping
<tsmithe> hi - could a motu upload the new version of mscore as detailed at bug 195170
<ubotu> Launchpad bug 195170 in nspluginwrapper "npviewer.bin crashed with SIGSEGV in g_slice_free_chain_with_offset()" [Undecided,New] https://launchpad.net/bugs/195170
<tsmithe> oops
<tsmithe> bug 195179
<ubotu> Launchpad bug 195179 in mscore "Please update mscore to 0.9.1d+dfsg-0ubuntu2 (debdiff attached)" [Undecided,New] https://launchpad.net/bugs/195179
<tsmithe> persia, ^^?
<james_w> CarlFK: I think that means that one of the types is unknown.
<james_w> using cpp on the file might give a clue
<bobbo> RainCT: Dpatch debdiff for ed bug: http://launchpadlibrarian.net/12278136/ed_0.7-1ubuntu1.debdiff
<CarlFK> james_w: this? $ gcc ../lib/v4l2_driver.h
<CarlFK> ../lib/v4l2_driver.h:26: error: expected specifier-qualifier-list before 'size_t'
<CarlFK> t$ gcc  driver-test.c = same thing
<RainCT> bobbo: great, uploading. please forward it to Debian
<bobbo> RainCT: will do :D
<james_w> CarlFK: "cpp file | less" to see if the types are resolved.
<CarlFK> james_w: which file?  .c or .h
<RainCT> bobbo: ehm.. ed is in main.
 * bobbo slaps head
<bobbo> RainCT: guessing its going to need another review from a core-dev or something?
<RainCT> yes, I'm subscribing ubuntu-main-sponsors
<james_w> CarlFK: the one that gives you the compile error, so h
<bobbo> RainCT: thanks :D
<CarlFK> james_w: same error
<CarlFK> http://dpaste.com/37236/  (all 3)
<bobbo> sorry for that RainCT
<RainCT> bobbo: it's no problem at all :    *
 * RainCT wonders how he send that if he didn't press enter.. :P
<blueyed> How is a package like virtualbox-ose-modules-2.6.24-8-generic to be upgraded to virtualbox-ose-modules-2.6.24-10-generic automatically? I'm asking, because it does not appear to happen (any more?)..
<RainCT> blueyed: with a transitional package, or if it's installed as a dependency for another package just change the dependency and I think the package manager should remove the old one as it's unused
<blueyed> RainCT: so it needs a meta package then? Changing the dependency in virtualox-ose does not make sense IMHO. Probably it should get added to linux-ubuntu-modules-2.6.24?!
<RainCT> blueyed: I can't really answer to that as I've no idea how virtualbox/kernel packaging works.. :(
<blueyed> RainCT: I think I'll provide a "real" package virtualbox-ose-modules, which depends on the current variants.. instead of the current variants only providing the virtual virtualbox-ose-modules package.
<james_w> CarlFK: I think you need to #include <stddef.h>
<CarlFK> james_w: that got me much further
<CarlFK> in fact, I think I can ignore what errored
<CarlFK> james_w: bam!  thank you.
<james_w> CarlFK: no problem. It's a very cryptic error, but I find it usually means "unknown type".
<CarlFK> james_w: you a Python coder?
<james_w> CarlFK: yes.
<CarlFK> I may have 50gig of PyCon videos to send you on a stack of dvd's
<CarlFK> pm me your email
<\sh> re
<blueyed> Hi \sh. Thanks for mentioning me in your blog.. have you fixed my name? :)
<\sh> blueyed: hmmm...no?! ;) I'll do it when you fix the vim xdebug plugin ;)
<\sh> blueyed: fixing it now
<\sh> blueyed: done
<hellboy195> geser: around?
<geser> hellboy195: yes
<hellboy195> geser: you already know if this clean-la patch is still required?
<geser> you mean for libnxml?
<emgent> heya geser
<geser> Hi emgent
<hellboy195> geser: yep
<geser> hellboy195: is it the only remaining change?
<hellboy195> geser: nope. I will introduce a new one
<hellboy195> geser: but except that it's the only one, yes
<geser> hellboy195: I'd suggest to test-build it without clean-la.mk and check then the libnxml.la file if it contains references of other .la files
<hellboy195> geser: yeah dholbach already told me. the only diff is that the debian la has the line "build-deps" filled with the depencies
<hellboy195> geser: what I mean. Debian has dependency_libs=' /usr/lib/libcurl.la /usr/lib/libidn.la -lldap -L/usr/lib -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lz /usr/lib/libgnutls.la'
<hellboy195> geser: and ubuntu instead only dependency_libs=''" . That's the difference
<geser> yes, that's exactly the reason why clean-la.mk was uses
<hellboy195> geser: so it's still necessary I suppose?
<geser> yes
<hellboy195> geser: great. thank you :)
<geser> you might be lucky that it not needed currently and libmrss builds
<hellboy195> geser: ??
<geser> the problem in the past was that libgnutls.la moved from /lib/ to /usr/lib/ but the libnxml.la file had still the old location which lead to a FTBFS because it couldn't find the libgnutls.la file
<hellboy195> geser: ah. k
<hellboy195> geser: btw, I'm afraid. May you could help me with another problem?
<geser> I can try :)
<hellboy195> geser: https://edge.launchpad.net/ubuntu/+source/starplot/0.95.4-3  :)
<\sh> ScottK: claws-mail-extra-plugins is building...so it seems the FFe report will hit you and the others tomorrow morning (my time)
<hellboy195> \sh: poor man. I suppose wine is still a bad boy?
<geser> hellboy195: my guess is that one of those *FLAGS made it fail, check config.log (from your pbuilder) for the exact reason
<hellboy195> geser: but it builds in my pbuilder
<geser> hellboy195: hmm
<hellboy195> geser: that's the strange thing
<\sh> hellboy195: yes
<hellboy195> \sh: damn :)
<geser> hellboy195: my pbuilder fails
<hellboy195> geser: same error?
<pochu> this brainstorm page is cool!...
<pochu> ...but we don't really need 7 posts in the planet about it :)
<geser> hellboy195: yes
<hellboy195> pochu: 5-bugs-a-day got many more posts ^^
<geser> hellboy195: from config.log:
<geser> configure:3037: gcc "-Wall -pedantic -O2 -g"  -Wl,-Bsymbolic-functions conftest.c  >&5
<geser> gcc: "-Wall: No such file or directory
<hellboy195> geser: really really strange
<pochu> hellboy195: yeah that too
<geser> hellboy195: but easy to fix: removed the " from CFLAGS in debian/rules
<hellboy195> geser: omg. wth? wired
<geser> forget it, wrong fix
<hellboy195> ^^
<geser> partly correct, configure runs now but make is missing the " around the CFLAGS
<hellboy195> geser: that means. configure hates " and make loves it
<geser> hellboy195: no, it depends who sets the variable in the environment
<\sh> ok...end of business
<hellboy195> geser: ah, k
<geser> hellboy195: remove the " from line 9 and 11 and add them to line 42
<hellboy195> geser: wait. I have to fetch the .dsc first. DaD already removed it ^^
<hellboy195> geser: ah, sry. where to add it in line 42? CFLAGS="$ ?
<geser> yes
<hellboy195> geser: so I prepare the merge/debdiff now. I hope this fixes it. I can't test it because it worked in my pbuilder ..
<geser> hellboy195: you can use your PPA
<hellboy195> geser: true. hmm nvm. we have time :)
<hellboy195> geser: that problem is that I always have problem with signing so I avoid using my PPA ^^
<hellboy195> geser: uhh nice. a unset GPG_AGENT_INFO
<hellboy195>  fixed it. how can I make that static?
<geser> hellboy195: no idea, you could try to add no-use-agent to your ~/.gnupg/gpg.conf
<hellboy195> geser: k, thx
<hellboy195> geser: but if it builds fine in my PPA the first thing I will do, after I did the debdiff, is to report that back to debian :)
<geser> emgent: have you seen http://packages.qa.debian.org/v/vlc/news/20080228T160212Z.html already?
<emgent> nope, i go to see
<hellboy195> geser: same error O_o
<emgent> thanks geser
<emgent> uhm other security fix..
<hellboy195> geser: ah wait. maybe a mistake from me
<hellboy195> geser: ah stupid question. Where does the " has to end in $(MAKE) all CFLAGS="$(CFLAGS) INSTALLPGM=$(INSTALLPGM) \
<hellboy195> 		docdir=/usr/share/doc mandir=/usr/share/man sysconfdir=/etc ?
<geser> hellboy195: CFLAGS="$(CFLAGS)"
<hellboy195> geser: thank you very much. :)
<geser> so the value from CFLAGS (line 9 or 11) gets passed as CFLAGS to make and not only the first part of it
<hellboy195> geser: in some minutes we will know
<hellboy195> anyone seen norsetto recently?
<hellboy195> geser: PPA is hating me. md5sum sucks ^^
<hellboy195> ah testing it tomorrow :) gn8 @ all
<blueyed> Any ideas why apt pulls in the -386 kernel if a package depends on "-386|-generic|..."? the -generic variant could be used without pulling another kernel image in.. http://pastebin.com/m363876fa
<pochu> blueyed: do you have the -generic already installed? I think apt will see if there's any installed and if not, install the first one
<pochu> blueyed: so change the order to be -generic | -386 should do the trick I think
<RainCT> pochu: Are you sure it looks at the order? I though dpkg would sort them anyway how it wants.. (might be wrong though)
<blueyed> pochu: changing the order appears to be a workaround only for -generic. The "end" package for -generic depends on linux-image-2.6.24-10-generic, which is installed.. but apt does not seem to resolve this properly to detect it being installed.. virtualbox-ose-modules-generic is not yet installed, but should get preferred, because it depends on the -generic kernel image (which is installed)
<pochu> RainCT: nope, it won't sort OR'ed dependencies
<RainCT> pochu: oh, cool :)
<blueyed> that's right.. this way you can put a preferred one in front of a more generic one.
<pochu> so if you have "foo, bar | foobar" it will become "bar | foobar, foo"
<RainCT> I see :)
<RainCT> pochu: thanks
<pochu> RainCT: but that sorting will likely be reverted in dpkg
<pochu> as a developer may have a reason to sort if in some special way
<pochu> RainCT: there's a thread in debian-devel about it btw :)
<pochu> that's why I know that... I'm no dpkg wizard ;)
<RainCT> heh
<RainCT> is there much traffic on debian-devel?
<pochu> yeah
<RainCT> :/
<pochu> 1297 in January
<pochu> 1216 in February as of today
 * RainCT decides that he won't subscribe :P
<pochu> heh
<blueyed> how is apt-cache dotty supposed to work? "apt-cache dotty virtualbox-ose-modules | dotty  -" ?
<RainCT> btw, that pypanel thing messed up my gnome-panel.. is this a feature or a bug? :P
<tbf> RainCT: i had to upload another revision of gnome-lirc-properties, since a stupid symlink in /usr/lib/python2.5 covered a refactoring problem for me. can you re-attach your advocating flag, please?
<tbf> RainCT: or isn't that needed?
<RainCT> (messed up = the time is configured correctly but the clock applet shows a wrong time, some icons disapeared from the tray but their menu appears on right click on the void space, etc.)
<RainCT> tbf: sure, one moment :)
<tbf> RainCT: awesome :-D
<tbf> RainCT: your gnome panel is from 2.22?
<tbf> RainCT: maybe some ugly side effects from federico's intlclock merge?
<RainCT> no, 1:2.20.1-0ubuntu1 (Gutsy)
<RainCT> I tried that pypanel thing and since then gnome-panel is mad :S
<tbf> RainCT: that sucks.
<tbf> RainCT: i'd try to reset the /apps/panel tree in gconf-editor...
<RainCT> yeh, specially the clock thing..
<tbf> RainCT: or course that's kind of drastic....
<tbf> ....but maybe the pythingy left bad entries there?
<blueyed> RainCT: here's the dependency graph for virtualbox-ose-modules: http://codeprobe.de/tmp/temp.svg
<bobbo> n/whois jpatrick
<bobbo> sorry
<jeromeg> RainCT: have you tried to restart your gnome-panel ?
<RainCT> tbf: is there anything more beside /apps/gnome-settings/gnome-panel (which hasn't really much)?
<RainCT> jeromeg: yes, the computer was off overnight
<jeromeg> weird
<jeromeg> no idea then :)
<jeromeg> going to be now
<jeromeg> good night
<RainCT> jeromeg: good night :)
<jeromeg> thank you
<RainCT> blueyed: does this image fit on your screen? :P
<blueyed> RainCT: not quite.. ;) (1920x1200 though)
<blueyed> RainCT: the interesting part is the top only though. apt only looks at the first level apparently.
<RainCT> +gnome-lirc-properties (0.2.1-1) hardy; urgency=low
<RainCT> tbf: what happened to the "0ubuntu"? :P
<RainCT> tbf: ping me once you fixed the version number
<RainCT> but tomorrow, me goes to bed now :)
<RainCT> good night all
<mok0> Any news on qa.ubuntuwire.com?
<tbf> STUPID uupdate tool!
<pochu> The server at brainstorm.ubuntu.com is taking too long to respond.
<pochu> too many people visiting it?
<jdong> slashdot.
<tbf> is that normal, that uupdate eats "0ubuntu" tags?
<jdong> uupdate by default does pump out -1, as if it were for debian
<jdong> currently I just mangle the changelog by hand afterwards
<azeem> huh, you'd think that'd be adapted to Ubuntu by now
<tbf> jdong: oh... the "u" prefix stands for "update"
<tbf> jdong, azeem: what!? "update-update"? what kind of name is that?
<tbf> i read the tool's name as "ubuntu update"
<jdong> tbf: I think Upstream Update
<tbf> jdong: hmm. also possible.
<jdong> azeem: I'm sure it's like a one-line patch
<azeem> tbf: it predates Ubuntu by a couple of years
<StevenK> Upstream Update would be my guess
<tbf> azeem: i am a total packaging n00b
<tbf> azeem: don't know such details.
<azeem> details.
<tbf> azeem: well, sense for details seems very important for packagers....
<tbf> ...as i learned last week
<azeem> did Murray send you to boot camp or what?
<tbf> azeem: no, he just figured it's easier and more fun for him, if he delegates the neccessary packaging
<azeem> heh
<tbf> azeem: ...like for that lirc properties thing
<tbf> azeem: hmm.... and i was too stupid to stand up, when i found that word in my contract ;-)
<azeem> details ;)
<tbf> well, should sleep now. have to master a 700km trip after wake up.
<tbf> ciao
<azeem> I hope he's flying
<jdong> whee, pbuilder's so much less painful now that I hacked the backend to use lzop rather than gzip
#ubuntu-motu 2008-02-29
<mok0> jdong: in what way, less painful?
<StevenK> I suspect the base tarball isn't one any more
<jdong> mok0: the base.tgz is much faster to build
<jdong> mok0: I find myself doing pbuilder updates quite frequently so that's greatly appreciated
<mok0> jdong: hmm, ok
<jdong> and the base.tgz size increased abt from 88->110MB
<mok0> jdong: I use cowbuilder, so no tarring or compression
<jdong> which is noticeable.. .but not too bad
<jdong> mok0: if I had LVM set up on this machine....
 * StevenK uses sbuild and LVM snapshots
 * mok0 plans to set up sbuild & LVM snapshots at some point
<LaserJock> hi mok0
<mok0> LaserJock: Hi
<LaserJock> I haven't quite been convinced yet that sbuild/LVM is much better than pbuilder
<LaserJock> seems like you need an aweful lot of disk space for them
<mok0> LaserJock: true, but my machine has so many gigabytes of diskspace I don't really need
<LaserJock> so what do you gain though?
<mok0> LaserJock: As I understand it, with sbuild you can create your own buildd system, that compiles several archs
<LaserJock> and you can't do that with pbuilder?
<LaserJock> just wondering
<mok0> LaserJock: you can use deb-o-matic
<LaserJock> deb-o-matic apparently work with pbuilder as well
<RAOF> LaserJock: It's a bit faster than pbuilder, and it's an environment closer to what the buildds use.
<mok0> yes that's right
<LaserJock> RAOF: right
<LaserJock> but they seem fairly comparable
<LaserJock> when I reinstalled my system I LVM'd it all so I could try it out, but I haven't had a chance to try yet
<LaserJock> I don't have a lotta hard drive space so that was my biggest concern
<StevenK> You seemed more content to complain about 64 bit issues instead.
<LaserJock> heh
<LaserJock> I haven't reinstalled it though, I'm still sticking to 64 bit
<LaserJock> I've been learning how to work around the issues
<LaserJock> I need to figure out how to get a 64 bit skype 2
<LaserJock> that's my latest challenge
 * RAOF laughs derisively.
<RAOF> Actually, that's unfair.  Skype _would_ be easy for me to set up if ALSA wasn't broken.
 * LaserJock cringes at reading people trying to deploy Hardy production school servers
<RAOF> LaserJock: http://www.skype.com/go/getskype-linux-beta-dynamic seems to work (modulo ALSA problems) for me.
<Fujitsu> I've deployed Hardy to a server.
<Fujitsu> Though it isn't doing much at the moment other than rebuilding universe.
<RAOF> As have I.  But that's because I'm _insane_.
<jdong> LaserJock: I've been shocked by how stable hardy has been throughout development...
<Fujitsu> jdong: Indeed.
<LaserJock> well
<jdong> the hiccups have only been minor so far
<jdong> there's that pycentral day :)
<Fujitsu> Apart from composite on -intel, it hasn't broken.
<Fujitsu> And that, yeah.
<jdong> and yeah, intel xv from day to day
<LaserJock> I'm not afraid of the desktop stuff in general
<Fujitsu> And g-p-m a bit lately, but nothing important.
<jdong> my biggest trouble area right now is the newest HAL
<jdong> i.e proc->sys batteries
<LaserJock> but deploying unfinished software to workaround Gutsy bugs seems doomed
<RAOF> Yes.
<jdong> sysfs batteries do not update properly for me, so I've personally locked my own patched hal to my macbook right now
<Fujitsu> jdong: I have 59 hours until my battery is charged.
<RAOF> My battery is discharging on AC :)
<emgent> eya people
<emgent> 59 O_O
<emgent> lol Fujitsu
<Fujitsu> I had 63 hours of runtime this morning, too.
<jdong> my battery only updates when I /etc/init.d/hal restart
<jdong> so I love how I have 98% battery for 4 hours
<jdong> then my PMU puts the laptop to sleep.
<Fujitsu> Same.
<mok0> jdong: Just tested lzop, it's about 2x faster than gzip
<jdong> hence why I inverted the patch we chose to apply
<Fujitsu> I see the flashing red battery light, and note that I have 100% full...
<jdong> mok0: it turns the process from CPU bound to IO bound.
<Fujitsu> But then the power history graph shows correct discharge...
<mok0> jdong: ok
<jdong> Fujitsu: and even worse, g-p-m and laptop mode both apply the wrong power saving settings
<jdong> mok0: so the more underpowered your CPU is, the more you'll likely save
<mok0> jdong: I have a q6600, not exactly underpowered :-)
<jdong> mok0: oh PFFT
<jdong> mok0: then you'd almost not benefit from the switch
<mok0> jdong: 2x
<jdong> mok0: you'd probably want to use p7zip's bzip2 backend
<jdong> mok0: which can quad-thread bzip2 from stdin
<jdong> that might end up faster on your muscle CPU
<mok0> jdong: cool
<mok0> lzop doesn't delete the original?
<jdong> mok0: lzop is identical in behavior to gzip
<mok0> jdong: no
<mok0> jdong: not for me
<mok0> jdong: it leaves the original as well as the compressed file
<jdong> mok0: you're right
 * mok0 tries p7zip
<mok0> definitely slower
<jdong> mok0: are you sure you're multithreading bzip2
<mok0> jdong: no :-)
<jdong> lemme TRY to recall the cmdline
<jdong>  | 7z a -tbzip2 -mx=1 -mmt=on -si test.bz2
<jdong> that should be the "business end" of your pipe
<jdong> it's definitely gonna be 3-4x faster than standard bzip2, and compress better than it.
<mok0> jdong: I am testing on an .iso, it doesn't really compress well
<jdong> the question is, is it gonna be faster than lzop.....
<jdong> mok0: you should probably test on a gunzipped base.tgz
<mok0> jdong: you mean gunzipped base.tgz?
<jdong> what did I say?
<mok0> jdong: kkk
<mok0> 7z: 7.77 secs :-)
<mok0> lzop: 2.26 sec
<jdong> ok, that's what I expected
<jdong> though of course the former would be a lot smaller if it were compressible
<mok0> Both compress the image to 81M
<mok0> bzip2: 19.9 sec
<mok0> 81 Mb
<Fujitsu> How long does pbuilder usually take overall? sbuild+LVM gives me <25 second builds on lots of things.
<mok0> Fujitsu: it take me 3.9 secs to decompress base.tgz
<LaserJock> man, pbuilder used to take slightly over 1 min. on my older laptop
<Fujitsu> Not bad.
<mok0> I use cowbuilder, which does no unpacking/packing
<Fujitsu> We seem to have a lot of failures in universe because of the dh_iconcache/dh_icons migration.
<mok0> Fujitsu: what's the problem?
<Fujitsu> dh_iconcache doesn't exist any more, so the builds fail.
<jdong> Fujitsu: unpacking the base.tgz usually takes me 3-4 secs, cleaning takes another 5 secs or so
<mok0> Ah.
<jdong> so I'd guess at top 15s overhead
<LaserJock> Fujitsu: I thought it was transitioning
<Fujitsu> LaserJock: My build results say otherwise.
<LaserJock> hmm :/
<LaserJock> Fujitsu: do you have any idea how many FTBFS we're looking at?
<Fujitsu> LaserJock: Total, or just from that?
<LaserJock> just from that
<Fujitsu> Still grepping for that.
<LaserJock> I guess total would be good to know as well ;-)
<Fujitsu> ~500 out of the ~8300 that I've built so far have failed. Some of those won't be legit failures (because I forgot to use P-a-s this time), but most will be.
<LaserJock> hmm
<LaserJock> that's fairly significant
<Fujitsu> Yes.
<Fujitsu> About 3000 builds still to go, which should take about 36 hours more.
<LaserJock> I wonder if they're biased towards Ubuntu packages or if they're a general problem
<TheMuso> Fujitsu: I'm guessing this is related to performing universe rebuilds?
<Fujitsu> TheMuso: Correct.
<TheMuso> Lovely.
<slangasek> LaserJock: defining "Ubuntu packages" how?
<LaserJock> slangasek: Ubuntu versioned
<slangasek> dh_iconcache was never in Debian, so they'll all be Ubuntu-local bits
<jdong> pkgname =~ ubuntu?
<LaserJock> slangasek: I was speaking about all FTBFS for that part
<slangasek> ah, yes
<jdong> is there any way of grabbing the changelog between two vers of packages from launchpad?
<jdong> or is hitting up changelogs.ubuntu.com the only way?
<slangasek> in that case, I'm sure there are plenty of FTBFS that can be blamed on the Debian maintainers ;)
<LaserJock> yeah
<LaserJock> we often sync at precisely the wrong time ;-)
<slangasek> nah, there's no right time to sync that will avoid the fact that a significant number of packages in Debian unstable are poorly maintained
<Fujitsu> Hm, pycentral breakage in a build just a few minutes ago.
<Fujitsu> During bzr installation. Is that known?
<superm1> what actually happened that initiated this pycentral breakage in so many things?
<LaserJock> slangasek: I don't mean sync repo wide, just on a per-package basis
<LaserJock> anyway, yeah
<slangasek> LaserJock: yes, and some packages sit FTBFS in unstable for longer than an Ubuntu release cycle :)
<LaserJock> yeah
<jdong> Is there some method other than grep-dctrl that I can use to resolve an arbitrary binary package name to its source package?
<LaserJock> it's difficult sometimes because Debian seems to have quite variable levels of maintenance
<blueyed> Should a package remove obsolete config files when it gets upgraded? They seem to stay in /etc and get listed as "obsolete" in "dpkg -s".
<Fujitsu> Erasing modified configs is a Bad Idea.
<blueyed> Fujitsu: sure. But they should get removed when they are unmodified, shouldn't they?
<crimsun_> jdong: rmadison?  apt-cache madison?
<jdong> crimsun_: really? *checks his sanity*
<jdong> crimsun_: rmadison on a binary package name doesn't seem to tell me its source package?
<jdong> or am I being retardd?
<crimsun_> jdong: ah, it's not reliable, true
<crimsun_> jdong: it only shows source if the binary pkg name is also the source pkg name
<jdong> right
<crimsun_> jdong: ("apt-cache madison" should suffice, though)
<jdong> I guess I'll just grab the Source.bz2's
<jdong> crimsun_: well that makes assumptions about what's in sources.list
<crimsun_> true
<jdong> if only launchpad were magical...
<crimsun_> jdong: PTS has something of that sort
<emgent> heya crimsun_ :)
<crimsun_> hey emgent
<ScottK> \sh_away: If it's bugfix only, no FFe is needed.  Just file a bug to document what you are doing.
<LaserJock> hmm
 * LaserJock wonders why git-core in fiesty-backports has a ~dapper1 version and is newer than in gutsy
<Hobbsee> hm?
<Hobbsee> heh
<ScottK> LaserJock: Because it was backported from Hardy to Dapper and then Hardy got a newer one that wouldn't backport cleanly past Gutsy so the Dapper one was forward ported to Edgy/Feisty.  Gutsy backport from Hardy is pending.
<ScottK> Clear?
<LaserJock> ScottK: kinda
<ScottK> It'll all work out right in the end.
<ScottK> jdong had it all figured out.
<LaserJock> I figured
<LaserJock> just made me smile as I was backporting
<jdong> lol
<jdong> yeah lamont uploaded to dapper initially, then I realized we needed to care for everyone else
<jdong> I got a FTBFS of the latest hardy to gutsy which I am investigating
<jdong> somehow the test for cvs fails in pbuiler
<LaserJock> hmm, I'm  currrently trying it
<LaserJock> it takes an insane amount of time doing tests
<jdong> LaserJock: one of the final test cases failed with can't cd into cwd, IIRC
<LaserJock> hmmpf
<ScottK2> jdong: Lucky you to have an interested core-dev that might upload a source backport for you.
<jdong> ScottK2: yeah, just have to know what to upload ;-)
<TheMuso> hrmf. Since when did pycentral start using /usr/share/pyshared?
 * TheMuso had to find that one out by building a damn package by hand.
<emgent> hello world
 * jscinoz is away: I'm busy
<RAOF> jscinoz: Thank you for that useful titdit of information :P
 * jscinoz is back (gone 00:00:52)
<jscinoz> what happened
<jscinoz> didnt know that would go out in every channel
<jscinoz> >_<
<LaserJock> jdong: well, git-core just finished building for me
<jdong> LaserJock: no way
<jdong> LaserJock: well why did it fail for me :(
<jdong> oh well I'll assume it works
<ScottK2> jdong: You don't have that special core-dev touch.
<jdong> and get a backport going
<LaserJock> heh
<jdong> ScottK2: lol
<LaserJock> hmm, so the icecast of the local police scanner proved useful tonight
<LaserJock> "Powered by Ubuntu" ;-)
<AstralJava> LaserJock: Could you elaborate, please? Sounds fascinating. :)
<LaserJock> well, somebody in my LUG emailed to say they set up an icecast server on an Ubuntu box to stream from his police scanner
<LaserJock> tonight "something" happened in our neighborhood
<LaserJock> a helicopter kept circling around
<LaserJock> so I thought I'd make use of the stream and see what was up
<AstralJava> Oh alright. Nice. :)
<LaserJock> I'm still a bit shaky on the details, but something definately when down a couple streets away
<AstralJava> Right.
<LaserJock> I thought it was an interesting use of Ubuntu :-)
<AstralJava> Most definitely. :)
<jscinoz> ugh this is maddening
<jscinoz> package builds fine with dpkg-buildpackage, but if i debuild -S -sa then use pbuilder it fails
<RAOF> jscinoz: Missing build-deps?
<jscinoz> none afaik
<RAOF> jscinoz: Also, logs make for more useful answers :)
<jscinoz> sec il lpatebin
<superm1> good evening slomo, you around?
<slomo> superm1: yes
<jscinoz> RAOF, http://pastebin.com/m28dfdc95
<superm1> as we had discussed the other day about that patch related to V4L/V4L2, I scrapped it and made one against gst-plugins-good0.10 that just changes the default
<slomo> superm1: sounds better
<superm1> I talked to an upstream dev about making the change show up upstream as well, and they're going to consider making it a change there too
<warp10> Good morning
<RAOF> jscinoz: Your /tmp is out of space?
<RAOF> jscinoz: That's likely to be a fair sized package, yes?
<slomo> superm1: sounds sane anyway... who did you talk to? :)
<jscinoz> yes 750mb
<jscinoz> RAOF, shouldnt be, i have 1.4gb free
<superm1> slomo, er i'd have to look at my logs at my PC in the office.  gentleman in #gstreamer
<superm1> he said they'd decide later though, so just to document it on a bug for now
<slomo> superm1: ok, so things are taken care of ;) feel free to patch the ubuntu package for now
<superm1> slomo, well it's in main
<superm1> so i'd need to get sponsorship on it
<slomo> oh
<slomo> give me a patch then ;)
<superm1> the debdiff on the bug is against debian
<superm1> bug 195914
<ubotu> Launchpad bug 195914 in ekiga "Ekiga & gstreamer inputs default to outdated V4L, and require to be changed to V4L2" [Undecided,In progress] https://launchpad.net/bugs/195914
<slomo> superm1: thanks
<jscinoz> RAOF, wait i guess you're right, it is running out of space >_<
<slomo> superm1: will care for that later, don't worry :)
<superm1> slomo, thanks
<jscinoz> is it possible to tell pbuilder to use a different temp dir? i have plenty of room on my home partition
<AstralJava> jscinoz: Change the APTCACHE and BUILDRESULT config option in your pbuilderrc, I would think.
<jscinoz> thanks
<AstralJava> jscinoz: Also BASETGZ and BUILDPLACE config options in the same file come to play.
<jscinoz> If i get my package in to debian, will it likely be in ubuntu 8.10?
<AstralJava> jscinoz: Most probably, yes, unless you manage to sneak it in within the next few days, and then file a FF exception bug, get it reviewed and accepted within the next two weeks or so. I'm not sure about the dates, but it's getting pretty late for 8.04 cycle anyway.
<jscinoz> yeah, i was told it'd be better to go for debian unstable and it would get into intrepid anyway
<AstralJava> Yeah, during the Intrepid cycle, it's only a matter of a simple sync request.
<jscinoz> arent the debian folk rather tight-arsed about what gets included though?
<AstralJava> jscinoz: Heheh. :) I guess one could find a more delicate description. :) To answer your question, I don't really know, I haven't tried to upload anything there, but I've been told they have a good tight QA process, which really is a good thing, mind you. :)
<jscinoz> yeah
<jscinoz> i have one small licensing issue with my package
<jscinoz> a single file is under a non-free license
<AstralJava> They're strict about licenses, yes.
<jscinoz> the Quake 3 SDK EULA, which permits distribution.
<jscinoz> >_<
<jscinoz> at the moment i have it display the license preinst, then upon acceptance i have it download this one file which is only 1.2mb
<AstralJava> Hmm... I have no experience when it comes to such issues.
<AstralJava> Right, well unless the upstream agrees to change the policy and license, I'm afraid that's the only approach possible.
<jscinoz> well i'll submit it to mentors and see what feedback i get.
<jscinoz> although i'd imagine every quake3 based game has this same issues, and they're still in the repos
<jscinoz> this data package takes so darn long to build >_<
<jscinoz> finally built now to upload the 800mb package >_<
<AstralJava> Ouch. :)
<jscinoz> 108kbyte upload speed >_<
<jscinoz> dput cant do a diff upload can it?
<jscinoz> because i have a feeling the first one is gonna be rejectect and i get to uploda the whole thing again >_<
<slomo> superm1: uploaded
<slomo> superm1: will take the patch to debian too and upload after the previous version went to testing
<HighNo> Hi everyone. Is updating a package to a new upstream version a feature freeze exception? and if so how can new upstream versions be included into hardy at all? Or do they only go into intrepid and have to be backported?
<nixternal> HighNo: yes. if it fixes bugs, doesn't include new api/abi changes, then filing a feature freeze exception should be easy
<nixternal> if it is major changes, then it may be a bit more difficult for it to get included
<HighNo> ok, it would be a major update...
<nixternal> morning dholbach
<dholbach> good morning
<dholbach> hey nixternal
<\sh> moins
<Hobbsee> morning
<\sh> who can I bug about UbuntuWeeklyNews?
<\sh> Message from Zend: http://andigutmans.blogspot.com/2008/02/zend-framework-to-be-part-of-ubuntu.html
<dholbach> \sh: just edit the wiki page :)
<\sh> dholbach: this one? https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Ideas <--- looks a bit outdated ;)
<HighNo> nixternal: so what about if I want to integrate the new version with hardy and most likely without a ffe?
<\sh> oh no...there is something else
<dholbach> The next Ubuntu Weekly Newsletter, Issue #80 is due to be released on March 1st 2008.
<dholbach> https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue80
<dholbach> \sh: ^
<\sh> dholbach: yeah found it :)
<HighNo> anybody - what is the exact process of releasing a new version of a package already included in hardy - if that new version only has functionality, not bugfixes? Am I getting this right - it is typically not wanted unless using the backport project?
<cody-somerville> HighNo, Are you looking to get the new version into Hardy or into an already released version of Ubuntu?
<HighNo> cody-somerville: Hardy at this time - though the new version will be released next week
<cody-somerville> HighNo, The feature freeze has already passed for Hardy. If you want to upload a new version to Hardy, you'll need to file for an exception.
<cody-somerville> HighNo, See https://wiki.ubuntu.com/FreezeExceptionProcess
<cody-somerville> HighNo, What package are you thinking of?
<pwnguin> neat. someone finally wrote some colorblind simulations for colorfilter
<HighNo> cody-somerville: blueproximity
<cody-somerville> HighNo, interesting package.
<cody-somerville> HighNo, What is the upstream URL?
<HighNo> cody-somerville: I am the upstream author and doing some major feature enhancements these days. The version that made it into hardy is very stable and works great but has limited functionality. I was mainly asking to know what to do after I completed those changes and did the testing. If there are ways to get the package with the new funcionality in hardy. (which also implies feisty and gutsy as backporting takes place)
<HighNo> cody-somerville: http://blueproximity.sf.net
<cody-somerville> HighNo, Is there a risk of regression? How big is the update?
<HighNo> anyone: It is ok for MOTUs to accept a package with very low build deps (like debhelper 5). It would make backporting of my package very easy (that is no change at all)
<HighNo> cody-somerville: could you explain regression?
<cody-somerville> HighNo, Is there a big risk that the package will stop working where it would work before? ie. The risk of regression would be greater if the amount of changes you've made since the last upload is larger than what some might consider "minor"/.
<cody-somerville> HighNo, Once you've made the next release, you can make yourself (or ask someone else) to file a Ubuntu Freeze Exception to see if you can get approval to upload your new version. As I already pointed out, the procedure is detailed at https://wiki.ubuntu.com/FreezeExceptionProcess
<HighNo> cody-somerville: ahh, ok, no danger of regression then
<cody-somerville> HighNo, Okay. Well, once you've made the release, feel free to e-mail me if you need help filing for a freeze exception.
<HighNo> cody-somerville: that sounds great
<cody-somerville> HighNo, Do you need my e-mail address or will you be able to find it?
<HighNo> cody-somerville:  until when can new versions be introduced?
<cody-somerville> HighNo, Technically, new versions may not be introduced with an exception approved by the motu release team. The closer we get to the release date, the harder it will be to get approval.
<cody-somerville> HighNo, If with the exception request, you could prove that you've tested it for regressions, I'm sure you'll have an easier time getting approval.
<cody-somerville> HighNo, OooOoo... I'm just looking at the release schedule now. I dunno how easy it will be able for you to get an exception. The UserIterface freeze passed on the 28th.
<cody-somerville> HighNo, If we can't get your new version into the official hardy repository, we can always put it in a PPA :)
<cody-somerville> HighNo, And that'll mean it'll be all ready for a quick upload once the repository for the next version (intrepid) opens in a few months.
<cody-somerville> HighNo, Do you know what a PPA is?
<HighNo> cody-somerville: sorry, have been afk
<HighNo> cody-somerville: I've hear of PPA but have not used it until now
<cody-somerville> HighNo, It is a personal package archive. It allows you to host debian packages on launchpad easily :)
<HighNo> cody-somerville: I'd like to involve launchpad a bit more into development but don't know how. Are You used to that?
<cody-somerville> I am.
<HighNo> whoohoo
<cody-somerville> I'll continue this conversation with you in a private query.
<HighNo> ok
<proppy> oy
<dholbach> soren, geser, nixternal, persia: I won't be able to make it to the MOTU Meeting today (just as a heads-up) - need to prepare some stuff for next week :/
<Hobbsee> oh, there's a meeting?
<Hobbsee> goody
<Iulian> Hi
<sistpoty|work> motu meeting in #ubuntu-meeting now
<RainCT> Heya
<txwikinger> moo
<mok0> persia, about the logo, you can see it in https://help.ubuntu.com/community/UbuntuScience
<persia> mok0: Ah.  I'm in agreement with you then :)
<DaveMorris> I've created a bug, assigned a debdiff for a package thats been included in hardy, and assigned USU to it.  What else do I need to do to get it built and released?
<mok0> DaveMorris: you've created a bug? ;-)
<DaveMorris> technically I did, I left off some dependencies in the package I created :)
<mok0> DaveMorris: The procedure seems correct
<DaveMorris> so just a matter of time till it's build, or do I need to change teh status as well?
<mok0> DaveMorris: Status = confirmed
 * RainCT supposes that DaveMorris means u-u-s and not u-s-u
<DaveMorris> Ubuntu sponsors for universe is who I subscribed
<RainCT> ok then :)
 * mok0 's head just exploded
<RainCT> rofl
 * RainCT puts mok0 head back together with some glue ;)
 * mok0 hugs RainCT
 * RainCT hugs mok0 back :)
<mok0> DaveMorris: If you click on the Ubuntu Sponsors for Universe string in LP, you can see that your package now appears on their list
<emgent> heya
<DaveMorris> yeah, I noticed I had only subscribed them, not assigned it to them
<RainCT> Hi emgent
<mok0> DaveMorris: I don't think you should assign it to them,
<mok0> but to yourself, showing that you take responsibility for it
 * DaveMorris needs to sort out some backports of the package yet
<RainCT> actually, I think it shouldn't be assigned to anybody (so that the reviewer can assing it to himself) :P
<RainCT> which bug is it, btw?
<DaveMorris> #195433
<mok0> RainCT: Ah, is that how it works?
<mok0> bug 195433
<ubotu> Launchpad bug 195433 in opensg "libopensg-core-dev is missing dependices which are called on in the pkg-config file" [Undecided,Confirmed] https://launchpad.net/bugs/195433
<soc> hi
<soc> can someone help me?
<soc> i worked on bug https://bugs.launchpad.net/ubuntu/+source/blogtk/+bug/196813
<ubotu> Launchpad bug 196813 in blogtk "BloGTK doesn't work with Python 2.5 (IOError: unsupported XML-RPC protocol)" [Undecided,New]
<soc> and found the fix
<soc> i contacted the upstream developer and asked him to include it in a new upstream version
<soc> hope that was right?
<mok0> RainCT: I am constantly confused by what you are supposed to and not supposed to in LP.
<soc> when a new version gets released how can i sync it in ubuntu?
<mok0> RainCT: ... and the rules tend to change ever so often
<RainCT> soc: yes, contacting upstream is always right :)
<RainCT> soc: now what would be good to do (unless the next upstream version is a bugfix only release) is to include the fix in the version that is currently in Ubuntu
<RainCT> (s/Ubuntu/Hardy)
<RainCT> mok0: heh
<soc> RainCT: how can i do that?
<RainCT> mok0: I also find them somewhat confusing :).
<soc> imo the fix would be very useful because it fixes a) a crasher b) makes BloGTK run with Python 2.5, so the dependency on Python 2.4 can be dropped ...
<RainCT> soc: do you have the hardy source repository enabled?
<soc> yes
<RainCT> mok0: and the answer to your question is yes (well, at least there are some sponsors doing so)
<soc> i downloaded the orig.tar.gz and the diff.gz now
<RainCT> mok0: it's allways good to subscribe yourself when reviewing something so that other sponsors don't duplicate the work
<soc> in my opinion in the diff all the lines with "-#!/usr/bin/env python
<soc> +#!/usr/bin/env python2.4"
<soc> have to be changed back ...
<RainCT> soc: okay. you'll need also the .dsc, and then run:   dpkg-source -x *.dsc   to get an uncompressed directory
<soc> but just deleting deleting is not the right to do i gess :-)
<soc> ok
<mok0> RainCT: Ok, I understand
<mok0> RainCT: But subscribing is different than "assigned to"
<LucidFox> What should be the version number for a fakesync?
<soc> ok, did it ...
<RainCT> mok0: Yes. Subscriber's get bug mail (and in the case of u-u-s, the bug is listed in their "bugs the group is subscribed to" list..)
<soc> do i have to manually change #!/usr/bin/env python2.4 to #!/usr/bin/env python or is there a way to revert that change?
<RainCT> mok0: the Assigner field is to say who is working on the bug, and usualy a field with someone assigned shouldn't be touched (unless he is asking for information on his last message or something, then you should answer if you can :))
<RainCT> soc: let me have a look at the source.. :)
 * jdong half-loses temper at bug reporters
<HighNo> soc: I believe that there should be #!/usr/bin/python and no env anymore
<soc> ok
<jdong> "Why don't you just upload the package without the launcher and break all the launcher icons? I need this bugfix on hardy NOW"
<jdong> *grumble*
<Hobbsee> haha
<HighNo> hehe
<Hobbsee> sounds like a $clueless_user
<Hobbsee> apply $lart
 * HighNo pours in another cup of coffee for jdong
<jdong> HighNo: thanks
<soc> RainCT: the last change was basically setting the py interpreter to a fixed version
 * Hobbsee takes away the accompanying crack pipe
<jdong> Hobbsee: what's even more... he used a *homemade deb* as a threat :D
<Hobbsee> haha
<HighNo> hehe
<HighNo> and he didn't ask for archive upload rights?
<jdong> https://bugs.launchpad.net/ubuntu/+source/ktorrent-kde4/+bug/192812/comments/20
<ubotu> Launchpad bug 192812 in ktorrent-kde4 "[FF exception] New upstream release ktorrent-kde4 3.0.0 " [Wishlist,Confirmed]
 * jdong cries a bit
<RainCT> haha
<HighNo> hehe, hey at least 'he doesn't want to sound rude'
<Hobbsee> silly users.
<Hobbsee> remind them about hte idea of patience
<RainCT> HighNo: hm.. are you sure? /usr/bin/env allows the user to specify a custom version
<jdong> HighNo: whenever a statement is prefixed by that, it almost ALWAYS tends to have the opposite effect
<HighNo> jdong: hehe, I know :-)
<jdong> Hobbsee: I almost want to reply back "Well if I do that, don't ever expect me to get a feature freeze exception approved again for the next 2 decades"
<Hobbsee> haha
<Hobbsee> it's not like you would anyway.  you're jdong.
<HighNo> RainCT: that's what the MOTUs have told me to change in my package, telling me the env style is 'outdated'
<RainCT> HighNo: oh, will have to check this then.
<soc> RainCT: still here?
<RainCT> soc: yes, 1 moment
<jdong> kinit -R
<jdong> grumble
<soc> afaik /usr/bin/env selects the _first_ python interpreter in the path
<jdong> soc: that's correct
<soc> i guess this is useful if you develop something, where you have different versions installed
<jdong> soc: it's also useful when deploying software to platforms with inconsistent python locations
<soc> but for software release /usr/bin/python should be used, because it uses the _system_ interpreter
<jdong> i.e. I'm doing that for MIT's intro EECS packages because we must deploy to the network cluster, personal debian/ubuntu, solaris.... etc
<soc> so software behaviour doesn't change if you install another python interpreter
<RainCT> soc: the change to "python2.4" was done by upstream?
<soc> yes
<jdong> but for an Ubuntu.Debian package, you should use /usr/bin/python*
<jdong> because by policy they are fixed to that location anyway
<jdong> and you'd rather NOT get bugreports from people who decided to run it with some other python interpretor in their path
<soc> because py2.5 was more strict in some XML-RPC things which made BloGTK crash
<RainCT> jdong: and packages should be patched to use usr/bin?
<soc> so i think the one before me thought "well, then just use pyx 2.4"
<jdong> RainCT: I would personally be inclined to do so
<soc> ^py 2.4
<RainCT> soc: heh. and you have a patch for those crashes now?
<jdong> RainCT: either via gigantic patch or via some sort of make rule in the install target...
<soc> i would now make my changes to source ...
<soc> yes
<RainCT> jdong: I usualy prefer sed in debian/rules for such things :)
<soc> my patch verifies that the uri starts with http:// or https://
<jdong> RainCT: but big patches are fun ;-)
<RainCT> lol
<soc> if it not starts, BloGTK will crash on Python 2.5
<soc> because Py 2.5 _requires_ http:// or https://, Python 2.4 didn't do that
 * jdong tries his newly built ktorrent-kde4
<soc> RainCT: i would now make my changes ok?
<RainCT> soc: okay. you can do those changes on the source directly here, as the package isn't using any patch system
<soc> and then could you tell me how they get into the diff?
<soc> or can i just change the last patch?
<RainCT> soc: (if it was using one you'd have to create a patch using that system; you can see what patch system is being used by running "what-patch" in the source directory, if you have ubuntu-dev-tools installed)
<RainCT> soc: run:  debuild -S
<soc> RainCT: before or after my changes?
<Amaranth> after
<RainCT> soc: after doing your changes and adding a new changelog entry (with "dch -D hardy -i")
<soc> ok
<soc> can i modify things in the diff?
<bobbo> What is the current DH_COMPAT level to use?
<RainCT> soc: then cd to the previous directory (where you have the .dsc, .diff.gz and .orig.gz) and run: debdiff <old version>.dsc <new version.dsc> > <new version>.debdiff
<Hobbsee> 6
<RainCT> bobbo: 4-6
<soc> ok
<bobbo> Hobbsee, RainCT; thanks
 * RainCT prefers the lowest one which isn't deprecated (unless newer features are needed) as it makes backports easier
 * HighNo applaudes to RainCT
<RainCT> soc: (where <old version> is is blogtk_1.1-2build1, and <new version> blogtk_1.1-2ubuntu1)
<soc> ah ok
 * RainCT hugs HighNo 
 * HighNo feels warm enough, you can let go now :-)
 * RainCT unhugs HighNo heh
<jdong> vorian: ok I see the problem with ktorrent-kde4
<jdong> rather, it's one of those "it's a transition not a bug" things.
<HighNo> I always if these jokes only cost precious time one could really spend much more useful or if one does productivity will be lower since you're not motivated...
<RainCT> soc: and debdiff will then create a diff from the version that is currently in Hardy to your new one
<HighNo> +wonder
<jdong> vorian: the /usr/bin/ktorrent-kde4 launcher is nixed, the desktop file just explicitly calls the kde4 version
<soc> mhhhh
<jdong> Exec=/usr/lib/kde4/bin/ktorrent %i -caption "%c" %u
<jdong> anyone think that'll actually work?
<soc> RainCT: i'm currently on a gutsy system, but have the hardy package (which is imo the same as the gutsy one)
<jdong> we don't need to set any PATHs to contain KDE4?
<soc> is that a problem?
<soc> how can i drop the dependency on python 2.4?
<RainCT> soc: no, same here :)
<soc> ok, good
<RainCT> soc: the dependency will change automatically
<soc> ah, ok
<soc> fantastic :-P
 * RainCT wonders if HighNo wouldn't be more productive if he wondered less and spend more time working instead
<RainCT> :D
<soc> sorry, closed the window ...
<soc> ok
<tonio> hi there
<soc> so now i do: dch -D hardy -i
<tonio> I'm attempting to package a gnome application, and I must say I'm a bit embarassed with gnome build-deps
<soc> then debuild -S?
<Hobbsee> RainCT: as everyone knows, the most effective thing to do is whing :P
<tonio> for kde, kdelibs4-dev does the trick
<tonio> isn't there a gnome-libs meta package for development files ?
<jdong> Hobbsee: do you use KDE4? :)
<Hobbsee> sometimes
<RainCT> soc: yes. dch will open a nano window where you have to explain what you changes (look at the previous entries for reference), and also ensure that the version number is right
<jdong> Hobbsee: do you know if a .desktop file just runs /usr/lib/kde4/bin/some_app, whether or not that'll work?
<Hobbsee> no idea
<soc> ah ok
<soc> i see it
<jdong> Hobbsee: I thought several environment variables had to be augmented for KDE4 apps to launch
<soc> it now says hardy in the changelog
<soc> is that a problem for gutsy?
<jdong> soc: if you're uploading it into Ubuntu, yes. If you are doing something locally, no.
<soc> mhh
<RainCT> soc: no, it should say Hardy
<soc> i would prefer that the change would get into gutsy and hardy ...
<jdong> soc: first, fix it in Hardy
<soc> ok
<RainCT> soc: you'll have to request a SRU then once it's fixed in Hardy
<jdong> soc: the process of fixing it in Gutsy is slightly different (StableReleaseUpdates on the wiki)
<soc> ah ok
<soc> mhh
<soc> my emailadress says "doko@ubuntu.com" is that right?
<RainCT> Hobbsee: uhm.. whing isn't in the dictionary :D
<Hobbsee> er, whining
 * Hobbsee probes RainCT with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! â¢
<RainCT> soc: in the changelog?
<soc> yes
<jdong> soc: lol I'm not sure doko_ would be happy with that ;-)
<RainCT> soc: you've a bad global variable then
<soc> last version was 1.1-2build1, should the new version now be 1.1-2ubuntu0?
<soc> should i change it to my adress?
<RainCT> soc: ubuntu1
<soc> ok good
<RainCT> soc: what does "echo $DEBEMAIL" say?
<soc> nothing
<RainCT> soc: ok, do you have a GPG key?
<soc> yes
<RainCT> soc: then open ~/.bashrc and at the end add:
<RainCT> soc:  export DEBFULLNAME="Your Name (and key comment)"
<RainCT> soc:  export DEBEMAIL="your@email"
<soc> what's key comment?
<RainCT> soc: if you run "gpg --list-secret-keys", do you have (something) after your name?
<soc> i have 3 entries ...
<soc> 2 mail adresses, one jabber
<RainCT> soc: look at that one you have on Launchpad and which you want to use for Ubuntu development
<soc> should i choose the email adress from my launchpad account?
<soc> ok
<RainCT> soc: DEBFULLNAME should be your name exactly like it's listed there (but without the email)
<soc> ahh ... ok
<RainCT> soc: dch should get it right then. and yes, for now change the email in the changelog (and also the name if it got it wrong too)
<soc> so, i should run dch again now?
<protonchris> I submitted a FFE.  It was ack'ed twice, approved and marked as confimed.  Do I need to do anyting else other than wait?
<RainCT> soc: either change it manually or close nano without saving (ctrl+x n) and run it again then
<soc> ok
<Amaranth> protonchris: us uus subscribed?
<Amaranth> err, is
<soc> guess i have to restart gnome-terminal too?
<RainCT> soc: eh, yes (or at least get into a new tab).
<protonchris> Both uus and MOTU Release team
<soc> :-)
<RainCT> protonchris: then yes, just wait :)
<protonchris> Cool.  Thanks.
<soc> know it looks right!
<soc> now^
<protonchris> I just wanted to make sure I wasn't the hold up :)
<soc> parsechangelog/debian: error: badly formatted heading line, at file debian/changelog line 5
<soc> dch: fatal error at line 1166:
<soc> Problem executing dpkg-parsechangelog:
<soc> mhhh
<RainCT> soc: copy the changelog to http://paste.ubuntu.com
<soc> ok, fixed it ...
<RainCT> (or any other site you prefer)
<soc> looks like i have to manually align the enumerations ... :-)
<soc> *sigh*
<RainCT> soc: you can also edit the file with any other text editor
<RainCT> soc: geany for example gets the align right automatically (and most other graphical editors probably too) :)
<soc> ok
<soc> works now
<RainCT> soc: just save (Ctrl+O) the document in nano after it shows up and then you can edit it with what you want ;)
<soc> i exited nano now ... dch is now finished, right?
<RainCT> yes
<soc> ok
<soc> now debuild -S?
<RainCT> right
<soc> *sigh* pgp passphrase ....
 * RainCT wonders if he is spamming the channel and #ubuntu-classroom would have been better.. :P
<soc> ah now ...
<soc> ok
<soc> ok, signed that now
<RainCT> soc: cool, now the debdiff thing
<soc> debdiff blogtk_1.1-2build1.dsc blogtk_1.1-2ubuntu1.dsc ????????.debdiff
 * RainCT also wonders why he always forgets something when he mentors someone :P
<soc> what name should debdiff have?
<Hobbsee> packagename.debdiff
<RainCT> soc: blogtk_1.1-2ubuntu1.debdiff, and there's a > missing before it
<soc> debdiff blogtk_1.1-2build1.dsc blogtk_1.1-2ubuntu1.dsc > blogtk_1.1-2ubuntu1.debdiff
<soc> like this?
<RainCT> yes
<soc> great!
<sistpoty|work> persia: thanks for hosting the meeting, and sorry again that I had to leave
<RainCT> soc: does the debdiff look good?
<soc> Warning: You do not seem to have interdiff (in the patchutils package)
<soc> installed; this program would use it if it were available.
<soc> gpg: Signatur am Mo 15 Jan 2007 18:58:57 CET mit DSA SchlÃ¼ssel, ID 0F932C9C, erfolgt
<soc> gpg: Unterschrift kann nicht geprÃ¼ft werden: Ãffentlicher SchlÃ¼ssel nicht gefunden
<Hobbsee> install patchutils then
<RainCT> soc: install interdiff and ignore the gpg warning
 * persia catches up on backscroll, references https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue, and notes that it doesn't appear to change very often (or at least in short bursts).
<soc> ok
<soc> now it works
<RainCT> s/interdiff/patchutils
<Hobbsee> RainCT: no, patchutils
<Hobbsee> yes :)
<RainCT> Hobbsee: yes, thanks :)
<soc> RainCT: the GPG warning is gone now too
<persia> sistpoty|work: Happy to.  I hope you don't disagree with any of the agreements after you had to run.
<soc> ater installing patchutils
<RainCT> cool
<sistpoty|work> persia: no, I think it was a very productive meeting :)
<soc> good
<soc> now i have the debdiff
<RainCT> soc: okay, now you can create a new one because I forgot something :$
<persia> sistpoty|work: I generally find 12:00 UTC meetings the most productive, and sometimes wonder why we have them at different times (aside from fairness).
<RainCT> eh, I mean because I didn't explain something yet so that you create it twice and get more practice :D
<soc> ok :-)
<soc> no problem :-)
<RainCT> soc: get back into the source directory, open debian/control and look at the "Maintainer: ..." line there
<RainCT> soc: then run update-maintainer (you'll need package ubuntu-dev-tools for that) and notice what changed in debian/control and debian/changelog :)
<soc> "You don't have hardy in your source repos."
<soc> nothing changed ....
<bobbo> Debdiff up for Bug #196870 if anyone has some spare time
<ubotu> Launchpad bug 196870 in gpppon "No .desktop file for gpppon" [Undecided,Confirmed] https://launchpad.net/bugs/196870
<RainCT> soc: do you have hardy in your source repos?
<RainCT> (try "update-maintainer --section=universe" for now)
<persia> RainCT: Do you happen to have a plan for chromium?  I've just noticed it FTBFS (although we've still working gutsy binaries)
<persia> (update-maintainer issues seem to be the source of the FTBFS)
 * RainCT doesn't understand persia's last sentence :S
<persia> http://builder.ubuntuwire.qeuni.net:9998/job/7936
<RainCT> persia: (about the first questio,) not really. I want to look at the package in debian-games' SVN (and apply our patches there if they aren't in Debian yet), but that's all. I still can't any C/C++ :(
<RainCT> oh
<persia> RainCT: It's just a packaging issue.  If the C++ really FTBFS, bug me about it.
<RainCT> persia: yes I see. I'll fix it now then
<persia> Also, I think the new sound files were put in SVN recently, and it might be nice to use them (as they are free, unlike the current sound)
<persia> If I'm wrong, it's worth pinging to see if they can be added (they should be ready soon, if not already, and a weekend is coming up)
<RainCT> persia: if so what do you thing about bugging some DD in debian-games to release it and then syncing?
<persia> RainCT: That works too, but I think D-G is waiting for the new upstream, so I suspect that to be unlikely.
<RainCT> persia: ah yes I got some email about that. is there already one or you mean they are waiting until there's one before releasing anything?
 * RainCT wonders if soc is still there
<RainCT> btw, does artwork freeze apply to universe?
<soc> sorry
<soc> just made a soup
<soc> no, no hardy
<soc> i'm running gutsy
<RainCT> heh no problem :)
<RainCT> soc: yes, but you can still have a deb-src line in /etc/apt/sources.list
<soc> "Maintainer changed to Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>"
<persia> Yes.  Artwork Freeze / Doc Freeze applies everywhere.  As with any other freeze, if you've a good reason, ask motu-release (but first, have a good reason)
<soc> no, i downloaded the hardy package manually
<RainCT> soc: if you plan to contribute more often, I recommend adding "deb-src http://archive.ubuntu.com/ubuntu/ hardy main restricted universe multiverse" there so that you can get the sources with "apt-get source package-name" and have a working update-maintainer
<persia> Either that, or create a chroot tracking the development version, and do package updates from the chroot.
<soc> ah ok
<soc> i guess i'll have to decide where i do my developing in the future ...
<RainCT> soc: well lets continue.. that change is something you always have to do when you change a package for Ubuntu (it's needed because of https://wiki.ubuntu.com/DebianMaintainerField, if you are interested)
<soc> on my laptop with hardy it would be easier ... but my gutsy desktop has a brandnew 24" tft :-P
<soc> yes, i know that ...
<RainCT> soc: ok, so now you can create the new debdiff ( debuild -S; !debdiff)
<RainCT> ok :)
<soc> debdiff: fatal error at line 260:
<soc> Can't read file: blogtk_1.1-2build1.dsc
<RainCT> soc: oops, cd .. first :)
<soc> could it be that i have to change dirs between debuild and debdiff?
<soc> ok
<RainCT> soc: ok, now just check that the debdiff only has the changes that you did (you'll see that sometimes you find strange stuff there), and then attach it to your bug report
<soc> mhhh
<soc> how do you know that -Maintainer: Diego Andres Sanabria (diegueus9) <diegueus9@gmail.com> is a debian dev and not an ubuntu dev?
<RainCT> soc: use "apt-cache madison blogtk" to check that the package is in universe, and then subscribe ubuntu-universe-sponsors to the bug (or in this case, better just give me the URL)
<RainCT> soc: because of the version number in his changelog entries
<RainCT> soc: but this change is done always anyway
<soc> ah ok
<soc> mhhh
<soc> mhhh
<soc> beneth my changes there is something else:
<soc> http://ubuntuusers.de/paste/53106/
<soc> is that a problem?
<RainCT> soc: only Ubuntu Developers (with @ubuntu.com) can decide to leave themselves as the Maintainer in packages they create if they want
 * soc thinks that having an @ubuntu.com email adress would look veeeeery cool :-P
<soc> but i guess that will take some years :-P
<RainCT> soc: heh :D. not really.
<soc> isn't it only for canonicals employees?
<soc>  isn't it only for cannonical's employees?
<persia> soc: Only for Ubuntu members.  Typically takes 3-6 months of solid, linkable contributions to get Membership.  Of course, you ought keep the contributions up at that point :)
<soc> ah ok ...
<RainCT> soc: no, Canonical guys have @canonical.com; the have to go through the Community Council (or some other Ubuntu council) to get an @ubuntu.com, too
<soc> but back to topic ...
<RainCT> s/the/they
<soc> is that thing http://ubuntuusers.de/paste/53106/ ok?
<soc> the last entry looks a bit weird
<RainCT> soc: which one?
<soc> that one after: blogtk (1.1-2build1) feisty; urgency=low
<soc> "only in patch2:
<soc> unchanged:"
<RainCT> looks strange :S
<sistpoty|work> tjaalton: can you attach diffstat/upstream changelog diff to bug #196073 please?
<ubotu> Launchpad bug 196073 in libpciaccess "Please sync from libpciaccess from Debian unstable" [Wishlist,Incomplete] https://launchpad.net/bugs/196073
<RainCT> patching file src/spellcheck.py
<RainCT> patch unexpectedly ends in middle of line
<RainCT> Hunk #1 succeeded at 1 with fuzz 1
<RainCT> soc: strange.. try rm blogtk_1.1-2ubuntu1*; cd blogtk-1.1/; debuild -S; cd ..; !debdiff
<soc> ok
<soc> mhh
<soc> the same
<persia> Anyone interested in a possible security SRU combined with some date checking code?  Bug #196854 seems to cover a few interesting issues.
<ubotu> Launchpad bug 196854 in fail2ban "fail2ban doesn't handle leap years" [Undecided,New] https://launchpad.net/bugs/196854
<persia> Err s/security SRU/security\/SRU/
<soc> http://ubuntuusers.de/paste/53108/
<RainCT> soc: that was intending to be run in ~/build/BloGTK
 * RainCT wonders how many computers soc has (desktop07..) :P
 * RainCT wonders why he is wondering that much today
 * DktrKranz wonders about RainCT wonderings
<RainCT> debdiff blogtk_1.1-2build1.dsc blogtk_1.1-2ubuntu1.dsc > blogtk_1.1-2ubuntu1.debdiff
<RainCT> (oops, sorry)
<RainCT> soc: hm.. I get the same thing here
<RainCT> soc: well, if you fix the patch manually it works
<soc> how?
<RainCT> soc: http://paste.ubuntu.com/5141/
<soc> mhhh
<soc> i think i need the last one, too
<RainCT> soc: it's there. I just moved the stuff up to the other src/* changes, removed the -orig from the --- line, add a "diff -u ..." line and remove the "only in..." crap
<soc> ahhh now
<soc> ok, didn't see that ...
<soc> ok
<soc> i corrected my debdiff now
<RainCT> soc: ok, attach it to the bug report. and normally you would have to subscribe ubuntu-universe-sponsors but don't do this now as I'm already subscribing it
<RainCT> s/subscribing/reviewing
<RainCT> soc: eh, but before add: (LP: #xxxx) to the 1st or 2nd point in your changelog entry
<RainCT> where xxxx is the bug number
<RainCT> (rather to the 2nd one)
<soc> ok, mom
<soc> ok
<soc> i'll attach it
<persia> soc: Careful.  The acronym "MoM" means something very specific here (merges.ubuntu.com) :)
<soc> ah ok :-)
<soc> http://launchpadlibrarian.net/12296500/blogtk_1.1-2ubuntu1.debdiff
<soc> https://bugs.launchpad.net/ubuntu/+source/blogtk/+bug/196813
<ubotu> Launchpad bug 196813 in blogtk "BloGTK doesn't work with Python 2.5 (IOError: unsupported XML-RPC protocol)" [Undecided,New]
<HighNo> what is the usual crowd in #launchpad? are those paid people? Somehow they are much less responsive than MOTUs...
<persia> HighNo: Mix of paid and unpaid, but the community is smaller (harder to review code).  Generally best to check during CET working hours.
<HighNo> persia: but that's the place to ask if something with launchpad (like rosetta) is somewhat broken?
<soc> RainCT: what does happen now? (btw, i changed status to Fix Committed, hope that's right
<HighNo> Maybe I'll post the question here too: I'm having a strange behaviour with rosetta: I uploaded a translation, get the import mail with the correct number of entries but the translation does not show up in launchpad - it still shows an old version...
<RainCT> HighNo: yes, either there, on the Launchpad mailing list or filling a bug
<RainCT> soc: was about to complain about that, should be "confirmed" or "triaged" (fix committed means that a MOTU uploaded it) :)
<soc> ah ok
<persia> HighNo: That's the place, although launchpad-users@ and answers.launchpad.net may also be helpful.
<soc> ok, changed
<RainCT> soc: uhm, btw, why do you mentor yourself on the bug report? :P
<RainCT> soc: I'll upload your changes in some minutes :)
<soc> yesterday i thought "ok, if someone fixes it, i can at least review the patch" but today i thought, "well, let's just do it myself"
<soc> ^^but i hope by mentoring myself i get extrapoints? :-P
<HighNo> hehe
<HighNo> did you help yourself much?
<soc> that remains to be dicussed between reporter, mentor and asignee :-P
<RainCT> lol
<soc> uuuhh
<soc> btw ...
<soc>  gpg --send-key --> which key should i choose?
<soc> the "pub" id or the "sub" id?
<soc> i just saw that i forgot to import my gpg key into launchpad and didn't sign the code of conduct ...
<RainCT> soc: ohhhh, I can't speak to you anymore until you've signed it :D
<soc> :-P
<soc> just tell me which id i have to use!
<RainCT> soc: what do you mean with which?
<RainCT> soc: that one you used for the package..
<soc> when i do  gpg --list-keys soc@krg-nw.de i get 5 lines ...
<soc> first starts with "pub"
<soc> then 3 with "uid"
<soc> 5th starts with "sub"
<soc> and i wonder which id i have to use for  gpg --send-key
<RainCT> soc: ah. dunno, mine starts with "sec 1024D/0EADC245 2006-11-04 [expires: 2008-11-03]", where "1024D/0EADC245" is what I've to pass gpg --send-key
<soc> (and for gpg --fingerprint)
<RainCT> soc: try with gpg --list-secret-keys
<soc> now i have one line with sec
<soc> 3 with uid
<soc> and one with ssb ...
<RainCT> soc: see above :)
<soc> guess i'll take that one with sec
<soc> https://wiki.ubuntu.com/Soc
<soc> coooool
<soc> that's bad for google's summer of code :-)
<sistpoty|work> protonchris, murrayc_: thanks for adding the check-symbols output to bug 190744. Unfortunately the abi is not stable, please see my comment at the bug.
<RainCT> heh
<ubotu> Launchpad bug 190744 in libgdamm3.0 "Request: Upgrade libgdamm3.0 to upstream version 2.9.81" [Undecided,Confirmed] https://launchpad.net/bugs/190744
<RainCT> (if someone is bored, http://paste.ubuntu.com/5144/plain/)
<HighNo> doh!
 * HighNo feels bored enough to fall for that one...
<soc> ouuuch ... that's really brilliant ...
<soc> the call the file UbuntuCodeofConduct-1.0.1.txt
<soc> but give the line gpg --clearsign UbuntuCodeOfConduct-1.0.1.txt ... of course, that can't work ...
<bobbo> soc: they spell it wrong on the site
<soc> yes ...
<bobbo> try tab completing it
<soc> already fixed it ...
<protonchris> sistpoty|work: thanks for taking a look.  I was under the impression that symbols starting with an underscore were internal.
<bobbo> soc: ah sorry
<protonchris> sistpoty|work: admittedly, I am new to all of this.
<sistpoty|work> protonchris: nope... that's the c++ mangling (everything starting with _Z is a c++ symbol iirc)
<sistpoty|work> protonchris: you can just use echo "c++demangledsymbolname" | c++filt to see the demangled name
 * RainCT observes how HighNo loops :P
<HighNo> damn, that is a loop?
<RainCT> HighNo: do you have a broken parser or what? :D
<HighNo> hehe
<protonchris> sistpoty|work: Ahh.  Thanks.  I'll see if murrayc_ wants to do a new release with an updated soname.
<sistpoty|work> protonchris: thanks!
<soc> RainCT: is there anything i can do now?
<\sh> grmpf
<\sh> can't we patch away the registration dialog box of netbeans?
<HighNo> \sh:  why is it bothering you?
<\sh> HighNo: it shouldn't be in an app we ship..there is no need to register, so it's useless...
<\sh> HighNo: and it's highly annoying
<RainCT> soc: fix another bug :)
<HighNo> \sh: at least full ack on 2nd one. I am not certain about the first one. If it is in universe and a commercial one - there still is a point in kindly asking the users to register. Knowing about your users is good for commercial development
<bobbo> RainCT: you got time to sponsor another debdiff for me?
<bobbo> RainCT: this one is actually in universe ;)
<HighNo> (hey, it's not even bad for any software)
<\sh> HighNo: then it should belong to multiverse but as we build it from source, and as it's opensource now, we should get rid of it
<RainCT> soc: (I'll need some time to upload this one as I'm uploading my Hardy chroot and that's damn slow.. feel free to donate me a better connection :P)
<RainCT> bobbo: subscribe me and I'll have a look at it later today :)
<HighNo> \sh: you are free to do it - but still open source does not conflict with commercial app.
<bobbo> RainCT: thanks :)
<soc> RainCT: no problem?
<soc> is there a way to see which packages still depend on python 2.4 instead on python?
<soc> so i can investigate if it's a mistake or if there is something fundamental blocking it from using Python 2.5
<RainCT> soc: apt-cache rdepends python2.4   might help
<sistpoty|work> soc: apt-cache rdepends python2.4
<sistpoty|work> heh
<soc> thanks
<RainCT> ^^
<soc> :-)
<\sh> HighNo: well, then we should change the text "you'll receive mail for new version releases blabla" doesn't make sense in a package which will be supported for 3 years...
<HighNo> \sh: ok, that does not make sense then
<RainCT> hooray, pbuilder finished :)
<HighNo> \sh: do you formally ask me to patch that?
<HighNo> \sh: I just freed 500mb of disk space :-)
<\sh> HighNo: :) disk space is not the problem i have :)
<murrayc_> sistpoty|work: I don't update .so names for any of the *mm libraries, and neither does GTK+.
<HighNo> \sh: Yes, but it was mine. (<150mb) I meant I have enough space to apt-get source netbeans now :-)
<\sh> HighNo: and it would be nice, if we could get rid of this screen...or just make it a simple splash which disappears after 2 or 3 secs ,-)
<\sh> the former is my favorite solution :)
<HighNo> \sh: I'll have a look.
<sistpoty|work> murrayc_: well, you really should, as the abi is broken by the change (that's what the soname is for)
<HighNo> \sh: you want me to patch the hardy release, right?
<\sh> HighNo: yepp :)
<murrayc_> sistpoty|work: It's unstable. It's meant to break. But on the other hand, I don't mind if we change the .so name it for that very reason, so I'd accept a patch. Without a patch I'm not confident that I'd make the right change in configure.ac.
<HighNo> \sh: can you give me some short details on when the dialog pops up and what its content is (at least part of it so I can search for that in the source)
<sistpoty|work> murrayc_: ok, I'll take a look, once I'm at home (or maybe protonchris would like to do that?)
<emgent> jdstrand, ping
<\sh> HighNo: directly when you start netbeans the first time
<murrayc_> sistpoty|work: Thanks.
<sistpoty|work> Thanks for the lib in the first place, murrayc_ ;)
<RainCT> btw, nano segfaults when the terminal is too small
<soc> RainCT: ok, i'll review balder2d next ...
<soc> i'll leave my hands of zope and plone ... and falcon repository builder mentions something about py 2.5 incompatibility ...
<RainCT> go soc go! :)
<HighNo> \sh: I never used netbeans - how do you start it from the command line?
<soc> ^^:-)
<\sh> HighNo: netbeans :)
<\sh> HighNo: if you have sun-java6 installed somehow, it will crash right before start.
<\sh> HighNo: just do this on the CLI:  export LIBXCB_ALLOW_SLOPPY_LOCK=1
<\sh> and start netbeans...this is a workaround
<soc> weiiird ... since when go executables to /usr/lib?
<\sh> HighNo: I'll go home now...and come back in at least 1h30mins :)
<\sh> HighNo: if you need help, I can look into the code too :)
<\sh> ok...and weekend time now
<tjaalton> sistpoty|work: I'm too lazy, I'll just close it as invalid for hardy. it's only really needed when xserver 1.5 is uploaded after hardy.. ;)
<sistpoty|work> ok, thanks tjaalton
<Iulian> I'm trying to debuild a package after I added .desktop file but I get an error from lintian: desktop-file-but-no-dh_desktop-call
<Iulian> I've added dh_installmenu in debian/rules
<Iulian> Am I missing something?
<RainCT> Iulian: you've to add dh_desktop, not dh_installmenu
<RainCT> Iulian: dh_installmenu is for debian/menu files
<Iulian> RainCT: Boah!
<Iulian> Right
<Iulian> Thanks RainCT
<RainCT> Iulian: np :)
<RainCT> soc: uhm.. blogtk is failing to build
<RainCT> soc: both the current version and that one with your changes
<bddebian> Heya gang
<RainCT> chmod +x debian/blogtk`pkg-config libgnome-2.0 --variable=prefix || echo /usr`/bin/BloGTK
<RainCT> chmod: cannot operate on dangling symlink `debian/blogtk/usr/bin/BloGTK'
<RainCT> strange.. but running make install manually works
 * RainCT thinks that this is a strange package.. :P
<RainCT> can someone try to build blogtk on a Hardy chroot?
<bobbo> RainCT: i'll give it a go
<bobbo> RainCT: vanilla package from Hardy apt-source?
<hellboy195> dholbach: around?
<dholbach> hellboy195: yes, but quite busy - how can I help you?
<hellboy195> dholbach: ah, just wanted to let you now that clean-la thing (libnxml) is *still* necessary. so the uploaded debdiff should be ok. if you want to go ahead ,.. but if you have no time, it 's no problem. just no stress :)
<hellboy195> *know
<dholbach> hellboy195: OK, best to ask for *somebody* to upload it :)
<hellboy195> ^^
<hellboy195> MOTUs out there with a little bit of time. Ok in fact I only need '1' ^^. bug 195532 :)
<ubotu> Launchpad bug 195532 in libnxml "Merge libnxml 0.18.1-4 from Debian(Unstable)" [Undecided,Confirmed] https://launchpad.net/bugs/195532
<Iulian> RainCT: Do you have few seconds to take a look at my debdiff please? http://paste.ubuntu.com/5145/ - it's bug #196871
<ubotu> Launchpad bug 196871 in zblast "No .desktop file; here is one" [Undecided,In progress] https://launchpad.net/bugs/196871
<bobbo> RainCT: blogtk fails on my end too Error: http://pastebin.ubuntu.com/5146/
<soc> RainCT: could it be that the main py-file isn't chmod+x ed?
<hellboy195> LucidFox: btw, why are you a subscribed at my beagle merge if you are already in the MOTU Mono Team?
<LucidFox> hellboy195> I marked my intention to do it this way
<hellboy195> LucidFox: ah k, nice if you would do it. I uploaded the debdiffs a long time ago and you should have noted that already somebody asked about the progess
<LucidFox> Indeed :)
<LucidFox> (By the way, for some reason I don't receive mail from team subscriptions - none from u-u-s, for example)
<hellboy195> LucidFox: :)
<RainCT> Iulian: sorry for the wait. the .desktop file won't validate; otherwise it looks good
<RainCT> bobbo: thanks
<RainCT> bobbo: same error as here
<RainCT> but dpkg-buildpackage -rfakeroot works
<RainCT> LucidFox: u-u-s mails go to ubuntu-universe-sponsors@lists.ubuntu.com
<Iulian> RainCT: No problem, what should I do before submitting the debdiff to the bug report?
<RainCT> Iulian: ensure that the .desktop file is clean, using the desktop-file-validate command
<RainCT> (it's installed with the default installation)
<Iulian> RainCT: Ok, will do that.
<RainCT> Iulian: on a first look the Encoding line should be removed, the Application category too, the Icon field should just be "xzb" and the command should start with a verb (desktop-file-validate won't find this last one, but trust me :))
<RainCT> ah, and remove the GenericName thing if it's empty
<RainCT> perhaps a more descriptive Name would be good, but I don't see many games following this so you might also leave it as it is
<RainCT> Iulian: ah, and if you tell me what Comment you're going to use I'll give you one or two translations :)
<Iulian> RainCT: Actually I don't know. :-)
<Iulian> RainCT: I don't mind if you give me one though
 * Iulian smiles
<RainCT> igh-speed shoot 'em up game
<RainCT> argh
<RainCT> Iulian: "Play a high-speed shoot 'em up game" would be the easy one
<Iulian> RainCT: Heh, ok, will add that. Thanks
<RainCT> Iulian: ok.. I'll give you a translation when I decide how to translate "shoot 'em up" :P
<Iulian> RainCT: Okay
<jpatrick> sorry about that guys
<Iulian> RainCT: I'm still fighting with the .desktop file, can you give me a hint? http://paste.ubuntu.com/5147/
<Iulian> jpatrick: You missed one :)
<jpatrick> gah
<PP|Spydon> Who shall I contact if I want a package reviewed and updated to the repos?
<bobbo> Iulian: "Applications;Games;" should just be "Games;" i think
<Iulian> bobbo: Let me try.
<Iulian> bobbo: Nop, seems that it should start with X-
 * bobbo goes to grab gnome-games source to check this out
<Iulian> bobbo: Yep, it should start with X-. Now I get only this error: zblast.desktop: warning: key "Encoding" in group "Desktop Entry" is deprecated
<bobbo> Iulian: just remove the entire Encoding line and it should work
<Iulian> Ok
<Iulian> Isn't necessary to have that line?
<bobbo> Iulian: Looks like its been deprecated to me
<Iulian> That's true...
<bobbo> Iulian: is it working now?
<Iulian> bobbo: Yes
<PP|Spydon> The game X-Moto is version 0.3.2 in the repos and there has been many improvements since that version to the current version (0.4.1) is it possible to get in updated in some way? :P
<PP|Spydon> Or this is maybe the wrong place to ask?
<bobbo> PP|Spydon: is there a newer version in Debian Sid?
<PP|Spydon> bobbo, I don't think so...
<stgraber>      xmoto |    0.3.2-1 | gutsy/universe | source, amd64, i386, powerpc
<stgraber>      xmoto |    0.4.0-2 | hardy/universe | source, amd64, i386, powerpc
<PP|Spydon> ah how nice!
<stgraber> so hardy's 0.4.0
<bobbo> Debian sid has 0.4.1-1
<PP|Spydon> Ah okay, how can I check things like that? :P
<sistpoty|work> oh, you don't want to block the release team having to extensively test the newer xmoto from sid? *g*
<stgraber> PP|Spydon: I just used : rmadison xmoto that gives you the versions for Ubuntu and there is an extra parameter to check Debian IIRC
<PP|Spydon> thx
<stgraber> rmadison xmoto -u debian
<PP|Spydon> ah this is a really nice app
<PP|Spydon> I shall not take more of your time, thx for the information and keep up the good work! :)
<PP|Spydon> bb
 * sistpoty|work heads home... later folks
<jakev> Hello all
<Iulian> Hi jakev
<Iulian> RainCT: I think it's ready now, can you please take a look at it again? http://paste.ubuntu-nl.org/57847/
<hellboy195> \sh: good to see you :) I have a question
<hellboy195> \sh: I'm currently mergin gnustep-gui and I have an error I can't avoid. http://pastebin.com/m44f7596a
<RainCT> Iulian: why "X-Game"?
<\sh> hellboy195: you need to install some of the gnustep -dev packages
<\sh> hellboy195: it's a essential build-dep for gnustep stuff, and it needs to be installed on the host where you run debuild -S -sa
<\sh> or something similiar
<hellboy195> \sh: ah. I'm a dork.
<RainCT> Iulian: it's just Game, see http://standards.freedesktop.org/menu-spec/latest/apa.html
<hellboy195> \sh: just wondering why the build machines don't have a problem!?
<Iulian> RainCT: I changed it because this: zblast.desktop: error: value "Games;" for key "Categories" in group "Desktop Entry" contains an unregistered value "Games"; values extending the format should start with "X-"
<RainCT> Iulian: because it's "Game" and not "Games" ;)
<Iulian> RainCT: Blah! :)
<RainCT> Iulian: using "X-Game" either it won't be displayed or it would create a new category in the menu
<Iulian> RainCT: Okay, after that should I attach the debdiff to the bug report and subscribe u-u-s?
<RainCT> Iulian: yes
<Iulian> RainCT: Thanks!
<hellboy195> \sh: but debuild is also very funny. dpkg-source: error: syntax error in ./gnustep-gui-0.12.0/debian/control at line 55: line with unknown format (not field-colon-value)
<hellboy195>   http://pastebin.com/m28b8e3fa  ;)
<RainCT> does anyone know what "chmod: cannot operate on dangling symlink" means?
<RainCT> slangasek?
<\sh> hellboy195: that was the rules file
<hellboy195> \sh: I'm just wondering what's false at line 55
<slangasek> RainCT: it means coreutils has gotten silly in its old age
<slangasek> RainCT: that used to fail silently, now coreutils balks when you try to chmod a symlink that's pointing out into nowhere
<\sh> hellboy195: but there is something wrong in debian/control not in rules...
<hellboy195> \sh: l g
<hellboy195> \sh: I mean. OMG. I should stop for today xD
 * RainCT decides that slangasek is allmighty :)
<RainCT> slangasek: thanks
<afflux> there are three bugs in gnome-art for which I have fixes that I'd like to get sponsored. Should I create multiple debdiffs or one big containing all three fixes ?
<RainCT> afflux: one
<hellboy195> \sh: thanks, thanks, thanks :)
<RainCT> slangasek: but the symlink works..
<afflux> RainCT: okay. And attach that one to which bug?
<hellboy195> wb LucidFox :)
<LucidFox> I won't stay for long
<LucidFox> going to sleep soon
<hellboy195> ^^
<RainCT> afflux: create a new bug "Candidate for version XXX"
<RainCT> afflux: and post a comment in the other bugs stating that there's a fix available on that other bug
<slangasek> RainCT: more context, please?
<afflux> RainCT: alright, thank you
<RainCT> slangasek: http://paste.ubuntu.com/5146/
<RainCT> slangasek: it builds in Gutsy but failds with that error in Hardy chroots
<RainCT> slangasek: btw, if you know what that strange "`" is please tell me (it's also there when building on Gutsy)
<slangasek> ln -s  debian/blogtk`pkg-config libgnome-2.0 --variable=prefix || echo /usr`/share/blogtk/BloGTK.py debian/blogtk`pkg-config libgnome-2.0 --variable=prefix || echo /usr`/bin/BloGTK
<RainCT> s/is/are
<slangasek> RainCT: that's not a proper package symlink according to Debian policy; you're supposed to use relative symlinks, where this one is an absolute symlink (which would be invalidated in the actual package, besides)
<Iulian> bobbo: Are you working on #196872 ?
<slangasek> basically, that line above reduces to ln -s debian/blogtk/usr/share/blogtk/BloGTK.py debian/blogtk/usr/bin/BloGTK
<slangasek> and it should be ln -s ../share/blogtk/BloGTK.py debian/blogtk/usr/bin/BloGTK
<slangasek> RainCT: so the blogtk Makefile is just not compatible with current coreutils, and also creates a symlink that's wrong; the latter was not an issue for the package because it was overridden by debian/blogtk.links
<slangasek> but the former is an issue
<RainCT> uhm.. the package has been removed from Debian
<LucidFox> Gosh, an iPod is _heavy_.
<hellboy195> LucidFox: not if you loose it (like me :( )
<bobbo> Iulian: i was thinking about working on #196872 but you can have it if you want
<LucidFox> I've compared my dad's iPod video 5G to my iriver clix. The iPod's ONLY advantage is 40x more storage space, 80GB vs 2GB (but, then, it's HDD vs flash). Everything else is worse.
<RainCT> slangasek: from popcon  web: position by_vote: 26 blogtk  inst: 1949  vote: 158  old: 1703  recent: 87
<RainCT> slangasek: do you think is should be removed or rather adopted in Ubuntu?
<LucidFox> Overpriced, heavy, few formats supported, requires special software, etc.
<slangasek> RainCT: I'm not familiar with the package and have no opinion
<LucidFox> anyway... night all
<RainCT> anyone here knows blogtk?
 * soc knows it a bit since yesterday ...
<soc> :-)
<RainCT> heh
<RainCT> soc: do you think it's worth being in Hardy?
<soc> good question ...
<soc> it's the only remotely usable blogging client for gtk ...
<soc> afaik
<soc> i have absolutely no experience with makefiles, but i can look at it ...
<Iulian> bobbo: Ok, I will take a look.
<slangasek> I'm not even sure what a "blogging client" is...
<slangasek> my blogging client is my editor + my VCS (ikiwiki++ :P)
<RainCT> soc: I'm already looking at it
<soc> mh ok
<soc> at least it would be good to have one program less which depends on python 2.4
<soc> so either fix or remove i would say ...
<soc> but atm it's not really nice ...
<RainCT> well, I think I'll just clean it up a bit for now
<\sh> man I'm tired of sckers who steal property, even if it's only an article
<\sh> check out "http://www.linuxindex.com/" and tell me what you see...this is ridiculus
<jpatrick> \sh: especially when they get money with ads..
<RainCT> :/
<\sh> jpatrick: and more annoying when they send trackbacks in their name with our content
<\sh> http://www.mysqlperformanceblog.com/2008/02/04/finding-out-largest-tables-on-mysql-server/ as he did here
<\sh> if you want to send emails to him, all infos are on http://www.sourcecode.de/content/damn-you-thieves :)
<\sh> sadly that p.u.cs cronjob isn't running :)
<tbf> superm1: revu has an updated version of gnome-lirc-properties
<tbf> RainCT: danke! :-D
<RainCT> tbf: you're welcome :)
<TuxCrafter> hi guys
<TuxCrafter> how do I remove all *-dev files
<TuxCrafter> packages
<fdoving> for example_:
<fdoving> dpkg -l '*-dev'|xargs aptitude remove
<TuxCrafter> i am working with a driver developer and he needs /usr/include/linux to link to the kernel sources but is this a correct way
<fdoving> em, that missed a cruical part. hang on.
<TuxCrafter> he needs the compiler.h
<fdoving> dpkg -l '*-dev'|awk '{print $2}'|xargs aptitude remove
<fdoving> there.
<fdoving> that can be used to uninstall all -dev packages.
<jpatrick> fdoving: woah... tons of output
<slangasek> TuxCrafter: ehm, no, the correct way is for the driver developer to not use /usr/include/linux, which is reserved for userspace headers
<fdoving> jpatrick: did you get the one with awk? - the first command i left awk out. which is fun, but it won't work.
<jpatrick> fdoving: aptitude is still working the stuff needing removal out..
<TuxCrafter> slangasek: it is a special tvtime modivication
<TuxCrafter> or am i just missing a important dev package
<fdoving> jpatrick: oh, that much :)
<TuxCrafter> how can i search apt-cache for  an package that will install the compiler.h header?
<TuxCrafter> in the /usr/include/linux dirs
<TuxCrafter> i got one in my normal headers
<fdoving> TuxCrafter: you can't use apt-cache for that. there is apt-file
<fdoving> or you can use packages.ubuntu.com
<slangasek> TuxCrafter: it doesn't matter what it is, that's the wrong directory to use when building kernel modules.  you want either /lib/modules/$(uname -r)/build, or a specific path under /usr/src/ depending on the kernel ABI you're building for
<slangasek> and compiler.h is not a userspace header, so if you're building something that's /not/ a kernel driver, you shouldn't be using that header
<TuxCrafter> slangasek: i agree
<TuxCrafter> i am going to talk with him about than
<TuxCrafter> i will show you
<TuxCrafter> maybe you can give me advice where he sould be looking for his header files
<TuxCrafter> slangasek: http://pastebin.ca/923686
<TuxCrafter> he is working on some very advanced video and tuner chips for external pctv devices
<TuxCrafter> but his dependency checks are driving me crazy so i am doing the documentation for him
<slangasek> TuxCrafter: this is userspace code using a kernel-only header.  compiler.h is not vetted for use from userspace; if he wants that definition, he needs to copy it into his own code
<TuxCrafter> so nobody else have to go through it agiain
<TuxCrafter> slangasek: and if he needs kernel space code because it is interfacing with hardware?
<TuxCrafter> that would not be a good idea
<TuxCrafter> it would break the API
<TuxCrafter> ABI
<slangasek> TuxCrafter: false, you only need kernel space code if you're writing kernel code
<TuxCrafter> slangasek: yes i see that
<slangasek> if you're writing a userspace application, the rule has always been that if it's not a header exported by the kernel, you either can't rely on it at all or you make a local copy
<TuxCrafter> slangasek: In file included from videoinput.c:39: videodev2.h:19:46: error: linux/compiler.h: No such file or directory
<slangasek> yes
<slangasek> linux/compiler.h is not a header intended for userspace
<TuxCrafter> so he needs to include that file in his own code?
<slangasek> if he thinks he needs to use it, yes
<TuxCrafter> or should he do something else?
<slangasek> personally, I think the reference to linux/compiler.h ought to be dropped entirely
<slangasek> since the only definition he uses from it is __user
<TuxCrafter> so relinking /usr/include/linux to my kernel source tree is not correct
<slangasek> nope, a userspace app should be buildable without having to do that
<TuxCrafter> slangasek: can you please help me explain this issue to the developer at #dvb at freenode.org
<TuxCrafter> slangasek: http://packages.debian.org/search?searchon=contents&keywords=compiler.h&mode=exactfilename&suite=stable&arch=any
<TuxCrafter> why does debian has a /usr/include/linux/compiler.h and ubuntu does not
<slangasek> TuxCrafter: no time to get involved in this discussion on another channel right now, sorry
<slangasek> TuxCrafter: Debian no longer has /usr/include/linux/compiler.h either; that information only applies to etch, not to lenny
<TuxCrafter> slangasek: also is this normal to do sudo ln -s /usr/src/linux-source-2.6.24 /lib/modules/$(uname -r)/source
<TuxCrafter> i had to do that to compile an other piece of his kernel userspace driver
<slangasek> TuxCrafter: generally one can use the linux-headers-$(uname-r) package instead
<TuxCrafter> yea but the headers the package was needing where not there with only the headers
<slangasek> then that code is also broken for relying on headers that aren't part of the interface exported for kernel modules ;)
<TuxCrafter> slangasek: pfff
<TuxCrafter> i aslo cant get the guy to change his mind
<TuxCrafter> seem to be something broken in videodev2.h when i compile it
<TuxCrafter> is there some documentation that explains developers where to look for header and source files
<TuxCrafter> found the problem
<TuxCrafter> this code is just bad
<Ubulette> is http://paste.ubuntu.com/ broken only for me ? http://pastebin.mozilla.org/349392
<jpatrick> Ubulette: paste.u.c is broken beyond belief, use http://paste.ubuntu-nl.org/ instead
<Ubulette> jpatrick, i use paste.u.c a lot and it's the 1st time it dies on me
<sistpoty> hi folks
<tbf> hey sistpoty :-)
<hellboy195> sistpoty: ahoi :)
<sistpoty> hi tbf and hellboy195
<tbf> sistpoty: hope it wasn't my mail, that brought you back to life! :-D
<hellboy195> sistpoty: May I ask you what kind of job you have. You work prettly long
<tbf> hellboy195: its in the ubuntu wiki
<tbf> it's
<sistpoty> tbf: no, I'll take a look later (need to do some things first)
<hellboy195> tbf: k
<sistpoty> hellboy195: I'm a scientific research (computer science) at the university of erlangen
<tbf> sistpoty: of course!
<hellboy195> sistpoty: cool :)
<sistpoty> hellboy195: and since I pretty much can choose from when and to when I work, as long as I work my 40hrs per week, I tend to arrive later :)
<hellboy195> sistpoty: that's nice. lucky one :)
<sistpoty> heh, I even develop foss there: www.faumachine.org is the big project of the chair I'm working at
<RainCT> soc: ok, I changed the package a little bit (my changelog entry is only 50 lines long) :)
<HighNo> sistpoty: hm, latest release 20060310 ?...
<sistpoty> HighNo: yeah... everyone is busy adding new features atm *g*
<HighNo> seems like there are a lot of germans around here :-)
<sistpoty> so, the long awaited new release still needs to wait a little bit longer
<sistpoty> heh
<HighNo> sistpoty: I see... not exactly the 'open source way' ("release early, release often")
<sistpoty> HighNo: well, it's still a university project (and of course there is cvs access) *g*
<soc> RainCT: ok, i'll watch out on hardy :-)
<hellboy195> Wow. Today is a popential programs for FFE release day :)
<zul> hello anyone feeling like patching fail2ban?
<sistpoty> anyone, who'd like to proofread meeting minutes? http://paste.ubuntu-nl.org/57883/
<RainCT> sistpoty: Â«such an ACK does "not necessarily whether it's correct or not" [Hobbsee].Â»
<sistpoty> RainCT: fixed, thanks
<RainCT> btw, with what keyboard shortcut can I paste in konsole?
<nixternal> RainCT: shift + insert
<RainCT> thanks nixternal
<nixternal> or clicking the middle mouse button
<nixternal> no prob
<nixternal> I have gotten so used to shift+insert I use it now more than I do ctrl+v
<sistpoty> tbf: just looking at gnome-lirc-properties: though I'm not a cdbs expert, I guess the autotools-dev build-dependency is not necessary (at least I didn't find something using it there).
<tbf> sistpoty: hmm
<tbf> sistpoty: hmm.... the generated makefile contains several autotool invokations...
<sistpoty> tbf: also, please make sure to file a new FFe (referring to the needs-packaging bug) and mention that in debian/changelog (otherwise, archive admins might put it back to motu-release)
<tbf> ...even if they shouldn't be called normally
<sistpoty> tbf: then you'd need to build-depend on auto*conf* (the autotools-dev rather is useful, if upstream config.sub/config.guess is outdated and doesn't support a newer architecture for example)
<persia> sistpoty: FFe bug?  Not new package bug?
<sistpoty> persia: well, the new package bug is confirmed (rightfully that), an FFe being confirmed would mean that it's accepted
<sistpoty> see bug 192368
<ubotu> Launchpad bug 192368 in ubuntu "Please add gnome-lirc-properties" [Wishlist,Confirmed] https://launchpad.net/bugs/192368
<sistpoty> though I don't mind too much to have only one fulfilling both ;)
<sistpoty> but at least one new package feature freeze exception bug should be there *g*
<persia> sistpoty: I thought the plan was one filling both, but I suppose that's an implementation detail :)
<sistpoty> persia: let's say it evolved in this case *g*
<bddebian> persia: !!??!
<tbf> i read you shall just subscribe the ffe team
<persia> tbf: Good :)
<sistpoty> tbf: sure, is ok as well, but please set it back to new or triaged then
<sistpoty> tbf: (otherwise motu-release won't look at it *g*)
<hellboy195> persia: No one picked wxwidgets so far. So if you want to, just take it :) I'm going to bed now. hf and gn8
<tbf> sistpoty: hmm... maybe a new bug is more secure
<sistpoty> heh
<persia> hellboy195: I can't compile it on my machine.  We'll have to wait for someone else.  Thanks again.
<tbf> sistpoty: i am that much lost in procedure already... that i've entered no-risk mode some time ago :-)
<hellboy195> np. so gn8
<persia> bddebian: Hi.  I've still not tracked down the attal thing, but it's on my list for tomorrow (when I ought have some time).
<bddebian> persia: NP.  Actually I was wondering if you saw the newpki-client upload?
<tbf> sistpoty: regarding: "and mention that in debian/changelog" --- something like "* Initial upload to Ubuntu (#192368, #xyz)"?
<persia> bddebian: I did, and was very happy.  Unfortunately, it appears I deleted the patch that makes ctsim compile and segfault.  I'm thinking about disabling the GUI for hardy, and just shipping the CLI tools.
<sistpoty> tbf: s.th. like "feature freeze exception LP: #bugnumber" (to make it more clear, and LP: #bugnumber will also close that bug)
<soc> RainCT: did you figure out what caused the problems in BloGTK?
<tbf> sistpoty: removed autotools-dev, really doesn't seem to make sense - but crosschecking by uploading to ppa
<tbf> sistpoty: what stands "LP" for?
<azeem> tbf: "launchpad", usually
<tbf> azeem: ah!
<sistpoty> tbf: I guess I asked you before, but what is the prerm good for?
<sistpoty> tbf: sadly, it doesn't work for me (see revu comment)
<sistpoty> tbf: looks like the python-support directory is wrong (/usr/share/python-support/gnome-lirc-properties/*gnome-lirc-properties*/)... though I'm no python packaging expert
<tbf> sistpoty: that it doesn't find gnome_lirc_properties for you...
<jdong> vorian: poke; you back yet? :)
<tbf> sistpoty: for me python-support creates all the symlinks in /var/lib/python-support/python2.5/gnome_lirc_properties/
<tbf> all pointing to that odd /usr/share/python-support/gnome-lirc-properties/*gnome-lirc-properties*/ folder
 * sistpoty installs again
<sistpoty> tbf: looks like it was my fault, didn't see that dpkg bailed out on missing dependencies (closed the shell too early *g*)
<tbf> ah... the odd folder name also is right
<tbf> it is gnome-dash-lirc-dash-properties/gnome-underscore-lirc-underscore-properties
<tbf> the dash variant is the package name....
<sistpoty> tbf: still looking at the ui, it seems strange: I couldn't unlock at the first try, and had no chance to unlock for a second time (some error appeared). when I restarted it, somehow it was already unlocked
<tbf> ...the underscore variant is the public module name, sistpoty
<sistpoty> tbf: ah
<sistpoty> tbf: oh, it crashed when clicking on help (note, that I don't have gnome installed)
<tbf> sistpoty: hmm... shall i add yelp to the depends list, or shall i make the code calling yelp more robust
<sistpoty> tbf: whatever you prefer, I guess
<sistpoty> (I guess, if there is a button, I'd like to be able to click it, though yelp as a dependency makes some sense to me)
<sistpoty> s/though/so/
 * persia notes that robust code might also provide some user feedback to install yelp when clicking an otherwise nonfunctional button, but doesn't intend to sway the decision either way
<persia> Anyway feel like reviewing some packages and preparing new candidates for upload?  There are 395 likely candidates available from http://tinyurl.com/create.php, which is likely plenty to share :)
<persia> Err.. http://tinyurl.com/2stsyf
<persia> s/Anyway/Anyone/
 * persia stops, apparently being unable to type
<sistpoty> heh
<vorian> jdong, in about 30 min
<vorian> :)
 * sistpoty ponders fixing a configure.ac to bump soname for upstream
 * sistpoty also ponders going to bed though
<jdong> vorian: :)
<vorian> maybe 40
<vorian> I just happened to hear my computer talking again :P
<jdong> vorian: what are you, the Vista copy dialog?
<vorian> hehe
<jdong> :)
<jdong> (maybe this is a bad joke to make in the Gates building; he might just disassociate me from the AP... AGAIN)
<tbf> sistpoty: also have to sleep: had a 700km trip today
#ubuntu-motu 2008-03-01
<tbf> persia: sounds easier than it is, cause pygtk throws X Window System errors, after closing a forked process
<persia> tbf: Depends on the app, but please take anything I say with care when applying to anything related to python.
<azeem> tbf: 700km by plane wouldn't be so bad
<tbf> azeem: car
<azeem> ok, that's worse
<sistpoty> oh, that's far indeed
<tbf> sistpoty: berlin-stuttgart
<persia> Well, depends on the car and local airport regulations.  For distances of <500km in some parts of the world, cars are faster.
<azeem> still, it's better to drive 700km on the Autobahn, then through Poland and Ukraine
<azeem> than*
<tbf> azeem: with a little baby you only can choose between train and car
<azeem> heh
<tbf> well, and using the car is significantly cheaper...
<azeem> why do you have to drive 700km with a little baby?
<ScottK2> Because they're to young to stay at home by themselves.
<tbf> azeem: 'cause we prefer visting my parents in law, instead of having them in our flat and bugging us
<azeem> heh, fair enough
<azeem> my GF's mother is living together with her in some sort of WG
<jdong> 700km's probably also cheaper if there were more than 2 or so passengers to get there
<tbf> persia: as long as you stay within germany flying is like taking a bus
<tbf> persia: you checkin 20 minutes before departure, take your seats.... fly for 90 minutes max., get your stuff back within minutes and leave
<persia> tbf: That being the reason I prefer trains to planes for local travel in Germany.  A bus shouldn't fly (and yes, it does feel like a bus) :)
<tbf> persia: trains are fskingly expensive in germany
<tbf> persia: and odly ICE's aren't half as ecological as deutsche bahn claims
<tbf> persia: trains only give you a ecologic benifit, if you stay arround 160 km/h
<azeem> which is the case for most ICE tracks...
<persia> tbf: True.  I have the luxury of not living in Europe, making trains significantly cheaper for short stays.
<tbf> above that barrier they waste as much, or even more energy than cars
<azeem> eh, most tracks ICE run on
<tbf> azeem: hmm? maybe that's the benifit of living in berlin... but the ice's i used usually went full steam
 * sistpoty needs some sleep
<sistpoty> good night
<vorian> weeee!
<vorian> freedom!
<vorian> jdong, see latest debdiff
<jdong> vorian: -ENOLINK & -ETOOLAZYTOFINDIT
<jdong> s/&/|/
<vorian> bug 192812
<ubotu> Launchpad bug 192812 in ktorrent-kde4 "[FF exception] New upstream release ktorrent-kde4 3.0.0 " [Wishlist,Confirmed] https://launchpad.net/bugs/192812
<jdong> new com.ubuntu.irc.ThankYouMessage(net.launchpad.users.get("vorian"))
<jdong> (top signs you've been coding in Java for a day)
<vorian> jdong, you are nuts
<vorian> :P
<jdong> vorian: with regards to that debdiff are you SURE that all the changes in the tarball are representable by that debdiff?
<jdong> let me just filterdiff -i 'debian/*'
<vorian> jdong, uscan then uupdate then debuild
<jdong> vorian: so are you giving up on the cdbs method?
<vorian> jdong, aye
<vorian> kind of
<jdong> vorian: elaborate please
<nixternal> I wonder why the wrapper in kde.mk isn't working
<nixternal> drwxr-xr-x root/root         0 2008-02-29 19:30 ./usr/bin/
<nixternal> -rwxr-xr-x root/root       169 2008-02-29 19:30 ./usr/bin/ktorrent-kde4
<nixternal> -rwxr-xr-x root/root       171 2008-02-29 19:30 ./usr/bin/ktupnptest-kde4
<nixternal> vorian and jdong: the new debdiff for ktorrent-kde4 does the wrapping it seems..if this was the issue you all were talking about
<nixternal> note to self: when in Virtualbox, ctrl+alt+backspace doesn't restart X in VBox but restarts the systems X
<jdong> nixternal: there is no wrapper in kde.mk, btw
<jdong> nixternal: the so-called wrapper seems to just sed the .desktop file to /usr/lib/kde4/bin rather than /usr/bin, which (1) I'm not sure even works with the PATHs (2) isn't friendly to someone who wants to call ktorrent from the CLI
<nixternal> they would call ktorrent-kde4 from the cli
<Amaranth> jdong: i can run kde4 apps from my gnome menu
<Amaranth> oh, i see what you're saying
<jdong> nixternal: right, that's with the wrapper restored from the earlier packaging
<jdong> nixternal: that's not something that's availabe if only kde4.mk were used
<jdong> the so called wrapper target that I saw in the .mk file was just that sed job
<jdong> which, I don't have a kde4 setup to test, I suspect wouldn't even work unless paths were mangled via something automagic that I don't know about
<jdong> (grumble which Ubuntu tends to do more often than not :D)
<nixternal> ahh
<jdong> I'd personally feel more comfortable with vorian's latest debdiff (a straight uupdate from our manual wrappered previous revisions)
<nixternal> ya, I still use the old school wrapper in debian/rules
<jdong> just wanted to check that that's okay with everyone
<vorian> agreed
<nixternal> the one in kde.mk seemed to only work when there were multiple binaries in the package
<nixternal> jdong: ditto
<jdong> okay, then let me prepare such for upload :)
<jdong> NOOOOOOOOOOOOOOO
<jdong> permissions error on my results dir caused that entire ktorrent build to be discarded
<DarkMageZ> ktorrent doesn't take that long to build tho. you'll be ok.
<jdong> DarkMageZ: meh ktorent-kde4 did take the past 15 minutes to build
<vorian> jdong, really?
 * vorian checks build logs
<jdong> vorian: yeah, in a pbuilder; though I was messing with some other stuff that's disk intensive
<vorian> i seeeeee
<jdong> namely cloning the rockbox svn repo
<DarkMageZ> is this 3.0 release for hardy?
<vorian> he
<vorian> DarkMageZ, aye
<DarkMageZ> hmm, now i've just got to figure out how to move my 2.2.5 configs to 3.0
<jdong> vorian: ktorrent-kde4 uploaded
<vorian> ^5
<vorian> thanks jdong
<jdong> :)
 * jdong continues 3-way merging his rockbox-on-steroids
<jscinoz> well that was embarrasing
<jscinoz> just spent an hour figuring out why it was building my package as -0 instead of -1... i forgot that changelog has the latest at the top not bottom >_<
<jscinoz> *facepalm*
<LaserJock> jscinoz: doh :-)
<jscinoz> le sigh
<Iulian> G'morning.
<coolbhavi> When does next development cycle begin...?
<LaserJock> once Hardy is released
<coolbhavi> Probable date of hardy release?
<Iulian> coolbhavi: https://wiki.ubuntu.com/HardyReleaseSchedule
<coolbhavi> Thanks
<ScottK> superm1: If you're around, please have a look at my comment on your libmime-lite upload bug...
<superm1> yeah i am
<superm1> ScottK, have the bug number handy?
<ScottK> Bug #197192
<ubotu> Launchpad bug 197192 in mythbuntu "8.04-alpha2 installs bad mail config" [Undecided,Fix committed] https://launchpad.net/bugs/197192
<superm1> whew.  that's not cool
<superm1> okay i'll get this taken care of further
<superm1> (tomorrow morning that is)
<ScottK> Sure.  The bug was just filed against a later version, but I think we ought to make sure ...
<superm1> thanks for looking further into it.  did you have a particular interest in mime lite, or just that efficient :)?
<ScottK> I just say it on -changes and got to wondering why it would have been a dependency.
<superm1> ah
<ScottK> Usually stuff is in depends for a reason ...
<superm1> well i sent an email to the debian maintainer to ask about it a few days ago
<superm1> and he hadn't responded
<superm1> in any case, g'night :)
<ScottK> It took just a minute to see what was in BTS...
<ScottK> Good night.
<hellboy195> DktrKranz: yeah starplot got synced but it never build. Despite that I have to omit previous changelog entries. ?
<DktrKranz> hellboy195, make a new debdiff on top of the synced version or the one in Debian (since they have a newer one)
<hellboy195> DktrKranz: well my merge is about the new one ;) But I'll make a new debdiff
<hellboy195> DktrKranz: btw, thanks for correcting the lufs changelog xD and thank you for looking at my stuff ^^
<DktrKranz> you're welcome
<bobbo> If im bumping DH_COMPAT to version 6 what version of debhelper should the build-deps require?
<HighNo> >=6 i believe
<james_w> yup
<bobbo> ah thanks, didnt know it was that simple
<james_w> you do find some islands of simplicity from time to time :-)
<RainCT> Hi
<persia> RainCT: Hey.
<Iulian> Hello RainCT
<persia> Anyone bored and want to process some updates?
<RainCT> bobbo: better to use compat level 4 or 5 if you don't need the features from 6 (see 'man debhelper')
 * persia has a menu available: maintainer mangling, NBS issues, FTBFS issues, user-supplied patches, outdated menu files, and more
<RainCT> bobbo: and sorry for not looking at it yesterday :)
<RainCT> heh
<RainCT> persia: well, give me some URL
<persia> RainCT: Any preference for type of work?
<persia> http://tinyurl.com/2stsyf has user-submitted patches
<jpatrick> bobbo: I recommend using a debian/compat file instead of DH_COMPAT
<persia> `wget -O - http://archive.ubuntu.com/ubuntu/dists/hardy/universe/source/Sources.gz| gunzip | grep-dctrl -sPackage,Maintainer -FVersion ubuntu  | grep-dctrl -sPackage -FMaintainer -v -n ubuntu | sort -u` need maintainer mangling
<RainCT> jpatrick: how can I open a URL from konsole without having to copy it?
<persia> http://people.ubuntu.com/~ubuntu-archive/NBS/ has NBS stuff.
 * RainCT wonders what NBS is :)
<persia> Not-Built-from-Source
<persia> Essentially, some binary package names change for certain types of transitions.
<HighNo> RainCT: gnome-open url
<jpatrick> RainCT: that feature is only in konsole-kde4
<persia> As a result, packages that depend on those binary packages cannot be installed.
<RainCT> HighNo: I said without copying it..
<HighNo> doh, kde - hmmm
<HighNo> RainCT: KDE, right? I am a GNOME guy, urls are always clickable there...
<persia> Frequently, a rebuild will cause a selection of new binary dependencies, and the package will work (although sometimes one needs to adjust debian/control, and more rarely, one needs to port the package to work with the new system)
<persia> HighNo: Not always yet.  Would you like to help finish the migration to GTK+2?
<RainCT> HighNo: I use GNOME too, but I switched to irssi now and want to have a hideable terminal, so I'm using yakuake.. (don't like tilda)
<HighNo> RainCT: I think you could use some kind of strange scripting involving grep http /dev/pts/X ... :-)
<HighNo> persia: hm, how could I help there?
<RainCT> persia: allright, I'll look at some.. Thanks :)
<Iulian> HighNo: Great question :-)
<HighNo> :-) well, ok - how can I help there?
<persia> HighNo: `apt-cache rdepends libgtk1.2` run against a Hardy apt-cache provides a quick&dirty list of applications that need to be reviewed for porting, removal, etc.
<HighNo> persia: would that involve installing hardy first?
<persia> Debian is working on getting this done for lenny, so there may be patches available from Debian for some of them.
<mok0> New upstream version 2.4.0 of pidgin yesterday
<persia> HighNo: No, just having a hardy apt-cache.  You could use a chroot, or generate a hardy apt-cache in a temporary directory (by passing the appropriate apt configuration options).
<persia> Alternately, download a hardy packages file, and use grep-dctrl.
<Iulian> persia: And what exactly should we do with that list of packages?
<HighNo> persia: ok, I think I still have a pbuilder hardy environment flying around somewhere so I guess that I could do that...
 * Iulian hides behind HighNo 
<HighNo> persia: errm: apt-cache rdepends libgtk1.2 -> W: Unable to locate package libgtk1.2
<HighNo> args, have to setup universe too
<persia> HighNo: Yep.  It's MOTU stuff :)  Anyway, if you don't want a chroot, http://paste.ubuntu.com/5159/ might help.
<HighNo> that's too late now - pbuilder login still works...
<persia> (except I forgot a bunch of '$' characters before "USER")
<hellboy195> mok0: pidgin 2.4, nexuiz 2.4 , gimp 2.4.5 ,.. :)
<HighNo> persia: ok, that's a hell of a list
<HighNo> persia: so what would be the next step?
<mok0> hellboy195: wow
<hellboy195> mok0: and all were released yesterday ^^
<persia> Iulian: The idea would be to make them not depend on libgtk1.2.  The mechanism for doing so depends on the package.
<mok0> hellboy195: ah, of course, 29.2 :-)
<Iulian> persia: Ohh, right.
<HighNo> persia: so we are into patching the sources, right?
<persia> HighNo: Pick a package.  Check Debian to see if there is a patch available.  Check upstream to see if there is a patch available.  If either is the case, apply and test the patch.  If it works cleanly, submit a debdiff.
<persia> If neither is the case, patch the source, and send upstream and to Debian.
<hellboy195> mok0: what do you find. how many will get into hardy?
<persia> Note that the patches have to be small to get in past BetaFreeze, so what doesn't get done this week should be pushed upstream and to Debian so that it doesn't have to be done next cycle.
<mok0> hellboy195: 0 :-(
<hellboy195> mok0: no FFE candidates?
<mok0> Don't know... from what it looks, pidgin 2.4 fixes a lot of bugs
<mok0> Don't know if that's true of the others
<hellboy195> we'll see
<mok0> ... but they will tell us to wait for the Debian update
<thp> I've submitted an updated .dsc and .diff.gz for gPodder 0.10.4 in Hardy, can someone please upload the new package? https://bugs.launchpad.net/ubuntu/+source/gpodder/+bug/197256
<ubotu> Launchpad bug 197256 in gpodder "gpodder crashed with TypeError in show_message()" [Undecided,New]
<persia> For pidgin, check in #ubuntu-desktop.  It might be fairly easy to get both updated, if it is indeed only bugfixes.
<RainCT> persia: I think I didn't really understand that FBS stuff.. Both installing packages from that list and installing packaging depending on packages in that list works..
<persia> thp: Just as a note, the .dsc doesn't help for sponsoring.  Also, for updates that are not new upstream versions, a debdiff against the current package is preferred for review.
<HighNo> persia: what if packages are like VERY old - I picked gman and it shows the last update is 2006 and had very low changes, being updated 2001 the last time with new features
<persia> thp: Also, you'll want to subscribe ubuntu-universe-sponsors to request the upload.  It may be worth reviewing https://wiki.ubuntu.com/MOTU/Contributing.
<persia> HighNo: Then you likely don't have much competition for the patch development :)
<HighNo> persia: hehe
<persia> RainCT: Would you like to walk through an NBS check together as an example?
<thp> persia: so, I should add the debdiff of the two .dsc files to the bug report?
<persia> thp: Please, and subscribe the sponsors queue.
<RainCT> persia: if you have time, sure :)
<persia> RainCT: Sure.  Essentially, everything currently works because the outdated binary packages haven't been removed yet (to avoid breakage).  Once everything is confirmed as ported, the binaries no longer built from source can be removed from the archive, making everything cleaner.
 * persia looks for a good example
<persia> OK.  Let's look at libmpich1.0c2
<thp> thanks, bye
<persia> The current source package for mpich builds a library called libmpich1.0ldbl instead of libmpich1.0c2, for the long-double transition.
<persia> Looking at http://people.ubuntu.com/~ubuntu-archive/NBS/libmpich1.0c2 we can see the reverse dependencies for the outdated libmpich1.0c2 for each supported architecture.
<persia> In this case, we have three binary packages to inspect: illuminator-demo, libluminate7, and libpetsc2.3.2
<HighNo> persia: I found aria being abandoned for aria2 which is ok regarding GTK use - should I patch it?
<persia> Looking at a hardy cache, we can discover that those come from two sources: illuminator and petsc
<persia> HighNo: Do we have aria2 in the archives?  That might be a big change to do after FeatureFreeze.  Would it require a freeze exception?
<persia> RainCT: Are you with me so far?
<RainCT> persia: Yes :).
<HighNo> persia: aria2 is in universe
<persia> HighNo: Is there a good reason to have both aria and aria2?
<RainCT> persia: I downloaded illuminator's source (the other one will take some time)
<persia> RainCT: No rush.  Take a look at the binary packages generated by the current petsc source.  What do you see?
 * persia is a huge fan of apt-cache, if this hasn't become clear already
<HighNo> persia: hm, aria has a GUI, aria2 has not but otherwise superceeds aria in functionality
<mok0> I need to find to what source package a file "netkit-inetd.prerm" belongs from feisty. How can I do that?
<HighNo> persia: aria2 is actively developed
<mok0> (I don't have a running feisty system)
<persia> mok0: chroot or alternate apt-cache.  http://paste.ubuntu.com/5159/ was a little snippet I threw up earlier to give hints on generating alternate apt caches.
<persia> mok0: Anyway, any file in /var/lib/dpkg/info/ is always of the form $(binary-package).$(function)
<mok0> persia: thanks!!
<persia> RainCT: hint: `apt-cache showsrc petsc`
<RainCT> persia: yep, got that
<RainCT> libpetsc2.3.3-dbg, libpetsc2.3.3-dev, petsc-dev, petsc2.3.3-doc, libpetsc2.3.3
<persia> OK.  Our reverse dependency is libpetsc2.3.2, which means we don't really care, as the new source doesn't use it, but we need to NBS libpetsc2.3.2 before we can NBS libmpich1.0c2
<persia> (so you can stop the huge download)
<persia> Next step is to inspect the current binary packages to see if they have alternatives defined in the dependencies.  I typically use aptitude for that, but other tools work as well.
<persia> In this case, there are hard-dependencies for libmpich1.0c2 for both illuminator-demo and libluuminate7.
<persia> Next thing to try is a rebuild.  Update the changelog with a 0.10.0-4build1 entry, reporting the transition you are processing, don't touch any other files in the package, generate a new source candidate, and try a test build.
<persia> mok0: Oh, also, the feisty Contents.gz file ought be available for download, and can be processed by grep if you want a more specific solution :)
<persia> RainCT: Still with me?
<RainCT> persia: yes, rebuilding
<persia> RainCT: While that rebuild is happening, let's take a look at the libpetsc2.3.2 NBS list, just to start researching the recursion.
<RainCT> persia: it lists the same packages (illuminator-demo and libluminate7)
<persia> RainCT: Excellent.  You might want to mention both transitions in the changelog then.
<RainCT> persia: Did so. Is the changelog entry OK like this: "Rebuild for transition to new libmpich and libpetsc versions."?
<persia> I like to state the specific versions (e.g. rebuild for libmpich1.0c2 -> libmpich1.0ldbl and libpetsc2.3.2 -> libpetsc2.3.3) just to make it clear that the specific transition is already complete (helps when there are a lot of transitions happening).
 * persia wishes build-depending on tex didn't run mktexlsr so many times
<RainCT> persia: pbuilder is downloading 171MB and ETA is 3h -.-
<persia> RainCT: Are you still using your phone?  I thought you had arranged an alternate connection.  You might consider a local mirror (if you have disk space available): that way you only have to download things when they are updated.
<HighNo> persia: what if packages have a debian bug filed: xxx: should this package be removed ?
<HighNo> persia: like array-util has
<persia> HighNo: A package removal bug?
<RainCT> persia: Yes, we tried ADSL with two different providers and none worked... :(
<HighNo> persia: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456648
<ubotu> Debian bug 456648 in array-util "array-util: should this package be removed?" [Important,Open]
<persia> RainCT: Anyway, the build failed for me: http://paste.ubuntu.com/5160/
<persia> Next step is to track down the FTBFS issue, port illumintator to the new PetSC, and upload it.
<persia> HighNo: At this point, that's only a request for the Maintainer to consider removal, rather than a request for removal.
<persia> As a result, it's likely premature to remove it from Ubuntu (unless you expect to fix all the other packages first).
<persia> Maybe the next one will be easier to handle...
<HighNo> persia: too bad, I hoped I could at least drop that one...
 * RainCT is away for a moment
<persia> HighNo: There are generally three reasons we drop packages: 1) Dropped from Debian and nobody wants to save it in Ubuntu, 2) Hopelessly buggy and replaced by a clear better alternative, and 3) Ubuntu has a different package from the same upstream source.
<persia> aria doesn't fall under #1 or #3, so you'd have to apply for #2.
<persia> The part that makes me unsure is you say aria2 doesn't have a GUI.  Maybe you can find another replacement, but otherwise removal would be a regression.
<persia> Regressions of this type are sometimes acceptable, but it only makes sense to request an exception if we are removing libgtk1.2.  Until the list of reverse dependencies is smaller, better to concentrate on cases where the replacement is more glaringly obvious.
<mok0> persia: I need a bit of help resolving a bug, do you have time?
<persia> mok0: A little, but I'm for bed soon.  Which bug?
<mok0> 120080
<mok0> bug 120080
<persia> bug #120080
<ubotu> Launchpad bug 120080 in netkit-base "dpkg refuses to uninstall netkit-inetd due to script error" [Undecided,New] https://launchpad.net/bugs/120080
<mok0> I've found the problem, but I'm surprised it's still around
<mok0> also look at bug 27385
<ubotu> Launchpad bug 27385 in netkit-base "invoke-rc.d should be used" [High,Fix released] https://launchpad.net/bugs/27385
<persia> Not calling update-rc.d properly?
 * RainCT is back
<mok0> In netkit-inetd.prerm it just calls /etc/init.d/inetd stop, but that fails if that script is not there
<mok0> persia: I assume update-rc.d is more robust
<mok0> persia: so it wont fail on a missing script
<persia> No, for this it likely wants invoke-rc.d inetd stop
<HighNo> mok0: that script is part of netkit-inetd and so it should be there
<mok0> persia: exactly. But 27385 claims the problem was solved in dapper
<persia> HighNo: Not necessarily at postrm time
<HighNo> mok0: or am I missing something
<HighNo> mok0: that's way it is called .prerm right=
<persia> mok0: TO me it looks like Uekawa-san's patch only handled start and restart, but not stop.
<mok0> HighNo: I can't explain the circumstances, but it sometimes fails
<mok0> persia: the right construction should be added by dh_installinit
<mok0> persia: perhaps I should just get rid of the prerm file and let dh_installinit handle it? (It's commented out in rules)
<persia> mok0: heh.  That would be one way to solve it (and stops me from digging further into the installinit source to find out why it was generating inconsistent behaviour)
<persia> Just be sure to compare the autogenerated maintainer scripts with the manually generated ones.  There may be some reason why it needs to be special.
<mok0> persia: I'll try it. And also see if it's been fixed later
<mok0> persia: working on clearing out my own bug submissions from when I was a n00b :-)
<mok0> ... now I'm a n11b
<persia> mok0: That's a good plan.  I started that once, but ended up getting distracted by trying to close all the bugs in the packages I had uploaded and get most of my diffs back to Debian and upstream, which led to more distractions...
<persia> Closing one's own bugs early and often is definitely ideal.
<mok0> persia: the distraction bit... I've been there...
<mok0> If you generate more bugs than you solve... that's not good
<persia> Depends.  I've been doing that a lot in hardy (although I've been trying to get lists of potential bugs, rather than filing bugs), and I think it has led to a lot of fixes.
<persia> The main rule being that if you are generating a lot of bugs, be sure to also describe how to fix them, and call for volunteers to help fix them.
<mok0> persia: heh, that's a good plan
<persia> (a good example would be the libgtk1.2 transition HighNo is looking at: we could file 300 bugs, but better to just have someone with some interest start investigating and proactively fixing them in advance)
<mok0> my early bug descriptions actually did not contain enough inofrmation
<persia> mok0: Ah.  Yes, generating lots if insufficiently triaged bugs is not as ideal :)(
<mok0> Learning by doing is the way to go here.
<mok0> And I can't leave my old incomplete bug submissions for others
<persia> Yep.  Of course sometimes one gets bugs that one cannot solve yet.  In these cases, best to file with as much information as possible, in the hopes it will be easy for someone else, and then work on things one can do, to make sure others have time for the hard ones (we all have different definitions of "hard")
<mok0> Well, thanks for your help, persia. Don't let me keep you from getting your rest
<persia> mok0: Thanks for chasing it.  Maintainer script failures are currently one of the things we have trouble detecting, and they are painfully visible to users (and appear to have trivial fixes), so it's important work.
<mok0> persia: my pleasure :)
<RainCT> persia: when a from the NBS list has no reverse dependencies anymore, is it removed automatically?
<RainCT> *when a package
<james_w> I'm working on https://bugs.launchpad.net/ubuntu/+source/startupmanager/+bug/195028 and I have no idea how those files got there. I would like to add an rm call to the preinst of the package, would that be a good solution?
<james_w> I suppose if the user uninstalled the package before upgrading to this proposed version it wouldn't help.
<ubotu> Launchpad bug 195028 in startupmanager "Upgrade bug gutsy to hardy (python errors)" [Undecided,New]
<persia> RainCT: autonomously, but not automatically.  pitti checks every once in a while, but always appreciates when someone reports that a transition is complete in #ubuntu-devel.
<warp10> persia: since I was away, I skimmed the log and read your "lesson" about NBS. Our wiki has 0 pages regarding this argument. What about opening a new page and copying the log there?
<RainCT> I can't debuild package swscanner even with build dependencies installed... I already found one which was missing, but now it complains about KDE headers not being installed; what package do I need for those, kdelibs-dev?
<RainCT> Iulian: Your patch on bug #196871 won't install the .desktop file; dh_desktop only registers it (you have to install it manually, with dh_install or whatever).
<ubotu> Launchpad bug 196871 in zblast "No .desktop file; here is one" [Wishlist,In progress] https://launchpad.net/bugs/196871
<james_w> warp10: good call.
<RainCT> Iulian: also, I think that dh_desktop should be in the binary-arch target (but I'm not really sure as I always work with cdbs)
<RainCT> Iulian: and if you update the Debian policy version please also move the Homepage to the source stanza
<HighNo> persia: I'm kind of stock. I patched cccd so far and it seems to compile build doesn't link. I don't know what to change -lgtk to in the linker command
<HighNo> brb
<HighNo> ahh, got it
<HighNo> hm, anyone - I am no c pro. what about an error like cccd.c: (.text+0x126a): undefined reference to `gtk_tooltips_set_colors' , is that a missing linker directive?
<mok0> HighNo: yes
<HighNo> mok0: could you try to help me with that one?
<mok0> HighNo: I can try :-)
<HighNo> mok0: makefile has this entry (now) LDFLAGS = -L/usr/lib `pkg-config --libs gtk+-2.0` which I thought should include everything needed
<mok0> HighNo: most likely, you are linking to a version of the library where that function is not in -- either has been removed/renamed or does not yet exist
<HighNo> mok0: so I am compiling against a correct one but linking against a wrong one?
<mok0> HighNo: Hmm
<HighNo> mok0: just for the records:  CFLAGS = -O2 -Wall `pkg-config --cflags gtk+-2.0`
<mok0> HighNo: It could also be a local function of the program that is n not gettting linked in
<mok0> HighNo: try grepping the source for it
<mok0> HighNo: it could also be mis-spelt
<HighNo> mok0: I just googled a bit more and found that it seems to be deprecated and not to be used in gtk+2...
<mok0> HighNo: Ah. Then you need to figure out what has replaced it
<mok0> HighNo: ... but you know that
<HighNo> mok0: funny thing is that I think it compiled - it should not do that  right?
<mok0> HighNo: depends on what you mean "compiled"
<mok0> the compile will not discover that this routine is not included in the gtk library
<mok0> only the linker
<mok0> HighNo: It seems you can safely remove the call to gtk_tooltips_set_colors since it appears to not do anything
<HighNo> mok0: hehe, read the same thing just a few secs ago...
<mok0> HighNo: then it must be correct :-)
<mok0> HighNo: you know what to do now, right?
<HighNo> da**, is archive.ubuntu.com down again?
<HighNo> hm, seems to be ok again, must have been a local issue...
<HighNo> I need someone to test that package now - I don't have a cd drive :-)
<HighNo> mok0: persia: probably the funniest problem: I can't test the new package. It starts and acts exactly like the old version but that means it hangs after the start because I don't have a cdrom and it is a cd player package :-)
<mok0> HighNo: I haven't followed the discussion... was this the bug you were trying to fix?
<HighNo> mok0: moving from gtk1.2 to gtk2
<mok0> HighNo: Ah.
<mok0> HighNo: I guess the program should  just abort with a message
<HighNo> I hope disk space will be enough for a vm to test it there. sure it would be nice to test it by someone with a real cd drive...
<mok0> HighNo: the developers didn't think of a situation with anyone foolish enough to run a cd player program on a machine without a cd device
<HighNo> mok0: that's true but Ia m not the one to integrate that error message
<mok0> HighNo: perhaps you should report it as a bug upstream, though
<HighNo> mok0: last change was 2006 - I don't think it is in active development :-)
<mok0> There isn't yet a "Hardware-Depends:" option in debian/control
<HighNo> hehe
<mok0> HighNo: I can't test it for you either, my machine at home is dead
<ScottK2> Uses gtk1.2 pretty much == not under active development.
<HighNo> :-)
<HighNo> ok, I have a running package now, what should I do exactly to create the debdiff and where should I put it? Package is cccd
<HighNo> (And do I need to add anything to any copyright/control/changelog file?)
<HighNo> persia: please let me know what to do
<soc> hi RainCT
<RainCT> soc: hi :)
<soc> just downloading BloGTK ...
<soc> your changelog is impressive :-)
<RainCT> heh
<RainCT> if it has to be maintained in Ubuntu at least let's have a nice package :)
<bobbo> A package depends on libgtk1.2-dev and wont build in pbuilder, what should i replace libgtk1.2-dev with?
 * RainCT is starting to hate telepathy and mono :D
<HighNo> RainCT: that changelog is almost like a 'what to do to package your stuff' wow- every step...was it more work than the actual change? :-)
<HighNo> bobbo: I'm just working on those things - use libgtk2.0-dev
<HighNo> bobbo: you will likely have to change the source and makefiles too
<bobbo> HighNo; thanks, will try that out
<RainCT> HighNo: heh Might be :P. I'm wondering wheter a "* Repackage this." entry wouldn't have been better :P
 * RainCT is thinking about leaving packaging for today..
<RainCT> everything I try to build is failing lol
<soc> RainCT: is there a guide somwhere, how to do packaging right?
<soc> btw, will pidgin 2.4 get into hardy, or is it to late ?
<RainCT> !packagingguide
<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
<jdong> no
<jdong> BAD NEXUIZ
<jdong> the watchfile now somehow downloads the binary.
<jdong> which left me very confused
<soc> thx
<bobbo> Does anyone know if a package that build-deps on libgtk1.2-dev will build for Hardy?
<geser> it should
<RainCT> bobbo: libgtk1.2-dev is still available in Hardy, so yes, if there isn't any problem with it it should build
 * bobbo thanks god
<geser> bobbo: what error did you get from your pbuilder?
<bobbo> geser; http://pastebin.ubuntu.com/5166/
<jdong> top
<HighNo> geser: I think libgtk1.2 support in hardy is to be dropped? persia lets me work through all old packages and recompile/patch them to be gtk2
<HighNo> RainCT: then why am I doing this stupidious work? :-)
<jdong> HighNo: because gtk2 is twice as good
<HighNo> now that's a reason :-)
<bobbo> HighNo; if you are patching 'gpppon' any time soon i have a whole load of other fixes for it that wont build without gtk2
<HighNo> bobbo - I can take that as my next one - no guarantee it works though...
<geser> HighNo: oh, but I guess it's not that easy as Debian would have already done it, gtk1 -> gtk2 needs porting
<HighNo> anybody help me please woth getting the correct debdiff done?
<geser> HighNo: where got you stuck?
<RainCT> HighNo: lol yes, because gtk2 is better and because it would be good to removed it somewhen soon
<HighNo> geser: I made the following steps: apt-get source cccd, modified it where needed, it compiles and builds now. which files in debian should I touch in addition to my change and should I make a patch from it and where should I put it?
<RainCT> HighNo: add a new changelog entry with  dch -D hardy -i
<RainCT> (you'll need to export DEBFULLNAME and DEBEMAIL for this to work)
<geser> HighNo: dch -i (comment your changes), debuild -S
<HighNo> RainCT: what should be in that entry exactly
<HighNo> RainCT: ok, keep going
<RainCT> HighNo: explain briefly what you changed
<RainCT> HighNo: once you have added the changelog entry  debuild -S  as geser just said
<RainCT> HighNo: then  cd ..  , download the source from Hardy again (.dsc and .diff.gz) as you probably have overwritten them
<RainCT> HighNo: and then run:  debdiff packagename_oldversion.dsc packagename_newversion.dsc > packagename_newversion.debdiff
<RainCT> HighNo: and check that everything ending up in packagename_newversion.debdiff was changed by you; if there are other changes you'll need to filter them out
<bobbo> RainCT; You can unsubscribe yourself from Bug #196870 if you want as nothing can be done until it is ported to GTK2
<ubotu> Launchpad bug 196870 in gpppon "No .desktop file for gpppon" [Low,In progress] https://launchpad.net/bugs/196870
<RainCT> HighNo: ah, if the previous version didn't end with "ubuntuX" you'll have to run "update-maintainer" (from package ubuntu-dev-tools) before debuild -S
<RainCT> HighNo: ok, and after you have the .debdiff file just attach it to your bug report and subscribe ubuntu-universe-sponsors
<soc> HighNo: doesn't gftp use gtk1?
<RainCT> soc: no, gtk2
<HighNo> sorry, busy doing the dch entry - now done with that.
<HighNo> soc: RainCT is right, it's not on my list
<soc> ah ok ..
<soc> i always thought, because it's such a pita usability-wise
<RainCT> soc: on that I agree
<RainCT> soc: I switched to sftp (command line) because of gftp :P
<HighNo> apart from my problems - some people tend to have a wiki based homepage - would they put it on wiki.ubuntu.com? cause I did (as I have found others to do it too) and on every change I get the note of a change notice sent to dholbach & co... that does not sound ok. Yes, I have used TemplateHomepage
<RainCT> bobbo: gtk1.2 is still in hardy, theoretically gpppon should build
<bobbo> RainCT; so the build farms will build it just pbuilder wont?
<RainCT> HighNo: that's normal, they are subscribed to the entire wiki
<RainCT> HighNo: probably with some fake mail because that has to be a lot of SPAM :/
<RainCT> bobbo: ah, it fails in pbuilder?
 * RainCT checks the backlog
<bobbo> RainCT; yeah http://pastebin.ubuntu.com/5166/
<RainCT> apt-cache should really have a -t option..
<RainCT> bobbo: strange..
<RainCT> well, I'm away for a while..
<bobbo> bye
<lorenzo> I have created a package and need docs or other info on how to get it into Universe. I'm new to the process and need a starting point.
<HighNo> geser: so I have to create the bug report myself?
<HighNo> bobbo: do you have a .desktop file to gpppon?
<HighNo> bobbo: I could include it into the patch
<bobbo> HighNo; yeah ive got a pile of other patches aswell
<geser> HighNo: yes, if no one exists
<bobbo> Hattory; i had to bump DH_COMPAT etc. for dh_desktop to work
<bobbo> sorry i meant HighNo,
<Hattory> ;)
<HighNo> bobbo: I have patched gpppon for gtk2.0 and it works
<bobbo> HighNo; Do you want me to send you all the changes i have so far?
<HighNo> geser: could you guide me through my first bug report for this then?
<bobbo> or do you want to send your changes here as i have a pile of other fixes i could do as Lintian is having a field day on this package
<HighNo> bobbo: sounds good
<HighNo> I'll make a debdiff for it and send it to you
<geser> HighNo: there are no requirements how the bug should look like
<bobbo> HighNo; thanks :)
<HighNo> bobbo: I'll leave the maintainer-change to you
<bobbo> HighNo; yeah ive already got that my end
<bobbo> HighNo; pastebin it ;)
<HighNo> true
<HighNo> forgot about it
<HighNo> bobbo: http://pastebin.com/d6a72a809
<bobbo> HighNo; brilliant thanks
<HighNo> geser: what should I change bug status to?
<HighNo> geser: the patch is already attached and uus is subscribed
<geser> HighNo: to "Confirmed" according to https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue
<HighNo> geser: assign it to me?
<geser> Assign to "nobody"
<HighNo> geser: can you check LP #197358 please. If that is ok I can do it that way for the other packages too
<ubotu> Launchpad bug 197358 in cccd "patch for use of gtk2.0" [Undecided,Confirmed] https://launchpad.net/bugs/197358
<bobbo> HighNo; thanks for that gtk2 patch for gpppon. https://bugs.edge.launchpad.net/ubuntu/+source/gpppon/+bug/196870/comments/7 <-- Changelog/Final debdiff for it
<ubotu> Launchpad bug 196870 in gpppon "No .desktop file for gpppon" [Low,In progress]
<geser> HighNo: almost correct: the version is wrong and the maintainer changes seems to be missing
<geser> HighNo: -XbuildY is only used for no-change rebuild but as you added changes the version should be -6ubuntu1
<HighNo> geser: hm, can you do that on your own or would I have to change that in the debdiff again?
<geser> depends on the sponsor of your bug
<bobbo> I know its a bit off topic but do any MOTU's know how big (in gigabytes) Universe is?
<HighNo> bobbo: just download every package and count :-)
<bobbo> HighNo; if only i had a good internet connection
<mok0> bobbo: That information might be on Ubuntu's "want to mirror" page
<HighNo> bobbo: honestly - there are different ways to count. universe is also an archive for older versions so it is much bigger than the size of all installed versions of e.g. hardy
<bobbo> mok0; genius, Edgy Eft was 25gb, thought it would be larger
<mok0> bobbo: ok. I estimate hardy would be > 25% larger
<HighNo> "At this writing, the Ubuntu Archive takes up about 215 GB of space." -> https://help.ubuntu.com/community/Rsyncmirror
<bobbo> wow
<HighNo> that was when feisty was newest
<mok0> Still well within a smallish disk :-)
<HighNo> mok0: I am surprised too
<bobbo> i was thinking of trying it on a 100gb disk i run my Hardy partition off, thank god i didnt start it
<mok0> But that includes binaries for several archs
<mok0> bobbo: The sources would likely fit on that disk
 * bobbo might give it a go if he gets a better Internet connection
<HighNo> hm, it might be enough if debmirror is used. that one only mirrors the hardy packages
<mok0> bobbo: what is the purpose of mirroring?
<HighNo> The page reads funny as it seems to be the most normal thing in the world to have a mirror... :-)
<bobbo> mok0; to see what would happen really :)
<Nafallo> ehrm
<mok0> bobbo: hehe. You'd get a huge bill from your ISP
<Nafallo> I can tell you what would happen :-P
<bobbo> Nafallo; you tried it?
<Nafallo> bobbo: you would get local copies of the entire space you mirror.
<Nafallo> I thinks that's pretty obvious actually :-)
<bobbo> someone suggested it on Ubuntuforums, was just curious :)
 * mok0 finds that there are so many mirrors it's not worth the bother
<Nafallo> mok0: not true :-)
<Nafallo> mok0: people with 200 servers in the network would benefit from a local server :-)
<mok0> Nafallo: depends where you are, perhaps
<Nafallo> one machine pulling at the transit instead of all of them
<mok0> Nafallo: true. I don't think bobbo has 200 local installations
<Nafallo> apparently not :-)
<Nafallo> I was responding to the 'not worth the bother' part ;-)
<mok0> Hmm. Perhaps there is a need for a "cache" like system, where you could set up at local "cache"
<mok0> The cache server would just keep a copy of requested packages, not the whole caboodle
<Nafallo> that would work as well.
<RainCT> hi again
<Nafallo> hi RainCT
<RainCT> bobbo: hm.. why does gpppon need a .desktop file if it's an applet?
<RainCT> or is the description wrong?
<hellboy195> hoi jono :)
<jono> hey hellboy195
<vorian_> nope
<AnAnt> man-di: hello
<Iulian> RainCT: Sorry, I was afk, I'm looking to it right now.
<Iulian> Thanks
<man-di> AnAnt: contentless ping...
<AnAnt> man-di: oh,
<AnAnt> man-di: I remember some months ago you said you're going to do icedtea package for Debian
<AnAnt> man-di: I wonder what happened
<man-di> AnAnt: in the works
<AnAnt> man-di: I see
<AnAnt> man-di: couldn't the Ubuntu package be used for Debian ?
<man-di> AnAnt: was uploaded, got rejected with some requests from FTP-MAster and these are not all solved yet.
<AnAnt> oh ic
<man-di> AnAnt: This was the Ubuntu package
<AnAnt> ok
<AnAnt> man-di: can I help ?
<man-di> AnAnt: if you can tell me why that package doesnt build on debian sid currently...
<AnAnt> man-di: did you get build log ?
<man-di> AnAnt: libgcj.so not found because gcc is 4.2 and gcj is 4.3 on Debian
<AnAnt> i see
<AnAnt> so you are waiting till gcc becomes 4.3 in sid
<AnAnt> ok, later
<man-di> I would have answered 'no' ...
<persia> HIghNo: Sorry.  Sleeping.  Looks like you got your help.  libgtk1.2 removal won't be finished for hardy, but work towards that goal, and patches uploaded and sent to Debian will be very helpful towards making things look nice (and dropping libgtk1.2 later).
<persia> warp10: Putting an NBS guide on the wiki is an excellent idea.  Would you mind drafting it?  I'm happy to review.
<persia> man-di: Just for fun, icedtea FTBFS in Ubuntu for i386 in a recent test :)
<man-di> persia: do you have a link to the build log?
<warp10> persia: What about MOTU/School/NBS ?
<HighNo> persia: ok, will try to keep on. will be a longer run though. about 180 packages to do
<persia> warp10: It's not officially MOTU/School, but I'm happy with that if james_w agrees.
<james_w> persia: I don't really mind, but I don't think it's the right place, how about packaging guide, or processes doc?
<persia> HighNo: Yep.  It's a huge bit of work.  From what I understand, Debian hopes to finish it by June or July, so you might expect more people chasing it soon.  Just be sure to get things pushed back and forth with Debian to avoid duplicate effort.  Also, sending patches to upstream MLs or bugtrackers (even when upstream is dead) is a good way to share your patches with any other distribution that might also want to make the change.
<james_w> or just /NBS perhaps? Or MOTU/NBS?
<james_w> I don't think it matters too much, just get it down somewhere and start linking.
<warp10> MOTU/NBS should be fine too
<persia> james_w: I don't think the packaging guide is the right place, as it's local process.  Maybe somewhere in processes.  Also, it needs doing for both main and universe, so I'm reluctant to use MOTU/
<hellboy195> persia: hi, I'm currently merging new gaphor revision from debian. now I discovered a bug report from 2007-09-24 where somebody complains that gaphor depends on zope3 because that slows down everything.  bug #144377 . That has been ignored so far. Should I take care about it or not?
<persia> (and yes, starting anywhere is good, and we can put it in the right place later)
<ubotu> Launchpad bug 144377 in gaphor "gaphor depends on zope3" [Wishlist,Confirmed] https://launchpad.net/bugs/144377
<persia> hellboy195: No.  The new upstream doesn't do that cleanly, and it would be new feature, so you can hide behind FeatureFreeze.
<hellboy195> persia: good. thank you :)
<warp10> persia, james_w: ok, I will open MOTU/NBS, we will choose a better place later
<HighNo> persia: geser mentioned on the first one I finished that I should change the maintainer. That could be done by simply running update-maintainer?
<persia> Also, the Debian really-avoid-cheeseshop patch is better than mine.  The only outstanding change should be to force the use of python2.4 in all cases (assuming zope3 still uses python2.4).
<RainCT> warp10: what's about https://wiki.ubuntu.com/PackagingGuide/Howtos/
<persia> HighNo: I believe so, although I always just paste "Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>" manually (the string is in a small text window on my desktop)
<james_w> warp10: while I remember, it would be great to mail u-motu and -motu-mentors when you have something to get some more people working on it.
<james_w> HighNo: yeah, update-maintainer does all you need.
<james_w> HighNo: just make sure you run dch first to get a new version stanza, otherwise it goes in the one before you want.
<warp10> RainCT: well, NBS are not really related with packaging, I don't think PackagingGuide would be the right place, IMHO
<persia> RainCT: I'm not sure it's "packaging", so much as "maintenance".  I don't remember where the guide of how to generate a debdiff lives, but I would think that would be the right namespace.
<RainCT> ah yes, right
<HighNo> great. btw, where does popcon get its Maintainer from- from the package? cause it declares my package as 'unknown' which is uncool as it shoudl either be myself or motu-devs
<HighNo> james_w: thanks for the correct order
<RainCT> persia: the debdiff guide is there (well, or at least there is a debdiff guide there)
<RainCT> https://wiki.ubuntu.com/PackagingGuide/Howtos/Debdiff
<warp10> james_w: I will write an e-mail once a first draft is ready to be worked on.
 * persia fails to understand, and puts "Read the wiki" near the bottom of the TODO list
<hellboy195> persia: it's just strange that debian has python-nose as build depend and we als build-dep-indep
<hellboy195> persia: ah nvm. found the reason ^^
<james_w> warp10: thanks.
<persia> warp10: Thanks for that.  I tend to just walk through specifics, and really appreciate it when someone generates a guide.
<persia> hellboy195: It should be build-depend.  Everything but the python2.4 forcing is better in Debian (and all the interesting patches have been absorbed).
<james_w> HighNo: what package do you refer to with popcon?
<HighNo> blueproximity
<james_w> HighNo: where does Ubuntu's popcon data live?
<james_w> or rather, where can I query it?
<RainCT> james_w: popcon.ubuntu.com
<james_w> RainCT: ah, thanks, should have guessed that.
<james_w> HighNo: that is odd, I don't know why that happens.
<persia> vorian: regarding upstream releases after a FFe exception approval and before upload: I suspect this requires another FFe, but you might be able to reuse the bug.  Best ask here or by an email to ubuntu-motu@.
<ScottK> vorian: Ask again in the same bug.
<persia> ScottK: And resubscribe motu-release?
<ScottK> Yes
<persia> hellboy195: double-check, but I think the better disable_ez_install patch might make the rm -rf for .egg no longer required.
<hellboy195> persia: well debian also applied the rm -rf I think but I can't run debuild because it complains about this patch ^^
<persia> hellboy195: Odd.  I didn't think there was a new upstream, and Piotr's patches are typically perfect.  You aren't trusting MoM or anything, are you?
<bobbo> RainCT; have you have a chance to look at bug #196870 yet? HighNo ported it to GTK2 so it actually builds
<ubotu> Launchpad bug 196870 in gpppon "No .desktop file for gpppon" [Low,Confirmed] https://launchpad.net/bugs/196870
<hellboy195> persia: well trust or not. I only see http://pastebin.com/m7773dc33
<hellboy195> persia: wtf? the patches are in patches and not in patched O_O
<persia> hellboy195: Are they in series?
<RainCT> bobbo: 20:46:41 < RainCT> bobbo: hm.. why does gpppon need a .desktop file if it's an applet? or is the description wrong?
<bobbo> RainCT; never read the description of the package but its definately not an applet
<hellboy195> persia: hellboy@ubuntu:~/merges/gaphor/gaphor-0.12.5/debian/patches$ ls
<hellboy195> 00list  disable_ez_setup.dpatch  remove_shebangs.dpatch
<persia> hellboy195: Check 00list then
<RainCT> bobbo: then please fix the description
<hellboy195> persia: disable_ez_setup.dpatch *\n* remove_shebangs.dpatch
<bobbo> RainCT; ok :)
<RainCT> bobbo: beside this, good work :)
<bobbo> RainCT; thankyou
<persia> hellboy195: Very odd indeed.  Is dpatch called in debian/rules?
<hellboy195> persia: yes : include /usr/share/dpatch/dpatch.make
<persia> hellboy195: Can you paste a source build log?
<hellboy195> persia: ehm. sry. source build log?
<persia> hellboy195: You should have a foo_source.build in the parent directory after running `debuild -S -v0.12.5-1ubuntu1`.
<persia> (you were having trouble generating source, right?)
<hellboy195> persia: yeah. I pasted the log already :) http://pastebin.com/m7773dc33
<persia> hellboy195: Sorry.  Didn't see that.
<hellboy195> persia: np
<HighNo> persia: have you taken a look at my first shot? LP #197358 - just wanted to check further before going to make my process a template...
<ubotu> Launchpad bug 197358 in cccd "patch for use of gtk2.0" [Undecided,Confirmed] https://launchpad.net/bugs/197358
<POX__> hehe, "Piotr's patches are typically perfect"
 * persia defers to POX__ to debug disable_ez_setup
<hellboy195> hrhr
<POX__> hellboy195: unpack it again
<POX__> my guess: your setup.py is already patched
<HighNo> persia: I am not quite sure if I have to create my changes as a patch or just change the source (and debian stuff) and do the debdiff...
<POX__> or changed
<persia> HighNo: I'd suggest changing the description to say something about GTK1.2 being obsolete, and porting to new libraries, rather than referencing a semi-random IRC comment :)  Looking at the debdiff now.
<hellboy195> POX__: /me is checking that
<POX__> hellboy195: disable_ez_setup patch doesn't disable Eggs, it just prevents setup.py from downloading newer (but not required) setuptools
<persia> HighNo: Your patch ought have maintainer mangling for the debdiff for upload, and drop changes to changelog and control for submission to Debian.
<POX__> Egg is installed (not as normaand both systems are doing )
<POX__> err, ignore my last msg
<hellboy195> POX__: you have 100 points
<hellboy195> damn grab-merge ^^
<persia> HighNo: Regarding application of the patch in debian/patches vs. inline, I find running lsdiff -z foo.diff.gz to be the best way to determine how previous patches in the package have been done.
<POX__> so ""Piotr's patches are typically perfect" is still valid ;)
<HighNo> persia: hm, I was told to document my changes in the changelog. hmmm - now am I doing this for ubuntu in the first line or for debian, waiting for them to integrate the patch and afterwards synching it?
<hellboy195> POX__: ^^
<persia> If that doesn't provide a hint, you get to choose the patch system (although checking other packages from that maintainer to try to use their preference will make merging simpler later)
<bobbo> RainCT; Fixed the descriptions, new debdiff; http://launchpadlibrarian.net/12345384/gpppon_0.2-4ubuntu1.debdiff
<HighNo> persia: my problem is mainly that I don't know if I could break existing patches by patching the source before they do their magic...
<persia> HighNo: For any gtk1.2 -> gtk2.0, you want to generate two patches: one for Ubuntu that is a complete debdiff (including changelog and control) to be uploaded, and one for Debian that is just the required changes to the source (and be sure to send to the BTS).  There's no need to wait for the sync, but Debian QA will be lots happier if the BTS already has patches for the GTK1.2 bugs (I think the mass bug filing already happened)
<persia> HighNo: If there are existing patches, you want to patch in the same manner.  If they are in debian/patches, it is often safest to apply your patch last.
<HighNo> persia: ahh, so I can always create the debdiff and afterwards strip the parts for debian dir and send those to the debian maintainer?
<persia> hellboy195: grab-merge is a handy way to collect the sources, but MoM doesn't always know best about merging, especially when the Debian package has many of the same changes (only implemented in a superior fashion)
<HighNo> persia: hm, that leaves the question how I should work on the source. So I should run all patches first and do my work afterwards?
<persia> HighNo: Yes, except send the patch to the BTS, rather than to the maintainer.
<HighNo> BTS= Bug Tracking System?
 * HighNo admits this is a nooby question...
<hellboy195> persia: true. btw. why sometimes brings grab-merge sometimes *ubuntu*.patch which only show the new changelog entry? So I have to edit debian/control ,.. manuelly
<ScottK> HighNo: Yes
<bobbo> HighNo; yep
<persia> HighNo: If debian/patches is populated, you typically want to use cdbs-edit-patch, dpatch-edit-patch, or apply all the quilt patches before you make your patch.
<persia> hellboy195: That happens when the Ubuntu changes went back to Debian without improvement.  In those cases, you need to double check, but it is usually a sync.
<HighNo> cdbs-edit-patch will apply all prior patches, right?
<hellboy195> persia: well I had 2-3 of that merges in past ...
<ScottK> Yes
<persia> HighNo: For simple-patchsys.  I'm not sure if it works properly for other patch systems.
<persia> hellboy195: changelog only?  I don't see the point of such a merge, but maybe it's just me.
<hellboy195> persia: no I mean the autogenerated patch vom grab-merge only showed that new changelog entry. I had to do the other things manually
<persia> hellboy195: Ah.  That makes more sense.  Personally, I only use MoM as a convenient source of the common ancestor package: I've not had good experience with MoM patches.
<hellboy195> persia: me too, so I'm double checking ^^
<hellboy195> persia: argh. damn it! applying patch remove_shebangs to ./ ... failed.
<persia> hellboy195: You're working from the Debian source or the MoM source?
<hellboy195> persia: unfortunately the MoM one.
<persia> For this one, I'd just take the Debian source, force python2.4 in debian/control and debian/rules, and verify the shebangs in /usr/bin from the build.
<hellboy195> persia: yeah. nvm. I did my first 40 merges without grab-merge so this isn't a problem for me :)
<warp10> persia: https://wiki.ubuntu.com/MOTU/NBS Mostly, I have just rearranged your lession on -motu, but probably another rebuild example would be nice, maybe an easier one (this one has a double transition, not really appropriated for a new contributor)
<persia> hellboy195: That's good volume.  Thanks a lot for helping integrate all the fixes from Debian.  I'm expecting the RC list to be much smaller than usual when it gets published :)
<persia> warp10: Actually, double and triple transitions are not uncommon, especially for core libraries.  Given that tracking that down is just a couple links, I think it's better than pretending each library can be NBS'd independently.
<warp10> persia: I will work a little more on it tomorrow and send an e-mail to the lists. It's bed-time now on this side of the world :)
<hellboy195> persia: fine :) btw, bug #197425  I suppose I'm right and he not ;)
<ubotu> Launchpad bug 197425 in streamtuner "Merge streamtuner 0.99.99-11 from Debian(Unstable)" [Wishlist,Confirmed] https://launchpad.net/bugs/197425
<persia> hellboy195: For that, yes.
<RainCT> bobbo: http://paste.ubuntu.com/5175/plain/
<warp10> persia: indeed, but a very plain example could be useful to get familiarity with the topic, and then the double transition one is great to see a "real-world" transition.
<hellboy195> persia: and with that confirm thing. I learned that after I uploaded the debdiff I should set "Confirmed" and unassign me. So this was false?
<RainCT> bobbo: of those only the 2nd one is important
<persia> hellboy195: Workflow bugs are awkward.  If you open a bug you want someone else to fix, please don't confirm.  If you open a bug and supply the fix, and subscribe the sponsors, please confirm.
<bobbo> RainCT; ok, will fix later :)
<hellboy195> persia: I always set to confirmed *after* I uploaded the debdiff ...
<RainCT> bobbo: Okay. Also, I still don't like the description (if you don't mind please remove the "A" from the start, and the "small tool that is.." isn't really ideal, I'd prefer somewhat more direct).
<bobbo> RainCT; ive never been good with descriptions ;)
<RainCT> :)
<RainCT> well, good night all
<persia> warp10: Sounds reasonable.  Would you like to try to find one on the NBS page?  I'd be happy to verify it.
<persia> hellboy195: confirming after uploading the patch is good practice.  Personally, I recommend using "In-Progress" while you are working on the patch.
<HighNo> hmpf, I've learned not much so far but already forgotten half of it.... -XubuntuY - is that for the first release 0ubuntu1 or the other way around?
<RainCT> HighNo: 0ubuntu1 is the first release of a upstream version which isn't in Debian
<warp10> persia: at a first glance, http://people.ubuntu.com/~ubuntu-archive/NBS/libminc0 could be one. I'm going to bed now, so I will check more carefully tomorrow
<hellboy195> persia: well, true but mostly a merge is done in ~10 minutes
<HighNo> RainCT: thanks
<persia> warp10: That's a good example (appears to be caused by a FTBFS).  Have a good night.
<vorian> ScottK: thanks
<warp10> good night persia and all.
<HighNo> persia: if version is 0.1.3-3, should my version be 0.1.3-3ubuntu1 or 0.1.3-4ubuntu1 ?
<hellboy195> persia: I like debuild. dpkg-source: building gaphor in gaphor_0.12.5-2ubuntu1.dsc
<hellboy195> debuild: fatal error at line 1247:
<hellboy195> dpkg-source -b gaphor-0.12.5 failed
<hellboy195>   BUT I have the .dsc xD
<persia> HighNo: -3ubuntu1.  When your patch goes back to Debian, it gets merged with other things into -4, and that can be a sync.  If you upload -4ubuntu1, it needs to wait for -5.  I made that mistake once, and had to manually check a package as a merge candidate for 2 releases.
 * vorian needs to scroll up more
<vorian> thanks persia
<vorian> should be ready in a few
<persia> vorian: Thanks for chasing it.  You've been working on that bug for a while, and it didn't make sense to me to wait until it reached least-recently-touched in the queue before you were redirected.
<geser> persia: have we currently a location where we collect links to our QA tools till qa.ubuntuwire.com comes back?
<geser> I've setup the FTBFS list on an other host for now
<vorian> agreed
<hellboy195> persia: I have a .dsc, a nice looking debdiff, a built deb and /usr/bin/gaphor has a python2.4 shebang. I'm happy :)
<persia> geser: https://wiki.ubuntu.com/MOTU/TODO seems the appropriate place, but it's not currently in use.  I think Fujitsu has a DNS mirror that we could use to show the qa homepage from BZR.
<persia> hellboy195: Next question, does it work?
<hellboy195> persia: gaphor? sure :)
<persia> hellboy195: Great then.  Thanks for chasing it.
<hellboy195> persia: well, thx for your endurance and support :)
<HighNo> am I right that changes to the control file are not to be made in a patch as debuild does not see them at the right time?
<persia> HighNo: Yes.  No patch should ever update anything in debian/
 * hellboy195 is cleaning up the debdiff :)
<geser> persia: I'll add the temporary location to the TODO page
<persia> geser: This is the FTBFS report?
<TheMuso> Can anybody make sense of this mplayer FTBFs? http://www.pastebin.ca/925082
<HighNo> hm, and signing - can it be left out for creating the debdiff? I have not setup a gpg-agent and my passphrase is rather long...
<geser> persia: yes, it's now available at http://members.ping.de/~mb/buildstatus_hardy/
<persia> HighNo: Yes, you don't need to sign a debdiff
<hellboy195> persia: form 11k lines to 174. I'm loving it xD
<hellboy195> *from
<persia> geser: Have you also seen http://builder.ubuntuwire.qeuni.net:9998/dist/hardy/arch/i386?  Still 1500 or so packages to go, but includes things not yet known to LP.
<geser> persia: yes, I'm looking right now at it :) And also working on fixing the easy ones (see hardy-changes).
<persia> geser: Ah.  Excellent :)
<hellboy195> So. Here in Austria it's pretty late (geser don't work too long ;) ) Gn8 folks :)
<HighNo> hellboy195: it's no later than in Germany :-)
<hellboy195> HighNo: I know so I said to geser that he shouldn't work too long ^^
<hellboy195> nvm. gn8 :)
#ubuntu-motu 2008-03-02
<ScottK> jdong: I just did my first Debian backport.
<ScottK> ;-)
<jdong> lol
 * bobbo is about to go insane at dh_desktop
<bobbo> where should the .desktop file be when you are calling dh_desktop from debian/rules?
<ScottK> It should be wherever you tell debian/rules to find it.
<bobbo> ScottK; ah! I was just running it without any args
<bobbo> and it wasnt doing anything
<ScottK> bobbo: In general man dh_* will have some useful information for you when you run into such problems again.
<bobbo> ScottK; legend thanks
<persia> bobbo: dh_desktop doesn't install the .desktop files: you need to install them independently.
<bobbo> persia; so dh_install the desktop file to usr/share/applications then run dh_desktop?
<persia> bobbo: Exactly
<bobbo> persia; thankyou sooo much :)
<bddebian> Heya gang
<geser> Hi bddebian
<bddebian> Heya geser
<HighNo> persia: hm, how do I include patches in a debhelper style package that has no patches yet?
<persia> HighNo: Firstly, best to ask questions generally, rather than to specific people, just to speed response.  Secondly, if you're sure there are no patches (based on lsdiff -z foo.dsc), you get to pick a patch system.  I recommend checking other packages by the same maintainer to select one most likely to be adopted by Debian.
<emgent> hello people
<bddebian> Hi emgent
<HighNo> hm, what would be the ubuntu package version of glotski_0.2-5build1 ?
<StevenK>  glotski_0.2-5ubuntu1
<HighNo> thx
<bddebian> Upstream version is 0.2 most likely Debian Revision 5 the build1 is the "Ubuntu release"  Meaning it was rebuilt probably for some build-dep transition
<HighNo> ok, I did at least fix 4 packages, have done absolutely nothing regarding household and did not learn for upcoming exam. I need a little cheer up before I go to bed. :-)
<persia> HighNo: There's still plenty of time tomorrow :)
<bddebian> heh
<HighNo> persia: great!
<HighNo> Can anyone please rationally explain why we all are doing this?
<HighNo> :-)
<bddebian> Nope
<persia> HighNo: Define "this" :)
<bddebian> persia: How's my attal? ;-)
<persia> bddebian: nemiver hasn't given me the answers I want yet :(
<bddebian> nemiver?
<pochu> #define this
<pochu> ?
<HighNo> persia: today I did nothing I ought to do, learned about gtk1.2 to gtk2 transitions, fixed 4 packages doing that, dumped 4 others for being too complex and now I am tired... <= this :-/
<persia> bddebian: My gdb foo isn't very strong, and I still rely on GUI
<bddebian> persia: Ah :-)
<persia> HighNo: Ah.  There are several papers written about that.  Most experts seem to agree it has something to do with either the appreciation others give, or as part of participation in a gift economy as a quid-pro-quo for using free software.
<HighNo> persia: I guess it's just love - there's nothing rational about it... don't answer to this one, let me keep this love thing in my mind, makes me feel warm about my work today :-)
<persia> HighNo: That works too (and similarly, there are several papers written about that) :)
<HighNo> hehe
<HighNo> I read about that 5-a-day thing and I liked the idea though I know I am too slow at the moment to get 5 done at a reasonable time. I wish I could help more (and would get money for it - so I could live from just doing this :-) )
<HighNo> Ok, I'll leave now. I have to study so I'll pass my exam - and I could do some other paid work too... gn8
<persia> HighNo: Thanks for helping with the transition.  Good luck on your exam.
<HighNo> persia: if I get bored studying I'll look for some more packages to help with...
<HighNo> bye
<frenchy> I'm an Ubuntu user but I maintain a package in Debian so that it can be synced into Ubuntu ... it was the easiest way to get started.  The issue is, I never use Debian, because it's harder to get stuff working and I'm lazy.  Do I have to become a MOTU before I'm allowed to upload to Ubuntu?  Is there any other way?
<pochu> you can use the sponsors queue, but no, there's no other way for you to upload directly without sponsoring
<frenchy> pochu: Thanks, I'm not a DD and I use sponser/uploader for Debian already.  I didn't know that there was an equivalent for Ubuntu.
<frenchy> !sponser
<ubotu> Sorry, I don't know anything about sponser - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<|rojanu|> here https://help.ubuntu.com/6.10/ubuntu/packagingguide/C/ubuntu-upload.html you can read
<frenchy> |rojanu|: Ta
<ScottK> persia: Would you please have a look at Bug #194509 and give your opinion on if this is a good then and if you think it ought to have an FFe?
<ubotu> Launchpad bug 194509 in jabref "should include icedtea-java7-jre as an alternative dependency to allow inclusion and building into purely free distribution such as gobuntu" [Undecided,Fix committed] https://launchpad.net/bugs/194509
<pochu> frenchy: https://wiki.ubuntu.com/SponsorshipProcess
<frenchy> |rojanu|: There's no mention of the sponser queue on that page.  Is it just a case of uploading
<frenchy> pochu: Ta
<pochu> anytime
<persia> ScottK: I'm not 100% happy with the debdiff (no maintainer mangling, build-dep on icedtea-java7-jdk should be optional), but I can't see how it would affect Feature Freeze.
<ScottK> persia: Thanks.  Would you please comment on the bug.
<persia> ScottK:  Sure: leaving standard sponsor rejection.  Any suggestions re: the ubuntu-motu@ thread?
<ScottK> I'll take care of that.
<persia> Thanks.
<persia> Bah.  Easier to just fix and upload.
<ScottK> persia: My next Java question is do we want Iced Tea 1.6? Bug #195300
<ubotu> Launchpad bug 195300 in icedtea-java7 "IcedTea 1.6 is now available" [Wishlist,Incomplete] https://launchpad.net/bugs/195300
<persia> I think we want OpenJDK, but I don't know the status thereof.  Better to ask slytherin, doko, or man-di
<ScottK> OK.  Hopefully you just did.
<ScottK> THanks.
<jdong> http://fedoraproject.org/wiki/FWN/Issue121?action=show&redirect=FWN%2FLatestIssue#head-ceb67569d30fe439a8b6aa24529b4b1a28898b3a
<jdong> I thought that was an interesting discussion
<jdong> the fallout when Fedora decided to push out a non-backports-compatible unison update to its stable release
<jdong> s/backports/backwards/
<Fujitsu> Hahahahaha.
<Fujitsu> Fools.
<persia> jdong: I've been fiddling with the new version.  Which do you think we want for hardy?
<jdong> persia: I don't know enough about unison to comment specifically, but my gut feeling would be the newer
<persia> jdong: It's incompatible, which is why it's not been updated.
<jdong> persia: given that post-release providing users with a newer unison would be a bigger pain than now while Hardy users are limited.
<jdong> it does seem like Unison likes to break compatibility every other day ;-)
<persia> Hmm.  I and suppose with Hardy LTS, it's the best time to break it.  OK.  I'll finish up, and push to motu-release soon then.
<Fujitsu> I'd really like a new stable rdiff-backup for Hardy :(
<persia> No, they have a new versioning scheme: X.Y.Z, where incompatibiilities only happen for increasing Y.
<jdong> persia: I hope they don't increase Y frequently?
<jdong> Else it's kinda like "ffmpeg has a new versioning scheme YYYYMMDD where incompatibilities only happen for increasing D" :D
<persia> jdong: Well, at least they have Z now.  Used to just be X.Y, so everything was always incompatible.
<persia> (or maybe 2/3  but there was no easy way to tell)
<ScottK> Is unison being actively developed again?  Last I looked it was pretty dead.
<persia> Upstream isn't pushing development anymore (the research project is finished), but patches get accepted, and there is still a bit of use.
<persia> http://tech.groups.yahoo.com/group/unison-announce/ is probably a good indication of update frequency.
<jdong> I think I've been using git/bzr as my "unison" for a while...
<ScottK> Unison was developed at the university that I attended (long after I left of course).
<persia> jdong: You clearly don't have high data turnover needs.  Start playing with gigabytes of data that gets completely replaced one a month or so, and you'll want something else.
<jdong> persia: yeah, you're right, my needs have been small scale so far
<jdong> I totally see the merit of unison
<persia> (mind you, unison still had the bug that it hangs for >15,000 files in a directory, last I checked)
<ScottK> Kind of knocks it our for maildir syncs then.
<persia> ScottK: Do you run hot-hot redundant mailservers with dual active copies of maildirs?  If so, you might have a great test case to fix the bug.
<ScottK> persia: I don't.  I use maildir on my workstation and periodically rsync.
<ScottK> our/out btw.
<ScottK> jdong: I just queued up postfix 2.5.1 backports for Gutsy/Feisty/Edgy/Dapper (last 3 were source backports).
<persia> Ah.  Yes, that changes the meaning considerably :)
<jdong> ScottK: cool
<jdong> ScottK: whenever you feel bold enough, I've got dscs for the firefox+xulrunner backports ready to go
<ScottK> Actually I last used unison when I was still on Windows.
<ScottK> jdong: Not tonight.  I was up until almost 4AM last night trying to understand why libpythonize0 was trying to dlopen libpython2.5.so and not libpython2.5.so.1 without success.
<ScottK> I can't stay up so late tonight.
<jdong> ScottK: get your rest :)
<ScottK> I got as far as figuring out it was probably something libtool related and gave up.
<ScottK> The good news is our fearless release manager has taken up the cause and assigned the bug to himself.
<jdong> do you guys have any idea if there exists a disk buffer type piping utility for Linux?
<jdong> I'm thinking something like "expensive_input_resource | buffer cache_file | inexpensive_slow_output"
<jdong> i.e. something that allows the thing before the pipe to be buffered/queued to a filesystem backed cache, so that it can be slowly slurped up by some other pipe
<jdong> I would benefit from something like that for some media encoding that I'm doing where a 80GB input video gets compressed down to 8-10GB and I'd rather not require so much free diskspace; the process runs like 0.75x realtime so in reality I should only need around 20% the storage
<persia> jdong: Filesystem-backed cache?  That's just using the storage, no?  If you want lower-latency storage, /dev/shm mounted as tmpfs is the common tool, perhaps pushing swap if needed.
<jdong> persia: right, it's using storage but only the amount of storage necessary to "pick up the slack"
<jdong> i.e. allow left-hand-side to output as fast as it can, and right-hand-side to intake as slow as it can
<persia> jdong: Ah.  That's harder.  All the techniques I know generally push to RAM, figuring it's the vm's responsibility to decide when/if it should be on disk.
<jdong> persia: I'm thinking about implementing a circular buffer on-disk using sparse files....
<jdong> just need to figure out how to "punch sparse holes" arbitrarily in a file
<persia> jdong: Just be careful with that sort of game.  More and more people run solid state these days (if only with an IDE->CF converter) and may not want the on-disk cache.  Also, remember that the kernel cache mechanism has a somewhat lazy write, so you may end up not having the contents in the file when it actually commits to the physical disk.
<persia> (and bypassing the kernel file cache makes everything much slower...)
<Hobbsee> \sh_away: ping
 * superm1 wonders if emdebian will work properly on an ubuntu box.  Here we go :)
<Gunner_Sr> I am trying to get the following package - "libapache2-mod-wsgi" does anyone know where I can get it from for Ubuntu?
<persia> Gunner_Sr: apt-get source (or aptitude download) ought work for hardy.  Otherwise, consider the LP page.
<Gunner_Sr> persia: I am on gusty..
<warp10> Good morning
<persia> Gunner_Sr: In that case, you'll need to download from LP.  https://launchpad.net/ubuntu/+source/...
<Gunner_Sr> persia: does it need lib6c 2.7 or higher?
<persia> Gunner_Sr: You really don't want to use the binary package.  You can try backporting the source.
<Gunner_Sr> persia: ah, ok
<Gunner_Sr> persia: how do I combine the diff with the main tar?
<persia> Gunner_Sr: dpkg-source -x foo.dsc
<Gunner_Sr> persia: thanks
<gmatht> Is there any documentation on "control.modules.in" anywhere?
<Gunner_Sr> persia: what is the best way to install the main tar and then combine the dsc?
<persia> Gunner_Sr: What are you trying to accomplish?
<persia> gmatht: It can be used a few different ways: there is typically something in debian/rules that generates debian/control.
<Gunner_Sr> I want to install libapache2-mod-wsgi on a server to support multiple sites on trac.
<Gunner_Sr> persia: I want to install libapache2-mod-wsgi on a server to support multiple sites on trac.
<persia> Gunner_Sr: OK (and no need to repeat yourself).  Steps are 1) download the source (all three files), 2) unpack the source, 3) build a binary, 4) install a binary.  Steps 1 & 4 are typically self-explanatory.
<Iulian> Can someone please check my new debdiff for bug #196871 before submitting it to the report - http://paste.ubuntu.com/5183/ ?
<ubotu> Launchpad bug 196871 in zblast "No .desktop file; here is one" [Wishlist,In progress] https://launchpad.net/bugs/196871
<gmatht> Well, I am trying to build a kernel module compcache which is automatically named compcache-_KVER_
<persia> Step 2 is optional, depending on your build system.  If you are using something like pbuilder, prevu, sbuild, etc. you ought be able to call that directly on the .dsc.  If not, dpkg-source -x foo.dsc is likely the easiest.
<gmatht> However control.modules.in just seems to be ignored when I do debuild -S or debuild -b.
<persia> Step 3 is the aforementioned call to any of several utilities, or in their absence, you can try `debuild -b` from the unpacked source directory.  The first time, it will probably complain that you need to install the build dependencies.
<persia> Iulian: Note that if you choose to bump the standards version, you are expected to get the package lintian and linda clean for that standards version.  Also, it might be worth checking to see if the debian/menu file needs a matching update, even if you decide not to bump the standards version.
<gmatht> I am using the default deb_helper script and also looking at the script at: http://permalink.gmane.org/gmane.linux.debian.packages.voip.devel/183
<persia> Iulian: Other than that, it looks sane, although I don't tend to be that verbose in changelogs (given that it uses up disk space for every user installing the package).  For this, I'd just add three lines, one about the .desktop file, one about the Homepage entry, and (optionally), one about the standards version.
<Iulian> persia: I don't get any warnings from lintian and linda. I will take a look at debian/menu file to see what I can do there.
<persia> gmatht: The kernel is a somewhat special case.  While someone may answer here, this is the quietest time of the day on the quietest day of the week for this channel.  You might also want to try in #ubuntu-kernel, although I don't know if they are active at this time.
<Iulian> persia: Ok, I will remove some lines from changelog.
<gmatht> Ah I see. Yes, there was a dh_gencontrol buried in the rules. I'll have a look at that. Thanks.
<persia> Iulian: check with all the flags (e.g. lintian -iIv and linda -v -f long -t E,I,W,X)* some things can slip by (and it's not important to update the standards-version, just to make sure it is correct).
<Iulian> persia: Ok, thanks a lot.
<Amaranth> persia: If you want to be verbose about a change that's what revision control is for :)
<Gunner_Sr> persia: thanks, I will do that.
<Amaranth> 2 page commit messages ftw
<persia> Amaranth: You have my complete agreement.  I like upstream changelogs to summarise the commit logs to indicate things interesting to users, casual developers, bug hunters, and distribution maintainers.  I like distribution changelogs to summaries the upstream changelogs to indicate changes significant for end-users, policy updates, or significant packaging changes.
<Iulian> persia: This is what I get from lintian and linda now: http://paste.ubuntu.com/5184/
<Iulian> persia: And about the debian/menu file I think it's ok.
<persia> Iulian: You're probably safe for the standards-version update then (although it ultimately depends on your sponsor, and how familiar they are with policy)
<Iulian> persia: Btw, in debian/menu file I have: longtitle="High-speed shoot 'em up game". Should it start with a verb?
<Iulian> Or it's necessary only in .desktop file?
<persia> Iulian: I don't see any specific guideline.  Definition seems to be "For people that like descriptive titles (about one line) It is probably best to include this in your menu entries, while the window-managers don't (by default) put it in the menus.  That way, people who want descriptive titles can turn them on, but others don't need to use them."
<persia> Iulian: Also, isn't there supposed to be a Version=1.0 in the .desktop file?
<persia> Iulian: For extra points, consider migrating the entire package to dh_install instead of still using dh_movefiles in a couple places.
<persia> (alternately, you may want to install the .desktop file with dh_movefiles)
<Iulian> persia: Didn't know about that, I've added Version=1.0 right now.
<Iulian> persia: I'll take a look in debian/rules file to see what I can change. Although I'm not so sure I can do it.
<persia> Iulian: OK.  The current form works, and I doubt anyone will force you to learn dh_movefiles, but 1) it's good practice to use the installation systems already in place in a package, and 2) packages are encouraged to use dh_install rather than dh_movefiles.
<Iulian> persia: To be honest, I don't know anything about dh_movefiles. Where should I change dh_install with dh_movefiles?
<persia> Iulian: It's not quite that simple.  Both those programs take care of installing files into the appropriate package directories for building the binary packages, but they do it in different ways.  The current rules file calls dh_movefiles.  The manpages are your best guidance.
<Iulian> persia: Ok, will go to read the manpage then.
<persia> Iulian: Good luck.  If you get stuck, skip it for next time, and look for another bug.
<Iulian> persia: Thanks, I have three files in debian/rules - dh_movefiles -p zblast-svgalib; zblast-x11 and zblast-data
<gmatht> Is it bad to use `uname -r` in a source deb?
<Iulian> persia: Should I remove them? if yes where I have to call dh_install?
<persia> gmatht: Yes.  You care about the kernel you intend to compile against, rather than the kernel the buildd happens to be running.
<persia> Iulian: If you replace the dh_movefiles calls with dh_install calls, you also need to update the other files in debian/ to be changed.
<persia> More specifically, you'd need to change the debian/*.files files to debian/*.install files, and update the syntax to the new format.  You likely want to include your .desktop file while you do so.
<persia> The simpler way is just to ask for the .desktop file to be installed in the relevant debian/package.files file, rather than directly in rules (leaving dh_movefiles).
<Iulian> persia: Ok, will take care of that right now.
<Iulian> persia: One more thing, do I have to include the .desktop file in all debian/*.install files? What is the command for that?
<gmatht> Is there a standard way of over-riding uname. Fiddle with path? Just patch the upstream Makefiles?
<persia> Iulian: I generally use vi, and no, only for the package in which you want to install the .desktop file.
<Iulian> persia: I have three files: zblast-data.files; zblast-x11.files and zblast-svgalib.files
<persia> gmatht: That's the sort of specific question you want to ask in #ubuntu-kernel (sorry)
<persia> Iulian: OK.  Do you understand what they do?  If so, which one do you want to edit to install your .desktop file?
<Iulian> persia: Well, all .files are install one specific file
<Iulian> persia: Maybe zblast-data.files ? because the other two files are installing the man pages.
<persia> Iulian: Only one file each?  That's not a lot of extra files.
<Iulian> persia: Yes.
<persia> Hmm.  Sounds like this could use a bit of work.  manpages are usually installed with dh_installman these days.
<persia> Given the complexity, I'll suggest you not try to migrate to dh_install just yet.  In which package do you want the .desktop file (or do you want all three?)
<Iulian> persia: I don't know exactly, maybe the data one because like I said the other two file are installing the manpage.
<Iulian> persia: the data files contains only this line: usr/share/games/zblast
<persia> Iulian: OK.  Let's take a step back.  There are a few different binary packages for this source package.  Which one seems like the right choice for the .desktop file?
<Iulian> persia: Let me see.
<Iulian> persia: Maybe zblast-data
<persia> Iulian: You say "Maybe", so I'll ask "Why?"
<Iulian> persia: I was looking in debian/control and svgalib and x11 are depending on zblast-data. Anyway I don't think it has something to do with the .desktop file
<Iulian> persia: Uh, I'm a bit confused about it.
<persia> Iulian: Does the .desktop file work for both zblast-x11 and zblast-svgalib?
<Iulian> persia: I don't know exactly, where should I look?
<persia> Iulian: Well, what does the ,desktop file do?
<Iulian> persia: Creating a desktop file in the menus.
<persia> Iulian: Right.  It creates a menu entry.  Now, what happens when the user selects the menu entry?
<Iulian> persia: Uhmm, the .desktop file should have something from where it can be called.
<persia> OK, and which entry in the .desktop file specifies that?
<Iulian> persia: Exec
<persia> Exactly.  Now, if there are two packages (-x11 and -svgalib) for a program, how can we determine if they can share a single .desktop entry?
<Iulian> persia: Unfortunately, I don't know to answer that question.
<Iulian> Uhmm
<persia> OK.  We've determined that a .desktop file specifies what program the menu system should call in the Exec= key, right?  So, if this file needs to work for two packages, what must be true for those two packages?
<Iulian> persia: I don't have a clue. What about the Terminal=false from the .desktop file?
<Iulian> Ahh, it has nothing to do with that.
<persia> OK.  In order for two programs to have one .desktop file, the menu system needs to be able to call both of them in the same manner, so they must both provide an executable file that matches the Exec= string in the .desktop file.
<persia> This can be a standard conflicting file (with Conflicts:), a defined alternative, or a shell script in the common package that selects one of them at runtime.  The mechanism doesn't really matter.
<persia> Iulian: Does that make sense?
<Iulian> persia: Yeah... but I'm wondering where to provide the executable file for both programs.
<persia> Iulian: OK.  So, getting back to specifics, if you look at the zblast-* packages, do they need different Exec= keys, or can they use the same one?  (dpkg --contents may help, as may inspection of the maintainer scripts)
<Iulian> persia: I don't have the deb package yet to use dpkg --contents. Is there another way to look for it?
<persia> You can examine the upstream build system, but you might just want to download the previously built binary packages with `aptitude download zblast-x11` to investigate.
<persia> (or just run a quick build locally, and investigate)
<Iulian> persia: I don't see nothing there which can be useful.
<Iulian> I'm a bit confused, sorry.
<persia> Iulian: OK.  Let's ask this differently.  If a user installs the zblast-x11 package, how should they launch zblast?
<Iulian> persia: They should have an entry in the menus, because that's why we're making a .desktop file
<persia> Iulian: OK.  How should they run it today, before there is an entry in the menus?
<Iulian> persia: From terminal.
<RainCT> Morning
<persia> Iulian: OK.  And what command should they use?
<Iulian> persia: Ahhh, gotcha!
<Iulian> persia: Wait a second please
<persia> :)
<Iulian> zblast-x11
<Iulian> Right?
<minghua> I'd like a second pair of eyes to look at the sync request bug #197562 to make sure everything is correct, since I haven't done this for quite a while.
<ubotu> Launchpad bug 197562 in xfonts-wqy "Please sync xfonts-wqy 0.9.9-3 from Debian unstable main to hardy universe" [Undecided,New] https://launchpad.net/bugs/197562
<persia> Iulian: I've no idea: I've never installed or used the package.
<Iulian> persia: In this case I will go and install it and check.
<persia> minghua: Looks safe to me.
<persia> Iulian: Just to let you know, so you can queue your downloads, my next question would be "How does the user launch zblast-svgalib?".
<minghua> persia: Thanks!
<Iulian> persia: Hmm, weird - svgalib: Cannot get I/O permissions.
<Iulian> persia: Found it, xzb
<Iulian> persia: They should run xzb from terminal in order to play the game.
<persia> Iulian: For both packages?
<Iulian> Humm
<Iulian> persia: Not really, only xzb, so...
<persia> Iulian: You've confused me.  Is `xzb` for -x11 or for -svgalib?
<Iulian> x11
<persia> OK.  What does -svgalib use?
<Iulian> persia: In the description it says there are two versions, -x11 and -svgalib and this package is using the -x11 one.
<persia> Iulian: Aren't there two different binary packages, one for each variant?
<Iulian> persia: Yes
<Iulian> persia: There are two in debian/control - -x11 and -svgalib
<persia> OK.  So, the user should start the program contained in the zblast-x11 package by calling `xzb`.  How should the user start the program contained in the zblast-svgalib package?
<Iulian> persia: The same command, it doesn't mention in the description of the zblast-svgalib package what cmd you have to use.
<Iulian> persia: So, I think both packages are using the same exec.
<persia> Iulian: In that case, can they share the same .desktop file?
<Iulian> persia: Yes, why not? They don't mention anything about two different commands.
<persia> Iulian: So, if both executable packages can share the same .desktop file, in which of the three binary packages produced by the source should the .desktop file be installed?
<Iulian> persia: zblast-x11
<persia> Iulian: How does that help users who install zblast-svgalib?
<Iulian> persia: In the description they mention there are two versions but I couldn't find anything to run the second version (-svgalib). So I think -x11 should be the right one.
<Iulian> Don't have a clue what zblast-svgalib is about.
<Iulian> Or how to run it.
<persia> Iulian: Now I'm confused.  I thought you said earlier that `xzb` would launch zblast-svgalib.
<persia> Going back to look at that package, what does it install in /usr/bin ?
<Iulian> persia: How do I check it?
 * Iulian shrugs
<persia> Iulian: You can either install the package, and use dpkg -L or you can use dpkg --contents on the binary .deb.
<Iulian> persia: From dpkg --contents I get only the dirs.
<persia> No files?  The package is empty?
<Iulian> persia: No, it isn't. http://paste.ubuntu.com/5186/
<persia> Iulian: That's the contents of zblast-x11.  Wasn't there a zblast-svga package?
<persia> (this may be made more confusing because zblast-svgalib is only available for i386)
<Iulian> persia: I've downloaded with `aptitude download zblast-x11`
<Iulian> persia: I'm on i386
<persia> Iulian: OK.  Now download with aptitude download zblast-svgalib
<Iulian> persia: Here http://paste.ubuntu.com/5187/
<persia> Iulian: Looking at those side-by-side, which are the executable files in each package?
<persia> (skipping directories)
<Iulian> persia: -x11 is using xzb and -svgalib xblast
<persia> Iulian: OK.  So, if they are separate executables, can they share a single .desktop file?
<Iulian> persia: I don't see any reason why they can't.
<Iulian> persia: So, my answer is yes.
<persia> Iulian: Let's review.  How does a .desktop file specify which program to run?
<Iulian> persia: I'm so stupid.
<Iulian> persia: From .desktop file. Exec=xzb
<persia> Iulian: No.  Everyone has to learn it once :)
<persia> OK.  So, if the .desktop file is calling xzb, does that work for both zblast-x11 and zblast-svgalib?
<Iulian> persia: Yea, but I'm bothering you too much with my stupid questions. :)
<Iulian> persia: No, they doesn't work
<persia> Iulian: I think of it as you putting up with me refusing to supply an answer, and just asking questions back in answer to your questions :)
<persia> OK.  So, in which package does the .desktop file with Exec=xzb need to be installed?
<Iulian> In zblast-x11
<persia> Why?
<warp10> Anyone knows how frequently is http://people.ubuntu.com/~ubuntu-archive/NBS/ rebuilt? 6 hours, maybe?
<persia> warp10: roughly 6 hours, but it gets stuck sometimes.  Complain on #ubuntu-devel if it hasn't been updated for a long time (but first check the archives to make sure).
<Iulian> persia: Because of what I can see from dpkg --contents
<Iulian> persia: If it was svgalib, it should have /usr/games/xzb too.
<RainCT> can someone tell me what the pushd/popd is doing here please http://paste.ubuntu.com/5188/plain/?
<persia> warp10: Also note that sometimes one NBS package will depend on another, which can confuse a transition.  Further, if a package has an alternate dependency, it will still show (but doesn't always need fixing).  Lastly, removals are manual, which can confuse the results.
<Iulian> persia: I'm sorry, I will be back in 10 minutes.
<persia> RainCT: Pushd adds a directory onto the stack, and sets the new working directory.  popd returns to the working directory.  The behaviour depends on the definition of . (and whether that is supposed to be make or shell)
<warp10> persia: thank you. I will add that to the NBS wiki page. I added the other example, and the page is almost ready to be reviewed.
<persia> Iulian: Right.  Good answer.  Please add the .desktop file there.  Thanks for working through the problem step-by-step.
<RainCT> persia: I know pushd/popd, but don't understand what that line is for (it's make)... And, Ubuntu's buildd use bash?
<RainCT> well, never mind, that isn't the problem anyway
<persia> RainCT: No, they oughtn't use bash.  That's not make syntax, it's an embedded shell script.  Best solution is to rewrite in make, but rewriting to be dash-compatible works too.  It specifically changes from the working directory $(CURDIR) to the calling directory (anywhere, really) and then pops back to the working directory.
<hellboy195> persia: 2012 is right. I simply can't read the calendar -.-
<persia> hellboy195: Next step is to determine which Ubuntu releases will be supported for that event, and make sure the fix has been applied to all those releases.
<RainCT> persia: thanks
<hellboy195> persia: I suppose gutsy won't be supported until 2012 and every release since hardy will have that fix!?
<persia> RainCT: For make syntax, just set a variable to be the results of the find.  Use that variable as a dependency of another rule, and set up a dynamic rule to process each of the directories with meinproc $(basename $@).  Be sure to also add the dynamic rule to .PHONY.
<RainCT> Hey bobbo
<bobbo> Hi RainCT
<Iulian> persia: I'm back. I won't change dh_movefiles with dh_install so the files should be *.files. Now how should I add the .desktop file?
<Iulian> persia: I should add it in zblast-x11.files right?
<persia> Iulian: You've already read the dh_movefiles manpage?
<persia> Yes.
<persia> hellboy195: I think so (I haven't done the math).  Perhaps no SRU is required then :)
<Iulian> persia: Yes, from what I understood is that dh_install is much better than dh_movefiles but I will leave it just like that for now.
<hellboy195> persia: to make you happy I will double check ;)
<persia> Iulian: No worries.  Changing the entire package to not use dh_movefiles is a larger project.
<Iulian> persia: What is the syntax for adding the .desktop file to zblast-x11.files ?
<warp10> persia (and all): https://wiki.ubuntu.com/MOTU/NBS is ready to be reviewed. Any comment will be greatly appreciated.
<persia> hellboy195: No need.  I trust you (in the worst case, we can complain to you in 2012 if it is still broken)
 * persia edits the NBS wiki page
<hellboy195> persia: haha :)
<persia> warp10: I've added a few minor grammar changes.  Larger items I saw include: no discussion of how illuminator FTBFS and no investigation of the libpetsc2.3.2 NBS effort.  It would be good to expand on these for the example.
<Iulian> persia: Please see my last question (you missed it) :)
<persia> Iulian: I've never used dh_movefiles.  Please check the manpage, and try a couple things.  (also, no need to repeat: I'm just slow often)
<Iulian> persia: Okay, sorry. Anyway, you ROCK! Thanks for helping me.
 * Iulian hugs persia
<bobbo> RainCT; do you want the new debdiff for Bug #196870?
<ubotu> Launchpad bug 196870 in gpppon "No .desktop file for gpppon" [Low,Confirmed] https://launchpad.net/bugs/196870
<RainCT> bobbo: have you fixed the description already?
<bobbo> RainCT; i *knew* there was something i had forgotten :)
 * RainCT wonders if there is a build server which Ubuntu developers could use somewhere :P
<bobbo> RainCT would something like "A utility that wraps around pon and poff" be better?
<RainCT> bobbo: I suggest "graphical wrapper around pon and poff" (or perhaps even remove the reference to "pon" and "poff" and explain what it actually does for the end user)
<RAOF> RainCT: There was going to be/was/is the ubuntuwire servers that were build boxes for MOTU.
<warp10> persia: regarding the FTFBS I'm adding a snippet from http://paste.ubuntu.com/5160/. About libpetsc, I didn't really understood what you would like to see there. Can you elaborate, please?
<Iulian> Anyone knows how can I add a .desktop file to *.files ?
<RainCT> RAOF: thanks, I'm asking in #ubuntuwire then :)
<RainCT> Iulian: can you paste the content of a .files file somewhere?
<RAOF> RainCT: Also, if you're after an AMD64 to test bitness problems, I have been known to issue shell accounts to one of my boxes.
<Iulian> RainCT: This is the only line: "usr/games/xzb usr/share/man/man6/xzb.6"
<bobbo> Is ubuntuwire down for anyone else?
<persia> warp10: Well, in the text it mentions that the libpetsc2.3.2 package needs to be cleared before the libmpich1.0c2 can be completed.  There's no further mention of libpetsc2.3.2 or http://people.ubuntu.com/~ubuntu-archive/NBS/libpetsc2.3.2 (or the results of the investigation)
<persia> bobbo: For everyone
<bobbo> persia; ah thanks
<RainCT> Iulian: I see. You have to copy the .desktop file into debian/tmp/usr/share/applications/ and then add " usr/share/applications/desktop_file_name.desktop" to the end of the line in the .files
 * persia understands why dh_install is preferred over dh_movefiles: only one step
<warp10> persia: ah, I understand now. Ok, I will provide something for that too. What about the libminc0 example? everything ok?
<RainCT> persia: it only accepts stuff from inside debian/tmp
<RainCT> persia: and it has to be placed in the right directory there
<persia> warp10: Sure.  You've uploaded that candidate already?
<RainCT> (at least that's what I understood from the manpage)
<RAOF> RainCT: What, dh_install?
<persia> RainCT: Which is handy for splitting packages, but annoying for installing extra files.
<persia> RAOF: dh_movefiles
<RainCT> RAOF: well, I'm just looking for some server where I didn't have to wait several hours for dependencies to download -.-
<bobbo> RainCT; fixed description; http://bobbo.mooo.com/~bobbo/gpppon_0.2-4ubuntu1.debdiff
<persia> Iulian: never mind.  $(INSTALL) is likely easier to read, if dh_movefiles is really that awkward.
<RAOF> Ah, right.  I don't think I've touched a package using dh_movefiles, and I've certainly never deliberately used it :)
<Iulian> RainCT: I've added $(INSTALL) debian/zblast.desktop /usr/share/applications in debian/rules and dh_desktop in binary-arch like you said yesterday
<warp10> persia: I didn't yet, I will take care of it once I'm done with the wiki.
<persia> warp10: Best hurry before someone else does it :)
<RainCT> Iulian: that should work
<Iulian> persia: Yes, so I don't have to add it in *.files file right?
<persia> Iulian: Right.
<Iulian> RainCT: Ok, making now a new debdiff.
<warp10> persia: looks like not so much people likes NBS, so I'm not really scared for that :)
<RainCT> Iulian: just to be sure, $(INSTALL) = dh_install?
<Iulian> RainCT: Where can I check that?
<RainCT> Iulian: there should be an INSTALL= somewhere at the top of debian/rules
 * persia suspects $(INSTALL) to be /usr/bin/install
<Iulian> RainCT: http://paste.ubuntu.com/5189/
<Iulian> That's my debian/rules file.
<RainCT> just to be sure, if a (beside this) bugfix release has "experimental support for CMake build system", it still doesn't need a FFe, or?
<RainCT> bobbo: building & uploading :)
<bobbo> RainCT; thanks :)
<RainCT> Iulian: better replace $(INSTALL) with dh_instal
<Iulian> RainCT: Okay
<RainCT> *dh_install
<Exfil> Hello All
<Iulian> RainCT: Can you please take a look at http://paste.ubuntu.com/5190/ to see if I missed something?
<RainCT> Iulian: looks good, just remove the changes to the *.files files from the diff
<Iulian> RainCT: Ok
<Iulian> RainCT: Done, see http://launchpadlibrarian.net/12350200/zblast_1.3-2.3ubuntu1.debdiff
<Iulian> RainCT: Do I have to subscribe again u-u-s?
<RainCT> bobbo: http://paste.ubuntu.com/5191/plain
<RainCT> bobbo: want to fix those?
<bobbo> RainCT; looks a bit of a mission but yeh i could give it a go
<Iulian> It's pretty weird that you can't use caps in descriptions.
<azeem> can somebody please dget http://people.debian.org/~mbanck/opensync_0.22-2.dsc and tell me whether it builds fine in hardy?
<persia> hellboy195: Take a look at the latest traffic in bug #196854: maybe it does need an SUR.
<ubotu> Launchpad bug 196854 in fail2ban "fail2ban doesn't handle leap years" [Undecided,Fix released] https://launchpad.net/bugs/196854
<persia> s/SUR/SRU/
<bobbo> RainCT; for lintian error "copyright-lists-upstream-authors-with-dh_make-boilerplate" what should i put in the changelog?
<RainCT> bobbo: Â«Change "Author(s)" to "Author" to make lintian happy.Â» or something like tha
<RainCT> +t
<bobbo> ty
<persia> azeem: Builds fine.  Not tested further in any way.
<azeem> thanks
<bobbo> RainCT; fixed them. http://bobbo.mooo.com/~bobbo/gpppon_0.2-4ubuntu1.debdiff
<Hobbsee> RAOF: ROCK ON!  i didn't know gnome-do was in ubuntu
<StevenK> Failed to build or is in NEW, though.
<StevenK>   gnome-do | 0.3.2.1-0ubuntu1 | hardy/universe | all
<StevenK>   gnome-do | 0.3.2.1-0ubuntu2 | hardy/universe | source
<Hobbsee> wfm
<Hobbsee> oh, your cache is out of dae
<StevenK> I should hope not, since that's rmadison
<Hobbsee> that's otu of date too then
<Hobbsee> was only accepted at 19.25 local
<StevenK> Ahh
<afflux> morning
<afflux> RainCT: The maintainer of gnome-arts is already set to ubuntu-motu (bug 197078)
<ubotu> Launchpad bug 197078 in gnome-art "candidate for version 0.2-8ubuntu2" [Medium,New] https://launchpad.net/bugs/197078
<afflux> *gnome-art
<RainCT> afflux: oops sorry
<afflux> no problem :)
<afflux> anyway, gnome-art has no upstream development anymore 2005
<afflux> +since
<RainCT> afflux: I guess you have already tried if it works right with the patches?
<afflux> it works for me
<RainCT> afflux: ok, I'll upload it then :)
<HighNo> Hi, guys. Offtopic question: does anyone know how to send an Xevent (keystroke) to any application via either python or commandline?
<Iulian> RainCT: When you have some time, please review my new debdiff. I'm going outside for ~30min. Please ping me when you're done. :)
<RainCT> Iulian: sure, I'm building it right now :)
<hellboy195> persia: I'll take care of it later :)
<RainCT> Iulian: the dh_install line doesn't work as it has multiple binaries -.-
<persia> (rather, it needs the -p argument)
<RainCT> Iulian: and please remove the "upstream webpage: http://www.svgalib.org/rus/zblast/" things from debian/control (and change the changelog to say that you moved the Homepage field to the source stanza instead of that you added it)
<RainCT> afflux: uploaded :)
<afflux> RainCT: tyvm :)
<Iulian> RainCT: I'm changing it now, how you'd like to be the changelog?
<Iulian> About the Homepage field.
<RainCT> Iulian: I normally write "* Move Homepage field to Source stanza."
<Iulian> Ok, thanks.
<Iulian> RainCT: It should be fine now - http://launchpadlibrarian.net/12350803/zblast_1.3-2.3ubuntu1.debdiff
<RainCT> dh_install -p debian/zblast.desktop /usr/share/applications
<RainCT> Iulian: -p should be followed by the package name, like -pzblast-x11
<Iulian> Ahh
<RainCT> Iulian: the .desktop should go into the -x11, or? (I'll just change it, no need to create a new debdiff)
<Iulian> It should be dh_install -p debian/zblast.desktop /usr/share/applications
<Iulian> dh_install -p zblast-x11 ...
<Iulian> RainCT: Yes, that's right.
<james_w> thanks warp10, persia for the wiki page.
<bobbo> RainCT: thanks for uploading gpppon :)
<Iulian> RainCT: Next time I will build it myself so you don't have to do my work. :)
<Hobbsee> \sh_away: i think they're mindlessly copying planet...
<Hobbsee> \sh_away: because they've got your latest post on there too...
<Hobbsee> \sh_away: planet.ubuntulinux.org too
<emgent> heya
<Iulian> Hi
<RainCT> james_w: thanks for looking at those crashes :)
 * RainCT is away again
<james_w> RainCT: no problem. I saw you had glanced at them, so I stopped where I did.
<james_w> quite a coincidence they were both yours wasn't it?
<Iulian> RainCT: Thanks for uploading it.
<RainCT> Iulian: np, thanks for the debdiff :)
<emgent> geser, ping
<pochu> Hi MOTUs!
<geser> emgent: pong
<Exfiltrate> HEllo pochu
<pochu> hey Exfiltrate
<Exfiltrate> whats goin on
<Exfiltrate> Flare183: Cant decide on a nick
<Nafallo> ehrm
<Nafallo> nick flood
<Nafallo> please stop
<FlareFlare> ok
<Exfiltrate> thanks
<Exfiltrate> how is everyone doin?
<bmhm> hi
<bmhm> where do i find this release? https://bugs.launchpad.net/gutsy-backports/+bug/192751
<ubotu> Launchpad bug 192751 in gutsy-backports "Backport of network game "pioneers"" [Wishlist,Fix released]
<bmhm> It has NOT been released...
<geser> bmhm: https://edge.launchpad.net/ubuntu/gutsy/+queue
<geser> bmhm: it waits for an archive admin to accept it into gutsy-backports
<bmhm> :-(
<bmhm> it takes sooooooo long... :P
<bmhm> but i can download it now, thanks geser
<geser> bmhm: you usually won't find an archive admin working during weekend
<bmhm> geser: 29th was friday for me, but well they got probably more important work to do.
<_emet_> is it bad form to use a python postint script instead of a shell script?
<geser> bmhm: it was added friday evening (18:15 UTC) to the queue
<bmhm> oh
<bmhm> ok I don't work at that time ;)
<afflux> Is there anything special to do with "new upstream version" bugs for bug-fixing-only releases since featurefreeze?
<afflux> special to do when filing such a bug, that is
<jdong> if you're reasonably confident it's bugfix-only, then probably not
<pochu> afflux: no need to file a bug. just upload, but put in debian/changelog what has changed / what is fixed
<afflux> pochu: I can't upload, I'm not a motu
<afflux> jdong: except the bug-fixes, it only contains some synced  translations from rosetta
<pochu> afflux: ah, ok. Then put something so the MOTU understands it's a bug fix only release (probably a changelog.diff) :)
<afflux> pochu: good, thank you
<mib_b7kf8rdn> Has anyone tried to use ketchup to get the latest -rt kernel (2.6-rt)... it seems that ketchup breaks quite frequently and I wonder if it is even still maintained... it looks like the ketchup wiki (www.selenic.com/ketchup/wiki) is filled with spam and it stopped at release 0.9.8.
<emgent> jdstrand, ping
<fmarier> I've got a Perl 5.10 build fix for a package in hardy, should I bother asking for a sync with the Debian package (which has the fix) or is it unnecessary since hardy only has Perl 5.8?
<fmarier> The only change: http://pastebin.com/m168ef0ab
<ScottK> It's unnecessary for Hardy.
<ScottK> If the Debian package has the bug you ought to file the patch with the Debian in their BTS.
<ScottK> Then we'll get it automatically for the Ibex.  Debian will likely do the Perl 5.10 transition before we do.
<warp10> If I am packaging a software from scratch, and need to patch the source (adding a patchsystem), do I need to add an entry in debian/changelog?
<ScottK> warp10: Yes.  Your debian/changelog should describe how you are patching the upstream code.
<warp10> ScottK: Ok, thank you.
<ScottK> Someone who hasn't just totally given up on the idea of filing bugs against Launchpad might want to suggest that they try out their new "builds as soon as you upload it" PPA feature with an empty PPA.
<ScottK> It's just barely possible that they didn't really design or test this particular feature very completely.
<hellboy195> ScottK: ^^, so far it worked for me with i386 and amd64 very good
<ScottK> hellboy195: First upload to an empty PPA since the last LP release?
<hellboy195> ScottK: ah, not to an empty. You found a bug?
<ScottK> Yes.  Since no packages are published, there is no release.tgz, soyuz looks for it, and the build fails.
<ScottK> Typical half designed half tested LP feature development.
<RainCT> good night
<hellboy195> ScottK: as I said. LP should go opensource and you agreed me :)
<hellboy195> RainCT: gn8
<ScottK> hellboy195: With some community governance too.  Just releasing the code isn't sufficient.
<ScottK> But as I started with ...
<ScottK> I've sworn off reporting launchpad bugs as bad for my health, so someone else may want to report that.
<hellboy195> ScottK: If it isn't urgent I would do it tomorrow, I'm going to bed soon ..
<ScottK> hellboy195: For me, no Launchpad bugs are urgent.
<ScottK> ;-)
<hellboy195> hrhr, bad ScottK :P
<hellboy195> ScottK: bug #196782 ?
<ubotu> Launchpad bug 196782 in soyuz "First build in a new PPA fails" [Low,Triaged] https://launchpad.net/bugs/196782
 * ScottK just barely avoids making a really snide comment in that bug.
<hellboy195> ScottK: but it's the right one?
<ScottK> Yes
<hellboy195> :)
<hellboy195> problem solved
<hellboy195> no one has to report it ^^
<ScottK> Yes.  Thanks.
<hellboy195> nvm. gn8 folks :)
<ScottK> I need to avoid even looking.  Their snide attitude to releasing shoddy software just drives me nuts.
<RAOF> Hobbsee: Yeah; gnome-do has been one of my pet licensing annoyances.  Hooray for being a part of upstream!
#ubuntu-motu 2009-02-23
<directhex> mrooney, run "requestsync" from ubuntu-dev-tools
<mrooney> directhex: okay, now if I am the ubuntu maintainer but don't have upload rights, is there anything special I should do?
<directhex> anakron, the version number of a package in debian/changelog should be appropriate. if it's an ubuntu-specific package based on 1.0-1, it should be 1.0-1ubuntu1
<directhex> mrooney, nope
<mrooney> directhex: excellent, thanks!
<anakron> ping directhex : and if i got "Patch 10_remove_encoding_from_desktop_file does not remove cleanly (refresh it or enforce with -f)
<anakron> after applying patches
<anakron> then i must remove them?
<directhex> anakron, patches must be removable as well as addable
<anakron> but, what i must do now
<anakron> ?
<directhex> anakron, check your patch - it might be slightly buggy
<directhex> anakron, if in doubt, regenerate the patch. it can help
<anakron> it's not mine
<anakron> can you check it? its qtpfsgui
<anakron> i want to add some changes
<anakron> oops
<dholbach> good morning
<fabrice_sp_> Good morning dholbach !
<dholbach> hiya fabrice_sp_ :)
<stefanlsd> Morning!
<dholbach> hiya stefanlsd
<stefanlsd> hihi
<ara> morning dholbach :)
<stefanlsd> dholbach: Is there going to be an official gbj close meeting...
<dholbach> stefanlsd: what would you expect to happen there?
<stefanlsd> dholbach: just maybe people who attended or had concerns to  raise them. problems we encountered or things we thought worked well
<dholbach> stefanlsd: I didn't plan anything of that sort yet - maybe we could ask for feedback on ubuntu-bugsquad@ and loco-contacts@?
<didrocks> I have to microblog about the bugjam in Paris... Let's say this evening to have my photos :)
<stefanlsd> didrocks: FR did great!
<didrocks> stefanlsd: for a first officiel participation, yeah, little pride about it :)
<didrocks> but most important: Paris wins over Toulouse :)
<didrocks> take that huats :p
<dholbach> didrocks: on a bug-per-inhabitants basis? :)
<didrocks> dholbach: no, that's not good stats. I can assure you ;p
<dholbach> :-)
<didrocks> dholbach: how did you compute this stats? It's not the number of touched bugs?
<dholbach> why isn't it?
<didrocks> hum, I was just wondering, seeing yesterday that there was some bugs like Toulouse having 23 000+ points ;)
<dholbach> that was a bug I fixed
<didrocks> I am just impressed by the number of touched bug by us, Didn't realize it was so much
<stefanlsd> didrocks: yeah, us neither
<didrocks> dholbach: I am sure it's huats who asked you to do such a bug ;)
<dholbach> didrocks: no, I broke it just myself :)
<didrocks> stefanlsd: you too? apparently, it's hard to count/estimate number of touched bugs ;)
<didrocks> dholbach: :)
<stefanlsd> Did we have a blog for ubuntu dev stuff? Was it on fridge, or was that only developer news?
<mok0> stefanlsd: we don't. It was proposed but never decided on
<didrocks> stefanlsd: yes, there were an open thread about it
<mok0> Someone mentioned we might use the fridge
<stefanlsd> mm. yeah. i think it would be a nice feature to have
<stefanlsd> i think often there's alot of stuff going on, and guys could help, just you dont have a good way of putting it out there, or asking
<mok0> stefanlsd: yep
<xakep> well there is one way
<stefanlsd> and things like a common thing that biting everyone at the moment. maybe some big api change or something that would help a bunch of people hitting the same issue
<xakep> how about a forum
<mok0> stefanlsd: and important information like the python 2.6 upgrade
<xakep> haha
<xakep> python is pretty nice
<xakep> why not use the 3.0.2 stable version
<mok0> xakep: that's an understatement...
<xakep> no thats not
<directhex> xakep, pythono 3 is incompatible with 2.x by design
<xakep> cause ScITE much better
<stefanlsd> mok0: yeah. stuff like that.
<mok0> oh, here comes my cat...
<xakep> python 3 will eventully be compatable
<stefanlsd> i dont mind hosting a drupal site with a blog with openid to LP for this. Who would be the right person to check with?
<mok0> xakep: nonsense
<xakep> well i counld open something like that
<xakep> in a matter of minutes
<xakep> what would it be called
<xakep> good urls are hard to find these days
<xakep> maybe wordpress would work
<dholbach> didrocks, stefanlsd: I'm just checking the code - it might be that I counted some bits twice :-/
<mok0> If it's meant to be for the -devs, you need the blessing of a MOTU meeting
<dholbach> didrocks, stefanlsd: will let you know
<didrocks> dholbach: don't cheat to make ubuntu-berlin the first one :)
 * didrocks keep an eye on dholbach ;)
<xakep> there is a beta verison of python that might work
<dholbach> didrocks: let's continue in #ubuntu-bugs :)
<xakep> that is strange code thou
<xakep> beta versions seem to crash allot
<xakep> I have been having allot of luck with Ruby
<xakep> well im trying to repair damaged driver files
<directhex> well that was odd
<ara> Hey MOTUs! Today is an Ubuntu Testing Day!: https://wiki.ubuntu.com/Testing/UbuntuTestingDay/20090223
<ara> help us testing the new features!
<huats> morning
<AnAnt> Hello, can someone review http://revu.ubuntuwire.com/details.py?package=webstrict ?
<slytherin> anyone here with access to an ia64 machine.
<directhex> no comment
<directhex> why?
<slytherin> directhex: mjpegtools fails to build on ia64 with error that libquicktime-dev is not installable because some particular version of libquicktime1 is not installable.
<directhex> slytherin, can you phrase that in the form of a SLES10 question?
<slytherin> directhex: I don't think so.
<stefanlsd> Are blueprints meant to be discussed before proposed, or proposed and then discussed?
<AnAnt> persia: ping
<AnAnt> persia: I have fixed the issues you mentioned in webstrict
<Koon> stefanlsd: I would say both
<Koon> stefanlsd: some blueprints are well advanced when discussed at UDS... for some others its the UDS discussion that sparks the blueprint
<stefanlsd> Koon: mm. ok. I was wondering about a opt in / out notification for new merges / syncs to the last uploader. Also some way of that uploader saying, i will do this / i dont have time and feel free to take it.
<Koon> stefanlsd: interesting.
<Koon> since the merge/sync window usually starts before UDS I guess that should be discussed well before
<stefanlsd> I think it will make the merge/sync stuff alot smoother.  I often didnt realise that there was a new merge available, and the merges that were there ,I didnt really wanna 'steal' someone elses merge.. - mm. i could register a blueprint i guess. (i actually already have done the python code to check for updates and notify if new merges are available).
<Laibsch> Is this the right place for motu-sru?
<Hobbsee> Laibsch: on irc?  Yes.
<StevenK> We
<devfil2> Laibsch: what do you need?
<Laibsch> I'd really like bug 221010 to be pushed
<ubottu> Launchpad bug 221010 in mailgraph "homepage for mailgraph has moved" [Low,Fix released] https://launchpad.net/bugs/221010
<Laibsch> outstanding for dapper and gutsy
<devfil2> Laibsch: ah, I forgot to ack it
<Laibsch> Here's your reminder ;-)
<devfil2> Laibsch: the problem is only the icon?
<Laibsch> icon and url
<Laibsch> the debdiff should be taking care of both
<Laibsch> url icon and the url where the image links too have both changed
<Laibsch> s/too/to
<Laibsch>  /
<devfil2> Laibsch: why is it so important?
<Laibsch> Did I say it is important?
<Laibsch> it is a question of user experience, though
<Laibsch> And now that I've gone to the trouble of preparing the patch, I guess I want to see it released
<DktrKranz> Laibsch: gutsy will reach EOL very soon, so I guess it won't be processed in time (speaking with former motu-sru hat)
<Laibsch> too bad
<Laibsch> it lingered for a while
<Laibsch> all the more reason to release dapper quickly ;-)
<devfil2> Laibsch: uhm it's ok
<Laibsch> That being said, I still see feisty around
<DktrKranz> Laibsch: huh? Feisty is EOL since october
<Laibsch> officially
<Laibsch> oops, you're right
<Laibsch> But it wasn't taken off pages like http://packages.ubuntu.com/search?keywords=aptitude immediately
<devfil2> DktrKranz: can you upload the debdiffs?
<DktrKranz> devfil2: no gpg key handy right now
<DktrKranz> Laibsch: probably it's still displayed, but I'm not sure we can actually push packages to a "obsolete" distro with success
<DktrKranz> soyuz could reject them
<Laibsch> I'm not suggesting to push packages to already eol'd releases
<Laibsch> I was merely trying to point out that although eol is looming, releases sometimes have a bit more room to breath even after official eol
<Laibsch> DktrKranz: can I ping you when you are around your GPG key or would it be better to ask somebody else?
<devfil2> Laibsch: I'm uploading your debdiffs
<Kamping_Kaiser> i know this is slightly OT here, but how long can i expect a build of Linux to take in a Launchpad PPA?
<Kamping_Kaiser> i'm at 3 hours, I'm wondering if it'll be another hour, or another 15 :)
<slytherin> Kamping_Kaiser: check how much time it takes for the official builds.
<geser> linux == kernel?
<Kamping_Kaiser> geser, yes.
<Kamping_Kaiser> slytherin, where can i look for that info?
<slytherin> Kamping_Kaiser: https://edge.launchpad.net/ubuntu/jaunty/+source/linux/+builds
<Kamping_Kaiser> slytherin, thanks
<devfil2> Laibsch: I'm changing your debdiffs to use the patch system
<Kamping_Kaiser> interesting. I cant view https://edge.launchpad.net/ubuntu/hardy/+source/linux/+builds
<Kamping_Kaiser> jaunty kernel will have to do.
<geser> Kamping_Kaiser: I don't know if the package was already named linux in hardy
<Kamping_Kaiser> geser, aaah. I'll go and look. thanks for that pointer
<Kamping_Kaiser> I can view the builds via https://edge.launchpad.net/ubuntu/hardy/+source/linux/2.6.24-24.50 , but +source/linux/+builds i cant view. would this be worth asking about #launchpad ?
<geser> Kamping_Kaiser: just checked myself, I see "not allowed here" too, will ask in #launchpad
<Hobbsee> i get a 404 there
<Hobbsee> https://edge.launchpad.net/ubuntu/+source/linux/+builds
<Kamping_Kaiser> Hobbsee, https://edge.launchpad.net/ubuntu/hardy/+source/linux/+builds
<Hobbsee> oh, right
<Hobbsee> forbidden, even here.  strange.
<Kamping_Kaiser> hiya, btw.
<Hobbsee> no one shall have access to that page!
<Hobbsee> greetings!
<Kamping_Kaiser> hehe.
<Kamping_Kaiser> gday.
<slytherin> can anyone provide any insight in this build failure - http://launchpadlibrarian.net/22998337/buildlog_ubuntu-jaunty-ia64.mjpegtools_1%3A1.9.0-0.0_FAILEDTOBUILD.txt.gz
<slytherin> I checked the archive (ports.ubuntu.com) and both libquicktime-dev and libquicktime1 are present on ia64.
<wgrant> slytherin: It could mean a conflict of some sort.
<Laibsch> I'm working on bug 139661 and have prepared patch http://oss.leggewie.org/wip/LP139661.diff
<ubottu> Launchpad bug 139661 in aptitude "[tribe 5] aptitude ncurses interface refers to su vs sudo in status bar notes" [Low,Triaged] https://launchpad.net/bugs/139661
<wgrant> libquicktime1 could well not be installable on ia64.
<Laibsch> I'm not terribly familiar with translation.  Do I even need to patch all those .po files?
<slytherin> wgrant: I am not able figure out the problem from log.
<Laibsch> or just ui.cc and possibly the .pot file?
<wgrant> slytherin: It's not too useful for debugging things at that stage of the build. You need to try to resolve the deps yourself, I suspect, and see what's broken.
<wgrant> (ideally in an ia64 chroot)
<slytherin> wgrant: I don't have access to ia64 chroot. :-(
<directhex> slytherin, debootstrapping, just for you
<slytherin> directhex: thanks. :-)
<slytherin> And I now have a hunch where the problem could be.
<directhex> NOW you tell me, after messing about with debootstrap rpms...
<geser> directhex: can you install libquicktime-dev?
<slytherin> directhex: I believe libquicktime needs a rebuild. Because I can see libavcodec51 as runtime dependency in libquicktime1 package for ia64. But libavcodec51 is not a package anymore in jaunty.
<directhex> The following packages have unmet dependencies:
<directhex>   libquicktime1: Depends: libavcodec51 (>= 3:0.svn20080206-8) which is a virtual package. or
<directhex>                           libavcodec-unstripped-51 (>= 3:0.svn20080206-8) which is a virtual package.
<slytherin> directhex: right, so libquicktime needs a rebuild.
<directhex> that what you were after?
<slytherin> No. I wasn't sure before.
<slytherin> I will do the rebuild today.
<directhex> can i delete this chroot? it's a production box...
<slytherin> or if any motu free enough to upload a build1 source package for libquicktime, that will be great. :-)
<slytherin> directhex: sure, thanks for your help.
<DktrKranz> Laibsch: if you're online around 20 UTC, sure
<directhex> i wish i knew why the test box wasn't booting
<devfil2> DktrKranz: I've already uploaded Laibsch packages
<Laibsch> DktrKranz: most likely not, I'm in Japan
<Laibsch> devfil2: oh, thanks!
<Laibsch> great
<devfil2> slytherin: a rebuild of libquicktime?
<slytherin> devfil2: yes
<slytherin> devfil2: to pickup correct dependencies (libavcodec).
<ScottK> devfil2: Your koffice upload FTBFS.
<ScottK> You going to fix it?
<devfil2> ScottK: it FTBFS on i386 due to sh script if I remember right, feel free to check it
<DktrKranz> Laibsch: oh... pretty incompatible, then. But they're already in unapproved
<ScottK> devfil2: Your upload FTBFS.  I don't find telling me to check a very responsible attitude.
<devfil2> ScootK: ok, I can look at it
<Laibsch> is this the mailgraph package?
<james_w> anyone have any items they think would be good for the Developer News?
<directhex> mono 2.0 app transition done? ;)
<DktrKranz> directhex: can you read my brain? :)
<directhex> yes
<directhex> ew, you disgusting child, is that even legal? :o
<DktrKranz> it's legal given that you don't disclosure my password to launch nuclear missles
<savvas> This is weird - I'm listed as subscribed in most of the packages I submitted in revu-ubuntuwire, but I don't receive the comment updates
<james_w> directhex: yeah, that will be on there
<james_w> savvas: I think you have to enable email notifications
<devfil2> ScottK: koffice ftbfs due to kdelibs changes
<savvas> james_w: I have that checked! I think I have to subscribe to each package I upload, or was that supposed to be done automatically?
<savvas> e.g. http://revu.ubuntuwire.com/u/medigeek shows I'm subscribed to "Own packages, fatrat, fspy", whereas I am listed in the subscribers at http://revu.ubuntuwire.com/p/lxsplit
<RainCT> savvas: have you checked your mail address?
<RainCT> (hint: preferences page)
<savvas> RainCT: yes, I've just unchecked and checked it again - but why am I listed in subscribers at the package page http://revu.ubuntuwire.com/p/lxsplit and not shown in my user page?
<savvas> RainCT: also at the lxsplit page I have a "Subscribe" link on the top menu, not "Unsubscribe"
<RainCT> savvas: because it's your package
<RainCT> savvas: so in the profile it's displayed as "Own packages"
<RainCT> savvas: the link says "Subscribe" because you can still subscribe to that package and then you'd remain subscribed if later you uncheck the "get notifications for all my packages"
<RainCT> (btw, if REVU stops working access it from revu.ubuntuwire.org.. just heard in #ubuntuwire that the .com has expired)
<savvas> ok at my preferences page I have checked "Yes, I want to receive email notifications about everything related to my uploads."
<savvas> lxsplit package page says I'm a subscriber: http://revu.ubuntuwire.com/p/lxsplit (at the bottom of the page)
<savvas> I've just sent a test comment
<savvas> oh
<savvas> wait, .org ?:P
<RainCT> savvas: did you get email before?
<RainCT> *did you get email notifications before, ie. is it just failing today?
<savvas> I used to get them some time ago
<RainCT> perhaps it's because of the domain then
<savvas> I think it was fspy
<savvas> RainCT: this is the last email I got (or I know I got) from revu: http://paste.ubuntu.com/121804/
<savvas> oh anyway, perhaps there was a database update
<savvas> let me click on Subscribe, and see if it works then
<RainCT> uhm I'm not getting mail either
<RainCT> either it's the domain or I broke something :P
<savvas> do you see a "Subscribe" on top or "Unsubscribe"?
<RainCT> unsub
<savvas> hm.. same here now
<RainCT> ok, it's the domain
<savvas> http://revu.ubuntuwire.org/p/lxsplit - didn't receive neither of the last 3 test comments :(
<AnAnt_> Hello, I'm making a package for some CAD tool, the upstream makes a lot of shared libs, and I get this lintian warning: herb: package-name-doesnt-match-sonames libAbe0 libAbl0 libAbt0 libAbv0 libAut0 libBdd0 libBeh0 libBhl0 libBtr0 libBvl0 libCst0 libCtl0 libCtp0 libElp0 ...
<AnAnt_> is that alright to override ?
<JontheEchidna> yeah... I wouldn't expect you'd need binary packages for each of those
<JontheEchidna> that'd be crazy
<AnAnt_> ok, thanks
<AnAnt_> I still need to make shlibs & symbols control files ?
<RainCT> savvas: you didn't get any email, did you?
<savvas> RainCT: nope
<AnAnt_> do I still need to make shlibs & symbols control files ?
<sistpoty|work> hi folks
<DktrKranz> hi sistpoty|work
<sistpoty|work> hi DktrKranz
<bddebian> Heya gang
<geser> Hi bddebian
<bddebian> Hi geser
<sistpoty|work> hi bddebian
<bddebian> Heya sistpoty|work
<slytherin> directhex: openjdk on armel is surely taking ages. :-)
<directhex> slytherin, it's STILL there? o_o
<directhex> slytherin, no matter, moonlight is built for armel now ;)
<slytherin> directhex: yes, it has been five days now
<mok0> OT: Anyone here familiar with R
 * sistpoty|work calls it a day... cya
<ScottK> mok0: There's a guy on planet.debian.org who blogs about it a lot.  Dirk something.  Also maintains the R packages in Debian.  Seems very knowlegable about it.
<mok0> ScottK, thanks a lot, I guess I can find his name then. I solved my problem, though :-)
<ScottK> mok0: If you care about R, there are a fair number of R packages that are FTBFS in Jaunty.  Mostly just need a retry I think.  I looked into it a bit, but then it exceeded my caring factor to get it all done.
<mok0> ScottK, you are talking about r-cran-* packages?
<ScottK> Yes.
<ScottK> And some others too.
<mok0> ScottK, I will take a look at those
<ScottK> I just started looking through the r-base rdpends.
<savvas> I made some transitional packages for boost (1.34) to boost1.35 - bug 332120 - I don't know if it was required, but it was a good practise :P
<ubottu> Launchpad bug 332120 in boost1.35 "jaunty - boost (1.34) to boost1.35 transitional dummy packages" [Undecided,New] https://launchpad.net/bugs/332120
<ScottK> savvas: I uploaded your boost1.35 FTBFS fix the other day.  Thanks.  I also used it as a model to fix boost and boost1.37.
<mok0> ScottK: R's coolness never cease to amaze me :-)
 * ScottK doesn't know much about it.
<savvas> ScottK: sure, no problem :) by the way, I think boost 1.34 needs an update for it as well - unless ubuntu jaunty is going to be without boost 1.34
<ScottK> boost == boost1.34.
<savvas> ah it's renamed now?
<ScottK> We are actually only about 3 packages away from being able to remove boost entirely.
<savvas> let me guess.. deluge?
<ScottK> No luabind, cgal, and btk-core unless I missed some.
<ScottK> mok0: Are you still interested in btk-core?
<savvas> any takers? I have an hour or so to play around :)
<mok0> ScottK, I have to check again, but I'm afraid it's been abandoned upstream
<ScottK> mok0: Would you mind taking a look at Bug 331896?
<ubottu> Launchpad bug 331896 in btk-core "FTBFS on Jaunty" [High,New] https://launchpad.net/bugs/331896
<savvas> I mean, any non-taken :P
<mok0> ScottK, of course
<ScottK> mok0: I think we should either fix it or remove it then.
<mok0> ScottK, yes
<savvas> btw, a guy has ported glife to gtk+ 2 - bug 205218
<ubottu> Launchpad bug 205218 in glife "[unmet dependencies] glife requires libglade-gnome0, but that doesn't exists" [Medium,In progress] https://launchpad.net/bugs/205218
<mok0> ScottK, can you fill me in on the boost1.35 transition?
<ScottK> savvas: I think rather than add more transitional packages, I think it'd be better to work on fixing luabind or cgal.
<savvas> ScottK: will try :)
<ScottK> mok0: Main transitioned from boost (1.34) to boost1.35 and so I was hoping we could push the older version out of the archive.
<mok0> ScottK, you are looking at versioned rdepends?
<ScottK> We currently have boost, boost1.35, and boost1.37.
<ScottK> mok0: It's different package names.
<mok0> Ah
<ScottK> And then boost1.38 hit Sid too late for Jaunty, but it'll get added the next time around.
<ScottK> So we need to work on getting rid of the old one....
<mok0> ScottK, I will see what I can find out about upstream of btk-core... I've emailed them a couple of times on their sf.net email accounts
<ScottK> mok0: Thanks.
<mok0> NP
<savvas> "  * Update Standards-Version to 3.8.0 (explain in debian/copyright why package
<savvas>     is in non-free)."
<savvas> yet in debian/control: Standards-Version: 3.7.3
<savvas> oh sorry, cgal package :P
<savvas> I guess the debian maintainer forgot to bump it, cgal 3.4-2 is 3.8.0
<ScottK> savvas: Don't change it.
<ScottK> Updating standards version from Debian is a pointless change that Ubuntu policy says not to do.
<savvas> alrighty, thanks for the tip :)
 * savvas notes
<savvas> ScottK: Should I change the maintainer, since it's the first ubuntu change? If so, should I note in changelog that I changed the maintainer or is that unnecessary?
<ScottK> Change it, but don't mention it.
<savvas> ok
<savvas> lpia is an official arch?
<directhex> yes
<savvas> E: Package libatlas-base-dev has no installation candidate
<hyperair> hmm it would seem that some people managed to get exa working properly with i915 with driconf
<Laney> I think something is up with udev on my Jaunty upgrade
<Laney> the last thing before it hangs at boot is renaming wlan0 to wlan1
<geser> bug 332270 perhaps?
<ubottu> Launchpad bug 332270 in udev "udev repeatedly generates "change" events for the same block device(s)" [High,Triaged] https://launchpad.net/bugs/332270
<jdong_> popular bug of the day :)
<jdong_> I'm on a livecd sorting out that one on my macbook
<Laney> aha
 * Laney tries disabling watch then
<Laney> yay
<Laney> of course, x is broken, but still
* wgrant changed the topic of #ubuntu-motu to: Jaunty Feature Freeze in effect - Go fix bugs! | https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Fix RC bugs: http://qa.ubuntuwire.org/bugs/rcbugs | Help to clear NBS list: http://people.ubuntu.com/~ubuntu-archive/NBS/
<RainCT> jdstrand: hey
<jdstrand> hi
<savvas> darn, can't get past this: http://launchpadlibrarian.net/23016291/buildlog_ubuntu-jaunty-amd64.luabind_0.7.dfsg-5ubuntu1~ppajaunty1_FAILEDTOBUILD.txt.gz
<RainCT> jdstrand: just to be sure, about bug #292923, is backporting the version from Jaunty the Right Thing?
<ubottu> Launchpad bug 292923 in libphp-snoopy "CVE-2008-4796: missing input sanitising" [Undecided,In progress] https://launchpad.net/bugs/292923
 * RainCT is mentoring Vincenzo
<jdstrand> RainCT: heh, I *just* clicked 'Save Changes' in LP on that bug :)
<RainCT> heh
<jdstrand> RainCT: he needs to patch the version that is in intrepid
<jdstrand> (and hardy if he is interested)
<RainCT> jdstrand: OK. The version in Hardy is the same as in Intrepid, the only change being a Standards-Version bump and the addition of a watch file. It still needs a different patch, though?
<jdstrand> RainCT: the upstream version is the same, but the Ubuntu/Debian version is not
<RainCT> Right
<jdstrand> RainCT: eg, intrepid is 1.2.3-2, and hardy is 1.2.3-1
<jdstrand> RainCT: so intrepid becomes: 1.2.3-2ubuntu0.1 and hardy become 1.2.3-1ubuntu0.1
<jdstrand> (this is also in SecurityUpdateProcedures)
<RainCT> jdstrand: Yeh. Just asking because I find stuff like this rather pointless (the packaging changes done between both revisions are absolutely *not* going to cause any impact, and having the same version in both will make successive maintainance easier), but after all doing it twice isn't that difficult (and in this case perhaps even good as he'll get more practice by doing it twice)
<RainCT> jdstrand: Anyway, thanks :)
<savvas> ScottK: Here's cgal debdiff for boost1.35: http://paste.ubuntu.com/122044/ - however there is an lpia dependency problem: https://launchpad.net/~medigeek/+archive/ppa/+build/880368 (amd64 and i386 were built fine in my PPA)
<ScottK> RainCT: The build system won't let you upload the same revision twice.
<ScottK> savvas: Thanks.  Looking
<jdstrand> RainCT: in this case, the change may be minimal, but very often there are more significant changes
<jdstrand> RainCT: tbh, it is easier to create the extra patch than to review all the changes between versions and decide if they could cause a regression
<RainCT> ScottK: changing the version number is still easier than doing a new debdiff (and optimally there should be an option to copy the package from one distro to the other).. but anyway, ignore my rands, I'll actually get used to it ;)
<savvas> ScottK: And about luabind - I got stuck at a problem while compiling, I'm not that code-literate to fully understand it: https://launchpad.net/~medigeek/+archive/ppa/+build/880369 :)
<jdstrand> RainCT: and it doesn't save you anything in terms of testing, because all need to be tested on each Ubuntu release that will get the patch
<anakron> HI RainCT
<anakron> HI all
<RainCT> jdstrand: good point (the review time), but I still think SRU and Security updates are overly bureaucratic (surely for packages in main with lots of rdepends it makes sense, but not that much in the case of standalone universe apps where the risk is minimal..)
<ScottK> savvas: The missing package failed to build on lpia (and armel), so not your problem at all.
<jdstrand> RainCT: well, perhaps. But IMO I'd rather err on the side of caution than to risk a regression. Regressions are no fun
<RainCT> but I guess I'll get over it once I get used to them.. right now I'm still in the initial fase of trying to make sense of the system :P
<RainCT> hi anakron
<anakron> can you look this? https://bugs.launchpad.net/ubuntu/+source/qcad/+bug/311476
<ubottu> Ubuntu bug 311476 in qcad "qcad menu entry lacks a category" [Low,Triaged]
<jdstrand> RainCT: this is an exceedingly longstanding 'bureaucratic' measure to minimize risk (it started with Debian a *long* time ago)
<anakron> I'll test it and now i'll send it to debian maintainer too
<savvas> ScottK: oh, great! 1 out of 2 isn't bad :P
<RainCT> anakron: Looks good! (though the changelog entry isn't really clear.. adding a "debian/qcad.desktop:" in front of it would make it more understandable)
<RainCT> anakron: please wait a few days to see if Debian reacts and we can request a sync before subscribing u-u-s
<anakron> im looking for desktop bugs...but it's too difficult to find them with LP
<anakron> you can't got an exact search from lp
<savvas> qcad has a weird versioning
<anakron> XD
<savvas> I thought I was seeing double because I'm tired heh
<RainCT> lol
<savvas> Does anyone see anything weird in this debian/rules? http://paste.ubuntu.com/122054/
<savvas> let me check if it builds ok with boost 1.34
<anakron> why are you looking for something weird
<savvas> anakron: http://launchpadlibrarian.net/23016291/buildlog_ubuntu-jaunty-amd64.luabind_0.7.dfsg-5ubuntu1~ppajaunty1_FAILEDTOBUILD.txt.gz
<savvas> it fails to build and I'm playing around with patches and boost include directories :P
<anakron> thats weird
<anakron> xD
<anakron> RainCT, im doing a "nice" debdiff file
<anakron> and then ill sent it to debian maintainer
<savvas> RainCT: the emails are back :P
<savvas> ah no wait sorry
<savvas> it was from google code
<anakron> someone here knowns something about emma? im wanna know how is her icon
<anakron> i found one and it's mysql dolphin with "emma" writed
<savvas> anakron: /msg memoserv send emma yadda yadda yadda :p
<anakron> ?Â¿
<savvas> oh, I thought you mean emma/em, with nickname emma
<savvas> sorry :)
<anakron> :)
<anakron> its a project
<andersk> Can someone sync open-vm-tools 2008.11.18-130226-1lenny1 into Jaunty (bug 289921)?
<ubottu> Launchpad bug 289921 in open-vm-tools "network interface does not come up after installing open-vm-tools" [Undecided,Confirmed] https://launchpad.net/bugs/289921
<james_w> thanks nhandler
<nhandler> james_w: For what? The News page update?
<james_w> yeah
<nhandler> james_w: No problem. It is a great resource. I just keep forgetting to update it.
<james_w> the problem is there has been LOADS happening in the last month :-0
<nhandler> james_w: Do you want to mention the stuff going on regarding the MC? Or do you want to wait until after the election?
<james_w> hum
<james_w> I didn't find any announcements about that, except the long-expired call for nominations, did I miss something?
<nhandler> Daniel's membership expired
<nhandler> So currently, we only have 4 people on the MC
<ScottK> The did do the first new style MOTU application.
<ScottK> The/They
<nhandler> scottk: That is already included
<ScottK> K
<james_w> nhandler: I'm not sure that's really appropriate
<POX> is Gabriel Ruiz here?
<POX> anyway, please remember to check the newest Debian package before you'll duplicate the work ;P
<POX> haha
<anakron> hi
<POX> andersk: did you see emma 0.6-3 ? :-P
<anakron> someone can review it?
<anakron> https://bugs.launchpad.net/ubuntu/+source/firestarter/+bug/301603
<ubottu> Ubuntu bug 301603 in firestarter "Impossible to launch firestarter" [Undecided,Confirmed]
<anakron> look it
<anakron> https://bugs.launchpad.net/ubuntu/+source/emma/+bug/333049
<ubottu> Ubuntu bug 333049 in emma "Missing .desktop file" [Wishlist,Confirmed]
<POX> andersk: sorry, wrong nick
<POX> anakron: ^^
<anakron> jaja
<anakron> i was doing a patch for emma
<anakron> yes
<POX> please check -3 then
<anakron> why?
<anakron> :O
<anakron> :)
<anakron> hi Piotr
<POX> hi :)
<anakron> it was a patch for 0.6-3
<anakron> but i sent it like 0.6-2
<anakron> i was doing a patch for emma source package for jaunty
<POX> but the .xpm file is already there
<anakron> :O
<anakron> ops
<POX> or do you want to change it?
<anakron> so...
<anakron> no
<anakron> so
<anakron> forget it
<anakron> or there is an icon, but it doesn't get loaded?
<POX> ok, just remember to check Debian or you'll waste some time ;P
<goshawk> hi, am i the only one that couldn't reach REVU?
<anakron> :) ok
<POX> Ubuntu has -2, so you probably want to sync it
<anakron> mm
<anakron> i'll fill it
<nhandler> goshawk: revu.ubuntuwire.org
<nhandler> goshawk: ubuntuwire.com is down right now
<goshawk> nhandler: wasn't it .com?
<goshawk> ah yes :)
<goshawk> thx
<nhandler> It was .com until the domain name expired ;)
<goshawk> i'm packaging an application which is licensed as gpl v2, but there are some parts in other licenses (artistic and MIT/X11), should i write all the licenses in the debian/copyright file?
<directhex> yes
<goshawk> the package is dsss and it's in REVU
<goshawk> oki so it will be a long copyright file :)
<nhandler> goshawk: Just so you are aware, we are now in Feature Freeze, so we are focusing on making Ubuntu more stable. Your package most likely will not make it into Jaunty
<goshawk> nhandler: yes i know
<superm1> nhandler, its a popular item to use with mythgame, so there is a vested interest
<goshawk> dput ppa seems not working due to ubuntuwire.com down, can i switch to ubuntuwire.org?
<goshawk> s/dput ppa/dput revu
<jpds> goshawk: revu.ubuntuwire.com not working?
<james_w> the domain expired
<goshawk> yep : [23:42] <nhandler> goshawk: ubuntuwire.com is down right now
<jpds> james_w: Gah!
<james_w> goshawk: and yes, you can switch to .com
<james_w> .org I mean
<goshawk> .org you mean :)
<goshawk> ok
<goshawk> and i like .org more :P
<james_w> yeah, I need more beer or less, it's not yet clear
 * jpds really think we should get it registered with the -eu.org guys.
<nhandler> superm1: But is it a mythbuntu package that would fall under your delegation for a FFe?
<superm1> nhandler, no it wouldn't.  that's why i didnt comment on it
<superm1> nhandler, we have an interest in it, but in the end it's a regular ole' universe package
<superm1> so i certainly dont want to overstep my bounds with it
<nhandler> superm1: Ok, then I'll take a look. I just wanted to make sure I wasn't stepping on your toes here
<jpds> goshawk: Point dput at revu.tauware.de
<superm1> nhandler, i seem to think it makes sense to at least bring in that patch if we dont jump versions personally
<superm1> and maybe that's better until upstream does a "formal" release including the patch
<nhandler> superm1: By any chance is the package in a PPA?
<superm1> nhandler, i seem to doubt joel put it in one, but you can check his ppa i guess
<nhandler> superm1: Ok, it isn't a huge deal. It just would save me a few minutes
<superm1> right
<superm1> nhandler, the versioning in his packaging might need to be looked at anyway. i didn't give it that much of a look, figured it's more important to see it's right on principle before looking much into it
<goshawk> jpds: why?
<jpds> goshawk: Nevermind, I thought that domain had been pointed there.
<salty-horse> hi. why does flashplugin-nonfree still uses nspluginwrapper on amd64 instead of the native 64-bit beta?
#ubuntu-motu 2009-02-24
<loic-m> salty-horse: Last time I checked, Jaunty uses the native amd64 beta
<salty-horse> loic-m, http://packages.ubuntu.com/jaunty/flashplugin-nonfree says it depends on nspluginwrapper  (>= 0.9.91.4-2ubuntu1) [amd64]
<loic-m> salty-horse: I dunnon, i just now it dl and install the amd64 beta
<salty-horse> do you have nspluginwrapper installed?
<loic-m> no
<loic-m> on my system, it doesn't depends on ndiswrapper
<salty-horse> how odd
<loic-m> however I've got 3ubuntu2, not 3ubuntu3, there's been a change, see the changelog and you'll get your answer
<loic-m> http://changelogs.ubuntu.com/changelogs/pool/multiverse/f/flashplugin-nonfree/flashplugin-nonfree_10.0.15.3ubuntu3/changelog
<salty-horse> I don't see the answer.. :) it still claims to require nspluginwrapper ...
<salty-horse> oh oh
<salty-horse> ok
<salty-horse> haven't looked at 3ubuntu2 :)
<salty-horse> I wonder why the change was reverted. asac?
<asac> salty-horse: thats ok. when it is final we will pull the native binary from archive.canonical
<asac> the native thing comes from adobe.com which is error prone
<asac> as there is no stable link for versions
<salty-horse> I'm using it, and getting a better experience than with nspluginwrapper
<salty-horse> somtimes the sound stops and I have to restart it, but still a better experience
<directhex> salty-horse, you don't like grey rectangles?
<loic-m> salty-horse: the change wasn't reverted. If you look at the changelog, it's still using native amd64 flash, the problem was AFAIU that it still need ia32 libs
<asac> you didnt listen what i said ;)
<asac> native has no stable link ;)
<asac> like in URI
<asac> salty-horse: which version of nspluginwrapper are you using?
<salty-horse> asac, well, I'm reading you, and I didn't understand :)
<asac> works nice here in its latest form ;)
<asac> salty-horse: good. understood?
<salty-horse> I'm not using it ever since the native client came out :)
<asac> salty-horse: right. try it and you will see ;)
<asac> better than native ;) ... you can kill npviewer if it consumes too much mem
<salty-horse> asac, that's right, but then I don't have flash in *any* website.. not just the offending one :) besides, now I have a new computer and I don't mind restarting firefox with all of it's tabs.
<loic-m> salty-horse: are you on Jaunty amd64 now?
<salty-horse> yes
<asac> salty-horse: reloading pages should start it again. doesnt it?
<loic-m> salty-horse: do you see grey rectangles instead of video?
<salty-horse> didn't use to, AFAIR
<asac> loic-m: you see that with native or our package?
<salty-horse> loic-m, I put the native one in ~/.mozilla/plugin and it works just fine
<salty-horse> that's ~/.mozilla/plugins
<loic-m> salty-horse: do you see grey rectangles with -3ubuntu3?
<salty-horse> loic-m, never used it. want me to test?
<asac> for me youtube works ;)
<loic-m> asac: grey rectangles are there when using 32bits flash on amd64
<salty-horse> asac, I always test with homestarrunner.com :)
<loic-m> salty-horse: if you can, yes please
<salty-horse> downloading the specific package..
<asac> loic-m: you mean you dont see anything or just artifacts?
<loic-m> asac: 32bits flash on amd64 works once out of ten, which means you need to reload the page at least 10 times before you see anything
<loic-m> asac: 64bits flash on amd64 works all the time
<asac> k
<directhex> ctrl-f5 is your friend!
<asac> didnt experience something like that for ages
<loic-m> directhex: that, and unlimited patience
<salty-horse> loic-m, why aren't you using the latest version?
<loic-m> asac: me neither since i've been on native flash ;)
<asac> loic-m: maybe your install is wrong?
<asac> could be that the wrapper took your native plugin and tried to wrap that miserably ;)
<loic-m> salty-horse: I'm on intrepid. i use backported packages, and didn't even know there was a new version in Jaunty
<directhex> flash in general has exploded much less for me since i worked around bug 286119
<ubottu> Launchpad bug 286119 in samba "firefox 3.0.3 crashes (no SIG) on most pages w/ images when using nss_wins: 8.10beta AMD64" [High,Fix committed] https://launchpad.net/bugs/286119
<asac> loic-m: if you are on intrepid you should try the jaunty nspluginwrapper
<asac> that should work mostly flawless ;)
<salty-horse> loic-m, so do you still want to test it? :)
<directhex> if you're on jaunty you should try the jaunty moonlight-plugin-mozilla!
<loic-m> asac: nope, that's flash 32 bits expected behavior on amd64, since ages. Don't know if it's better in Jaunty though
<salty-horse> directhex, is that  moonlight 2.0?
<directhex> salty-horse, nay, only 1.0 for now
<salty-horse> :(
<asac> loic-m: its for sure. as i said i havent seen something like that for ages here
<loic-m> asac: why would I when -3ubuntu2 is native and works flawlessly?
<directhex> salty-horse, i'm in daily contact with upstream - trust me, 1.0 is best for now
<salty-horse> directhex, well, it's already packaged nicely as an extension :)
<asac> loic-m: until adobe changes the binary ;) ... then things blow up. thats why we cant use it yet
<loic-m> salty-horse: nope, if it's confirmed -3ubuntu3 uses 32 bits flash, I'd rather stay far from the pain.
<salty-horse> explosions are pretty
<salty-horse> thank you, loic-m :)
<asac> loic-m: take nspluginwrapper too ;) and you will like it
<asac> backports i mean
<loic-m> asac: I've got the binary on my install, and adobe ain't gonna change it
<asac> yes, but not for new installs or upgraders
<loic-m> asac: I don't support running 32bits app under amd64
<directhex> salty-horse, also an option. depends on whether you want to use the MS binary codecs, really
<loic-m> asac: that's ok. For me, if there's no reason to share the pain, I'd rather enjoy web browsing instead
<salty-horse> directhex, I'm not that much of a purist to mind
<loic-m> I'm not a purist either, but we've been asking for 64 bits flash enough not to  want to go back to square one
<loic-m> 32bits flash is so 2008
<fruchtix> slangasek: and because you asked for a statement like that in such a nice way: Catspaw (insanecats.com) is a modern woman who stands up for women rights. and she qualifies for that role. because she does not play with men like your darling helix
<slangasek> fruchtix: that would be off-topic here
<fruchtix> slangasek: as i said, you asked for it in such a nice way
<fruchtix> slangasek: maybe you should swing from girl (helix) to a real woman who teaches you about the power of feelings, emotions and social behaviour
<slangasek> !ops
<ubottu> Help! Hobbsee, Riddell, sladen, fbond, mneptok, gnomefreak, Seveas, dholbach, elkbuntu, PriceChild, or jpatrick!
<ajmitch> thanks Hobbsee
<Hobbsee> slangasek: nice timing!  I just managed to poke holes thru the uni firewall, too
<slangasek> heh
<ajmitch> slangasek: fwiw chanserv says you can boot trolls from here as well
 * Hobbsee dumps the guy on ignore
<slangasek> oh
<slangasek> right, someone did stick me with ops here, didn't they
<Hobbsee> yeah
<Hobbsee> that was probably me
 * slangasek files that away in a different part of his brain for reference
<slangasek> I believe so :)
<Hobbsee> man, this guy is a complete nutter
<directhex> and seems to hate erinn for some reason
<Hobbsee> hates me too
<mrooney> Should I be using requestsync for packages not in Debian and if so, how?
<directhex> mrooney, how "not in debian" is "not in debian"? some major third party repo?
<mrooney> directhex: I mean, it is in Jaunty universe as an -0ubuntu1 package
<mrooney> and I need an upstream sync
<directhex> mrooney, oh, well no, you need to prepare that yourself
<mrooney> directhex: okay, any instructions for that?
<directhex> probably on the wiki. my helpfulness tails off past 1am. sorry
<mrooney> Okay, I am looking at https://wiki.ubuntu.com/SyncRequestProcess, I don't see anything for non-Debian packages
<mrooney> I can file a sync request and see what happens!
<RAOF> Where is it that you're syncing from?
<directhex> what happens: bug marked invalid?
<directhex> RAOF, nowhere. he wants an uupdate
<directhex> RAOF, on a 0ubuntu1
<RAOF> Oh.
<directhex> mrooney, did you notice feature freeze? is this a bugfix release?
<slangasek> mrooney: "sync" refers to "there is an existing package that we can pull into the archive".  If you're updating a package to a new upstream version, how is that a sync?
<mneptok> slangasek: ooo! OOOOOO! i'll teach you! PICK ME!
<slangasek> mneptok: about the power of feelings, emotions and social behaviour?
 * Hobbsee snorts
 * mneptok preens Hobbsee 
<mneptok> slangasek: mrf mmmff hrrmmm yeah *preen*preen*
 * Hobbsee pets the crazy mneptok
<directhex> i'm confused :|
<mneptok> or we could click like dolphins. or the ant-thing (but i hate the exertion).
<directhex> i think i'll just go to bed
<josephpiche> I have a question: there is a package (gnugo) that I would like build a deb for and put in a PPA. I know how to build the software normally (using make), but I don't know how to actually package it
<josephpiche> is there a wiki page or or something that would help me?
<RAOF> !packagingguide
<ubottu> 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
<RAOF> josephpiche: Yes. ^^^
<josephpiche> sweet, thanks
<mrooney> slangasek: well it is a sync with upstream
 * Yagisan catches up on the scrollback and wonders how anyone could hate Hobbsee 
<mrooney> I assumed the term "sync" derives from synchronizing the ubuntu version with its source
<StevenK> But it isn't a sync in Ubuntu nomenclature
<mrooney> okay
<Hobbsee> Yagisan: because he's paddy frank, and i'm female.  There is no other reason
<StevenK> mrooney: No, the term sync is synchronizing from Debian
<mrooney> okay, that makes sense, now that I know
<mrooney> so what should the bug report look like before subscribing universe sponsors?
<mrooney> here is what I came with: bug 333639
<ubottu> Launchpad bug 333639 in wxbanker "Please sync wxbanker 0.4.1.0" [Undecided,New] https://launchpad.net/bugs/333639
<mrooney> I see now I should change the title
<slangasek> Hobbsee: s/female/an op/, I think :)
<Yagisan> Hobbsee, oh - I know your female - I vaguely recall meeting you when I was still young and optimistic ;)
<StevenK> Haha
<Hobbsee> slangasek: oh, was that it.  I got targetted in a very "you are female" way in PM, so i just assumed it was that
<Hobbsee> Yagisan: heh :)
<mrooney> StevenK: should I use "update" instead of "sync"?
<slangasek> Hobbsee: I believe that's tactical rather than indicative of his agenda
<ajmitch> Yagisan: back many years ago?
<Hobbsee> slangasek: you might be right there
<StevenK> mrooney: Yup
<slangasek> mrooney: that would be clearer, yes; and that would go through the generic sponsorship process
<Yagisan> ajmitch, yep - way back then. I must say, my beloved Ubuntu shirt is starting to wear out. Time for a new one I think.
<StevenK> I'm still trying to work out his agenda, but I don't think even he knows
<mrooney> slangasek: okay so, sync -> update, and subscribe u-u-s?
<slangasek> mrooney: yes
<mrooney> excellent, thanks!
<slangasek> mrooney: as mentioned earlier, please check that if your request needs a feature freeze exception, that the bug report includes all of that relevant information
 * Yagisan 's eyes glaze over as all these messages about update-manager pour into his inbox.
<slangasek> StevenK: I know but I'm not telling
<mrooney> slangasek: okay, it is only a bugfix and translation update, I assume it doesn't require one?
<slangasek> mrooney: "bugfix" is fuzzy - but I assume a sponsor will take it up with you if more detail is needed :)
<mrooney> okay thanks again :)
<mrooney> slangasek: okay one last question, I see people add comments when they subscribe sponsors like "subscribing u-u-s...", should I add one afterwards as well, or is that not important
<Yagisan> ajmitch, it's been so long since I last saw you - my little girl started school (and my $%#$%#%$#%$ uni degree still isn't over :( )
<slangasek> mrooney: not important - the subscription itself triggers mail to the appropriate parties
<slangasek> mrooney: if *I* subscribe u-u-s to a bug, I comment to let the submitter know why it's happening
<ajmitch> Yagisan: yeah, it has been awhile
<Yagisan> ajmitch, /me had, then come x-mas, didn't have a nice job as a sys-admin for Ubuntu boxes. People are still running Fiesty boxen on their networks.
 * ajmitch thinks the oldest install here is probably gutsy by now
<ajmitch> though last I looked, that computer didn't even boot :)
<Yagisan> ajmitch, well, suggesting they go to hardy instead of making a franken-fiesty box didn't go down well. OTOH was nice to have an Ubuntu related job
<ajmitch> apart from that, you've just been studying?
<ajmitch> plenty of time to work on ubuntu then...
<Yagisan> ha - I wish
<Yagisan> enough time to realise jumping on jaunty right now would probably annoy me
<StevenK> Does Jaunty want you jumping on it?
<Yagisan> StevenK, it sure does. Isn't that how you fit it onto a CD ?
<ajmitch> yeah, my laptop is still running hardy
<StevenK> Yagisan: I'd have to ask slangasek
 * Yagisan is mixed hardy/intrepid here.
<slangasek> StevenK: jackalopes love nothing more than jumping
<StevenK> That's *them* jumping, not them being jumped on
<ajmitch> does it blend?
<StevenK> My laptop was running Gardy at UDS Prague
 * Yagisan can imagine a rabbit in a blender actually. buzzzzzzzzzzzz chunk chunk buzzzzzzzz ....
 * Yagisan now needs to make an important decision - save some money and get a Phenom x3 for my virtual machine server, or bite the bullet and get a Phenom II x3
<tomhinkle> Hi all -- I'm an upstream developer who recently has (inadvertently) gotten into a conflict with the upstream packager of my software (i.e. a MOTU) and I was looking for some advice. Is this an okay forum to ask questions of this kind?
<RAOF> Absolutely.
<RAOF> tomhinkle: What is the problem?
<tomhinkle> The packager of my package is upset that I provide .deb files of my bleeding-edge releases for users on SF.  Is this generally discouraged? I find I have a large number of users who want to try the newest packages (more than once every 6 months) and it's handy.
<RAOF> That should be fine; we should be able to easily filter out those bug reports.
<RAOF> Perhaps the packager was annoyed that you have a debian/ directory in the releases you ship?
<tomhinkle> He asked me to get rid of that when he first packaged and I did.
<tomhinkle> Then after I realized my users were struggling to build from source, I used his debian/ directory as a basis for my own releases (he'd made a number of fixes to the packaging that I took on)
<tomhinkle> So now I'm releasing tarballs + .debs upstream, but the tarball has no debian/ directory.
<RAOF> Hm.  That seems strange.  I don't know why a MOTU would be complaining about that.
<tomhinkle> Yeah, that's what I thought. He's been upset about it for a while and we exchanged e-mails -- now he's said he's going to stop packaging the software. I wanted to check if I was breaking some established norms or something.
<RAOF> No.  Not from what you've said here.
<Hobbsee> er, that seems reasonable
<tomhinkle> Hrmph. Well, that's good and bad for me I guess. Good because it seems reasonable, bad because it doesn't give me any information about why he's so mad.
 * Hobbsee agrees with RAOF about it being strange that a MOTU is complaining about it
<ajmitch> the main reason I could see him complaining would be if the packages broke upgrades
<ajmitch> but the packager should be able to sort through that with you
<tomhinkle> That may be what's happened -- he mentioned the package being broken, but didn't get into specifics. He seemed to think I would just stop releasing them.
<Hobbsee> if that's gourmet, are you aware of https://bugs.edge.launchpad.net/grecipe-manager/+bugs?
<tomhinkle> It is and I am -- is there something in that list that sticks out as a particular problem.
<Hobbsee> (as a somewhat unrelated statement)
<Hobbsee> no, i just noticed it existed
<tomhinkle> ah, I see.
<tomhinkle> Alright -- well thanks for your input. It doesn't look like there's too much I can do at this point. I'll offer to fix any packaging errors he points out in my .deb if the problem is that they're breaking updates.
<tonyyarusso> what's the page for figuring out what's causing a segfault again?
<anakron> ping Laney : hey, can you see https://bugs.launchpad.net/ubuntu/+source/qcad/+bug/311476
<ubottu> Ubuntu bug 311476 in qcad "qcad menu entry lacks a category" [Low,Triaged]
<anakron> persia, can you look it please? https://bugs.launchpad.net/ubuntu/+source/qcad/+bug/311476
<anakron> hi all, hi persia and Laney
<anakron> or this one
<anakron> https://bugs.launchpad.net/ubuntu/+source/firestarter/+bug/301603
<ubottu> Ubuntu bug 301603 in firestarter "Impossible to launch firestarter" [Undecided,Confirmed]
<anakron> if someone can see them and review my patches
<anakron> and the last one
<anakron> https://bugs.launchpad.net/ubuntu/+source/qtpfsgui/+bug/309740
<ubottu> Ubuntu bug 309740 in qtpfsgui "no menu icon" [Undecided,Confirmed]
 * RAOF should, perhaps, not have picked beagle as my first evolution-sharp transition upload.
<tonyyarusso> How can I figure out the value of a variable (in C) while my program is running?
<tonyyarusso> It's not crashing, but I suspect something isn't being set right.
<StevenK> Use gdb?
<dtchen_> and your friendly print
<tonyyarusso> dtchen_: I don't really have a good place to print it, so while I could, it would likely be more work.
<tonyyarusso> StevenK: I figured that would be involved, but I'm not familiar with gdb beyond the instructions on https://wiki.ubuntu.com/Backtrace.  Looking through output from that now to see if it's already there.
<dtchen_> huh? meaning not even setting breakpoints is feasible?
<StevenK> tonyyarusso: gdb supports 'print <var>'
<tonyyarusso> oooooh, sweet
<StevenK> tonyyarusso: Set a breakpoint and poke around
<tonyyarusso> erm, breakpoint?  like, just 'break' in the code and kill it?
<fabrice_sp> tonyyarusso, when needed to set a breakpoint, I use DDD
<fabrice_sp> it's a gdb frontend
<tonyyarusso> fabrice_sp: that's another package?
<fabrice_sp> yes
<fabrice_sp> called DDD :-)
<dholbach> good morning
<fabrice_sp> good morning dholbach ;-)
<dholbach> hiya fabrice_sp! :-)
<tonyyarusso> fabrice_sp: man, that interface looked more confusing, not less...
<fabrice_sp> tonyyarusso, I myself find it more useful to go through the source, but it's as you want
<tonyyarusso> fabrice_sp: maybe once you know how to use it?  dunno.
<tonyyarusso> although in gdb proper I can't manage to define a break either.
<tonyyarusso> (gdb) break save_pounce_cb
<tonyyarusso> Function "save_pounce_cb" not defined.
<tonyyarusso> Make breakpoint pending on future shared library load? (y or [n])
<StevenK> tonyyarusso: No, specify the file and line number
<tonyyarusso> StevenK: that gives me "No source file named gntpounce.c"
<tonyyarusso> oh, I suppose it needs a path to it.
<tonyyarusso> nope, not that either
<ara> morning!
<tonyyarusso> StevenK: do you know what that would mean?
<hyperair> hey what happened to revu? it seems to have disappeared
<hyperair> $ host revu.ubuntuwire.com
<hyperair> Host revu.ubuntuwire.com not found: 2(SERVFAIL)
<savvas> ScottK: any other packages in order to remove boost 1.34 completely?:)
<mok0> hyperair: try revu.tauware.de
<Tonio_> what happens with revu ? is it down ?
<dholbach> Tonio_: http://revu.tauware.de/
 * Yagisan suggests someone update the topic to pint everyone looking for revu to the .org address
<dholbach> http://www.ubuntuwire.com/
<ajmitch> Yagisan: you've just volunteered yourself
<slytherin> Tonio_: use .org instead of .com
<Tonio_> slytherin: oki
<dholbach> slytherin: aha!
<Tonio_> dholbach: yeah that was my problem...
<Yagisan> ajmitch, you really want to give me op's etc ??? I may even have time to google up how to keep it
<Tonio_> slytherin: is that permanent change ?
<ajmitch> Yagisan: topic isn't locked
<geser> Tonio_: AFAIR someone is working on getting .com back (it didn't got renewed)
<dholbach> Tonio_: the .com address expired - I think sistpoty and siretart talked to imbrandon about it
<Yagisan> ajmitch, O-o
* Yagisan changed the topic of #ubuntu-motu to: Jaunty Feature Freeze in effect - Go fix bugs! | https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Fix RC bugs: http://qa.ubuntuwire.org/bugs/rcbugs | Help to clear NBS list: http://people.ubuntu.com/~ubuntu-archive/NBS/ | Revu is at http://revu.ubuntuwire.org/
<Yagisan> ajmitch, better ?
<Tonio_> dholbach, geser: oki
<ajmitch> Yagisan: I guess :)
<savvas> is there a team for lpia builds?
<hyperair> mok0: okay i will thanks
<mok0> hyperair: .org works too
<slytherin> savvas: AFAIK, no.
<slytherin> savvas: What builds you are talking about, by the way?
<savvas> slytherin: http://launchpad.net/~medigeek/+archive/ppa/+build/880883 - libatlas-base-dev dependency is missing
<slytherin> savvas: the build has failed on lpia - https://edge.launchpad.net/ubuntu/jaunty/+source/atlas/+builds See if you can debug the build failure.
<savvas> slytherin: ah, thanks, I'll take a peek :)
 * slytherin loves solving recursive FTBFS. :-D
<ScottK> savvas: cgal and btk-core I think are the only two.
<hggdh> dholbach, ping
<dholbach> hggdh: pong
<hggdh> good morning -- question: a get-orig-source is expected to be a manual target, correct?
<hggdh> dholbach, ^^
<dholbach> hggdh: yep
<hggdh> dholbach, k. another: although a build usually is not expected to run automake/conf/etc, should I adjust configure.in also?
<dholbach> hggdh: in which way to you want to adjust it?
<hggdh> dholbach, bloody thing recreates ./debian/changelog, among others
<hggdh> so I wanted tp make sure it does not
<hggdh> and I was getting  tired of seeing my ./debian/changelog vanishing on each make
<dholbach> ahhhhhhhhh, that's that thing where upstream does their own debian/ stuff
<dholbach> sounds like a good idea to add a patch that modifies configure.in to not do that - indeed
<hggdh> dholbach, thank you. Should have a new source package in a few
<savvas> anyone else having problems with gmail?
<dholbach> hggdh: excellent
<hggdh> savvas, gmail is working here (3 accounts)
<hggdh> savvas, correction: *was* working :-(
<savvas> heh
<savvas> :)
<savvas> hggdh: 502 error?
<savvas> ScottK: ok, sent patch for cgal: bug 331911 - I don't know how much luck mok0 had with upstream about btk-core, but I'm trying out a patch for boost1.35 anyway: http://launchpad.net/~medigeek/+archive/ppa/+builds?build_text=&build_state=building
<ubottu> Launchpad bug 331911 in cgal "FTBFS on Jaunty" [High,New] https://launchpad.net/bugs/331911
<hggdh> savvas, I do not know (did not try via HTTP) -- I am getting  SSL negotiation failure on POP3
<hggdh> hum. Now I am getting generic DNS resolution errors across the board
<stefanlsd> savvas: my gmail doesnt work either
<savvas> cc1plus: warning: unrecognized command line option "-Wno-long-double"
<savvas> oops
<AnAnt> Hello, can someone help me with generating symbols control file, I understand that I should use dpkg-gensymbols, but dunno how
<james_w> directhex/Laney: are you familiar with the evolution-sharp 5.0 transition? stefanlsd has posted debdiffs, and I just wanted to check if there was anything special to be aware of before I sponsored.
<Laney> james_w: I think RAOF is the man for that
<directhex> james_w, i've not been dealing with it... i think RAOF is your man
<Laney> HIGH FIVE!
<stefanlsd> hehe
<james_w> heh :-)
<directhex> in his oh-so-useful timezone
<stefanlsd> i think thats an unanimous agreement.
<stefanlsd> also kinda weird actually
<james_w> stefanlsd: would you do me a favour and install the tasque that you built and have a look at https://bugs.edge.launchpad.net/ubuntu/+source/tasque/+bug/313683 and https://bugs.edge.launchpad.net/ubuntu/+source/tasque/+bug/319385 to confirm they are fixed?
<ubottu> Ubuntu bug 313683 in tasque "Tasque 0.1.8-1 does not provide any backends" [Undecided,Confirmed]
<stefanlsd> james_w: will do
<directhex> sniff sniff, smells like mono-addins 0.4-2
<directhex> no, actual evo# bugs. wheee!
<directhex> i assume errors about things missing are caused by that ;)
<james_w> yeah tasque could use some triage love, I suspect several of the newer bugs are this problem
<directhex> bam! @ monodevelop
<directhex> the last 2 addins are there now, only an ickle bit past FF
<Laney> worketh it?
<directhex> just in need of a loving sponsor (yes, i test-built in pbuilder)
<Laney> did you remember to update-maintainer?!
<directhex> for once! :o
<Laney> !!!
<james_w> heh
<james_w> Laney: are you going to sponsor those?
<Laney> not now, at work
<Laney> feel free
<stefanlsd> i wonder if i work more on work or more on ubuntu at work
<Laney> actually maybe not even today if I can't fix xorg
<directhex> stefanlsd, shhhhhhhhh!
<Laney> heh
<Laney> there's some kind of pancake cooking going on right outside my office door
<Laney> but I haven't been invited :(
<directhex> ooh, pancakes!
<Laney> I'll just walk through reeeeeeeally slowly
<Laney> looking hungry
<stefanlsd> mm. tasque is actually pretty cool
<Laney> yep
<Laney> is evo# in debian?
<Laney> yep
<Laney> stefanlsd: please forward patches
<stefanlsd> Laney: the rebuild patches for lib-evolution3.0-cil to debian?
<Laney> stefanlsd: are there changes? I didn't check it out
<Laney> no-change rebuilds will be ok
<stefanlsd> Laney: yeah, no change. Just build-deps
<Laney> ok
<Laney> check whether RAOF will just do it himself then
<stefanlsd> james_w: both those bugs appear to be fixed.  I do get backends.  ie.   EDS, local file and something called remember the milk
<james_w> stefanlsd: thanks for testing
<james_w> stefanlsd: I'll add the bug numbers to the changelog
<directhex> stefanlsd, RTM is a website
<directhex> http://www.rememberthemilk.com/
<stefanlsd> directhex: yeah. figured it was some backend that would keep a task list for you
<stefanlsd> asac: were you doing something with google gears 64?
<asac> stefanlsd: not sure. do we have a package?
<asac> ;)
<stefanlsd> asac: heh. someone was saying something about it. thought it was you. (i also wanna get it in actually)
<asac> stefanlsd: i think i commented on a packaging request?
<asac> cant remember
<slytherin> gmail is back. :-)
<RainCT> Hey
<RainCT> jpds: I've just asked - "shouldn't be a problem" if I skip classes for UDS \o/
<Laney> :O!
<directhex> RainCT, the last day of UDS is my wife's birthday, which doesn't bode well for attendance :|
<Laney> RainCT: did you apply for sponsorship?
<Laney> directhex: bring her!
<RainCT> Laney: Nope. I wouldn't feel well doing so being only 30 minutes away from BCN :)
<Laney> hah
 * Laney will apply
<stefanlsd> fta: do you know of any work on packaging  google gears for 64?
<RainCT> stefanlsd: I have it on my TODO :)
<RainCT> feel free to take it if you want, though
<slicer> I could use a bit of advice on bug #333573 . It fails to build since we've added Qt 4.5.0-rc1, which changes the way qmake works. I have a workaround ready, which I'll submit to debian, which should eventually result in a new package version available for syncing. At that point, I'll request a new sync. What do I do with the sync request I already have? Just mark it Invalid?
<ubottu> Launchpad bug 333573 in mumble "Please sync mumble 1.1.7-2 (universe) from Debian unstable (main)." [Undecided,New] https://launchpad.net/bugs/333573
<RainCT> nhandler: about your merge request, that's not a bug but a feature :P
<stefanlsd> RainCT: oh cool. yeah. I think i'll start it out and get it into revu at least.  Did you say you possibly had a ffe for it?
<directhex> Laney, if you get to UDS and i don't, then you're gonna have to be the pkg-mono spokesman!
<Laney> directhex: I will be your mouthpiece!
<Laney> we should both go and crush the free desktop dream for good
<RainCT> stefanlsd: not yet, but 64 bit support is (according to asac) a good rationale :)
<stefanlsd> RainCT: kk. thanks
<directhex> Laney, why are we asking canonical for sponsorship? getthefacts@microsoft.com!
<directhex> Laney, they'll help!
<Laney> haha
<slytherin> directhex: Laney both of you should now take the microsoft certification for .net developers. :-P
<directhex> slytherin, i don't believe in vendor certs. they lack "heart"
<directhex> slytherin, i'd gladly make a macaroni picture depicting my work with c# for any prospective employer, though
<hyperair> when there's stuff in debian/tmp or wherever, just run dpkg-gensymbols | patch bla.symbols
<james_w> slicer: you can just edit the old sponsorship request to request the new version
<RainCT> Â«Ggfgf says: Oh look a Growl ripoff       Mark Shuttleworth says: Oh look, an anonymous coward.Â» lol
<slicer> james_w: Ok, thanks :)
<ScottK> RainCT: Where is this?
<savvas> ScottK: http://www.markshuttleworth.com/archives/265
<ScottK> savvas: Thanks.
<savvas> np :)
<AdamDH> hi all, what's the best way to find out what dependancies my package requires in order to be built from source?
<bmm> The wiki states revu.ubuntuwire.com and my default /etc/dput.cf also states .com but it seems to be revu.ubuntuwire.org is that correct?
<directhex> bmm, yup
<directhex> AdamDH, a new package? try building it in a pbuilder, and keep fixing control until it works
<bmm> K, then somebody needs to have the default dput changed and the wiki should be changed. Somebody with rights should get on it ;)
<bddebian> Heya gang
<directhex> afternoon bazza
<AdamDH> directhex: its a new package, will do that and keep modifying as required
<bmm> New packages should be set to karmic instead of jaunty, right?
<rexbron> bmm: we are in a feature freeze, so unless you file for an exception, that is correct
<bmm> rexbron: thought so, thanks!
<AdamDH> the .PHONY tag do I need to list each example: I use in my rules? say if I use one called extract: does that need to be listed?
<directhex> .PHONY is your friend
<hyperair> AdamDH: i don't think it's required, but it's good to add all rules that don't refer to a file to .PHONY
<hyperair> AdamDH: as in, if i have a rule foo, that generates a file called foo, then don't add it to .PHONY, otherwise do so
<directhex> e.g. clean
<directhex> you really want clean in .PHONY ;)
<AdamDH> clean is the rule I am having problems with now hence my question as what ever I do it does not seem to run
<savvas> AdamDH: try clean:: instead of clean: :)
<AdamDH> what does the extra : do?
<savvas> I have no idea, I'm still learning, but it makes it run :)
<savvas> good question though, what does it do?
<AdamDH> im still learning as well, I am good with shell scripts just learning the way debian handles creating packages
<savvas> well, debian/rules is a makefile
<savvas> it's better to wait for someone else to reply, I'm really not that good :)
<hyperair> adding rules to .PHONY basically means run the rule even if there is a file by that name
<AdamDH> what about if its not ran when added to .PHONY?
<savvas> there should an error message then about it
<AdamDH> i will take a look at the logs once once in case I missed something
<AdamDH> this is my rules: http://paste.ubuntu.com/122435/ I get no error on clean
<ScottK> savvas: I fixed the depends problem on lpia for cgal.  Now there's a header path issue: https://launchpad.net/~kitterman/+archive/ppa/+build/881158
<hyperair> hmm is it possible to create a karmic pbuilder yet?
<hyperair> AdamDH, savvas: rule:: means that you can declare it multiple times, and they're appended
<hyperair> basically i can have somerule:: something at the top, and then somerule:: somethingelse at the bottom, and then it'll just append everything
<hyperair> it's used a lot in CDBS
<hyperair> basically CDBS declares the rules with ::, so you can hook onto the end of them and run some stuff
<ScottK> I notice now that there's a rules change needed too.
<AdamDH> this is my rules files, http://paste.ubuntu.com/122435/ not sure why clean is not been ran
<AdamDH> will append a :
<AdamDH> just not seen a clean: in the examples so was looking to see if anything else was wrong
<AdamDH> clean:: sorry
<stefanlsd> yay. built a x86_64 xpi of google gears. seems to work ok.
<AdamDH> ah got it to work
<Laney> stefanlsd: can you hax it to work with ff 3.1 at all?
<AdamDH> if I paste my working rules files in a mo can some one just take a look to see if I missed anything? I will then add it to my ppa so I can get a few people to try it
<stefanlsd> Laney: can have a look at it. i was just gonna start packaging a .deb now so we can maaaybe get it into jaunty
<stefanlsd> Laney: do you want to try this xpi in 3.1?
<RainCT> ls
<stefanlsd> hehe
<RainCT> :$
<AdamDH> my clean rule is ran at the start of the build but not after the build so it leaves temp files lying about any ideas why?
<RainCT> AdamDH: that's the expected behaviour
<AdamDH> ah did not know that
<RainCT> AdamDH: you can run   fakeroot debian/rules clean   to clean up the source directory
<Laney> stefanlsd: I will later. I tried it from google's site and it wasn't compatible. I just wondered if you haxed the xpi whether it would work
<RainCT> if someone from motu-sru is around please have a look at bug #333902
<ubottu> Launchpad bug 333902 in webboard "Please upgrade webboard to version 0.2.2" [Undecided,New] https://launchpad.net/bugs/333902
<AdamDH> thanks RainCT I was not expecting that behaviour
<RainCT> AdamDH: No problem. It's useful in case you have to debug something, etc.
<AdamDH> this is my final rules file and it creates a working deb http://paste.ubuntu.com/122444/ can any one tell me if there is anything I could improve?
<RainCT> uhh nice :)
 * RainCT falls asleep waiting for Launchpad to load a page :'(
<RainCT> oh, it opened
<AdamDH> RainCT launchpad seems slow today, trying to upload a package to my ppa seems to be taking its time
<RainCT> not only today, it feel it like this since a few weeks already
<AdamDH> well we are on alpha4 so probally the reason why!
<RainCT> nobody uses alpha 4 (compared with the amount of people who will use the final version..)
<maxb> AdamDH: for the sanity of everyone else who ever needs to look at that rules file, *please* use standard 1-tab indentation
<maxb> also, as I've said before, the entire concept of remove-patch-stamp is fundamentally invalid
<maxb> furthermore, use CURDIR
<AdamDH> maxb, forgot I still have the clean patches in there I will remove that, I will clean up the rules a little
<maxb> Also, cd-ing just to exec rm is overcomplicating things, rm -f $(CURDIR)/whatever
<AdamDH> I always considered cding more robust
<AdamDH> I will alter all these small things and get it put into my ppa
<AdamDH> maxb I am using msp430-binutils-2.18-msp430-cvs.0.0.20090224 as my version as I am applying a patch to the upstream binutils. If my next package is msp430-gcc-3.2.3-msp430-cvs.0.0.20090224 in control for the next package how do I tell it to depend on msp430-binutils? just put msp430-binutils-2.18?
<maxb> msp430-binutils-2.18-msp430-cvs.0.0.20090224 is not a version, nor a package_version fragment of a dpkg filename, please clarify what you actually mean
<AdamDH> I used msp430-binutils-2.18-msp430-cvs.0.0.20090224 as the version for my package, where msp430-binutils-2.18 was the upstream version and the rest showing the patch came from cvs
<AdamDH> I came up with that after asking for advice here
<maxb> No, 2.18 is the upstream version
<AdamDH> yup thats what I said?
<maxb> You said msp430-binutils-2.18
<AdamDH> sorry yes see what you mean
<AdamDH> 2.18 is the upstream version and msp430-binutils is the package
<maxb> 2.18-msp430-cvs.0.0.20090224 is a bad version because versions should not contain multiple - characters unless the upstream version does
<maxb> s/does/contains any/
<AdamDH> my version should be 2.18-msp430-cvs.0.0.2009022
<maxb> Is the patch contained within your .diff.gz? Or is part of the patch applied in the .orig.tar.gz ?
<maxb> Where is the cvs repository in question?
<AdamDH> mspgcc.sf.net is where the CVS repository is
<AdamDH> I am applying it to the upstream source and the patch is contained within the tar.gz I do not have have a .orig.tar.gz I just called it binutils-2.18.tar.gz and applied the patch to that
<AdamDH> I created the patch from CVS sources
<maxb> binutils-2.18.tar.gz is horribly misleading because that is a name that is used by a real upstream binutils release
<AdamDH> yup maxb I agree but my patch is applied to that upsream release to create a cross compiler
<AdamDH> the whole project is a mess and missleading
<AdamDH> so it seemed better to show what upstream version I was working on
<maxb> The cvs repo you pointed me to contains "binutils/NO_LONGER_MAINTAINED" that requests people now use official binutils releases, so where's the patch coming from?
<maxb> "The standard binutils package, available at http://sources.redhat.com/binutils, now contains this MSP430 support. " says the website
<AdamDH> that is not true, the patches are inside packaging/patches
<AdamDH> the mailing list discusses what patches need to be applied to create a working version, nothing has been taken upstream
<AdamDH> so there is 3 patches to be applied to 2.18 before it will work with all msp430 devices
<maxb> You might consider asking upstream to fix their website, then :-)
<AdamDH> maxb its all a mess so my packages were supposed to take the headache out and leave programmers to programme instead of spending hours getting a working toolchain
<AdamDH> my binutils package works and so does gcc just need to work on libc
<maxb> Right. The nicest way to package this is to use the *original* *upstream* binutils-2.18 tarball, and to include the three patchfiles from mspgcc cvs within the debian/patches/ directory of your package, and to apply them in debian/rules
<maxb> Your version number then can simply be 2.18-0ubuntu1
<AdamDH> my package uses the orginal upstream tar ball and inclues the patches in a folder called patches, the patch as they just give the modified files on the cvs and expect you to copy over to the upstream source, I instead created a patch that could be applied to the upstream source. But how do I show what revision the patch is as that comes from CVS?
<AdamDH> *tarball
<AdamDH> if I keep with the 2.18-msp430-cvs.0.0.20090224 in the control for gcc that depends on binutils what do I put? just msp430-binutils and it uses what ever version is in the ppa?
<maxb> <AdamDH> my package uses the orginal upstream tar ball and inclues the patches in a folder called patches, the patch as they just give the modified files on the cvs and expect you to copy over to the upstream source, I instead created a patch that could be applied to the upstream source. But how do I show what revision the patch is as that comes from CVS?
<maxb> huh?
<maxb> I see three patch files for 2.18 in the cvs directory you pointed me to
<AdamDH> ah there are now, gcc has no patches tho that is the same case as before
<maxb> OK, but since binutils does have patches, I stand by what I said.
<AdamDH> so you would just call it by its upstream name in the case of binutils?
<maxb> AdamDH: I suggest you've reached the point where you should put your binutils package at least to REVU
<AdamDH> I have a PPA on launchpad will that do?
<maxb> AdamDH: PPAs build binaries, REVU doesn't, but it allows users to add comments.
<AdamDH> i will take a look at revu
<maxb> wiki.ubuntu.com/REVU
<hyperair> does anyone knoew if karmic packages will be reviewed? =\
<hyperair> can you even get a chroot for testing on karmic?
<RainCT> hyperair: that depends on how generous you are :P
<ScottK> Not until after Jaunty release most likely.
<hyperair> RainCT: how generous *I* am?
<hyperair> RainCT: if i'm very generous, then the revu queue will grow bigger ;)
<RainCT> heh
<fabrice_sp_> Hi, pigment-python is marked as FTBFS in qa.ubutnuwire.org/ftbfs, but I've built it successfully with an updated sbuild. I think that the dependency was compiling when  the build was running (http://launchpadlibrarian.net/23007901/buildlog_ubuntu-jaunty-i386.pigment-python_0.3.10-1_MANUALDEPWAIT.txt.gz). Is it possible for some admin to relaunch the build? Or do I have to force a new version with a debdiff?
<pochu> fabrice_sp: if it's in universe, I can retry it
<fabrice_sp> Hi pochu! yes, it's in universe
<fabrice_sp> :-D
<pochu> err
<pochu> fabrice_sp: it didn't FTBFS, it's DEPWAIT
<pochu> fabrice_sp: it will be built once the dependency it needs is available
<savvas> ScottK: I forgot who, but someone in the channel suggested that we could also debug the atlas problem: https://launchpad.net/ubuntu/jaunty/+source/atlas/+builds
<pochu> so nothing to retry ;)
<ScottK> savvas: atlas is a hairy mess.  I'd prefer to avoid it if we can.  If you can fix that, it'd be wonderful.
<savvas> pochu: in PPA? they're automatically retried once the dependency is satisfied?
<pochu> savvas: no, in the archive
<savvas> ah, I was prepared for a hug :P
<pochu> savvas: I guess it's the same in the PPA, but I'm not sure
<fabrice_sp> hmm: pigment 0.3.14 has been build :-/
<emgent> hello
<savvas> ScottK: I'll try both sides, see what can be done :)
<fabrice_sp> pochu, http://launchpadlibrarian.net/23033637/buildlog_ubuntu-jaunty-amd64.pigment_0.3.14-1_FULLYBUILT.txt.gz. (14 hours ago). What is the frequency of the retry?
<a|wen> fabrice_sp: did the binaries get out of binary new?
<fabrice_sp> a|wen, good point. How can I check that?
<a|wen> fabrice_sp: https://launchpad.net/ubuntu/+source/pigment/0.3.14-1/+build/879857 ... look to the right
<a|wen> fabrice_sp: "Binaries awaiting acceptance:" so not yet
<fabrice_sp> got it!
<a|wen> :)
<fabrice_sp> thanks and sorry for the noise :-)
<savvas> architecture armel in ubuntu is arm in debian?
<ScottK> savvas: No.  armel in bother
<ScottK> bother/both
<ScottK> Debian released Lenny with arm and armel, but arm is to be dropped soonish.
<savvas> oh, ok :)
<savvas> ScottK: is it similar to arm, something like i386 with lpia?
<savvas> with = and
<ScottK> Not exactly, but not so far off.
<ScottK> I don't recall exactly.
 * savvas crosses fingers
<savvas> I've noticed that in atlas there's not a folder for lpia nor for armel in debian/, but there is one for the rest of the architectures
<savvas> I'll have to make a pbuilder for lpia for this one, seems quite big to upload to a ppa :)
<salty-horse> hi. vlc on jaunty has the video detached from the controls, and it seems to not respect the "integrate video in interface" option. compiled from git it works fine... known bug?
<savvas> salty-horse: known :)
<salty-horse> I'm not worrying then :D
<savvas> salty-horse: you should be - it's a killer bug, if they allow integration, vlc will crash: bug 314038
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/314038/+text)
<savvas> woops
<savvas> https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/314038
<ubottu> Ubuntu bug 314038 in vlc "Integrated video interface is broken in Jaunty" [Undecided,Confirmed]
<savvas> salty-horse: I have a package for it integrated, but vlc crashes when I press stop :P
<ianto> With the Debian Policy Manual, does anyone know what section a code analyser for C++ would come under? âutilsâ perhaps?
<RainCT> ianto: devel?
<RainCT> ianto: Btw, if you look at http://packages.debian.org/unstable/, you have the sections there but with a description :)
<RainCT> (they have fancy names there, but if you look where the URLs point to you'll get the real name)
<ianto> RainCT: Ah right OK thanks, I thought that devel was more for the compilers & coding tools themselves rather than analysers; although I guess that it is too a development tool :-/
<_ruben> when using module-assistant, is it possible for a -source package to have a dependency on package-x.y.z-dev, where x.y.z is the kernel version for which you want to build a kernel using module-assistant?
<directhex> m-a? how retro
<_ruben> never got the hang of dkms
<_ruben> and dkms doesnt produce "distributable" packages, or does it? like i said, never really got the hang of that one
<RainCT> _ruben: afaik it compiles the modules at boot, so that if the kernel version changes they are just recompiled on the user's systems and the users don't have to wait for a new version
<superm1> it also has support for mkdeb or mkdsc if you want to build distributable packages
<_ruben> RainCT: which is not what i want really, as i dont want a build environment on all machines
<_ruben> superm1: interesting
<_ruben> but the question kinda remains the same .. is just a dependency possible?
<superm1> _ruben, it's almost inevitable to have a build environment on all machines unless you can control them to never run different kernels
<_ruben> superm1: i upgrade my "m-a packages" when i upgrade kernel .. no build env needed
<_ruben> got a buildhost to build new packages when needed
<superm1> _ruben, well you can do the same thing with dkms, it's the same tools you need for building
<stefanlsd> RainCT: i have a gg 64 ff3.0+ xpi built
<superm1> _ruben, DKMS can just handle that portion for you
<RainCT> stefanlsd: as a .deb?
<_ruben> superm1: i'll definately look into dkms once again, hopefully 3rd time's a charm ;-)
<stefanlsd> RainCT: xpi mainly. i just built a test .deb of the xpi following the mozilla-team extensions guidlines. so i do have a .deb and it installed. its just not really clean yet.. (changelog, copyright etc)
<RainCT> stefanlsd: OK. Got the source from Google Code?
<stefanlsd> RainCT: yeah
<RainCT> stefanlsd: Great. Poke me once it's ready and I'll review it :)
 * RainCT hugs stefanlsd 
<_ruben> as for the initial query .. i currently have 2 -source packages, but the 2nd has a dependency on a Symbols.symvers file that's created by the first .. which unless im missing something is a nasty dependency to properly fix ;)
<stefanlsd> RainCT: do you know if it will be acceptable to use the compiled xpi?
<RainCT> stefanlsd: the .xpi should be created at build time
<stefanlsd> RainCT: the mozilla team currently uses .xpis they get. maybe those xpi's dont contain .so's tho
<stefanlsd> RainCT: source is bout 300mb :|
<RainCT> stefanlsd: Oh (yeah, it took some time to checkout the source here but I haven't looked at it yet). Where does the xpi come from then?
<RainCT> and, how are you patching it for 64bit?
<stefanlsd> RainCT: the make of the source generates the xpi.  the source is patched to get it to compile
<RainCT> stefanlsd: So what's the problem?
<RainCT> stefanlsd: that you want to generate the xpi locally and only put the xpi into the source package to avoid the 300mb, or what?
<stefanlsd> RainCT: yeah. essentially
<ScottK> savvas: https://launchpad.net/~kitterman/+archive/ppa/+build/881570
<tonyyarusso> All right, I'm back at this and need a bit about gdb usage explained to be, specifically breakpoints and printing variables.  So far whenever I've tried to set a break I get Function not defined, make depend on future shared library?
<RainCT> stefanlsd: 19M  gears/
<RainCT> stefanlsd: did you get ride of the .svn directories?
<stefanlsd> RainCT: i did. i also builds against some of the 3rd party stuff. need to check exactly what. i know gecko_1.8 and gecko_1.9.
<stefanlsd> and theres a hack there also. You need to copy the xulrunner-dev  xpcom 64 .so's over those...
<RainCT> stefanlsd: that third_party directory looks really evil :P
<savvas> ScottK: that's great! one more to go then :)
<RainCT> stefanlsd: well, best ask asac if you have any problem, he's the real Fx master :)
<ScottK> savvas: mok0 filed a removal bug for btk-core, so I think we're done.
<stefanlsd> RainCT: kk. will do. I essentially wanna find out if we need to go from source. if so, i'll start cleaning it up, hopefully get the size down
<savvas> ScottK: does that mean that atlas wasn't necessary?
<stefanlsd> RainCT: at least then we can also link against the ubuntu build time libaries.
<ScottK> It will build without it.  If you look in debian/control you'll see it's excluded on quite a number of architectures.
<savvas> true, I missed that
<ScottK> savvas: You've been a big help on this.
<savvas> ScottK: I wish I could provide more help, but my knowledge in programming and packaging is limited - it was good for learning and practice! Do you have anything else similar on transitions? :)
<Teddy___> Ubuntu has an old version of my package.  How can I make sure the newer (actually working) version is included in Jaunty?
<ScottK> Teddy___: What package?
<ScottK> savvas: Nothing comes immediately to mind.
<ScottK> Getting rid of old GCC versionsis always 'fun'.
<Teddy___> ScottK: "mandos"
<savvas> mandos seems to be taken from debian
<savvas> http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=mandos
<Teddy___> savvas: Yes, it is.
<ScottK> Teddy___: Is it just bug fixing between what we have and what's in Debian?
<Teddy___> savvas: But Debian now has version 1.0.5-1, and will soon have 1.0.7-1, but Ubuntu is still on 1.0.2...
<Teddy___> ScottK: Yes, more or less.
<ScottK> Teddy___: Ubuntu works on 6 month release cycles.  In the first part of the cycle we automatically sync packages from Debian that we get unmodified from them.  At this point a sync would have to be requested.
<Teddy___> ScottK: ...  So what do I do?  The 1.0.2 version has some rather bad bugs, and 1.0.7 is completely compatible with only minor feature additions.
<ScottK> Teddy___: Or since the latest version isn't in Debian yet, you could file a bug in Launchpad and attach the .diff.gz to the bug.  If you 1.0.7-1/-0ubuntu1 and unstable/jaunty your package should be equally good for Ubuntu
<ScottK> Teddy___: Since we are post feature freeze for this release you'll need to give the information for a feature freeze exception.
<savvas> I think it fits the freeze exception :) https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze%20Exceptions
<Teddy___> ScottK: ...And what information is that?  And to whom do I give it?
<ScottK> You put it in the bug and subscribe motu-release to the bug.  It's described in the link savvas just gave you.
<Teddy___> ScottK: Thanks, I'll check it out.
<Teddy___> ScottK: To report a bug on launchpad, I'll have to register Yet Another Damn Account...
<ScottK> Yes.  Yes you will.
<ScottK> Sorry.
<Teddy___> ScottK: And it doesn't even support OpenID
<ScottK> It does, but only as a provider.  It'd actually be better if supported it less from a security perspective.
<ScottK> For developers Launchpad passwords have actual security implications which makes OpenID completely inappropriate.
<aeg37> hello everyone
<Teddy___> ScottK: I'll drop this for now; I don't like registering new accounts all the time.  Maybe someone else has an existing Launchpad account.
<ScottK> Teddy___: Ping me after it's in Debian
<Teddy___> ScottK: Ping?  Sure, will do.
<jdstrand> \sh: hi-- on bug #331410, were you able to reproduce it?
<ubottu> Launchpad bug 331410 in net-snmp "CVE-2008-6123: not fixed in latest security releases" [Undecided,In progress] https://launchpad.net/bugs/331410
<ScottK> savvas: If you want another puzzle, there is https://launchpad.net/ubuntu/+source/bmpx/0.40.14-1ubuntu1/+build/876596
<ScottK> That will also block the boost removal.
<savvas> hm.. checking for C64_clockSpeed in -lsidplay... no
<savvas> configure: error: libsidplay 1.x not found!
<savvas> dependency error?
<savvas> I'll check it out
<RainCT> jpds: What do you think about backporting espeak?  (The version in Jaunty has support for Catalan :)).
<ScottK> I suspect it'll end up being a kernel bug, but I don't know for sure.  I didn't have time to research it.
<RainCT> bah he's away
<savvas> can I use pbuilder to create powerpc packages?
<mdke> hi there. I've been looking through the various guides on the wiki and it is all very good. But I can't see how to actually upload a package to ubuntu, short of "use dput". Is there a more detailed document?
<ScottK> savvas: No, you need powerpc hardware for that.  TheMuso might be able to help you out.
<mdke> Launchpad has some quite good instructions on dput for PPAs but I wondered if there is an equivalent guide for Ubuntu
<TheMuso> savvas: Is there a specific reason you need to make powerpc packages?
<savvas> TheMuso: I'm looking at a failed build on bmpx powerpc: https://launchpad.net/ubuntu/+source/bmpx/0.40.14-1ubuntu1/+build/876596 - but no, not yet, I'll let you know if I come up with something :)
<TheMuso> savvas: hrm ok. Unfortunately I can't currently help, since I don't have a working powerpc jaunty install, due to various testing, and discovering some bits of breakage, however I should have that sorted by later today.
<mdke> ah, I've found this now, looks to be what I'm after - https://wiki.ubuntu.com/DeveloperGuide/Uploading
<savvas> TheMuso: ok, thanks!
<savvas> ScottK: could we possibly disable sid in debian/rules? --disable-sid instead of --enable-sid ?
<RainCT> mdke: see also https://wiki.ubuntu.com/MOTU/New
<ScottK> savvas: Dunno.  I haven't taken a look at it.
<mdke> james_w: thanks for that page (DeveloperGuide/Uploading), very useful - I think it would be useful to put a link on UbuntuDevelopment
<mdke> RainCT: ok, thanks
<james_w> mdke: too much of a WIP for that yet in my opinion
<mdke> james_w: ok, your call, but I found it very clear
<mdke> james_w: so thanks :)
<james_w> mdke: glad to help
 * RainCT agrees, nice page :)
<RainCT> james_w: ppa:<name> is only available on Jaunty, or?
<james_w> erm
<james_w> yeah, I think that's right
<james_w> Cody's clever idea
<RainCT> Yeah, it's *much* better than having to edit dput.cf
<savvas> When using -lsomelibname does it retrieve libsomelibname.so (as in, "lib" in filename) ?
<savvas> ah, yes
<slicer> quadrispro: Hi. About bug #333573. I was told earlier today by james_w to edit the original sync request once the bug was fixed in debian (it now is, 1.1.7-3 was released a few hours ago -- just waiting for PPA build on i386 to finish to be absolutely sure). Should I still do that, or should I create a new sync request?
<ubottu> Launchpad bug 333573 in mumble "Please sync mumble 1.1.7-2 (universe) from Debian unstable (main)." [Wishlist,Invalid] https://launchpad.net/bugs/333573
<quadrispro> hi slicer, no, updating #333573 is good
<anakron> hi all
<anakron> ping Laney: Hi !! how are you? im interested to show you some things that i worked
<Laney> anakron: Hi! Sorry I've been away
<slicer> quadrispro: Ok. So I just set it back to it's original state (new, undecided) and post a comment with the changelog? (Assuming the PPA build finishes successfully)
<anakron> ok
<Laney> let's have a look
<quadrispro> slicer: setting "new" again and change the description (instead of adding another comment)
<quadrispro> is good :)
<slicer> quadrispro: Ok, will do. Thanks.
<quadrispro> slicer: I'm already subscribed, feel free to assign that but to me
<quadrispro> s/but/bug
<anakron>  https://bugs.launchpad.net/ubuntu/+source/qtpfsgui/+bug/309740
<ubottu> Ubuntu bug 309740 in qtpfsgui "no menu icon" [Undecided,Confirmed]
<anakron> I'll review one now and then I'll tell iy to you Laney
<anakron> HI again
<anakron> damned mplayer
<Laney> hi anakron
<Laney> anakron: Are you familiar with patch systems?
<anakron> yes
<anakron> why?
<Laney> I notice you changed project.pro without using it, when the package uses quilt
#ubuntu-motu 2009-02-25
<anakron> ups
<anakron> yes :-)
<Laney> A couple of other things - the version should have been 1ubuntu1
<anakron> im not too familiar with this
<Laney> and you should put the .xpm inside debian/
<anakron> yes...
<anakron> ...
<anakron> o
<anakron> ok
<anakron> how i can do it
<anakron> create a new patch?
<Laney> anakron: I wonder if this patch is really necessary anyway? The bug is really minor in any event and introducing the change in Ubuntu means we have to maintain the patch until Debian or upstream take it
<anakron> yes i know it
<anakron> and this one?
<anakron> https://bugs.launchpad.net/ubuntu/+source/firestarter/+bug/301603
<ubottu> Ubuntu bug 301603 in firestarter "Impossible to launch firestarter" [Undecided,Confirmed]
<anakron> i edit a patch that changes su-to-root -X -c to gksu -X -C, but gksu does'nt have these options
<Laney> shouldn't su-to-root work fine?
<anakron> yes It will work
<anakron> but the package have this patch
<anakron> that change su-to-root to gksu
<anakron> i don't know why
<anakron> but add gksu with -X -c
<Laney> what about kde users who don't have gksu?
<anakron> Laney
<Laney> You need to add a dependency on it for it to be available
<anakron> i know that su-to-root its better for upstream than gksu
<anakron> but, the maintainer set it
<anakron> i could change it
<anakron> or set it as dependence
<Laney> aha, I misunderstood you
<Laney> I thought you removed su-to-root ;)
<anakron> :)
<anakron> the problem is that the patch set gksu with -X -c
<anakron> so, i remove -X -c
<Laney> yeah, I get it
<Laney> I don't understand the original patch though - drop it and it seems to launch fine
<anakron> but i can change it and add gksu in dependences
<anakron> i can't too
<Laney> anakron: I think whoever did the last merge was wrong
<anakron> ill see debian package
<Laney> From reading bug 5269 it looks like the package originally used gksudo
<ubottu> Launchpad bug 5269 in firestarter "Menu location" [Medium,Fix released] https://launchpad.net/bugs/5269
<Laney> but Debian changed to use su-to-root with -7, so we should have gone with this change
<Laney> anakron: If you do a debdiff which drops the patch (and confirm it works) then I will be happy to sponsor that
<anakron> ok
<directhex> Laney, monodevelop debuggers, tuppence a bag!
<directhex> Laney, got X going again then?
<Laney> directhex: metacity compositor was the culprit here
<Laney> although scrolling is still pretty slow especially in FF
<directhex> silly metacity
<directhex> evilwm!
<Laney> I want my freedom-hating fglrx back :(
<anakron> Laney, how i can take this patch away? it use dpatch
<anakron> im trying
<jmarsden> anakron: edit debian/patches/00list
<anakron> but
<anakron> that is all?
<anakron> i thought in it
<jmarsden> Well, you can delete the actual patch file too, once you are sure you want to get rid of it.
<Laney> yep
<Laney> delete it from 00list and then delete the actual file
<anakron> actual file, patch file?
<anakron> the last and first patch says that desktop file should use gksu
<Laney> uh, confusing
<anakron> yes
<anakron> its weird
<anakron> because first
<anakron> desktop file says that Exec=firestarter, then apply 1st patch to > gksu firestarter
<anakron> then i dont know which one but it changes to su-to-root
<anakron> and the last patch changes it to gksu
<anakron> xD
<anakron> I'll take away the last patch
<Laney> :q
<Laney> you aren't vim!
<anakron> Â¿?
<Laney> anakron: grep -r su-to-root . in the package directory will find it
<anakron> ok
<Laney> It seems like there were three patches touching the same line in Ubuntu
 * Laney spanks everyone concerned
<anakron> hi mruiz
<mruiz> anakron, hi
<Laney> anakron: please write in the changelog that no Ubuntu changes remain
<anakron> why?
<mruiz> anakron, sync?
<anakron> yes it seems
<Laney> so that the next uploader knows this
<anakron> I'll look at debian package
<mruiz> anakron, if Ubuntu changes are dropped they must be included by upstream or Debian
<Laney> or more correctly, the person who merges it next
<anakron> ok
<anakron> grep -r su-to-root still looking for, but nothing appears
<Laney> laney@chicken> grep -r su-to-root .                                ~/dev/ubuntu/packaging/firestarter/firestarter-1.0.3
<Laney> ./debian/patches/11_desktop_file.dpatch:+Exec=su-to-root -X -c /usr/sbin/firestarter
<anakron> mm here nothing happens
<anakron> xD
<anakron> it seems that the first patch must be deleted  and this one must be edited
<anakron> and the last patch must be deleted too
<Laney> what happens if you just delete 25?
<anakron> but the first patch is useless
<Laney> you should report a debian bug about it
<anakron> it's more easy to just delete 25
<savvas> ScottK: I found a patch that might fix the bmpx build for ppc/powerpc: http://paste.ubuntu.com/122614/ - http://www.mail-archive.com/pld-cvs-commit@lists.pld-linux.org/msg149860.html
<Laney> we don't want to make additional changes over Debian if we can help it
<anakron> i think that for this bug I only delete 25
<anakron> and then I'll do changes and report it to debian directly
<Laney> yes, that's a good way to do it
<savvas> ScottK: I'm trying the patch in PPA, to see if it works for normal architectures as well: http://launchpad.net/~medigeek/+archive/ppa/+builds?build_text=&build_state=pending
<ScottK> savvas: Great.  Let me know how it goes.
<btm> ScottK: with gems drama and all, we're back in sync with debian, right?
<ScottK> If the sync from experimental gets done, yes.
<btm> ScottK: I guess I meant policy wise / culture wise. Cool.
<ScottK> The one gems diversion did not stand, so I don't think it ended up being a significant diversion.
<ScottK> It was mostly a question of enough people knowing.
<Laney> gah
<Laney> can we start uploading notification fixes?
<Laney> I am about to rip Banshee's face off
<ScottK> Laney: Got FFe?
<Laney> ScottK: Is it a feature?
<ScottK> Certainly.  Changing the system to integrate with a different notification system is definitely a feature.
<ScottK> Not complying with something that isn't even a spec is not a bug.
<Laney> Well the feature was introduced in the new notify-osd package. Is not what we have now a series of bugs in upstreams (not checking for capabilities)?
<Laney> I guess you could argue that making notifications-with-actions into alerts is a misfeature
<ScottK> Laney: Where is there any standard that requires checking for features?
<ScottK> One can't take a draft, unapproved standard that is still under negotation, implement something new from it and then declare all non-supporters of this new feature buggy.
<ScottK> Well one can, but it's really not cricket IMO.
<Laney> Right; it has been done, and now we must implement the fixes.
<Laney> I don't see the point in requiring paperwork to do so, since there is really no way we are going to leave the behaviour as it is now
<anakron> https://bugs.launchpad.net/ubuntu/+source/firestarter/+bug/301603
<ubottu> Ubuntu bug 301603 in firestarter "Impossible to launch firestarter" [Undecided,Confirmed]
<anakron> Laney, here it is
<Laney> thanks
<Laney> anakron: It doesn't build
<Laney> applying patch 01_use_gksu to /build/laney-firestarter_1.0.3-7ubuntu2-amd64-hUSBIB/firestarter-1.0.3-7ubuntu2/debian/patches ... failed.
<anakron> Â¿?
<anakron> i built it and then i create a debfile
<anakron> and runs ok
<anakron> mmm ill see it
<anakron> http://pastebin.ubuntu.com/122624/
<anakron> i make debuild -S
<anakron> and then dpkg-buildpackage
<Laney> anakron: You should use pbuilder or sbuild to build packages
<anakron> ups
<Laney> often problems can be missed by using debuild/dpkg-buildpackage alone
<tonyyarusso> Would someone be willing to explain gdb breakpoints to me?  I'm trying to examine the values of a variable at various points in the execution of a program (finch), and when I try setting one it tells me the source file isn't found.
<mruiz> Laney, good point
<anakron> mm
<anakron> ok
<StevenK> tonyyarusso: You need to instruct gdb where to find the source
<tonyyarusso> StevenK: aaaah.  How do I go about that?
<StevenK> tonyyarusso: Step 1) Get the source
<tonyyarusso> Got that.
<xoox> Is there a way to check from the command line what the version of a package is in a given release?
<StevenK> xoox: rmadison
<StevenK> However, that will only cover supported releases
<StevenK> It requires Launchpad and a shovel to find out for unsupported releases
<tonyyarusso> Is it just cd?  (http://www.chemie.fu-berlin.de/chemnet/use/info/gdb/gdb_5.html#SEC20)
<xoox> Thanks StevenK
<StevenK> tonyyarusso: Sounds plausible
<Laney> anakron: I fixed a problem with a missing build-dep and now it's OK
<anakron> ok
<anakron> :) i do it when i try to do dpkg-buildpackage
<tonyyarusso> StevenK: That gets me to a different error at least, so progress.  Now it says "No symbol table is loaded.  Use the "file" command."  (just typing 'file' says "No executable file now, No symbol file now")  I passed -g and -gstabs in CFLAGS when I compiled, but I'm entirely certain what that does / how to make use of it.
<StevenK> tonyyarusso: Why did you feed into gdb to get that error?
<tonyyarusso> uh, "Why" or "What"?  I had just said 'break save_pounce_cb' (that being a function I want to stop at)
<savvas> ScottK: good news, lpia built! https://launchpad.net/~medigeek/+archive/ppa/+build/882034 - still waiting for i386 and amd64 though
<tonyyarusso> Sounds like I have to tell it how to load symbols?
<tonyyarusso> oh, found that.  'file /usr/bin/finch' is what it wanted.
<tonyyarusso> StevenK: I was able to get a bit further now.  http://paste.ubuntu.com/122638/  a) I'm not sure why I'm getting that message about No such file or directory, b) How do I make sense of 0x8242158?  (dialog->on_status is what I'm concerned with)
<Laney> anakron: I just uploaded it, thanks for your contribution
<anakron> :)
<anakron> thanks to you
<Laney> now to see if it also ftbfs on sid
<Laney> then I should go to sleep
<anakron> when is UDS?
<StevenK> anakron: https://wiki.ubuntu.com/UDS
<anakron> ok
<Laney> I just applied for sponsorship \o
<Laney> shot in the dark, but might as well try
<anakron> :)
<anakron> hey laney
<anakron> one question, what can i do for this desktop file http://pastebin.ubuntu.com/122641/
<Laney> yo
<Laney> what's wrong with it?
<tonyyarusso> I'm guessing 0x8242158 is a memory register address or something, but I need to be able to see the actual data (a pointer that actually just contains an integer, I want to know the integer) stored there.
<Laney> do you know about desktop-file-validate?
<anakron> because desktop-file-validate says that is not valid character
<anakron> yes
<Laney> right
<ScottK> savvas: If you think you have it figured out, we should ask TheMuso if he'll do a powerpc test build.
<anakron> but i can't validate it
<Laney> you can replace it with Ã¶
<Laney> the utf-8 character
<LaserJock> what's a good practice for changelog entries when Debian hasn't released yet?
<anakron> :O ok
<anakron> how i do it
<LaserJock> i.e. when you're uploading something based on a Debian VCS version
<Laney> anakron: But this is the kind of change we don't need to make
<anakron> ok
<Laney> LaserJock: I like -1~ubuntu1, but personal preference
<Laney> -x~ubuntu1, generally
<LaserJock> Laney: and do you keep the Debian entry even if it hasn't been uploaded yet?
<Laney> LaserJock: I keep it, but add a comment at the top under my name: "uploading Debian SVN revision"
<Laney> then the reason
<tonyyarusso> ~ubuntu1?  I thought it was -0ubuntu1.  :S
<Laney> Some people like that too (for new upstream versions). I think that ~ubuntu1 makes the heritage of an upload clearer
<LaserJock> the problem is that Debian has a -1 entry, and then I'm going to add on top of that a -0ubuntu1, a lower version
<LaserJock> that seems weird to me
<Laney> I don't think LP would even let you upload
<LaserJock> I would think it would
<Laney> Oh, *debian* has it
<Laney> yeah, that would work
<Laney> you could either rename -1 to -0ubuntu1 or -1~ubuntu1. Doesn't matter really
<LaserJock> Debian has an un-uploaded -1 entry
<LaserJock> well, I guess it doesn't matter a bunch, but I am going to make it UNRELEASED
<savvas> ScottK: I'll try and test it locally in about 10-15 minutes
<LaserJock> just so people know Debian hasn't uploaded it yet
<ScottK> OK.  Great.
<Laney> bed
<Laney> night all
<ScottK> Laney: -0ubuntu1 is the standard way to do it.
<theholyduck> if say. i wanted ubuntu to come with a non horribly broken x264, ffmpeg and mplayer, could i volenteer to motu and make updated packages for them?
<superm1> theholyduck, what's wrong with those packages?
<theholyduck> superm1, ffmpeg is built from a horribly old svn snapshot. x264 is built from a horribly old git snapshot. and mplayer is built from a release from 2007 instead of a svn snapshot
<theholyduck> all 3 packages are unsported and unstable for anything OTHER than latest svn
<theholyduck> but ubuntu still packages bad versions of them
<superm1> theholyduck, well for mplayer, that's the latest stable release
<superm1> 1.0~rc2
<theholyduck> superm1, well yes :P
<theholyduck> but svn is WAY stabler
<savvas> ScottK: it works on amd64 :)
<theholyduck> faster, and more usable
<theholyduck> than that release
<theholyduck> mplayer doesnt DO releases
<ScottK> great.
<theholyduck> wich is why its their "Latest stable"
<superm1> theholyduck, well you can certainly do the work to file a group of FFe's for these and have the motu-release time evaluate them if you are interested
<superm1> there would be no guarantees such things would be accepted, but that would be the process
<superm1> theholyduck, you might want to talk to siretart before you do so though
<theholyduck> superm1, well i currently resorted to writing a script for dling all deps and building and making a .deb for local system use
<theholyduck> so that all the ubuntu users who clog up #Mplayer #ffmpeg and #x264 could get up to date pacakges
<theholyduck> it doesnt do actual .deb packaging just checkinstall
<theholyduck> but i cant see why ffmpeg and x264 gets developement versions but mplayer doesnt.
<theholyduck> and why the developement versions dont get updated more frequently
<theholyduck> x264 and ffmpeg both enjoy very rapid developement
<superm1> theholyduck, i would imagine they generally have implications on other packages
<superm1> such as the gstreamer stack (for ffmpeg)
<theholyduck> doesnt gstreamer use its own package with its own ffmpeg
<theholyduck> gstreamer-ffmpeg or whatever?
<theholyduck> no reason you couldnt have a ffmpeg-svn x264-git and mplayer-svn package that fills the depends for their respective "stable" packages
<theholyduck> but for people who want a usable system
<superm1> theholyduck, no, it uses libavcodec from the system ffmpeg
<theholyduck> arghh. why do everyone persist in dynamicly linking everything :P
<superm1> saves space, encourages stable ABI & API
<theholyduck> superm1, in a perfect world yes :P
<theholyduck> but all its doing in this case is stagnating your ffmpeg
<theholyduck> since people depends on how that stagnated ffmpeg work
<superm1> theholyduck, so you will have more likelyhood of getting FFes on the parts that don't have potential to hurt other packages (such as mplayer)
<anakron> ping Laney; hey, how i can see which dependecies are needed to add
<theholyduck> the world isnt perfect thus dynamic linking doesnt work.
<superm1> theholyduck, but feel free to file the set of FFes and let the release teams evaluate them and talk to siretart about ffmpeg
<anakron> ups sorry
<theholyduck> i might just stick to my supply a script that compiles x264, ffmpeg and mplayer statically. then integrates it into the packagemanager plan
<theholyduck> more ideal since ffmpeg should be updated every day
<xoox> theholyduck: Use rvm's PPA. http://ppa.launchpad.net/rvm/ubuntu
<theholyduck> still no ffmpeg :)
<anakron> someone here
<theholyduck> but atleast mplayer is alteast sorta usably built
<anakron> if when i use pbuilder and it says that "E: pbuilder-satisfydepends failed"
<superm1> theholyduck, you might consider setting up a PPA for daily ffmpeg builds then
<anakron> what can i do?
<theholyduck> x264 is still horribly  outdated on that one xoox
<superm1> theholyduck, it would probably be useful to these same people who use your script
<savvas> TheMuso: Can you test a powerpc package of bmpx 0.40.14-1ubuntu1 on jaunty using this debdiff: http://paste.ubuntu.com/122614/
<theholyduck> 20080917 is so anicent its not really worth mentioning in x264 terms
<xoox> theholyduck: I would try searching people's PPA's before trying to build it yourself.
<anakron> i must look at debian/control and see which  things are needed to add as build-depends?
<TheMuso> savvas: I will try it later, still don't have a build environment up yet sorry, will get to it as soon as I do.
<xoox> theholyduck: I agree with you about the poor support for tracking rapidly developing packages.
<savvas> TheMuso: thanks :)
<hggdh> anakron, look at the output of the pbuilder run to find what was missing
<hggdh> anakron, and add it in debian/control
<anakron> i try to see it doing a dpkg-buildpackage
<anakron> and it says that are some deps that are needed to install
<hggdh> there you go
<anakron> but all of thm are used by pbuilder
<theholyduck> superm1, do i need to setup a launchpad team or project or something to get my own ppa?
<theholyduck> google to the rescue
<tonyyarusso> gah, I don't understand gdb at all.  I've managed to get output for 'print variable', but it looks nothing like what I expect to see in that variable.  :(
<StevenK> You mean, it's a pointer?
<tonyyarusso> Well, at least originally I was working with a pointer, but then I (thought I) created another dummy variable to hold the value of just the integer (gotten from GPOINTER_TO_INT()), and that doesn't help either, so I'm not really sure what's going on.
<tonyyarusso> (Keep in mind though that I just started trying to have the concept of pointers explained to me yesterday.)
<StevenK> Oh.
<StevenK> I'm guessing the variable you're interested in is a struct?
<tonyyarusso> I don't know?
<StevenK> tonyyarusso: Well, what is the type of the variable you're interested in?
<tonyyarusso> http://paste.ubuntu.com/122663/ - I'm trying to find out the value of dialog->on_status, so I can figure out why things aren't behaving like I expect around lines 200-207 and/or 468-473.
<tonyyarusso> StevenK: I believe it's an integer that's been converted to a pointer (to match what the function is expecting), and then I try converting it back.
<StevenK> tonyyarusso: And when you break at line 200, what is on_status_as_int ?
<tonyyarusso> $1 = -1210495972
<tonyyarusso> actually, wait - that's a few lines earlier I think.
<tonyyarusso> still get the same thing.
<tonyyarusso> StevenK: any idea why it's not 1, 2, or 3?
<StevenK> Perhaps it's not an int ...
<tonyyarusso> Time to hit the documentation for GPOINTER_TO_INT?
<StevenK> Sounds like a good first step
<tonyyarusso> sadly, this stuff seems to be quite poorly documented :(
<tonyyarusso> This is the clearest thing I've found so far, but it seems to say I had it right - http://mail.gnome.org/archives/gtk-app-devel-list/2001-July/msg00246.html
<tonyyarusso> Also, http://library.gnome.org/devel/glib/unstable/glib-Type-Conversion-Macros.html, but that page is gibberish to me.
<tonyyarusso> oh, wait a second
<tonyyarusso> I'm not entirely clear about how things are stored in the combo box I think.  Looking for examples of that too...
<tonyyarusso> I found a file that does similar things - http://paste.ubuntu.com/122670/.  Looking through that - hopefully it will help.
<dholbach> good morning
<dholbach> hi fabrice_sp
<fabrice_sp> Hi dholbach :-)
<fabrice_sp> dholbach, I've just update the debdiff of Bug #334035. I forgot to close the bug in the changelog :-/
<ubottu> Launchpad bug 334035 in transcalc "Transcalc FTBFS with error "call to '__open_missing_mode' declared with attribute error: open with O_CREAT in second argument needs 3 arguments"" [Undecided,Confirmed] https://launchpad.net/bugs/334035
<fabrice_sp> and I saw too late your comment :-) Do you want me to update the patch?
<dholbach> fabrice_sp: no, I uploaded it already - just close it manually
<fabrice_sp> ok. Thanks!
<fabrice_sp> A small question: what would be the Ubuntu's version for 0.99.5+cvs20070914-2.1~lenny2 ?
<fabrice_sp> dch propose me 0.99.5+cvs20070914-2.1~lenny2ubuntu1
<dholbach> sounds good
<dholbach> just add ubuntu1
<fabrice_sp> ok. Just seemed to me a too long version number! :-)
<dholbach> not our problem, we just add 7 characters to it ;-)
<siretart> theholyduck: I wouldn't call the ffmpeg snapshot from a few weeks ago 'horribly outdated'...
<theholyduck> well im talking hardy currently :P
<theholyduck> i only deal with what i have to support
<theholyduck> and the one in hardy is from sometime in 2008
<siretart> theholyduck: it should even provide VDPAU, but I couldn't find someone to actually test it
<theholyduck> siretart, well ffmpeg doesnt REALLY provide vdpau :P
<theholyduck> atleast not fully :P
<dholbach> fabrice_sp: are you going to forward the transcalc fix upstream?
<theholyduck> you need to get the nvidas own build for that
<siretart> well, ffmpeg in hardy is indeed nearly a year old, that's right.
<siretart> we could update it in -backports, but this would break nearly all media players in ubuntu
<theholyduck> siretart, yes. and there is no reaon you cant keep updating it:P
<fabrice_sp> dholbach, I didn't find a up-to-date upstream page (2007, it seems), so I was opening a bug report in Debian
<dholbach> fabrice_sp: sounds good
<theholyduck> siretart, well a ffmpeg older than 1 weeks is way outdated
<fabrice_sp> :-)
<theholyduck> by ffmpeg standards
<dholbach> fabrice_sp: do you use "submittodebian" for that?
<siretart> theholyduck: breaking all media players *is* a very good reason
<theholyduck> a x264 outdated by 3 days is outdated by x264 standards
<siretart> says who?
<StevenK> theholyduck: An ffmpeg outdated by one *commit* is ancient, for crying out load
<StevenK> *loud
<theholyduck> the guys CREATING the damn software
<fabrice_sp> dholbach, I generally use reportbug, with manual email :-/ I'll check submittodebian :-)
<theholyduck> StevenK, well yes. but when it hits a week its horrible :P
<StevenK> theholyduck: Hardy is released. I can't see us updating it.
<siretart> theholyduck: well, then try to provide a PPA with updated versions of x264 and ffmpeg. you don't even need to be a developer
<theholyduck> siretart, well if players just built in the version of ffmpeg they used.
<dholbach> fabrice_sp: the nice thing about it is that it makes use of the stuff in https://wiki.ubuntu.com/Debian/Usertagging for you
<siretart> theholyduck: I documented the update procedure pretty cleary in debian/README.upstream-upgrade
<theholyduck> instead of insisting on the idiocy of dynamic linking
<theholyduck> this wouldnt be a problem now would it?
<theholyduck> ffmpeg isnt really THAT large a binary anyway
<StevenK> IDIOCY!?
<siretart> then maintain all media players with static copies of ffmpeg in your PPA
<ScottK> We're pretty much in favor of dynamic linking around here.
<theholyduck> ScottK, im not though :P
<theholyduck> it encourages not updating packages
<theholyduck> because other packages would break
<siretart> ffmpeg is just about 8 MB of code (on i386). I would call that rather large...
<dholbach> ?
<ScottK> Not if they're sanely designed.
<theholyduck> ScottK, well ffmpeg isnt sanely designed or developed
<theholyduck> and never will be.
<ScottK> Agreed.
<theholyduck> most apps wont be
<StevenK> theholyduck: No, it involves updating one package in the case of a security flaw, rather than 15.
<ScottK> There I disagree.
<theholyduck> dynamic linking is perfect in a perfect world :P
<fabrice_sp> dholbach, I see. I'll check all that before submitting to debian. Tahnks for the pointers!
<theholyduck> but the world is far from perfect. thus it doesnt work
<dholbach> fabrice_sp: anytime
 * ScottK declines to really get into it and goes to bed instead.
<siretart> dynamic linking is okay for ubuntu & debian. I'd say we do a fairly good job so far, of course there is always room for improvements
<dholbach> ScottK: sleep tight
<siretart> ScottK: good night!
<ScottK> Good night all.
<theholyduck> and then you got softwares like x264.
<theholyduck> with THIIIINY binaries.
<fabrice_sp> good night ScottK
<theholyduck> that makes even LESS sense to dynamically link
<siretart> theholyduck: are you willing to actually help to improve the situation or are you only trying to make people work for your pleasing?
<theholyduck> siretart, well i'll start working on trying to package usable mediaplayers for ubuntu. but it sorta saddens me since i wouldnt ordinarily use it :P
<siretart> ubuntu already has rather useable media players: ffplay, gxine, vlc, gstreamer0.10-ffmpeg using packages like totem, phonon + applications...
<theholyduck> the only reason im willing to do it is because there are more and more people using the horrible abomination of mediaplayers known as vlc instead of mplayer because the mplayer in ubuntu is outdated
<theholyduck> siretart, gstreamer and vlc are abominations.
<theholyduck> ffplay isnt MENT to play files
<theholyduck> it cant even demux propperly
<siretart> what media players are missing?
<theholyduck> siretart, well the problem with linux is that all the playback solutions are horribly flawed in some way
<theholyduck> mplayer from svn is currently the only close to usable one
<theholyduck> but no distros package it :D
<siretart> well, then try to update the mplayer package
<siretart> preferably based on this git branch: http://git.debian.org/?p=pkg-multimedia/mplayer.git;a=summary
<siretart> I could then consider uploading it to debian
<theholyduck> well again. unless its a svn build its no good,,
<theholyduck> actually you shouldnt even be packaging mplayer svn, but one of the custom git reps.
<theholyduck> but thats another discussion alltogether
<theholyduck> then some users might want mplayer with ffmpeg-mt, or mplayer with a non sucky libass.
<theholyduck> etc :)
<theholyduck> mplayer is not a package that lends itself to sanely be used in a packagemanager
<siretart> then don't use the package at all, but install it in your ~/local or something. problme solved
<theholyduck> siretart, wich is basicly what the script i've been working on does anyway
<siretart> you could also craft script to automate this. just keep them out of ubuntu, please
<theholyduck> siretart, anyways the idea was to create a interactive script to pick if you want uau's improved git. or plain mplayer svn, libass patches, gradfun patches, ffmpeg-mt and what not
<theholyduck> then grab the deps and compile and install.
<theholyduck> and the same for x264 and ffmpeg.
<theholyduck> though alot of the situation would be fixed if ubuntu did the same thing with mplayer as they did with ffmpeg. as in package atleast a semi recent svn
<theholyduck> its better than nothing anyway
<siretart> as said, feel free to update the package. I even told you the url to the branch
<theholyduck> siretart, seems pretty old if you ask me. but whatever. i'll think im going to stick with the script it approach for now, trying to stick to all the ubuntu packaging rules that i quite frankly think are idiotic isnt exactly my idea of fun
<dholbach> theholyduck: I think it's a good idea to accept that the Ubuntu approach is a bit different because of our commitments wrt releases - if you want bleeding edge, that's fine too
<theholyduck> dholbach, another thing i never understood about ubuntu. is that while SOME of the packages are pretty up to date. others seems to orginate from debian stable
<dholbach> "live and let live"
<dholbach> theholyduck: we import source packages from sid
<theholyduck> dholbach, all of them?
<dholbach> until DebianImportFreeze
<dholbach> https://wiki.ubuntu.com/JauntyReleaseSchedule
<siretart> theholyduck: bashing developers for doing something you don't understand is not a good way to get people do what you want them to do
<siretart> anyway, need to hurry to work now, cu later
<dholbach> have a great day siretart
<ajmitch> hi
<theholyduck> anyways. i just think its annoying when distros dont listen to upstream. and then you get all the people reporting bugs that have been fixed ages ago. but the distros dont package the relevant versions
<dholbach> theholyduck: I understand your problem - the problem we have is that we need to be conservative with changes we make to something that is released already
<theholyduck> well ffmpeg/mplayer/x264 was never MENT to be stable consistent software that you could just depend upon and forget.
<StevenK> Why? Because API/ABI stability is pointless?
<theholyduck> StevenK, because ideas and techniques to encoding and decoding keep changing
<StevenK> That doesn't answer my question.
<theholyduck> StevenK, well if you say you're going to stick to a api. you loose the ability to break compitability
<theholyduck> for performance or cleanness reasons
<dholbach> users of a release are not interested in having compatibility broken :)
<theholyduck> the inability to break compitability is what makes things stagnate
<dholbach> like my mom
<dholbach> we can break it in the next release all we like
<theholyduck> and stagnation is bad.
<theholyduck> StevenK, like x264 added alot of major features not long ago
<theholyduck> "psyvisual" optimizations
<dholbach> and it's cool to add features in a new release, no? :)
<theholyduck> that instead of trying to replicate how the video looks. you try to replicate how the video SEEMS to the human eye
<siretart> StevenK: don't listen to him. lately, ffmpeg tracks API/ABI changes pretty carefully and adds lots of compatibility #ifdefs to avoid SONAME bumps...
<theholyduck> siretart, well its still known for breaking things
<siretart> theholyduck: whom do you tell that?
<theholyduck> dholbach, once you start doing real releases. you start focusing on the releases. and deadlines and stuff. instead of writing new intresting features when you want to write new intresting features
<dholbach> I'll give it a rest now - I'm not member of any ffmpeg team, so I don't feel I should discuss their release politics
<dholbach> I'm just glad that a lot of projects do manage to do both: have predictability of releases and hack on new features
 * theholyduck always used debian unstable/exprimental
<theholyduck> predictablillity is overrated
<siretart> dholbach: my impression of both ffmpeg and mplayer is that there is a lot of pressure from quite some very talented and good programmers who want to focus on writing code and improving quality instead of focusing on producing something usable for less active projects
<siretart> dholbach: which is a pain for distros :-(
<siretart> dholbach: but I'm in good contact with ffmpeg upstream about that
<theholyduck> siretart, wich is why they reccomend people building their own svns :P
<dholbach> as I said... I'm out of the discussion now
<AnAnt> Hello, can someone please review: http://revu.tauware.de/details.py?package=webstrict ?
<dholbach> Toadstool: good you're coming back!
<dholbach> everybody give Toadstool a hug!
 * dholbach hugs Toadstool
<Toadstool> heh :)
<Toadstool> hi everybody!
<dholbach> hiya bdrung_
<Teddy__> ScottK-desktop: Ping?
<ScottK> Teddy__: Pong
<Teddy__> ScottK: "mandos" 1.0.8-1 has now been uploaded to Debian.
<ScottK> OK.  I'll have a look.
 * ScottK waves to Toadstool.
<Teddy__> Thanks!
<Toadstool> heya ScottK
<ScottK> Welcome back.
<Toadstool> thank you :)
<ScottK> Teddy__: Bug #334295
<ubottu> Launchpad bug 334295 in mandos "Please sync mandos 1.0.8-1 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/334295
<ScottK> That will likely get processed by an archive administrator in the next few days.
<Teddy__> ScottK: Cool, thanks!
<ScottK> You're welcome.
<Teddy__> ScottK: ITYM "wave", not "waive"?
<ScottK> Yes.
<Teddy__> ScottK: Thanks (got a little confused there). :)
<savvas> ScottK: bugs launchpad has commands like bts? is there a tool or a list with those commands?
<ScottK> You still need to be registered.
<savvas> I am :)
<ScottK> Sorry, got confused who I was talking to.
<savvas> :P
<ScottK> savvas: There is a email interface and there's a help page on it.  I don't recall where.
<nhandler> https://help.launchpad.net/Bugs/EmailInterface
<savvas> great, thanks nhandler :)
<nhandler> You're welcome savvas
<pkern> Hi there.  Is it possible nowadays to push things from a PPA into universe?
<pochu> pkern: nope
<pochu> you have to reupload
 * Laney cuts banshee
<Laney> ScottK: Can I have your ack #1 to upload a fix?
<Laney> (notifications)
<ScottK> Bug?
<Laney> bug 327640, but I haven't done any paperwork on it
<ubottu> Launchpad bug 327640 in banshee "Need to check notification daemon for actions capabilities" [Low,Triaged] https://launchpad.net/bugs/327640
<pkern> pochu: *grmbl* Ok.
 * soren seems to have missed something.
<soren> Laney: Why would you need an ACK for something like that?
<Laney> soren: ScottK says so
<Laney> I intend to take it to the mailing list, but I want to fix this particular case first
<ScottK> soren: Featureful changes need FFes.
<soren> ScottK: Ah.
<soren> ScottK: I just wondered why he needed an ACK rather than a sponsor.
 * pochu still thinks those are bug fixes
 * Laney too
<Laney> pochu: do you want to kick off a ML thread?
 * james_w three
<pochu> I already said it in #ubuntu-devel some days ago and in ubuntu-devel@ yesterday
<Laney> Consensus from -release would be good
<pochu> <49A45463.5020206@ubuntu.com>
<pochu> Laney: do -release think otherwise?
<Laney> no, and motu-release seem to think that they do require FFes
<Laney> hopefully we can get a standing FFe at the next ubuntu-release meeting
<pochu> bah
<pochu> they're clearly bug fixes
<james_w> I've only heard the opinion of one member of motu-release so far
<Laney> james_w: nhandler and DktrKranz agreed in #ubuntu-release when I solicited input
<james_w> Laney: agreed that they needed FFe?
<Laney> yep
<james_w> ok, thanks
<Laney> I asked ScottK if he wouldn't mind bringing it up at the next ubuntu-release meeting for a standing FFe (or a dx delegate), but he didn't reply yet
<pochu> IMHO the feature is notify-osd, fixing apps to follow the specification are fixes, not features
<james_w> when is the next meeting?
<Laney> friday
<james_w> ok
<james_w> we're almost ready to request the FFe for them all anyway
<Laney> I'd rather avoid as much of the busy work as possible
<james_w> all the ones currently reported sorry
<james_w> Laney: well, they've already stated they want busywork IMO
<james_w> is the motu-release meeting the best place for that discussion?
<Laney> yeah, but getting a blanket exception will reduce it
<Laney> this is the ubuntu-release meeting
<james_w> ah
<pochu> we could promote all of them to main and fix them there, then put them back to universe
 * pochu runs :)
<Laney> to SAVE paperwork?!
<pochu> just kidding ;)
 * Laney notes http://irclogs.ubuntu.com/2009/02/20/%23ubuntu-meeting.html - slangasek at 15:07
 * Laney spies muddy waters
<james_w> it's less work for me to promote to main than apply for an FFe :-)
<Laney> you and your l33t powers
<james_w> not sure I'd risk the wrath of the MIR team though
<pochu> what looks weird to me is that they are treated as bug fixes in main but features in universe
<pochu> now tell me what new feature you see in this patch: http://launchpadlibrarian.net/22833022/notification_check_for_actions_support.patch
<asac> please dont misuse main ;)
<pochu> asac: archive reorganization FTW :)
<asac> notification_check_for_actions_support
<asac> ;)
<pochu> ?
<pochu> is that a new API? :)
<asac> pochu: no. thats how the patch is called
<asac> pochu: is that in libnotify?
<ScottK> Actually the next meeting is next week.  ubuntu-release meetings are every other week.
<asac> ah
<asac> seems not
<Laney> the fridge lies then
<pochu> asac: nope, the liferea patch
<Laney> "Jaunty Weekly Release Meeting"
<james_w> ScottK: how do you want to proceed with this?
<ScottK> IMO adding features needs an FFe.
<pochu> sure
<james_w> ScottK: fine
<pochu> but theose are not features!
<james_w> ScottK: that's not what I asked
<pochu> s/theose/those/
<ScottK> My expectation is that Ubuntu Release will give one archive wide, but I'm not aware of them doing so.
<james_w> ScottK: at the last ubuntu-release meeting it was stated that these can be considered bug fixes, and you are welcome to re-open that discussion if you like, but you were not present at the time to do so
<james_w> ScottK: so would you like to re-open the discussion
<ScottK> james_w: They aren't bugs.
<james_w> unanimously declare them features?
<james_w> grant a blanket exception?
<ScottK> They are unless you redfine the words.
<james_w> have FFe for each?
<ScottK> I'd like to understand how these are going to be maintained.
<pochu> ScottK: if you need to check for something but fail to do so, how is not that a bug?
<ScottK> pochu: there is no requirement to check.
<pochu> and how is *fixing* that to check for the support, a new feature?
<pochu> sure there is
<pochu> there is a spec
<ScottK> Where?
<ScottK> There is no approved spec.
<pochu> http://www.galago-project.org/specs/notification/
<ScottK> There is an unagreed draft.
<pochu> approved by whom?
<ScottK> FDO
<james_w> https://wiki.ubuntu.com/FreezeExceptionProcess makes no mention of some requirement for maintainence to be declared
<pochu> why should it be in FDO?
<james_w> there is a de-facto spec
<pochu> it was written by the very same guy who wrote libnotify and notification-daemon
<ScottK> james_w: Normally we don't creat permanent divergence from upstream.
<pochu> but upstreams are merging them
<james_w> ScottK: it is not permanent
<pochu> liferea, decibel-audio-player, banshee
<ScottK> james_w: How do you know that.
<james_w> ScottK: more than half of the current patches are upstream before Ubuntu
<pochu> because they are already upstream
<ScottK> That's all I want to hear.
<Laney> what is the alternative anyway?
<pochu> but that's irrelevant
<ScottK> I was starting to say I don't see a need for full FFe for there.
<ScottK> there/these
<pochu> if they are bug fixes, there's no need to request a FFe
<Laney> we cannot leave the behaviour as it is
<james_w> I think Laney said it best last night, we're not really going to leave things as they are, so requiring two ACKs is silly
<pochu> I'm dissapointed we are requiring FFe for this
<james_w> you can request a bug documenting what happened if you like
<pochu> it looks to me people are trying to block the move because they don't like notify-osd
<james_w> pochu: +1
<ScottK> I'm dissappointed Canonical dumped this into the archive without really considering the impact on the community.
<james_w> I think you are wrong there
<ScottK> All I ask is that if these patches go in we have someone committed to maintain them.
<ScottK> If they are accepted upstream, that's taken care of.
<pochu> but why do that for this and not for other things?
<james_w> right, and you sounded satisfied on that point a moment ago
<ScottK> james_w: If the changes are upstream, then I'm perfectly fine with them.
<james_w> so can we move on from that, and you tell us what we are required to do so we can leave this all behind and move on to other things?
<pochu> if they are bug fixes, they can be fixed. there's nothing else to discuss
<ScottK> They aren't.
<pochu> OK, so we disagree there
<ScottK> Changing requirements are features and that's exactly what this is.
<pochu> no, this is fixing apps to check for a capability they must check
<james_w> "user gets an annoying pop-up" sounds like a bug to me
<ScottK> There is no must.
<pochu> there is
<ScottK> This is all because notify-osd landed at FF.
<ScottK> If it had been delivered on a more timely sched, we wouldn't have this discussion.
<pochu> sure, but that's orthogonal
<pochu> s/sure/maybe/
<ScottK> No, if you land features before FF, no FFe is needed.
<ScottK> Since notify-osd landed at FF, it makes it rather hard for Universe to accomodate it.
<james_w> I think we would have had discussions that would have followed much the same pattern
<ScottK> ... before FF.
<pochu> I'll mail -motu tonight
<pochu> gtg to uni now, later
<Laney> I don't want to have to have endless discussions which amount to the same thing
<Laney> in the end, we have to implement these fixes one way or another
<dholbach> ScottK: can you tell me which problem you're trying to fix at the moment?
<ScottK> dholbach: If we are going to land these patches late in the release cycle (and I'm reasonably certain we are), I'd like to ensure that we have someone who is going to mind after them if there are problems.  If that's upstream has accepted the patches and so we can expect them to support the change, that's fine, if it's a community developer that agrees to maintain it, that's fine, if it's Canonical Dx, that's great too, I just don't think we sho
<ScottK>  injectling late changes into packages without someone who is paying attention.
<dholbach> To me this all sounds like integration fixes and integration is what we do every day.
<ScottK> dholbach: I disagree.
<james_w> ScottK: "late in the release cycle (and I'm reasonably certain we are)" <- when do you mean?
<ScottK> dholbach: I think if you go back and look at the other FFe I've commented on in previous releases, wanting to know who is going to keep track of it and fix it if there's a problem is a pretty consistent theme of mine.
<ScottK> james_w: Post FFe is what I'd consider late.  This all should have been done already.
<james_w> ScottK: ok
<james_w> ScottK: but there's a reason we have FFe.
<james_w> ScottK: and to me it feels like you are making it later
<ScottK> I don't htink I understand.
<ScottK> think even
<james_w> I'm still yet to learn what you want to happen
<RainCT> james_w: If I've understood him correctly, he wants someone to say Â«poke me if there's some problem with the patch or it need to be updated for a new releaseÂ»
<Laney> Can I please upload Banshee, given that the fix is upstream?
<james_w> RainCT: that's fine
<ScottK> Laney: I'm good with that then.
<Laney> excellent
<ScottK> I have several sets of wants around the notification changes.  The ones that are related to MOTU release involve wanting to make sure that these changes are going to be minded after and we aren't going to be stuck with last minute problems and no one to turn to.
<ScottK> Additionally, I'd like for these changes not to be a long term maintenance burden on the community.
<Laney> how would you have liked the releasing into the archive to have been different?
<james_w> ScottK: so FFe per package?
<Laney> (banshee uploaded, thanks)
<ScottK> james_w: I think so, but not necessarily a full one (we don't always require that).
<james_w> what does that mean?
<pkern> http://paste.debian.net/29195/ <-- Is that ok changelog-wise, or will bad things happen when 0.7.15-1 is synced from Debian at some point?
<ScottK> Laney: I'd like for there to have been a spec at UDS that was approved through the normal process and then for notify-osd to have landed soon enough for this work to have been done before FF.
<dholbach> I disagree - this should be of no concern to MOTU Release - there's still no charter for the team and the FreezeExceptionProcess is all there is. It only speaks about new upstream releases and NEW packages.
<RainCT> pkern: it is fine
<RainCT> I think
<dholbach> If you're really concerned about too much changes on the Ubuntu community's shoulders, you could raise it at a TB meeting or something.
<ScottK> dholbach: The freeze is called a feature freeze exception.  Feature has a plain language meaning.
<dholbach> Still I think that these are integration fixes.
<RainCT> dholbach: +1
<pkern> RainCT: Ok, thanks.
<james_w> ScottK: could you please explain what a "not full FFe" would be?
<ScottK> My main concern is that these changes be supported.
<ScottK> I'm not particularly concern about build/install logs.
<Laney> have any upstreams refused to accept patches?
<Laney> I see no problem with requiring that they are upstreamed first
<james_w> Laney: not that I have seen
<ScottK> I have no idea.  I'd like to hear that they are upstream or an Ubuntu Dev is willing to deal with them.
<james_w> Laney: there is one that has been un-reviewed upstream for a couple of weeks
<james_w> ScottK: I would appreciate it if you helped me to understand what to do
<james_w> I've already wasted too much time on this
<james_w> ScottK: if you want me to just file a bunch of FFes in the normal manner then just say so
<ScottK> james_w: Do you have a package for one of these notification patches pending?
<ScottK> I do.
<james_w> I'll live with the extra hassle so that users can get these fixes
<dholbach> I still don't think it's the MOTU Release team's call to do so.
<ScottK> dholbach: Who's is it then?
<james_w> dholbach: can we postpone this discussion for a few minutes please?
<james_w> I'd like to fix the problem, then we can discuss the issue
<dholbach> james_w: ok... ping me in a bit then
<Laney> How about, in the case where a bug is upstream but not reviewed yet, a MOTU may upload if he/she commits to merge if the committed patch is different?
 * dholbach needs to finish a letter
<ScottK> Laney: and also to watch the package for bug reports and deal with regressions.
<ScottK> I'm more worried about that for this cycle than if the eventual upstream solution is different.
<ScottK> dholbach: I don't think I'm doing anything that's not inherent in motu-release processes FFe for Universe/Multiverse, so I don't see as there's really anything to discuss.
<savvas> tonyyarusso: here? are you willing to work on packaging the new version of kompozer? There's a new package at Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406553 http://mentors.debian.net/debian/pool/main/k/kompozer/
<ubottu> Debian bug 406553 in wnpp "RFP: kompozer -- HTML WYSIWYG editor - bugfixed NVU" [Wishlist,Open]
<james_w> ScottK: you are using your definition of feature to select what things you have to review for one thing
<ScottK> james_w: Certainly, but what else could I do?
<james_w> ScottK: use the uploader's definition of feature?
<james_w> ScottK: use the general consensus?
<ScottK> All I'm asking is that these are sent upstream and there is someone who agrees to watch over the packages in question for problems.  If there's a consensus against that, I should just quit.
<james_w> I don't see why that's any different to any other change
<ScottK> Because it's being driven by Ubuntu unique requirements.
<RainCT> I think being responsible for your changes (in case they case breakage) is implicit with uploading the package
<james_w> ScottK: that's not what I meant
<james_w> I meant we should have that for every change
<ScottK> That's why it's different.
<RainCT> *case=cause
<ScottK> RainCT: I agree, but that's not consistent among developers.
<ScottK> james_w: I see from my bugmail that I'm now in a minority of motu-release in thinking these are features.
<ScottK> So while I still think it's wrong, I'll desist.
<slytherin> persia: do you have any idea if visualvm builds with latest netbeans packages? If it does then that should knock out 3 packages from NBS list.
<RainCT> If there are developers uploading broken stuff and not caring about it, we have a more serious issue
<ScottK> RainCT: I agree.  When I notice it I do chase after people.
<james_w> ScottK: so I am free to upload?
<sistpoty|work> hi folks
<ScottK> james_w: Yes.
<james_w> ScottK: thanks
<Laney> glad we got there in the end
<Laney> ScottK: And I do think you have a point about it landing sooner, and the potential community implications this has. I'd be interested if you were to raise this to some kind of governing body to see if lessons can be learned
<ScottK> RainCT: For webboard it sounds from your bug like it's currently in a 'not working' state.  Is that correct?
<ScottK> Laney: The response has been "It was discussed at UDS so you all should have known it was coming."
<RainCT> ScottK: It works, but you have to manually change the language every time
<RainCT> it's only the "Plain text" entry which is broken
<ScottK> Laney: Unfortunately for those of us that didn't go to UDS, none of the notifications related discussions were remotely accessible.
<ScottK> RainCT: Thanks.
<Laney> yep
<RainCT> ScottK is right here. I hadn't heard anything about it neither, until it came up on Mark's blog.
<Laney> Perhaps the TB or CC would be interested in hearing some views
<iulian> Hi sistpoty.
<sistpoty|work> hi iulian
<ScottK> I think they're getting an earful on the ML already.
<RainCT> heh
<RainCT> ScottK: (btw, I think I'll get the webboard upload in through Debian, if I find a sponsor soon -which shouldn't be a problem with PAPT :)-)
<ScottK> Great.
<ScottK> I ack'ed it in mail.
<RainCT> ScottK: Thanks :)
 * RainCT is off to school now.. Will be back in 2-3 hours
<ScottK> JFTR, I'd have been happier if Python 2.6 landed earlier too, but at least we had a spec for that.
<Laney> is debian moving to 2.6 any time soon?
<ScottK> Soonish, but not soon enough to give us much help for Jaunty.
<Laney> fair
<slytherin> If a package was synced from debian-mutimedia, has not been updated after warty, and is not present in debian-multimedia now, is it good candidate for removal?
<Laney> ScottK: I see you're in the modules team. You might be interested in the patch on bug 332053 - installability of nevow is broken with 2.6
<ubottu> Launchpad bug 332053 in nevow "Unable to install in jaunty" [Medium,Triaged] https://launchpad.net/bugs/332053
<pkern> Oh and does Ubuntu indeed miss debtags completely?  Then goplay should be removed.  At least on intrepid it didn't work at all to lookup something with it.
<slytherin> pkern: just because it doesn't work does not mean it should be removed.
<pkern> *sigh*
<mok0> pkern: on the contrary, it should be made to work
<mok0> pkern: and we should use it
<pkern> mok0: As debtags is very much infrastructurial, i.e. I think would need Launchpad support...
<pkern> Hm, or maybe the tag DB is still separate.  Let's try it.
<mok0> pkern: probably. LP should be using it
<mok0> pkern, bug 3945
<ubottu> Launchpad bug 3945 in launchpad-foundations "Support debtags in Launchpad for products and packages" [Medium,Triaged] https://launchpad.net/bugs/3945
<pkern> Old.  Very old.
<mok0> pkern: sadly sp
<mok0> so
<ScottK> Hopefully as debtags get more momentum in Debian the priority will rise in LP.
<mok0> ScottK, yes
<slytherin> Can anyone please answer my question - ï»¿If a package was synced from debian-mutimedia, has not been updated after warty, and is not present in debian-multimedia now, is it good candidate for removal?
<mok0> 3945 even has "medium" importance
<Laney> slytherin: does it still work?
<mok0> slytherin: what do _you_ think?
<Laney> is the functionality elsewhere? what is the popcon score? is there a new upstream version that we could update to?
<mok0> slytherin: ... and most importantly, is it maintained upstream?
<slytherin> Ok. The tools is cpvts. The functionality is available in other package (vobcopy, dvdbackup). The tools is not maintained upstream since 2003. So IMHO it is a candidate for removal.
<ScottK> Sounds reasonable to me.
<slytherin> filing a bug
<mok0> ScottK, only 1 FTBFS left for r-cran-*
<ScottK> mok0: Great.
<mok0> ScottK, but a strange one
<mok0> Error: package 'maps' required by 'mapdata' could not be found
<ScottK> Dunno.
<mok0> I'll see if I can find out where "maps" should come from
<sistpoty|work> james_w: did you mean to subscribe motu-sru instead of motu-release for bug #86685?
<ubottu> Launchpad bug 86685 in clearsilver "trac BROKEN on AMD64: "neo_cgi.so: undefined symbol: Py_InitModule4"" [Undecided,Fix released] https://launchpad.net/bugs/86685
<james_w> sistpoty|work: I think I did that last cycle
<sistpoty|work> james_w: oh, I see... no... seems like you actually subscribed motu-release during last cycle *g*
 * sistpoty|work unsubscribe motu-release
<sistpoty|work> that's really funny, I guess I noticed only now, because someone posted a comment to an old bug... how irritating
<mok0> ScottK, apparently it's missing a build-depends, but why did the other archs succeed? I am puzzled
<ScottK> Odd.
<savvas> mok0: package?
<mok0> r-cran-mapdata
<mok0> https://edge.launchpad.net/ubuntu/+source/r-cran-mapdata/2.0-22-1/+build/779326
<savvas> maybe it's the way it looks for the package?
<mok0> savvas: perhaps
 * savvas looks
<RoAkSoAx> heya guys, we have to put XSBC-Original-Maintainer on the control file always right?
<Adri2000> if you're introducing ubuntu changes in the package yes
<Adri2000> put the debian maintainer in there, and put the appropriate ubuntu team as maintainer
<RoAkSoAx> thnks :)
<Adri2000> (see update-maintainer in ubuntu-dev-tools for doing that with one command :))
<slytherin> RoAkSoAx: more appropriately, use update-maintainer script from ubuntu-dev-tools package
<mok0> ScottK, I get the same build failure on my sbuilder. Perhaps the missing package was installed on the buildd's for some freak reason
<mok0> ScottK, except for one
<ScottK> Odd.  Or maybe some build-dep of this package depended on it and then dropped it so this got build without due to archive skew.
<RoAkSoAx> slytherin, i'm packaging from scratch an setting XSBC-Original-Maintainer to myself and Maintainer to MOTU devs.
<mok0> ScottK, yes
<slytherin> RoAkSoAx: right
<mok0> ScottK, it builds for intrepid
<mok0> ScottK, the package wasn't compiled for jaunty on the other platforms; only armel was added
<ScottK> Sounds like a missing depends then.
<mok0> hah, lintian dies on the source package!!
<savvas> mok0: I think it has something to do with the file R/zzz.R (or maybe not)
<mok0> savvas: on the system?
<savvas> well the way I understood it, it gets the maps package from there
<savvas> its location I mean
<mok0> savvas: the problem is that it's not installed
<mok0> savvas: it used to be (apparently)
<savvas> oh.. so it needs r-cran-maps ?:P
<mok0> savvas: that solves it
<mok0> savvas: I haven't figured out why it didn't need it before... but the package hasn't been compiled since hardy on the other platforms
<savvas> how come it builds for debian? https://buildd.debian.org/pkg.cgi?pkg=r-cran-mapdata :\
<mok0> savvas: don't know, but those builds are old too
<savvas> ah wait, you're right, I think it's not built for armel yet
<ScottK> mok0: You might toss that package as is at a PPA and see what happens.
<mok0> ScottK, ... what would that do?
<mok0> ScottK, I don't follow
<mok0> ScottK, ah, you mean it would fail on all archs?
<ScottK> If it builds on the archs it built on before, then you have a mystery.  If it FTBFS then you know you have an archive skew issue and a missing builddep
<ScottK> Yes
<mok0> ScottK, it builds on jaunty when I add the build-depends, so should I just upload it?
<ScottK> I think that's reasonable and then I'd mail the Debian maintainer and ask.
<mok0> ScottK, right, will do that
<james_w> is anyone with a CD drive able to get goobox to do anything?
<savvas> james_w: tried with a dvd-rw drive, used an audio cd, sound juicer works, but goobox says "invalid device"
<james_w> savvas: yeah, me too
<hggdh> dholbach, ping
<dholbach> hggdh: about to have a call in just a bit
<hggdh> dholbach, np
<dholbach> hggdh: if it's about libpst - can you ask seb128 please?
<dholbach> ... or wait :)
<hggdh> dholbach, yes, I have, and he proposed one more change -- already done
<hggdh> dholbach, I will wait ;-)
<dholbach> if seb is cool with it, I'm a too
<hggdh> dholbach, he is. I am just unsure on what to do now... I will wait for you
<dholbach> hggdh: ask him to sponsor it :)
<hggdh> dholbach, will do
<dholbach> rock on
 * skorasaurus is away: Away
<LaserJock> c_korn: ping
<c_korn> pong
<LaserJock> c_korn: I'm looking at scilab and sivp
<LaserJock> c_korn: the debdiff you put on the sivp bug has a lot of .svn junk
<LaserJock> generally it's good to remove VCS files from a source package
<c_korn> LaserJock: the .svn directory is in the debian directory. not in my package I uploaded to revu
<c_korn> with debian directory I actually mean the debian directory in the debian package :P
<LaserJock> c_korn: ah, ok
<LaserJock> c_korn: is mok0 going to upload scilab and sivp if the FFe are approved?
<c_korn> ehm, I think so
<c_korn> he also pushed jeuclid in the jaunty queue
<LaserJock> c_korn: I've ack'd both bugs and he's assigned to them
<LaserJock> c_korn: so poke him about uploading ;-)
<c_korn> well, jeuclid has to go into jaunty before scilab can be compiled
<c_korn> and scilab has to go into jaunty before sivp can be compiled
<LaserJock> c_korn: they can all get uploaded at the same time though
<LaserJock> c_korn: and they'll just debwait until the others have built
<c_korn> ah, great
<slytherin> doko: do you think it is time to kill the openjdk build on armel? It has been running for 6 days now.
<doko> slytherin: does it hurt you? the buildds seem to keep up
<slytherin> doko: no it does hurt me anyway.
<doko> I know, it's slow
<a|wen-> if anyone wants to help finally getting aRts kicked out of the archive; three small debdiff's avaible at the bottom of bug 320915 still needs a sponsor
<ubottu> Launchpad bug 320915 in ktimetrace "Remove aRts from the archive - rebuild all dependencies" [Undecided,Confirmed] https://launchpad.net/bugs/320915
<slytherin> doko: looking at the logs, it looks like the tests (assuming unit tests) have very large timeout value.
<ScottK> a|wen-: I thought we were done?
<a|wen-> ScottK: I thought so too, but there were some build-depends left
<doko> apparently the timeout value is not big enough
<ScottK> Ah.
<a|wen-> ScottK: some dangling build-depends i presume? as no arts-stuff was included in the real depends
<ScottK> That'd make sense.
<ScottK> It seems the old kde.mk config settings pulled it in for everything.
<geser> a|wen-: I will take care of the sponsoring for the three debdiffs
<a|wen-> geser: thanks a lot!
<a|wen-> ScottK: none of them has kde.mk referenced in debian/rules ... would it then have any effect?
<ScottK> No.  That's not it then.
<geser> a|wen-: what's the connection of mcopidl to arts? (currently looking at the ktimetrace debdiff)
<a|wen-> geser: mcop = Multimedia Communication Protocol, an arts component
<geser> a|wen-: I see that two packages are KDE3 programs. Do they still work with KDE4? (/me is no KDE user)
<ScottK> geser: If they only depend on kdelibs they should be fine.
<a|wen-> geser: they start and the gui works for me ... one is for collecting data from some serial-devices (or something like that) so couldn't test that part
 * sistpoty|work heads home... cya
<geser> a|wen-: all three debdiffs sponsored
<a|wen-> thanks a lot geser!
<mrooney> Can anyone take a peek at https://bugs.launchpad.net/bugs/333639 and see if there is anything else I should do?
<ubottu> Ubuntu bug 333639 in wxbanker "Please update wxbanker to 0.4.1.0" [Undecided,New]
<mrooney> I am not sure what the normal response time should be from u-u-s
<Laney> longer than a day ;)
<james_w> mrooney: please attach the .diff.gz from your updated package to the bug
<james_w> mrooney: the diff you have attached has "Binary file changed" in it, so applying it won't give the new file
<mrooney> james_w: okay so do I use the version in jaunty as the .orig.tar.gz and then the updated version as the extracted? Is that what you mean?
<james_w> mrooney: no
<james_w> mrooney: if you build an updated source package, based on 0.4.1.0
<james_w> you will have a wxbanker_0.4.1.0-0ubuntu1.diff.gz file
<james_w> that's what we need
<james_w> we will download the 0.4.1.0 tarball and combine it with that to get the updated package
<james_w> then create diffs to review as needed
<mrooney> james_w: hm okay, I'll give it a try. I don't understand what the diff.gz will contain but I'll find out!
<james_w> heh
<mrooney> james_w: isn't the diff.gz what is different from the orig.tar.gz?
<a|wen-> mrooney: the diff.gz is all changes we have to the upstream tarball ... whereas the debdiff is an incremental changeset
<mrooney> james_w: yeah I am still confused. I downloaded the upstream tarball, extracted, and debuild -S but I obviously don't get the diff.gz from the ubuntu version.
<mrooney> what am I missing? (sorry, I am new to this :)
<james_w> mrooney: you've got to add the packaging
<james_w> mrooney: presumably you updated the packaging when you did this originally?
<mrooney> james_w: well the packaging is already there, already up to date for 0.4.1.0
<james_w> is that shipped in the upstream tarball?
<mrooney> james_w: yeah
<james_w> that'll be why then
<mrooney> ah
<mrooney> yeah the upstream tarball is literally ready to build and upload
<mrooney> do I need to change something?
<mrooney> I plan on moving the packaging to a different branch in the 0.5 series
<mrooney> that seems saner perhaps
<james_w> that is ok
<james_w> though you may get complaints :-)
<mrooney> james_w: yeah, at the time I thought it would make everything way easier for MOTU if it was all in one place
<mrooney> now I have learned :)
<mrooney> so what should I do now? Use the one in jaunty now as the orig?
<james_w> nope
<james_w> that would just be confusing
<RainCT> (lol.. Just found this http://utils.eurion.net/hosted/bug_sebner.png on my webspace.. those were times XDD)
<mrooney> james_w: ah okay, is there something I *should* do then?
<james_w> mrooney: I don't think so
<mrooney> james_w: okay thanks, I'll just wait :)
<RainCT> Adri2000: is it merged? \o/
<Adri2000> RainCT: merged into Keybuk's branch, and the server just got mod_python support enabled. last thing to do is to push the branch to production :)
<RainCT> Adri2000: awesome, that was about time! :)
<RainCT> Adri2000: can I use that module I had for the UI?
<Adri2000> RainCT: that module?
<RainCT> Adri2000: I don't even remember myself what it was.. :P
<RainCT> Adri2000: well, I'll reformulate: if I get the new UI ready, what are the odds that it will be merged in less than a year? :P
<savvas> anyone using flashplugin-nonfree ? do you get an md5sum error when you install it?
<RainCT> savvas: I reinstalled it yesterday in Intrepid and it worked fine
<jpds> Don't we use adobe-flashplugin now?
<savvas> bug 173890 is reopened
<ubottu> Launchpad bug 173890 in flashplugin-nonfree "flashplugin-nonfree fails to install due to md5sum mismatch" [High,Fix released] https://launchpad.net/bugs/173890
<savvas> jpds: isn't adobe-flashplugin in archive.canonical.com ?
<savvas> I think it's considered third-party and not checked by default
 * savvas bbl
<Adri2000> RainCT: eheh, I hope it'll be easier than it's been for the comments...
<tonyyarusso> savvas: Yeah, I've been speaking with the guy who was working on the Debian package.  I am hoping to get it put together for Ubuntu soon.
<mdke> hiya. Can someone help me with signing a package - I get the error http://paste.ubuntu.com/123023/ and as far as I know my secret key is present and working ok
<maxb> mdke: run "gpg --list-secret-keys" and check whether the EXACT uid "Matthew East <mdke@ubuntu.com>" is present
<mdke> maxb: ah, that must be the problem
<mdke> maxb: mine says Matthew East (Ubuntu) <mdke@ubuntu.com>
<mdke> I'll try and edit that I guess
<mdke> thanks!
<maco> using debuild to make a .dsc so i can make a debdiff to close a bug. debuild's lintian says the standards version is out of date. does this have to be updated?
<maco> (not in general, but rather...now)
<maxb> No - For a package synced from Debian, Ubuntu doesn't change Standards-Version at all.
<jamesrfla> Vote for nhandler!!!
<Laney> what am i missing?
<jpds> Laney: https://edge.launchpad.net/~ubuntu-dev/+polls
<Laney> aha
<Laney> was there an email?
<nhandler> Laney: Not yet
<nhandler> Polls open in 15 minutes though
<Laney> I demand hustings
<Laney> and campaigning
<pochu> nhandler: were you jamesrfla with a different nick? :P
<Nafallo> 1h...
<Nafallo> ;-)
<nhandler> pochu: No
<pochu> I guessed ;)
<nhandler> Laney: Why do we need campaigning? We are not competing against each other
<Laney> oh?
<Laney> in that case I want an email even more
<nhandler> They are expanding the MC to 7 people
<nhandler> Laney: Read the Tech Board meeting logs from the other day
<ajmitch> why are 7 people needed?
<nhandler> Although I agree, an email would be nice
<RainCT> Wow, 3 candidates I like :)
<nhandler> ajmitch: I'm not really sure what caused that decision. Although I do know they are trying to get some non-canonical people on the MC
<RainCT> oh
<RainCT> Great, so I don't have to decide between one of them :9
<RainCT> s/:9/:)
<Laney> RainCT: you fail at reading the preceding lines!
<RainCT> Laney: you too :D
<Nafallo> jpds: did you just fall of the jabber?
<Laney> RainCT: No, I fail at reading IRClogs
<Laney> minutes from the TB haven't been sent out yet
 * ajmitch shall have to dig up the TB meeting logs, since they haven't been posted
<nhandler> Laney: But the IRC logs are available on irclogs.ubuntu.com
<Laney> right
<ajmitch> amongst several other meetings
<RainCT> well, good night all
<nhandler> Night RainCT
<RainCT> nhandler: btw, I'm waiting for an email from you :P
 * ajmitch still can't find the appropriate meeting log
<nhandler> ajmitch: http://irclogs.ubuntu.com/2009/02/24/%23ubuntu-meeting.html
<ajmitch> thanks
 * ajmitch wonders if he should vote
<Laney> hmm, weird
<Laney> the selection process doesn't seem very transparent
<ajmitch> it's not
<nhandler> I agree. The first part (request for nominations) was fine. But after that, there really haven't been any updates
<ajmitch> you get the right to approve/disapprove of the candidates listed
<maco> you know the wtf command in bsdgames that defines acronyms for you? dholbach found this morning that it doesn't know how to define twss, so i filed a bug and attached a debdiff. is this something that requires an FFe?
<maco> its adding 1 line to a text file, not code
<ScottK> I'd say not.
<maco> ScottK: so does that mean universe-sponsors or universe-release or um...who to subscribe?
<ScottK> Universe sponsors
<maco> ok then
<maco> bug 334574 is waiting then
<ubottu> Launchpad bug 334574 in bsdgames "wtf doesn't know twss" [Wishlist,In progress] https://launchpad.net/bugs/334574
<james_w> maco: would you forward the change to Debian please?
<nhandler> james_w: I was just about to request the same thing ;)
<james_w> we're like a broken record :-)
<maco> james_w: er...i dont know how to do debian's rules
<james_w> it's even QA maintained, so you could get it uploaded there :-)
<maco> like i know the maintainer changes when going from debian to ubuntu
<james_w> maco: for something like this just sending the bug is fine
<maco> but debuild wont let me do it as just debian-way (without changing the maintainer)
<maco> oh ok
<james_w> maco: someone should be able to work out how to add the necessary line :-)
<maco> heh :
<nhandler> maco: https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers#Forwarding%20bug%20reports
<maco> *:{
<maco> bah i fail at typing!
<maco> :P
<maco> oh hey it explains the control file shtuffs
<maco> james_w: how does one login to bts? i see no login link on bugs.debian.org
<maco> i assume forwarding a bug involves logging in
<james_w> maco: heh, seems like that page needs a little bit of work :-)
<maco> is it to force you to look for dups before logging in?
<james_w> oh, it does link to http://www.debian.org/Bugs/Reporting
<james_w> no, there is no login
<james_w> everything is done by mail
<james_w> "reportbug -B debian bsdgames" will get you started
<maco> ooh you can tell reportbug that you're not talking to ubuntu this time? well that's helpful
<maco> LOL at this bug: bsdgames: number claims English output, but outputs in Americ
<maco> james_w: i made a -0ubuntu1 package for spim in ubuntu. i should also send that to debian too now, but what should i say?
<maco> i assume needs-packaging goes to the bts as well
<nhandler> maco: Ask them to upgrade to the latest upstream version of the package
<maco> well it was removed from debian's archive completely
<maco> it was unmaintained
<nhandler> maco: Are you planning on maintaining the package?
<maco> sure
<james_w> maco: what you need to do is send an "RFS", which is like requesting sponsorship in Ubuntu, but outside the BTS
<nhandler> maco: See if there is a bug filed against wnpp regarding that package
<james_w> they have the equivalent of needs-packaging, called ITP
<james_w> (and RFP)
<maco> er...
<nhandler> ITP=Intent to Package and RFP=Request for Package
<james_w> as nhandler says, these are bugs against the "wnpp" package
<maco> so which of those TLAs is the thing to do?
<maco> wnpp?
<james_w> "reportbug -B debian wnpp" knows how to handle these
<maco> cheating, with those 4-letter acronyms....
<james_w> sorry about the acronyms :-)
<maco> actually, THERE's some to check
<maco> $ wtf rfp
<maco> Gee...  I don't know what rfp means...
<james_w> wnpp is for something like "work needed on packages package" or something equally bizarre
<maco> ok so slowly and in the proper order.....
<maco> file a wnpp bug with ITP in the title?
<james_w> yeah
<james_w> reportbug will give you a menu of the possible choices and get the template right for you
<james_w> that's like filling a needs-packaging bug and assigning to yourself
<nhandler_> maco: https://wiki.ubuntu.com/UbuntuDevelopment/Abbreviations
<james_w> once that is done you can make your package ready for Debian
<james_w> and then send an "RFS" (request for sponsorship) to the debian-mentors@lists.debian.org list
<james_w> where an interested DD would pick it up, review it, and possibly upload it
<james_w> so it works a bit like REVU, but over email
<james_w> there is mentors.debian.net where you can host a package for review like REVU, but you should still send the email
<maco> ok
<james_w> feel free to ask again if that's a bit much in one go :-0
<nhandler> There is also a #debian-mentors channel on irc.oftc.net
<maco> HOLY!
<maco> why is reportbug asking me about 2792 outstanding bugs?
<james_w> heh
<nhandler> Probably to verify it isn't a duplicate
<james_w> one of the options is "skip this, I know it's not there"
 * directhex reckons an unupdate-maintainer could be helpful for applying ubuntu patches to debian
<james_w> if you already searched on the web interface
<Laney> directhex: I thought about this todayyyyyyyyyy
<Laney> submitttttttdebbbbiaaaannnnnnn should do it
<Laney> GASH
<Laney> spot the broken keyboard
<pochu> haha
 * pochu waves good night
<RAOF> Is that gash in your leg really wide?
<nhandler> Night pochu
<nhandler> Talk about nice planning. Launchpad will be going offline just as the MC vote begins
 * Laney grumbles at 0ubuntu1s
<directhex> Laney, they're ever so polite, especially with sid in full swing Â¬_Â¬
<Laney> tell me about it
<ajmitch> Laney: what do you have against them?
<Laney> I would rather they were done in Debian
<ajmitch> I'm sure ubuntu doesn't have that many packages which don't exist in debian :)
<RAOF> Laney: Of course, the fact that gnome is uninstallable in Sid makes 0ubuntu1s a bit more palatable.
<Laney> ajmitch: I mean updating to new upstream releases in divergance from Debian
<ajmitch> Laney: just because debian was frozen for a year or so
<Laney> RAOF: Yeah, but team-maintained packages can always be staged in VCS
<RAOF> Right.  Which is what I've done for beagle; but that's still a 0ubuntu1, because it can't be uploaded to sid.
<Laney> of course
<ajmitch> so what's the plan for getting all these dumped over the fence into sid?
<Laney> ajmitch: I appreciate that. My problem is when we do such a diversion without consulting maintainers
<Laney> I'd rather Ubuntu developers personally worked with Debian maintainers to get  0ubuntu1s turned into -1s
<Laney> s/rather/like it if/
<Laney> now that they are out of freeze
<ajmitch> of course, then they'd stand a much higher chance of not just being neglected & being yet another merge to botch
<directhex> debian NEW is a valid reason for 0ubuntu1
<Laney> "Are you planning on updating foo to version frobble soon? We'd like the new version in Ubuntu and if you aren't then I am happy to do the work and forward you the changes."
<directhex> on a related note, has anyone sponsored monodevelop-debugger-* yet? :p
 * ajmitch hasn't
#ubuntu-motu 2009-02-26
<Laney> I'll do another sponsorship round on Friday if nobody does it by then
<james_w> directhex: I can't see them on the sponsorship list
<directhex> gah, of course, bug 330519 is invisible now as all current components are Fix Released
<ubottu> Launchpad bug 330519 in monodevelop-java "The road to Monodevelop 2.0" [Undecided,Fix released] https://launchpad.net/bugs/330519
<directhex> so it's not on the sponsor list anymore
<Laibsch> hi there
<nhandler> Hello Laibsch
<Laibsch> some kind soul around to help me understand why http://oss.leggewie.org/wip/scim_1.4.8-1.dsc fails to compile?
<Laibsch> The error I get is http://rafb.net/p/bZhFkr75.html
<dtchen> line 30
<dtchen> keep in mind you can use -rm to have the build not fail, or you can fix it properly.
<dtchen> (e.g., -rm, rm -f, etc., etc.)
<Laibsch> yes, line 30 is clear
<Laibsch> But the file is missing, I wonder why that is
<Laibsch> What I did is
<ajmitch> because it was unnecessary?
<Laibsch> Take 1.4.7 (current Debian source)
<Laibsch> OK
<Laibsch> Let me dig a bit into this
<ajmitch> that debian/rules looks to be just clearing up stray stuff that shouldn't be aroun, judging by the comments
<ajmitch> maybe 1.4.8 doesn't build that, or it places it in a different place
<Laibsch> Hehe
<Laibsch> Interesting, I think I had rgrep for the file name before
<Laibsch> And found nothing
<leonel> scottK   clamav 0.95 rc was released as you already know .. any test ? for backports ??
<leonel> scottK I'll check if there's any cve open ..
<ScottK> leonel: We need to fix it for Jaunty first.
<ScottK> leonel: There won't be in the RC.  They'll hold the CVE for the final.
<leonel> scottK ok
<ScottK> leonel: Lots of porting work to do https://wiki.clamav.net/Main/UpgradeNotes095
<leonel> OUCH !
<ScottK> Yeah.
<phil_ps1> hello, I know is during a freeze, I have made a patch that makes glife compile again
<phil_ps1> it is my first patch and I need help submitting it
<ScottK> phil_ps1: Is there a bug about this problem?
<phil_ps1> yes
<phil_ps1> I submitted the patch to the bug
<ScottK> Subscribe ubuntu-universe-sponsors to the bug.
<phil_ps1> ScottK: ahh, I see
<phil_ps1> done
<phil_ps1> what will happen next?
<ScottK> The various people who review those bugs will get to it at some point and then they will either upload it or give you feedback on what else needs to be done to get it ready.
<phil_ps1> ScottK: okay, thanks
<ScottK> phil_ps1: You're welcome.  phil_ps1 thank you for showing up to contribute to make Ubuntu better.
<artfwo> Hello! May I ask, is it okay to use "debian/tmp/usr/..." lines in package.install? Or is it better to specify DHINSTALL_SOURCEDIR and prefix occasional exceptions with "../../"?
<RAOF> Laney: Ping, re: gnome-do.
<savvas> tonyyarusso: ok :) please do so as soon as possible, I was hoping it could be done for jaunty, since kompozer is a mess as it is now (segmentation faults etc)
<tonyyarusso> savvas: I'll do my best.
<savvas> thanks!
<tonyyarusso> We're already past feature freeze of course, but I suppose it would be likely to qualify for an exception.
<savvas> ok
<savvas> does anyone know what's the difference between jaunty-alternate-powerpc+ps3.iso  and jaunty-alternate-powerpc.iso ?
<StevenK> I think the +ps3 iso has a few extra packages and such like to deal with the PS3
<savvas> thanks :)
<dholbach> good morning
<StevenK> dholbach: Er, why did you ack bug 333573 when someone else commented that it doesn't build ... ?
<ubottu> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/333573/+text)
<dholbach> hang on
<dholbach> StevenK: because it was said "doesn't built" about -2
<dholbach> StevenK: then the bug changed to -3
<dholbach> StevenK: and I tested it
<StevenK> dholbach: I would prefer that was clear in the bug log.
<StevenK> Hmmm. Doesn't bug 334065 require an FFe?
<ubottu> Launchpad bug 334065 in libgems-ruby "Please sync libgems-ruby 1.3.1-1 from debian experimental" [Wishlist,Confirmed] https://launchpad.net/bugs/334065
<dholbach> StevenK: what do you want me to do now?
<StevenK> dholbach: In regards to bug 333573? Nothing, I'll sync it.
<ubottu> Launchpad bug 333573 in mumble "Please sync mumble 1.1.7-3 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/333573
<dholbach> good
<dholbach> thanks
<StevenK> No problem. :-)
<fabrice_sp> Good morning dholbach and StevenK ;-)
 * StevenK waves to fabrice_sp 
<dholbach> hiya fabrice_sp
<MOGUL-TECH> hello
<fabrice_sp> Hello MOGUL-TECH
<MOGUL-TECH> it's like quiet this morning
<fabrice_sp> yep :-)
<fabrice_sp> European not yet woke up (except somes :- )
<MOGUL-TECH> tell me, according to your knowledge of linux distros which GUI between KDE and GNOME is the best ?
<MOGUL-TECH> sorry to ask, but a lot of people saying that KDE is better because it's in QT and a lot of APPS are developped in QT.
<Toadstool> good morning
<RAOF> MOGUL-TECH: Very off topic for #ubuntu-motu.  Also, not really answerable.
<MOGUL-TECH> sorry
<c_korn> mok0: hello
<c_korn> do you want to upload scilab and sivp?
<mok0> c_korn: did jeuclid pass ?
<c_korn> it is still in the jaunty queue. but I was said that scilab and sivp would just wait for the missing dependency
<mok0> What about sivp, never heard about it
<mok0> AFAIR
<c_korn> it is Scilab Image Video Processing. it also needs to be updated (bug 334362). it build-depends on scilab-5
<ubottu> Launchpad bug 334362 in scilab "FeatureFreezeException: Please update sivp 0.5.0 from REVU" [Undecided,New] https://launchpad.net/bugs/334362
<c_korn> it is already in debian. but there have been made some recent changes (by sylvestre ledru and me) which are not in debian yet. I attached a debdiff in my last comment
<mok0> ok, I'll take a look. But there were some comments concerning jeuclid that concerned me
<quadrispro>  superm1: around here?
<c_korn> mok0: comments in the bug report? It was once rejected because I uploaded the wrong tarball which included files with licenses not mentioned in debian/copyright. but those files are not required anyway and are completely missing in the new tarball that is in jaunty queue atm?
<c_korn> -?
<mok0> c_korn: looking for it
<quadrispro> superm1: I'm looking at ipod-convenience, do you know if we can move the Depends on libgpod3 to libgpod4?
<quadrispro> hi mok0
<quadrispro> superm1: another thing, mythnettv-gui has been accepted by archive-admin but they rejected mythnettv, so now we have only the GUI in the repositories, and I think it could be a problem :)
<c_korn> mok0: as I see the version 3.1.4 of jeuclid is already in debian. I can provide a debdiff (but pastebin.com is down). there were only some small changes about annotations which are useless anyway (sylvestre said)
<c_korn> mok0: http://paste.ubuntu.com/123185/
<mok0> c_korn: I thought it was something about copyright still not being quite right
<c_korn> this is the debdiff jeuclid-debian -> jeuclid in jaunty queue
<c_korn> so jeuclid may also be synced now if that is easier
<mok0> c_korn: Hm. Perhaps we should just ask for a sync
<mok0> ^
<mok0> he
<mok0> c_korn: what about sivp, that could be sync'ed too
<c_korn> no, the debian package has some bugs
<c_korn> they were fixed by sylvestre and me yesterday
<mok0> c_korn: oh
<mok0> c_korn: and the fix is in your ppa?
<c_korn> it is also on revu
<c_korn> I also provided a debdiff
<c_korn> see my comment https://bugs.launchpad.net/ubuntu/+source/scilab/+bug/334362/comments/16
<ubottu> Ubuntu bug 334362 in scilab "FeatureFreezeException: Please update sivp 0.5.0 from REVU" [Undecided,New]
<mok0> c_korn: n/m, I can just fetch the source package from your PPA and fix the version string
<c_korn> mok0: why not take the package from revu?
<c_korn> the package in the ppa has no complete changelog
<mok0> c_korn: it's a new package in Ubuntu so it only should have 1 changelog entry
<mok0> c_korn: but we also need a FFE for it
<c_korn> hm, ok
<c_korn> well, there it is: https://bugs.launchpad.net/ubuntu/+source/scilab/+bug/334362
<ubottu> Ubuntu bug 334362 in scilab "FeatureFreezeException: Please update sivp 0.5.0 from REVU" [Undecided,New]
<mok0> c_korn: yes, but it hasn't been acked
<c_korn> https://bugs.launchpad.net/ubuntu/+source/scilab/+bug/334362/comments/15
<c_korn> need two akcs?
<c_korn> acks
<mok0> no...
<c_korn> so, it is ready to go?
<mok0> ah, yes :-)
<mok0> c_korn: but sivp needs scilab-5.1 is that right?
<c_korn> scilab >5 to compile yes
<mok0> c_korn: I'll process that first, then
<c_korn> ok
<c_korn> mok0: what about jeuclid now? should I change the bug report to a sync report?
<mok0> c_korn: I'll file a new one
<c_korn> mok0: now I read you said sivp is a new package in ubuntu. that is not true there is sivp-4.x already in jaunty
<c_korn> mok0: ok, thanks
<mok0> I must have had a typo when I searched for sivp before
<c_korn> maybe svip? I always mistype it like that
<mok0> he
<mok0> bug 334767
<ubottu> Launchpad bug 334767 in ubuntu "Please sync jeuclid 3.1.4-1 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/334767
<c_korn> ok, thank you. has this also to be ACKed?
<mok0> c_korn: There already is an ack somewhere
<mok0>  #326179
<mok0>  bug 326179
<ubottu> Launchpad bug 326179 in Ubuntu Jaunty "FeatureFreezeException: Please sync jeuclid 3.1.4 from debian experimental" [Wishlist,Fix committed] https://launchpad.net/bugs/326179
<savvas> mok0: is btk-core going to be removed?
<mok0> savvas: already gone
<savvas> mok0: great, so now all that remains is a powerpc build for bmpx :P
<mok0> savvas: eerr??
<savvas> mok0: sorry, forgot to mention, I was helping ScottK on the boost (1.34) -> boost1.35 transition
<mok0> savvas: ah it's part of that stuff
<mok0> savvas: what's involved in that transition? Change in API?
<iulian> mok0: Re: bug #333639.  Bug-fix only releases don't need an exception.
<ubottu> Launchpad bug 333639 in wxbanker "Please update wxbanker to 0.4.1.0" [Undecided,New] https://launchpad.net/bugs/333639
<savvas> mok0: no idea, but the developer of deluge said it's a "bad idea" :P
<mok0> iulian: yeah I was overly cautions
<mok0> cautious
<mok0> iulian: can you give it back?
<iulian> mok0: Would you like to take care of it?
<iulian> I'll unsubscribe motu-release.
<mok0> iulian: if you like
<mok0> iulian: thx
<iulian> Done, thank you.
<mok0> iulian: ok
<EagleScreen> hello
<EagleScreen> ubuntu-motu mail list is failing to me at remind me my password
<Laibsch> http://rafb.net/p/p2mP2T49.html: Hi, am I doing something wrong?  "puilder-dist create sid"
<Laibsch> I thought that was correct syntax.  I am running jaunty
<james_w> arguments are the other way round
<EagleScreen> i am not sure if is possibÃ±le to create a Sid enviroment
<EagleScreen> you have to create a squeeze enviroment, rename the .tar to sid and later run a pbuilder update to update it to sid
<james_w> no, hang on
<james_w> EagleScreen: you can
<james_w> Laibsch: your paste doesn't match your comment
<Laibsch> james_w: and?
<EagleScreen> I can pass on my pbuilder config file
<Laibsch> That command should be supported as well
<Laibsch> And of course I tried sid as well
<Laibsch> Nothing seems to work which gets me thinking I must be doing something wrong
 * directhex uses a pbuilderrc & regular pbuilder
<directhex> e.g. DIST=sid pbuilder update
<Laibsch> interesting
<EagleScreen> yes it is
<EagleScreen> can anyone run DIST=sid pbuilder create?
<james_w> Laibsch: it wasn't clear what you were trying to achieve
<Laibsch> OK
<Laibsch> james_w: Does that work for you, am I doing anything wrong?
<EagleScreen> sudo DIST=jaunty pbuilder update works for me
<directhex> EagleScreen, you need a custom pbuilderrc to allow it to work
<EagleScreen> yes I know, i have it configured
<Laibsch> directhex: Where is the documentation for that?
<jpds> Nafallo: (I thought you did... :/)
<Nafallo> jpds: ?
<directhex> Laibsch, https://wiki.ubuntu.com/PbuilderHowto
<sistpoty|work> hi folks
<Laney> pbuilder-dist FOR EVAR
<Laney> pbuilder vanilla FOR NEVAR
 * directhex pats Laney on the head
<hanska> Laney: wtf pbuilder-dist? :P
<Laney> hanska: it's a sweet way of managing multiple pbuilders
<Laney> pbuilder-sid build foo.dsc
<Laney> pbuilder-jaunty-i386 update
<hanska> Laney: uh, nice
<Laney> etc
<hanska> Laney: I make that with some aliases :P
<Laney> pbuilder-dist uses symlinks
<Laibsch> hanska: Are you on Jaunty?
<hanska> Laibsch: nope, Debian.
<james_w> directhex: monodevelop-boo is done, correct?
<Laibsch> OK
<hanska> Laney: ah, I'll check it. From pbuilder package?
<james_w> you added a .changes for it with a comment after it was apparently uploaded, which confuses me slightly
<james_w> hanska: no, it's in ubuntu-dev-tools
<hanska> james_w: why don't you send a patch to pbuilder guys to include that? Sounds useful
<directhex> james_w, yes, all done other than monodevelop-debugger-*
<james_w> directhex: cool
<james_w> hanska: I see no problem with that
<directhex> james_w, but afaik someone wanted to update the boo version (perhaps in debian) and it's not abi comp
<hanska> james_w: s/you/"generic" you/
<james_w> hanska: there's less of a need for Debian to have it because it's generally just sid that is needed, but it would be good to have it there
<hanska> james_w: not really, I currently have sid, squeeze, lenny and jaunty cowbuilders.
<james_w> hanska: but you're special :-p
<directhex> because hanska is one of these sexy collaborative types ;)
<james_w> exactly, and we should encourage that
<savvas> does anyone know if Greek (Ancient) is deprecated?
<james_w> hanska: I give you bug 161068 as evidence that I agree with you
<ubottu> Launchpad bug 161068 in ubuntu-dev-tools "Should pbuilder-dist be in a different package?" [Wishlist,Invalid] https://launchpad.net/bugs/161068
<savvas> I can't see it in the languages anymore
<directhex> savvas, is ancient greek deprecated? do i need to draw you a diagram? it involves naked men with beards
<james_w> Laibsch: bug 334848
<ubottu> Launchpad bug 334848 in ubuntu-dev-tools "[Jaunty] pbuilder-dist does not recognize any distributions at all" [Undecided,New] https://launchpad.net/bugs/334848
<Laibsch> james_w: Hehe, so you did find the bug I just created five minutes ago? ;-)
<james_w> oops :-)
<savvas> directhex: No offense, but I have jaunty and I don't see it as an option in the System > Administration > Language support > Install/ Remove languages
<savvas> directhex: whereas it was an option in intrepid, that's why I'm asking
<james_w> Laibsch: "which pbuilder-dist"?
<Laibsch>  /usr/bin/pbuilder-dist
<Laibsch> http://packages.ubuntu.com/jaunty/all/ubuntu-dev-tools/filelist
<james_w> just checking :-0
<james_w> I can't see what's wrong
<slytherin> any one free enough to do a small change to libdvdread packaging? The bug is not critical, so please reply only if you have nothing better to do.
<james_w> Laibsch: can you add "set -x" to the top of the script and re-run?
<Laibsch> You want the output as a pastebin?
<slytherin> is there any variable in rules which will have the value of package name?
<hanska> slytherin: you can use dpkg-parsechangelog
<Laibsch> james_w: This is not a bash script
<Laibsch> but python
<james_w> heh, sorry
<james_w> it was me that wasn't looking at /usr/bin/pbuilder-dist :-)
<slytherin> hanska: that is overhead for my requirement
<james_w> Laibsch: do you know how to operate pdb?
<Laibsch> no
<Laibsch> but I guess I can learn
<Laibsch> Is it something like gdb?
<james_w> yeah
<james_w> Laibsch: do you have /usr/share/debootstrap/scripts/ ?
<Laibsch> james_w: http://rafb.net/p/qgojoF90.html
<james_w> Laibsch: ok, please open the script in a root editor and find the line that says "script_name = os.path.basename(sys.argv[0])" and put in the line above
<james_w> "import pdb; pdb.set_trace()"
<james_w> making sure to indent with tabs
<james_w> then save and close and run again
<james_w> you will get a debugger prompt
<james_w> use "s" to step in
<james_w> "n" to step over
<james_w> and "p" to print something
<james_w> could you try and figure out why it claims not to know about any distributions?
<Laibsch> step in vs step over?
<Laibsch> I guess I should hit n until I hit a problem, right?
<Laibsch> Funnily enough, the thing works in pdb ;-)
<Laibsch> Maybe also because I have a ~/.pbuilderrc which previously I did not?
<james_w> directhex: you included tarballs for monodevelop-debugger-* as they are the tarballs in NEW?
<directhex> james_w, aye
<james_w> thanks
<directhex> james_w, if your git wrangling is good enough you can pristine-tar then yourself.....
<directhex> took me a few days to work it out though ;)
<james_w> if only you used bzr, it would all be transparent :-p
<mok0> james_w: hmm, coming from git, bzr isn't obvious either
<james_w> true
<james_w> but I'd like to fix that
<hyperair> but coming from svn, bzr is easier to figure out than git
<mok0> james_w: that would be good!
<hyperair> the commands for bzr are very similar to svn
<mok0> hyperair: yes, bzr reminds of svn in some ways
<hyperair> mok0: yeah, svn on steroids
<hyperair> mok0: svn with uber branching/merging capabilities
<mok0> What I don't like is having different directories for branches
<mok0> hyperair: yes
<hyperair> ah, i actually liked that at first, but come to think of it, having all of them in one directory is awesome
<mok0> hyperair: it is. Once you get used to it
<directhex> i agree with hyperair actually
<directhex> i find git confusing & painful. but not my decision
 * directhex hides from hanska 
<hyperair> directhex: agree.
<mok0> hyperair: what I lack in git is a simple command to see what the current branch comes off
<hanska> directhex: :E
<hyperair> directhex: git is awesome, but having revnos that are constantly huge strings is a pain
<directhex> heh
<hyperair> mok0: what dyou mean?
<mok0> hyperair: when I've been away from a project, I tend to forget what branch/tree structure the project had
<mok0> hyperair: I use gitk to visualize it
<hyperair> i see
<mok0> hyperair: but it would be nice with just a simple command
<hyperair> yeah it would
<mok0> james_w: so when do we start maintaining packages in bzr?
<mok0> james_w: we have a whole bunch of -0ubuntu* ones that we could start with right away...
<james_w> mok0: many people are already
<james_w> we'll be ready to do large-scale maintenance soon
<mok0> james_w: I thought there was read-only access only
<james_w> yeah, they'll be read-write soon
<james_w> but there are lots of independent branches already
<mok0> james_w: ah ok, private branches off the "official" one
<james_w> nope
<james_w> just independent branches
 * directhex isn't too sure how this packages-as-bzr thing is gonna work :/
<mok0> james_w: ok, but I am asking about common maintenance
<x-ip> Hi !
<james_w> yeah, I'm working on that
<james_w> as I said, it will be soon
<james_w> a month or two
<mok0> james_w: alrighty, sounds good
<mok0> james_w: any decisions on the workflow? I mean things like branch names, bug fix branches, new upstream versions etc?
<james_w> mok0: I'm not sure what there is to decide there, but that may be just that I'm too in to it. Could you expand a little please?
<mok0> james_w: Well, we need to have a branch that contains upstreams code, and branched off that we have our extra debian/ dir, then we perhaps have some bugfix branches off upstream as well, we might have a separate branch for each ubuntu release etc. We need some guidelines on how to construct that tree of branches
<mok0> james_w: presumably, there's a huge merge for creating the source package
<james_w> ah
<james_w> that's a bit beyond what I am working on right now
<mok0> james_w: ok :-)
<james_w> I'm interested in it, I'm just working on making our current workflow translate to bzr
<james_w> then we can start to get creative
<james_w> mok0: do you know the vcs-pkg.org project?
<mok0> james_w: I understand
<mok0> james_w: I follow their ML; not much going on atm
<james_w> yeah
<james_w> directhex: uploaded
<mok0> james_w: I've played with  a scheme similar to the above mentioned locally, using git
<james_w> directhex: mixing GPL with MIT/X11 is a little wrong in my eyes, but it's nothing to reject
<james_w> mok0: interesting, have you considered posting a description to the list?
<mok0> james_w: no I haven't...
<directhex> james_w, AFAIK it's fine to mix those, as MIT is GPL-compatible
<directhex> james_w, also, woo!
<mok0> james_w: it's pretty much inspired by what the masters have described
<james_w> directhex: yeah, it's not a problem of incompatibility in that sense.
<superm1> quadrispro, ipod-convenience fixed.  thanks for reporting
<superm1> quadrispro, as for mythnettv, what was the rejection purpose?
<superm1> we should get that fixed asap
<directhex> james_w, it's a dick move, you mean?
<james_w> directhex: the issue is with debian/patches/ really, debian/copyright says they are GPL, so upstream can't just take them
<james_w> and it may make the final thing GPL, I can't remember
<directhex> james_w, oh. erm, that's an error with our handling of copyright i think
<directhex> let me find a meebey
<james_w> directhex: what's your aim for mono 2.0 in jaunty?
<directhex> james_w, what about it, specifically? the major goal (jaunty install cd has only 2.0 classlib) is done
<james_w> cool
<james_w> I just looked at the TODO
<james_w> and it looks to me like there is will be too much there to get it done for jaunty
<goshawk> hi
<goshawk> if someone has free time, can please see http://revu.ubuntuwire.org/p/dsss ?
<directhex> james_w, in universe, yeah. but it's done in main, which is great IMHO
<james_w> so I wondered if there was a certain point it would be good to get to, thinking of the CD thing, but if that's done then anything else seems like a bonus to me
<directhex> james_w, and now debian is unfrozen, it means karmic's day-one import will basically get it all done
<james_w> coolio, nice work
<james_w> directhex: it won't cause those libraries to FTBFS if someone tries to rebuild them will it?
<directhex> james_w, um....... well........ yes, it will. i suppose that makes it a higher priority then
<james_w> err, yeah
<james_w> kind of
<Laney> haha
<james_w> that's not really the way to organise a transition, I've always been uncomfortable about that
<Laney> I (we) can take a big run at it over the weekend
<james_w> Laney: cool, thanks
<james_w> Laney: I'll help out if I'm around
<Laney> awesome
<directhex> i'll try too, time-allowing (but my weekend looks over-full)
 * Laney gets the tinnies in
<james_w> if it's not done next week I recommend we put the pieces back together so we can have a safe half-done transition for release
<james_w> then optionally transition anything else after that time
<directhex> james_w, IMHO it'll be easier to finish than half-finish. i'm not sure how to unbreak building old packages without major screwups
<AdamDH> hi, if my source is called  binutils-2.18.tar.gz should I rename this to binutils_2.18.orig.gz when I include it inside my package?
<james_w> directhex: yeah, that's why you shouldn't really organise it this way.
<directhex> james_w, transitioning 100 packages is hard
<james_w> directhex: indeed, I don't dispute that
<james_w> but making them all insta-FTBFS causes issues in itself
<james_w> doing it in experimental saves you from some of that
<james_w> but you will still have issues when you try and do all this in unstable and try and get it to transition to testing
<directhex> it's started in unstable
<directhex> release manager greenlighted a breaking transition, as it was blocking kde & gnome
<directhex> battery is nearly flat :(
<mok0> directhex: you _want_ it to be flat, otherwise it won't fit in your laptop!
<directhex> mok0, http://www.plusminus.ru/flashbag.html
<mok0> directhex: hehe
<AdamDH> when I am running debuild -S -sa so I can upload my package to my ppa I get an error about a debian revision number, there is no debian release so I did -0ubuntu1 in the changelog to show this? what else could be wrong here?
<james_w> AdamDH: "an error" isn't too informative. What's the actual error you get?
<AdamDH> sorry forgot the link to the pastebin, http://paste.ubuntu.com/123348/
<AdamDH> line 15 shows the error
<Laney> AdamDH: your orig is misnamed
<Laney> IMO that error is quite clear
<directhex> Laney, very!
<Laney> heh
<Laney> this is quite some flat battery you have directhex
<AdamDH> It sounds stupid thats what I considered so the upstream source is binutils_2.18.orig.tar.gz
<Laney> you need to name it what it wants
<directhex> Laney, "flat" means "red in gnome-panel"
<directhex> AdamDH, the orig name matches the name in changelog/control
<AdamDH> ah ok did not know that
<AdamDH> thanks again will modify that
<AdamDH> it seemed to upload ok, https://launchpad.net/~adamhorden/+archive/ppa and the package is there, I will change the orginal source name
<directhex> AdamDH, you created a native package, due to missing orig
<AdamDH> so my upstream source needs to be named msp430-binutils_2.18-msp430-cvs.0.0.20090226.orig.tar.gz?
<directhex> sounds right
<directhex> just... need... to last until coffee break...
<directhex> 20 minutes remaining,,,,,
<bddebian> Heya gang
<directhex> okay, i'm out of power...
<cristi> hello! what do i need to learn in order to be able to get involved in the motu project?
<dholbach> hiya cristi
<dholbach> check out https://wiki.ubuntu.com/MOTU/GettingStarted
<iulian> See /topic as well.
<dholbach> cristi: there's also a bunch of videos linked from there, docs, the packaging guide, etc etc
<dholbach> lots of information :)
<iulian> Hey dholbach.
<cristi> do i need to know cpp fundamentials however?
<dholbach> hiya iulian
<iulian> cristi: Not really, no.  If you want to start by packaging things, you don't need to know any programming language.  If you want to fix non-packaging bugs then yes, it may help you.
<dholbach> https://wiki.ubuntu.com/MOTU/FAQ should answer that
<dholbach> and one of the MOTU videos is especially about questions like that :)
<cristi> dholbach: ok, so i have a lot of reading to do, but i am very determined :D
<iulian> cristi: Excellent, please don't hesitate to ask questions in this channel if you encounter issues.
<dholbach> cristi: talk to us if you have any questions :)
 * dholbach hugs iulian
<dholbach> great minds think alike :)
 * iulian hugs dholbach back. :)
<RoAkSoAx> heya guys, can we still add watch files and update packages?
<dholbach> RoAkSoAx: you will need to follow https://wiki.ubuntu.com/FreezeExceptionProcess - we're focussed on bug fixing now
<RoAkSoAx> dholbach, ok thanks.. so bug fixing is it :)
<dholbach> iulian, sistpoty|work: gracias
<RoAkSoAx> but, we can do merges in case the package in debian fix any bugs in ubuntu right?
<sistpoty|work> dholbach: bitte ;)
<dholbach> RoAkSoAx: sure
<RoAkSoAx> dholbach, thnks :)
<iulian> Hmm, my sound stopped working and I haven't even noticed.
<iulian> Device: Playback: Null Output (PulseAudio Mixer)
<iulian> Looks odd.
<tgm4883> What is the reason that http://revu.ubuntuwire.org/p/mythnettv is rejected?
<sistpoty|work> tgm4883: see https://lists.ubuntu.com/archives/ubuntu-archive/2009-February/025035.html
<tgm4883> sistpoty|work, thanks.  Any chance I can fix that?
<sistpoty|work> tgm4883: realign debian/copyright to what the sources say?
<tgm4883> well yea, I meant can I fix that this cycle?
<sistpoty|work> tgm4883: I suggest you ask superm1 for this. If he absolutely wants it in, I assume he'll grant you a FFe
<tgm4883> ok
<tgm4883> thanks
<AdamDH> if there is no debian version then when I append to my version in the changelog I just do -0ubuntu1 or just -1?
<RainCT> AdamDH: -0ubuntu1
<AdamDH> thanks RainCT
<Adri2000> RainCT_: now is the time :)
<nixternal> 10 Minute Notice - Ubuntu MOTU Council Meeting - #ubuntu-meeting
<RainCT> Adri2000: as in, production is being updated?
<Adri2000> yep, see #-devel
<RainCT> great \o/
<quadrispro> superm1: I don't know why it has been rejected :-/ but I remember that there was some little issue (it might not be lintian clean really)
<superm1> quadrispro, tgm4883 found why it was rejected
<superm1> it was GPL2/3 typo in debian/copyright
<quadrispro> ahh!!
<superm1> he corrected it and put the new package on an FFe bug
<superm1> which i'm cool with
<superm1> quadrispro, if you want to sponsor it
<superm1> bug 334960
<ubottu> Launchpad bug 334960 in ubuntu "FFe for mythnettv" [Undecided,New] https://launchpad.net/bugs/334960
<quadrispro> great!
<quadrispro> right now
<quadrispro> superm1: mario, did you look at it? I'm asking you that because I've to go away now, and I haven't the time to review it
<superm1> quadrispro, the only diff should be a sed 's/2/3/' debian/changelog.  wouldn't hurt to do a debdiff and double check
<quadrispro> ok, i'll take a look later
<khirr> hello, how can ic reate .deb packages from my bash script using gdialog
<hyperair> read the packaging guide
<hyperair> https://wiki.ubuntu.com/PackagingGuide
<RainCT> vorian: the C10shell hook looks interesting.. perhaps it could be installed by default with ubuntu-dev-tools? (changing vim to sensible-editor, though :P)
<vorian> RainCT: i think so, it's a life saver
<RainCT> perhaps even include several of them and have a pbuilder-hooks script to enable/disable them (like the interface to choose a screen profile).. if someone is on hacking mood that could be something nice to have :P
<vorian> hmmm
 * sistpoty|work calls it a day... cya
<RainCT> do pbuilder hooks work with cowbuilder?
<RainCT> Unable to obtain lock [...] held by rainct@bazaar.launchpad.net [...] locked 6508 hours, 11 minutes ago    o_O
<vorian> RainCT: i've never used cowbuilder
<RainCT> it's fast (uncompressed chroot, no need to untar tarballs) :)
<vorian> hmm
<salty-horse> is gnome-volume-manager responsible for auto-mounting usb mass storage devices etc?
<mrooney> Could someone explain what this u-u-s comment means? https://bugs.edge.launchpad.net/ubuntu/+source/wxbanker/+bug/333639/comments/4
<ubottu> Ubuntu bug 333639 in wxbanker "Please update wxbanker to 0.4.1.0" [Undecided,Incomplete]
<mrooney> the patch is definitely not reversed
<slytherin> Is there anything wrong with ports repository server?
<cody-somerville> slytherin, yes
<slytherin> cody-somerville: What happened? I am getting error that libgmyth is not available (powerpc).
<cody-somerville> slytherin, I think there is a hardware issue.
<cody-somerville> slytherin, what component is libgmyth in?
<slytherin> cody-somerville: universe
<cody-somerville> slytherin, libgmyth is only built on amd64 and i386
<slytherin> cody-somerville: http://launchpadlibrarian.net/14121999/buildlog_ubuntu-intrepid-powerpc.gmyth_1%3A0.7.1-1_FULLYBUILT.txt.gz
<cody-somerville> http://packages.ubuntu.com/search?keywords=libgmyth
<slytherin> cody-somerville: that site does not list ports packages.
<cody-somerville> ah
<slytherin> can anyone having a jaunty installation please try playing a DVD with VLC or totem-gstreamer?
<quadrispro> superm1: are you sure we can upload a package in NEW during FF?
<superm1> quadrispro, i'm acking it. i'm delegate for mythbuntu related stuff
<quadrispro> superm1: ah perfect! can I upload the package or I have to wait for another ACK?
<superm1> quadrispro, i think you should be fine to upload the package, especially for how small that change was
<quadrispro> superm1: good
<quadrispro> ok
<moquist> if my package has multiple binaries with different .config scripts, should I have multiple .templates files or just one?
<slangasek> moquist: the .templates file has to accompany the .config file - i.e., it's per binary package
<moquist> slangasek: thx
<slytherin> can anyone running up to date jaunty do some testing with DVD playing for me?
<jreinhardt> Hi
<jreinhardt> I have a LaTeX package in REVU  (http://revu.ubuntuwire.org/p/pgfplots) waiting for review. A few days ago the Bugtracker informed me that there is a ITP for this package n Debian. (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514751), which was withdrawn, because the package will be part of TeXLive 08. Now what is the right thing to do with the package in REVU?
<ubottu> Debian bug 514751 in wnpp "ITP: pgfplots -- TeX package to draw normal and/or logarithmic" [Wishlist,Open]
<slytherin> can anyone please do some testing for me with dvd playing?
<moquist> I'm having trouble figuring out how to change debian/rules so only moodle-common has the moodle source tree, and moodle-mysql, moodle-postgresql, etc. just handle some deps, debconf, and postinst tasks.
<moquist> I've been reading http://wiki.debian.org/PkgSplit and looking at a couple multi-binary packages (NFS and postgresql), but if anybody has any recommendations for what I should read, I'll appreciate them.
<RainCT> moquist: When dpkg-buildpackage creates a .deb, what it does is (baldly) run the stuff from debian/rules, look at the control file to see which binary packages it should produce and then take the stuff from debian/<pkgname1> and put it into <pkgname1><...>.deb, then take the stuff from debian/<pgkname2> and put it into <pkgname2><...>.deb, etc
<RainCT> moquist: so your debian/rules has to place the files into debian/moodle and leave debian/moodle-{mysq,postgresql} empty if you don't want anything there
<moquist> that makes sense; thx
<RainCT> moquist: as for the postinst and such, you'll have to rename the files in debian/ which are only for a certain binary package to debian/<pkgname>.<original filename>
<RainCT> moquist: no problem, hope this helps :)
<moquist> we'll see, but it sounds like it will :)
<fabrice_sp_> slytherin, is it ok with a VM?
<moquist> I already have the various .postinst, .config, .templates files. .rules didn't work. :)
<RainCT> moquist: there can only be one rules file (debian/rules)
<slytherin> fabrice_sp_: yes, I just want to know if problem I am facing has anything to do with latest libdvdread update
<RainCT> moquist: the <pkgname>.<file> rule only goes for debhelper files
<moquist> yeah, that's what I figured
 * fabrice_sp_ starting Jaunty VM
<RainCT> (and the {post,pre}* and such of course)
<mrooney> mok0: could you explain what you meant re bug 333639?
<ubottu> Launchpad bug 333639 in wxbanker "Please update wxbanker to 0.4.1.0" [Undecided,Incomplete] https://launchpad.net/bugs/333639
<moquist> RainCT: right
 * moquist moves debian/<pkgname>.install back to debian/install
<RainCT> moquist: that one is fine ("install" is for dh_install, which is from debhelper)
<moquist> Oh.
 * moquist moves it back
<fabrice_sp_> slytherin, the VM is running. What do you want me to test?
<slytherin> fabrice_sp_: can you try playing some video DVD?
<fabrice_sp_> slytherin, with some specific pgm? I generally use vlc...
<slytherin> fabrice_sp_: vlc is fine. make sure it is fully updated.
 * fabrice_sp_ have to reboot his Jaunty VM :-/
<fabrice_sp_> slytherin, it's playing fine with totem
<slytherin> fabrice_sp_: what command did you use for playing? or did it auto start?
<slytherin> fabrice_sp_: and did you see DVD menu in totem?
<fabrice_sp_> slytherin, autostart
<fabrice_sp_> hmmm, have to check for the menu
<fabrice_sp_> slytherin, no, no menus. I'll check with another DVD
<slytherin> fabrice_sp_: does the DVD has any menu?
<fabrice_sp_> I think so. That's why I'm trying with one that for sure has a menu
<fabrice_sp_> slytherin, totem does not reproduce the menu (jaunty or intrepid). vlc does in both
<slytherin> fabrice_sp_: Ok. So at least there are no regressions. :-)
<fabrice_sp_> lol
<fabrice_sp_> slytherin, in which program are you missing the menu?
<fabrice_sp_> s/in/with/
<slytherin> fabrice_sp_: It is not question of missing menu. I am not able to play dvd at all. It was working till 2 days ago.
<fabrice_sp_> ohh
<slytherin> so I was afraid that I broke dvd playing completely with my uploads.
<fabrice_sp_> k
<slytherin> fabrice_sp_: I am surprised you are not getting menu in totem. You should (provided all the gstreamer plugins are installed).
<fabrice_sp_> slytherin, yes, I know. but as I always use vlc, I never noticed that. It's jumping directly to the movie, so it could be also some parameters
<slytherin> fabrice_sp_: any, not a high concern right now
<fabrice_sp_> no :-)
<fabrice_sp_> A library in adm64 should be installed in /usr/lib64? Or it should go to /usr/lib and symlink to /usr/lib64?
<dtchen> fabrice_sp_: on Ubuntu, it should install into /usr/lib
<dtchen> fabrice_sp_: /usr/lib64 is simply a symlink to /usr/lib
<fabrice_sp_> dtchen, ok. Thanks!
<TheMuso> savvas: I still have the diff here, so I will try asap
<savvas> TheMuso: I just realised I was talking in the wrong channel, sorry :P
<TheMuso> savvas: test building now.
<savvas> TheMuso: ok - I tried to create a virtual powerpc with qemu through virt-manager but something was going wrong
<TheMuso> savvas: That would probably be slow anyway.
<savvas> I read that there's a kqemu kernel module somewhere that speeds it up - but anyway, this is better :)
<TheMuso> savvas: FTBFS, getting you the necessary bit of the log.
<TheMuso> savvas: http://paste.ubuntu.com/123573/
<savvas> TheMuso: which version of bmpx did you use?
<TheMuso> savvas: the latest in jaunty
<TheMuso> and your diff applied against that ok.
<savvas> damn
<savvas> thanks TheMuso for your help, at least I/we tried :)
<TheMuso> savvas: by the looks of that, it needs a library to build against. Does Ubuntu have that library?
 * TheMuso will dig into this more later. I think this is quite fixable, just got to work out what its looking for, and that means building step by step in a chroot by hand.
<savvas> TheMuso: the last time I checked libsidplay was in the ports
<TheMuso> Yeah I just checked the package, and the build wouldn't have got that far if the sidplay lib wasn't found. I will look into it later if you like.
<savvas> ScottK: I guess the other solution is to remove libsidplay and remove support for commodore 64 music :\
<savvas> TheMuso: please do!!
<directhex> moo
<TheMuso> savvas: I don't think we will have to go that far, but I will see what I can find.
<TheMuso> But that will be later, since I have other work to do currently.
<savvas> alrighty, thank you
#ubuntu-motu 2009-02-27
<savvas> * Fri Jun  6 2008 Alexander Kahl <akahl@iconmobile.com> - 0.40.14-5
<savvas> - disabled sid support for now, problems on ppc
<savvas> heh, looks like fedora disabled sid for bmpx
<TheMuso> savvas: hrm ok, I can easily try disabling sid for ppc, without your diff...
<savvas> TheMuso: is it appropriate to disable sid for only one arch?
<TheMuso> savvas: Well if another distro is having the same problem, I say so.
<TheMuso> I'd say so even
<savvas> I mean if it breaks only one arch, is it ok to disable it for that one?
<savvas> ah ok
<TheMuso> savvas: I think so.
<savvas> it can be done in debian/rules I think
<savvas> let me try, it's good for practice :)
<TheMuso> savvas: debian/control should be enough to do it.
<TheMuso> Unless there is code in rules to explicitly enable it.
<savvas> there is, --enable-sid :)
<savvas> I was thinking of checking DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH) before passing the arguments
<TheMuso> That could work, although thats a lot of work, especially if can be done a lot more simply, but whatever works.
<savvas> http://paste.ubuntu.com/123596/plain/
<savvas> does this rules file look ok TheMuso ?
<savvas> I'm not familiar with makefile variables yet
<TheMuso> savvas: that looks ok.
<TheMuso> savvas: and to make it even more clear that sid is disabled on powerpc, you disable dis as a build dependency on powerpc, so it doesn't get installed at build time/.
<savvas> er.. libsidplay1-dev [!powerpc] ?
<savvas> in debian/control I mean
<TheMuso> savvas: correct.
<savvas> TheMuso: will that exclude it from the ${shlibs:Depends} and ${misc:Depends} that bmpx binary package depends on?
<TheMuso> savvas: Yes, because the library won't be in the chroot where it gets built.
<TheMuso> And disabling sid in the config arguments will also prevent it.
<savvas> cool, that should work then :)
<savvas> TheMuso: here it is: http://paste.ubuntu.com/123599/
<TheMuso> savvas: ok will test.
<savvas> thanks :)
<savvas> I'll go poke around a bit more with that old patch.. it was supposed to work, they used it on pld-linux: http://ftp.pld-linux.org/dists/th/PLD/SRPMS/RPMS/bmpx-0.40.14-5.src.rpm - I wonder if it actually works on a powerpc
<TheMuso> ok
<TheMuso> savvas: ah you have the if clause for detecting powerpc as host arch a little mixed up. THe --disable-sid and --enable-sid strings should be swapped around. I'll do that here now.
<savvas> TheMuso: right, sorry - it's 2.15 am here :)
<TheMuso> savvas: thats fine.
<savvas> I'll probably be heading for bed hehe
<TheMuso> savvas: thats fine. If this builds ok, do you want me to upload the change?
<TheMuso> savvas: ok bmpx is now building on powerpc, as in its actually compiling.
<savvas> great news
<TheMuso> savvas: so do you want me to upload if this succeeds?
<savvas> TheMuso: Can I let you know tomorrow?
<TheMuso> savvas: sure.
<savvas> ok, I just want to be sure about that patch - I mean, how come it builds on pld-linux?
<TheMuso> savvas: I'll take a look in a bit, busy with something else atm.
<savvas> TheMuso: sure, ok :)
<savvas> hm..
<savvas> pld-linux use autoconf and automake, whereas the debian package uses autotools-dev and this:
<savvas> 	ln -sf /usr/share/misc/config.guess config.guess
<savvas> 	ln -sf /usr/share/misc/config.sub config.sub
<TheMuso> savvas: that shouldn't be a problem however. I haven't looked at it myself, so I'd need to look at everything before commenting.
<savvas> TheMuso: alright, we'll talk tomorrow, or highlight me if you find anything - goodnight :)
<TheMuso> savvas: sure
<dholbach> good morning
<fabrice_sp_> Good morning dholbach ;-)
<dholbach> hiya fabrice_sp_
<fabrice_sp> Hi. I've found a package that needs a fix because of a FTBFS, but it doesn't have a .orig tarball. As it's a native package, may I then change the configure file directly or should I add a patching system to the package? it's libhid.
<ScottK> Change it directly.
<dholbach> fabrice_sp: I guess it doesn't use a patch system, does it? :-)
<ScottK> For a native package it doesn't make a huge amount of sense.
<dholbach> no, it doesn't
<ScottK> ... but /me is tired and going to bed..
<fabrice_sp> no patch system, no
<dholbach> but I've seen a lot of "accidental" native packages already :)
<fabrice_sp> good night Scottk
<dholbach> so there's nothing that surprises me anymore :)
<dholbach> night Scott
<fabrice_sp> it's this one: https://launchpad.net/ubuntu/+source/libhid
<dholbach> just go ahead then
<fabrice_sp> great! will be easier without adding a patching system :-)
<fabrice_sp> thanks ;-)
<Toadstool> g'morning everybody
<dholbach> hiya Toadstool
<Toadstool> hey dholbach!
<didrocks> dholbach: ahem... /me hides :) (strange, as if I ran dch in my pbuilder? :/)
<didrocks> dholbach: concerning the missing file, I am investigating, but normally I checked them
<didrocks> (yeah, the hook is still there)
<didrocks> dholbach: I think this issue may appears now because of the new python installer location (no more /usr/lib/python*/site-packages) and as my sponsor request is older than this change... Investigation in progress :)
<dholbach> thanks didrocks :)
<goshawk> hi, if someone has free time, can please review http://revu.ubuntuwire.org/p/dsss ?
<goshawk> thx
<Toadstool> goshawk: looks good to me but I'd rather let persia or rainCT judge since it's been a long time since I did not review packages
<goshawk> oki thanks a lot Toadstool
<goshawk> :)
<slytherin> Hi friends one question. Acer Aspire 4530, AMD 64, NVIDIA 9100 M G graphics card. Which version to install? Intrepid or jaunty and i386 or amd64?
<savvas> TheMuso: if bmpx for powerpc was built fine, please upload it. I've sent a bug report to Debian about this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517373
<ubottu> Debian bug 517373 in bmpx "FTBFS(powerpc): configure: error: libsidplay 1.x not found!" [Normal,Open]
<sistpoty|work> hi folks
<mok0> hi sistpoty|work
<sistpoty|work> hi mok0
<mok0> did you get somewhere with the copyright parser?
<mok0> sistpoty|work: ^
<sistpoty|work> mok0: not really (as in parse a new machine readable copyright format)
<mok0> sistpoty|work: ah ok
<sistpoty|work> mok0: however I started writing my own tool, that can generate a copyright file from sources (given that the sources have sane license headers)
<mok0> sistpoty|work: cool!!
<geser> slytherin: like you want, but with an amd64 install it's easier for you to test amd64 packages (if you don't have an amd64 install already)
<directhex> i signed a key!
 * directhex is special
<slytherin> geser: actually it is not a laptop for me. It is for a relative. The requirements are very generic (no voip, no DVD playing). I have never used amd64 so I was not sure if nvidia cards will work.
<directhex> slytherin, nvidia has been fine on amd64 for about 5 years
<slytherin> Considering that xorg is getting updated frequently in jaunty, I think I will go with intrepid.
<savvas> is there a patch gui editor? or something that allows me to quickly filter out file patches from a diff file?
<geser> slytherin: then use i386 as you don't need to fight with flash, acroread or other 32bit non-free software
<slytherin> geser: acroread is not an issue. evince works fine. and flash is available for 64 bit.
<geser> slytherin: I didn't try flash on amd64 yet. does it work reliable?
<directhex> geser, yes, but adobe AIR sites may not work
<sistpoty|work> savvas: I use vim for this :P (or filterdiff)
<geser> slytherin: I had to use acroread a few months ago for a PDF. I could view the PDF with evince but not use it because of javascript
<slytherin> geser: I have one week to test before I hand over the machine. So in worst case I will need to install ii386 before hand over.
<geser> other than that both amd64 and i386 are good
<slytherin> another related question. Would a single / partition for 160 GB HDD create any problem? The reason I want to have a single partition is to not limit size of home folder.
<savvas> thanks sistpoty|work :)
<geser> I'd probably do something like 20 GB for / (should be enough for everything) and the remaining part /home
<geser> having /home on a separate partition makes it easier if a reinstall is needed (for whatever reason)
<mok0> Better yet: have / on a separate disk
<mok0> Then use rsnapshot to create a backup of your /home disk to / disk
<slytherin> That is also fine. My /root with about 7 GB has not filled in last 3 years. So 20GB / is more than enough.
<slytherin> I hope this experiment succeeds. :-)
<geser> slytherin: perhaps 10 GB for / root is also ok
<savvas> sistpoty|work: found geany :P
<didrocks> doko: do you mean that python 2.5 will be removed in jaunty and python 2.6 will be the only release available?
<mok0> didrocks: As I understand, 2.6 will be default, but 2.5 will still be available
<doko> didrocks: likely not removed in time for jaunty
<mok0> doko: There was talk of keeping 2.4 around, even
<didrocks> doko: ok, and in a package which retreive python version in debian/rules with pyversions -vr debian/control, what do you advise?
<mok0> Users might be using extension modules that are not part of Ubuntu
<mok0> Esp. if they are commercial modules, it can be a pain to upgrade.
<mok0> That
<didrocks> mok0: yeah, of course
<didrocks> I'm just unsure to see if I need to ship both version (cdbs seems to want to make that) or just one
<mok0> didrocks: that said, I haven't followed what changes have happened in the API between 2.4 and 2.5
<didrocks> mok0: don't know either :/
<mok0> didrocks: yeah, the way all versions are packaged together makes it worth considering...
<mok0> didrocks: now, if it were possible to separate all 2.4 and 2.5 stuff out into separate packages....
<didrocks> mok0: yeah, it will be better...
<didrocks> but there is a lot of issue if I support 2.5 and 2.6, for instance together
<didrocks> site-packages/dist-packages in .install for instance
<mok0> didrocks: sure.
<mok0> didrocks: pycentral is nice that way
<didrocks> (yeah, I ask for sponsoring before this change, and now, when dholbach tried, it FTBFS because of dh_install ^^)
<mok0> didrocks: Murphey's law
<didrocks> mok0: obviously ^^
<didrocks> mok0: when i put 2.5 in debian/control.in, it builds against 2.5 and 2.6
<didrocks> I think this is the behavior of pycentral but I am not familiar with it
<mok0> didrocks: oh? Like, it builds >= 2.5 ?
<didrocks> mok0: apparently, that's why I ask some advices, not a python packager specialist ^^
<didrocks> XS-Python-Version: >= 2.5
<mok0> didrocks: I think it should be able to build everything you ask for, so if you ask for >= 2.4, it should build 2.4, 2.5 & 2.6
<didrocks> ok, and so, because of .install and site-packages/dist-packages change, it fails :)
<didrocks> I can explicitely named what I want to copy
<didrocks> but is it necessery? Or I just bump to 2.6...
<mok0> didrocks: oh yes, that
<savvas> so.. "XS-Python-Version: current" ?
<didrocks> savvas: it will take which version, when several are available like now?
<mok0> savvas: I think that just takes all the currently supported versions
<savvas> didrocks: no idea, I just saw it in a package and got me puzzled as well :)
<didrocks> :)
<mok0> basically, current and all mean the same thing
<doko> didrocks: if the package doesn't install (dependency on python (<< 2.6)), install pkgbinarymangler, try a local rebuild, see if it succeeds. if it's a no change rebuild, upload with a buildN release number, if you have to do local changes, upload a new version
<doko> didrocks: no, if it says >= 2.5, it's fine and doesn't need to be changed
<mok0> didrocks: .... and so you were hoping that 2.4 wasn't supported :-)
<didrocks> doko: but dh_install fails because of site-packages/dist-packages changes beetween 2.5 & 2.6
<didrocks> mok0: no, I just need 2.5 at least :p
<didrocks> doko: so, it's better to adapt the .install for 2.5 and 2.6 cases.
<didrocks> ?
<mok0> doko: is the dist-packages policy valid for 2.5 too?
<didrocks> mok0: apparently, not, dh_install yell at me :)
<dholbach> best to discuss in #ubuntu-devel so doko hears about it too :)
<savvas> didrocks: is there a pyversions file in the package?
<doko> didrocks: yes, use something like usr/lib/python*/*-packages
<doko> dholbach: ?
<dholbach> ah, he's here as well :)
<dholbach> doko is lurking everywhere
<dholbach> :)
<didrocks> doko: ok, that was my question, it's better to support both versions in install files, ok :)
<savvas> dholbach: by the way, I've sent the patch for glife gtk-2/gnome-2 upstream :)
<dholbach> savvas: ROCK!
<didrocks> dholbach: as seb128, he told me this morning "congrats for your first self-sponsored package" (yeah, I mainly touch "main" GNOME packages)
<didrocks> mok0 and doko : thanks :)
<savvas> :)
<didrocks> savvas: as well ^^
<mok0> savvas: he calls you a rock
<dholbach> I don't, really :)
<mok0> ;-)
<savvas> mok0: :P
<savvas> er..
<savvas> why is libboost1.37-doc in the libboost1.37-dev dependencies ?
<mok0> savvas: maintainer's choise
<mok0> should be Suggests: though
<savvas> I know, every time I use apt-get build-dep I get that huge doc package :p
<mok0> ha!
<savvas> same for libboost1.35-dev
<savvas> mok0: did you see a bug report about it?
<mok0> savvas: you can ask yourself what the point is of splitting the docs out then
<mok0> savvas: no
<savvas> ok, I will
<mok0> savvas: ROCK!
<mok0> hehe
<savvas> :P
<savvas> I know I ROCK your world!
<mok0> savvas: oh, so that's what's going on atm
<savvas> hehe :)
<slytherin> if a package in main has gained dependency on a package in universe what should be the approach to fix depwait?
<didrocks> slytherin: MIR for the dependency if you can't drop it
<slytherin> didrocks: I have never really worked on MIR. :-(
<didrocks> slytherin: let me seek for the link
<slytherin> calc: do you have time for doing MIR for libbcprov-java? it is build dependency of libitext-java which currently is in DEPWAIT state.
<didrocks> slytherin: https://wiki.ubuntu.com/MainInclusionProcess
<didrocks> dholbach: this page is hard to find, can I add MIR in the title?
<dholbach> didrocks: maybe link it from UbuntuDevelopment/KnowledgeBase ?
<dholbach> and a redirect from  /MIR ?
<didrocks> dholbach: both done (not sure to know how to redirect automatically, btw for /MIR)
<didrocks> dholbach: we don't use moins moins in ubuntu-fr :)
<dholbach> #REDIRECT MainInclusionProcess
<didrocks> done
<dholbach> super
<savvas> wow, I just managed to crach reportbug :P
<savvas> reportbug -B debian -p libboost1.37-dev -V 1.37.0-5 -s "libboost1.37-dev: libboost1.37-doc should be in Suggests" -S wishlist --paranoid --exit-prompt
<savvas> ah, --exit-prompt
<savvas> wrong format, without -p and libboost1.37-dev at the end :P
<savvas> is there a shell application that reads ini configuration files?
<RainCT> savvas: cat $file | grep ^<sth> | cut -d'=' -f2
<geser> . configfile  (if it's in shell syntax)
<RainCT> geser: and let bad stuff happen ;)
<RainCT> geser: btw, what happens if there's a "[header]"?
<geser> hmm, looks like I overlooked the "ini" in savvas question
<savvas> thanks :)
<savvas> I was looking for a single command, but that works as well :P
<AdamDH> can any one explain why this happens http://paste.ubuntu.com/123826/? the file names are the same so I have the correct .orig in my package but it still says its not there, I showed an ls -l just to show it is def there
<RainCT> AdamDH: it's in the wrong directory
<RainCT> AdamDH: the .orig.tar.gz must be in the parent directory, not in the source dir; so,   mv *.tar.gz ../      ;)
<savvas> RainCT: is the email for revu fixed?
<AdamDH> thanks RainCT
<AdamDH> did not know that
<savvas> AdamDH: that's a huge packaging version number :)
<savvas> not that I'm saying it's wrong, but it's long hehe
<RainCT> savvas: no :/
<RainCT> but I don't know why.. it's mad :P
<AdamDH> savvas, I know but due to the way this project is working out at the moment I am using that packaging version number and will change it later
<savvas> RainCT: are you sure it's not faulty on the software side?
<RainCT> savvas: No, e-mails are delivered fine if I send them manually (the same way REVU does).
 * RainCT goes to debug a bit more
<savvas> ah ok
<savvas> :)
<savvas> AdamDH: are you using get-orig-source ? Can I take a look at your debian/rules if you don't mind? (learning)
 * RainCT hates mod_python, btw :P
 * POX suggests mod_wsgi
<RainCT> POX: I know, I know.. The guys in #python told me that a lot of times already ;)
<RainCT> I just don't hate it enough yet as to switch spooky and REVU to it :P
<savvas> you have other frameworks, http://webpy.org/ or web2py http://mdp.cti.depaul.edu/ :p
<RainCT> savvas: OK, it doesn't like sending mail to multiple people.
<RainCT> savvas: err, wrong. if I write two addresses of mine instead of mine and yours it works o_O
<savvas> so.. it doesn't like me? :p
<bddebian> Heya gang
<RainCT> savvas: did you get mail?
<ScottK> Heya bddebian.
<bddebian> Hi ScottK
<ScottK> bddebian: I ran across one of your old packages yesterday.
<ScottK> It looks like libticables3 (or something close to that, I'm sure you'll remember) needs some adjustment due to the kernel modules it needs now being i the standard kernel and not a sepatate package.
<ScottK> bddebian: Dunno if you still have any interest in the package, but I thought I'd mention it.
 * RainCT restarts savvas 
<bddebian> Eeks I'll see if I can check it out, thanks
<ScottK> Great.
<savvas> santiago-ve: hold a sec, checking :)
<savvas> oops, sorry santiago-ve - I meant RainCT
<savvas> RainCT: nope, only a debian bug confirmation I reported earlier
<santiago-ve> savvas: no prob
<savvas> RainCT: by the way, is the code for revu posted somewhere?
<dholbach> savvas: lp:revu
<savvas> nice, thanks :)
<RainCT> (see the README for installation instructions)
<savvas> RainCT: got Last test. too :)
<savvas> To all the revu reviewers: Send your emails again (just kidding!) :)
<sistpoty|work> RainCT: just saw part of the revu diff, which was s.th. like self.mailserver.sendmail()... does this use the system mta as backend?
<RainCT> sistpoty|work: it uses smptlib, not sure how that works
<sistpoty|work> RainCT: hm... not too sure either... I hope it uses the system mta, because iirc we've got a route via uni MTA setup from this
<sistpoty|work> RainCT: I could check the exim log though :)
<RainCT> sistpoty|work: William Grant mentioned they go through some other server
<sistpoty|work> RainCT: ah... /me wonders why it's working in the first place then *g*
<sistpoty|work> RainCT: hm...  "<= noreply@revu.ubuntuwire.com H=localhost": looks like smtplib does use the local exim :)
 * DktrKranz is wondering how to track python2.6 rebuilds/changes for universe
<AdamDH> seems as if my package built correctly https://launchpad.net/~adamhorden/+archive/ppa, thanks for the help guys
<savvas> DktrKranz: you mean something like: rmadison python2.6 ?
<AdamDH> ok maybee not
<savvas> DktrKranz: or: aptitude changelog python2.6 ?
<AdamDH> what dependancy is required for make: dh_testdir: Command not found?
<dholbach> debhelper
<dholbach> build-depends
<DktrKranz> savvas: I mean something to easily discover which packages need love to manage python transition in time for the release.
<DktrKranz> we have python in build-depends, depends, and nowhere.
<savvas> ah, no idea sorry :)
<james_w> DktrKranz: what do you need to know?
<james_w> Arch: any packages that build-depend on python?
<james_w> they are the ones that will need a rebuild to pick up the new python version
<james_w> what else is there?
<DktrKranz> james_w: a list of arch:any packages potentially affected would be nice
<james_w> DktrKranz: a bit of grep-dctrl magic should be able to do that
<james_w> I'll have a go in a bit
<RainCT> james_w: are we dropping python2.5?
<james_w> nope
<RainCT> james_w: why/what packages are being updated then?
<james_w> http://irclogs.ubuntu.com/2009/02/25/%23ubuntu-meeting.html
<james_w> see around 16:20
<RainCT> thanks
<james_w> RainCT: arch: any packages are python-extensions
<DktrKranz> RainCT: also see today's email
<james_w> i.e. compiled C code against the headers of each python version
<james_w> when you add a new python version you have to rebuild all of these packages so that they pick up the new version and build for it
<james_w> otherwise you couldn't use the extensions under python2.6
<RainCT> DktrKranz: I saw the mail, but couldn't get anything out of it :P
<RainCT> ah, of course
<RainCT> arr why did the remove string exceptions? they are great for debugging :P
<RainCT> can someone refresh my memory about whether UI Freeze affects universe?
<DktrKranz> RainCT: we haven't tranlations in rosetta for universe packages, so UIfreeze is not affecting universe directly, I think only CD-flavours packages (such as xubuntu) have some issues.
<RainCT> DktrKranz: OK, thanks.
<jdong_> mmmph.
<jdong_> this pyrex stuff aint as intuitive as I would have hoped
<jdong_> I take that back. This HOWTO aint as good as it seemed
 * Laney loves a good pyrex dish
<Laney> jdong_: Fancy poking a couple of ancient SRUs that I've had lying around for ages?
<jdong_> Laney: I am on a crippled net connection currently, perhaps in a couple hours
<Laney> ok
<jdong_> feel free to link em and I will look at my scrollback
<Laney> bug 280129 bug 243163
<ubottu> Launchpad bug 280129 in ghc6 "Please SRU ghc6 in Hardy to fix correctness bug" [Undecided,Triaged] https://launchpad.net/bugs/280129
<ubottu> Launchpad bug 243163 in glom "Please update glom to 1.6.17" [Undecided,Fix released] https://launchpad.net/bugs/243163
<ploum_> Hello
<ploum_> I have a python application
<ploum_> and I want to make a .deb on a ppa out of it
<savvas> ploum_: does it use the standard setup.py script ?
<ploum__> Hello
<ploum__>  I have a python application
<ploum__>  and I want to make a .deb on a ppa out of it
<ploum__>  the application is on launchpad
<ploum__>  is there an howto or a specific chan where I can get help for that ?
<savvas> 18:41:55 < savvas> ploum_: does it use the standard setup.py script ?
<savvas> ( For future reference: It would be better if you pasted all that in one line though :) )
<savvas> ploum__ can you reply?
<savvas> is belgium adsl that bad? :P
<mrooney> How might I download a Jaunty deb (from universe) in Intrepid?
<Laney> mrooney: You can get them from LP or packages.ubuntu.com
 * sistpoty|work heads home... cya
<Laney> or add Jaunty to your sources.list and aptitude download foo/jaunty
<mrooney> Laney: so I am here http://packages.ubuntu.com/jaunty/wxbanker, but I don't see where I can get the deb
<Laney> mrooney: Click on "all"
<mrooney> Laney: doh, thanks :)
<AnAnt> Hello, is it possible to change a source package name ?
<ScottK> It is.
<ScottK> Why do you need to?
<fatal_> AFAIK there's nothing you guys can do about this, but maybe someone could poke the right person? https://bugs.launchpad.net/ubuntu/+source/iproute/+bug/335554
<ubottu> Ubuntu bug 335554 in iproute "iproute in Jaunty is out of date" [Undecided,New]
<fatal_> (reported by upstream himself)
<fatal_> <--- debian co-maintainer
<ahasenack> I have a package foo-1.0 with a file in /etc/cron.hourly/foo
<ahasenack> I changed it to have the file in /etc/cron.d/foo
<AnAnt> ScottK: the package was ubuntume-gdm-themes, but the distro got renamed to sabily, due to trademark issue, so I will have to rename the package to sabily-gdm-themes
<ahasenack> dpkg --contents ./foo-1.0.deb shows the change
<ahasenack> but when I upgrade it with dpkg -i, the cron.hourly file is not removed
<ahasenack> and, omg, dpkg -L doo | grep cron now shows *both* files
<ScottK> AnAnt: We can do that.  Just put it on REVU with the new name and ping me.
<ahasenack> why would the installed package suddenly list a file that is not in the package?
<AnAnt> ScottK: ok, what should I do in old changelog entries ?
<james_w> ahasenack: file in /etc are usually "conffiles" and they are handled specially
<fabrice_sp__> bddebian, ScottK: i made a debdiff to fix the FTBFS in libticables2 (Bug #335271)
<ubottu> Launchpad bug 335271 in libticables2 "FTBFS since Hardy, because of a dependency on tidev-modules-source" [Undecided,Confirmed] https://launchpad.net/bugs/335271
<ScottK> AnAnt: Leave them there, just change the name in the top one.
<fatal_> ahasenack: files in /etc are considered configuration files... those are not removed until a package is purged.... you need to handle the upgrade case and migrate carefully.... remove the file if it's md5sum matches the one you shipped, otherwise don't install the new one in cron.d ...
<AnAnt> ScottK: ok, thanks
<fabrice_sp__> I noticed you spoke about that earlier
<james_w> ahasenack: the packaging system won't remove them by itself when you remove (or upgrade the package)
<ahasenack> james_w: so I need to explicitly remove it in some script?
<james_w> ahasenack: http://wiki.debian.org/DpkgConffileHandling will tell you about it
<james_w> ahasenack: yeah, that page gives you the snippet to use
<ahasenack> james_w: thanks
<james_w> fatal_: hey, is the package in Debian yet, or just in git?
<james_w> argh!
<ahasenack> james_w: I would have thought that to be part of the package manager's job software, but I'm not going to argue with several years of experience
<ahasenack> james_w: the part about avoiding mistakes made me chuckle, though
<james_w> ahasenack: many would agree with you
<ScottK> bddebian: Do you want to look at the libticables2 fix or should I?
<james_w> the fact that this is handled by copy-paste from a web-page is particularly unfortunate
<james_w> but most people learn about this from exactly the same experience as you
<fabrice_sp__> some packages are FTBFS because the file rgb.txt has been dropped from x11-common. Would it be ok to copy the rgb.txt file from x11-common of intrepid to add it to each package in Jaunty?
 * sebner winks geser =)
<bddebian> ScottK: Should we even be carrying libticables2 anymore?
<ScottK> bddebian: You tell me?
<ScottK> It was your package.
<fabrice_sp> bddebian, it's still used in one app
<ScottK> I think we should fix it or remove it.
<ScottK> And since fabrice_sp has it fixed, that seems sensible.
<bddebian> I thought I did the new upstream that should have used libticables3.. Hmm
<fabrice_sp> I checked, and that's strange: tilp uses libticables3 but litp2 uses libticables2
<fabrice_sp> and on the homepage of tilp, both version are there
<fabrice_sp> the fix is simple: only drop the dependency, and it build and install fine
<bddebian> Right, that was it
<bddebian> There was a soname issue or something.  libticables2 is actually newer than libticable3
<fabrice_sp> yes :-/
<fabrice_sp> and the same for libticalcs2 and family
<fabrice_sp> (litifiles, also)
<bddebian> ScottK: Would you mind uploading the fix, I'm still without an Ubuntu machine :(  It looks sensible.
<ScottK> Not at all.
<ScottK> Just thought I'd give you first crack.  I remember how much 'fun' you had getting that in the archive in the first place.
<bddebian> Heh, aye
<ScottK> fabrice_sp: I'm looking at it now.
<bddebian> And I see Debian still doesn't have it.. Sheesh
<phil_ps> hello, I am trying to find the page on the wiki that shows how to setup my name for package uploads
<fabrice_sp> ScottK, thanks!
<phil_ps> I hosed my virtualbox installation and lost some files (including my private pgp key that I used to sign a patch I made)
<phil_ps> okay, I found it!
<RainCT> OT, Can somebody tell me what the CLI tool to spam myself with notifications is called? :P
<ScottK> fabrice_sp: Uploaded.  Thank you for your contribution to Ubuntu.  BTW, I did edit debian/changelog slightly to a more preferred style.  Please have a look.
<ScottK> bddebian: It's uploaded.  Thanks for looking at it.
<fabrice_sp> ScottK, ok. I'll check. Thanks!
<bddebian> ScottK: No, thank YOU and fabrice_sp :)
<fabrice_sp> bddebian, you're welcome :-)
<james_w> RainCT: notify-send?
<RainCT> james_w: thanks
<jdong_> heh. so pyrex is not magic sauce for making things magically faster.
<fabrice_sp> so no opinion on rgb.txt?
<RainCT> btw, anyone here running Jaunty on his normal PC?
 * RainCT is pondering updating his system..
<jdong_> ah. array type.
<fabrice_sp> ScottK, I'll update 2 more patch I have to fix FTBFS to avoid the line with the LP code. Thanks!
<ScottK> Great.
<fabrice_sp> jdong, it has been dropped from x11-common, and I saw 2 or 3 packages that FTBFS because of that, so I was wondering if putting rgb.txt in each package to fix the FTBFS
<onnadi3> Hi all. I hope this is the right channel. I'd like to know why xampp is not an official package even though (AFAIK) it is included in the ubuntu server install.
<ScottK> That's not actually possible.
<directhex> xampp is just a bundle of stuff already available in ubuntu
<onnadi3> directhex: But I thought the value of xampp was in the lampp tool wherein 1 command starts and stops everything. Ain't that worth packaging?
<directhex> onnadi3, is that valuable?
<onnadi3> I think so. THen I could do "apt-get install xampp" from the cmdline :)
<directhex> so... an init script in a metapackage?
<phil_ps> on this page: https://wiki.ubuntu.com/Bugs/HowToFix I don't see how to make a .deb file
<onnadi3> directhex: I'm an ubuntu packaing noob, but that sounds like it
<phil_ps> but under testing the fixes, it says sudo dpkg -i *.deb
<directhex> "Once you have a patch, reenter the source directory, and build the package. "
<directhex> "debuild -us -uc"
<jdong_> does installing the LAMP stack packages in ubuntu not already start everything automatically?
<jdong_> the missing feature would be stopping/restarting the whole stack.
<onnadi3> jdong_: yeah.
<jdong_> for which I question the usecase unless it is like a personal development setup you only want to run a small subset of the time
<jdong_> sounds to me like a 20 second bash script job :)
<onnadi3> jdong_: I fear you are right. I guess xampp is of more value to Win/OSX where installation isn't that easy
<jdong_> onnadi3: that is my opinion too
<jdong_> on those platforms when not using a package manager pulling in the LAMP stack manually is quite a tedious task.
<jdong_> on Linux IMO you can even name the entire LAMP stack in an apt-get install line without breaking a sweat :)
<onnadi3> that's why I'm an Ubuntu :0
<onnadi3> jdong_, directhex: Thanks for bouncing ideas with me
<jdong_> sure thing
<ScottK> onnadi3: sudo tasksel install lamp-server is all you need.
<onnadi3> ScottK: I'm unfamiliar with tasksel and the manpage isn't very helpful. What does the above command do?
<directhex> tasksel is a simple debian app to install "tasks"
<ScottK> It will install all the packages that are defined in the lamp-server task.
<ScottK> So that's the equivalent of picking the LAMP option at install time.
<onnadi3> ScottK: ah. So the Ubuntu installer is just a bunch of tasks and tasksel lets you pick individual bits, huh?
<ScottK> It's not just a bunch of tasks, but it has a bunch of tasks.
<onnadi3> OK
<directhex> NCommander, ping?
<NCommander> directhex, pong
<RainCT> | Â·   |
<NCommander> |           . |
<directhex> NCommander, i think i found what i was looking for... want an ARM qemu image...
<NCommander> ah
<directhex> ports.ubuntu.com seems to be trying for "slowest server not featured on slashdot"
<NCommander> Its on slashdot?
<NCommander> ports.u.c. always sucks w.r.t to speed
<directhex> and it seems ogra is the person to poke. i should stop thinking "port == NCommander" really
 * NCommander can help with the ARM port no issue
<directhex> NCommander, i'm attempting to help the novell people get some non-conventional arches going in qemu, for moonlight. except since there's no arm suse, i'm sanity-checking the RootfsFromScratch guide for them. which makes me giggle a bit
<NCommander> Its probably better to run through the installation in d-i
<directhex> where's a d-i image?
<NCommander> directhex, http://ports.ubuntu.com/dists/jaunty/main/installer-armel/current/images/versatile/netboot/
<NCommander> give them to QEMU with the -kernel and -initrd options
<NCommander> (you need to -append "console=tty1 root=/dev/ram")
<directhex> ports.u.c is in a huff with me :(
<ScottK> You should talk nicer about it.
<ScottK> NCommander: https://launchpad.net/ubuntu/+source/plasma-widget-toggle-compositing/0.2.3-0ubuntu2/+build/865664/+files/buildlog_ubuntu-jaunty-armel.plasma-widget-toggle-compositing_0.2.3-0ubuntu2_FAILEDTOBUILD.txt.gz looks like one of your classic armel porting issues if you care to have a look?
<NCommander> Oooh
<NCommander> a universe package
<NCommander> I can get an upload
 * NCommander hasn't uploaded anything in ages
<ScottK> yep.
<directhex> am i the only one who can't talk to ports.u.c? :(
<jdong_> doesnt speak with me either on HTTP
<directhex> it hates me. waa :'(
<jdong_> speaks on other ports though so it is not dead
<directhex> #canonical?
<jdong_> canonical-sysadmin
<NCommander> hrm
<NCommander> damn it
<NCommander> ports.u.c. is down
<directhex> not just me then
<directhex> bears, i suspect
<jdong_> black bear
<AnAnt> ScottK: regarding my previous question about source package renaming, should I add Replaces: <old package name> in debian/control ?
<AnAnt> ScottK: I mean for the target (binary) package
<ScottK> Yes.
<ScottK> It's a little more complex than that though.
<AnAnt> how so ?
<directhex> NCommander, <elmo> it's got hardware issues atm
<AnAnt> ScottK: what do you mean by more complex ?
<ScottK> AnAnt: You need to provide the old package name as a transitional package for upgrades.
<ScottK> AnAnt: https://launchpad.net/ubuntu/jaunty/+source/plasma-widget-toggle-compositing/0.2.3-0ubuntu2/+files/plasma-widget-toggle-compositing_0.2.3-0ubuntu2.diff.gz is a good example.
<NCommander> Oh
<NCommander> Ugh
<NCommander> -_-;
<AnAnt> ScottK: Provides: <old package name> ?
<AnAnt> oh
<ScottK> Look at the example.
<ScottK> The old package needs to exist and depend on the new one so the new one will get installed.
<AnAnt> I see
<ScottK> Note: You don't always need the conflicts.  That's only if they actually conflict.
<directhex> NCommander, <elmo> directhex: hey, it's 9pm and I'm in the office ,working on it :-P
<AnAnt> yes, I'm not using conflicts indeed
<fabrice_sp> Hi again. ia32-libs-tools FTBFS according to qa.ubuntuwire.com/ftbfs, but it's building successfully in an amd64 schroot here. So what can I do?
<AnAnt> ScottK: thanks a lot
<ScottK> AnAnt: You're welcome.
<directhex> fabrice_sp, try pbuilder
 * NCommander will buy Elmo a beer next time I see him
<fabrice_sp> directhex, will try, but I'm already using sbuild to build it
<fabrice_sp> so should be the same
<directhex> fabrice_sp, what does the build log show?
<RainCT> persia: btw, you are right about showing the license at the bottom if it's repeated multiple times in debian/copyright with the new format
<fabrice_sp> directhex, http://pastebin.com/d2012d41f
<fabrice_sp> it's building fine also in pbuilder
<directhex> fabrice_sp, no binary-arch rule?
<fabrice_sp> in this case, it would fail also in sbuild and pbuilder, right?
<fabrice_sp> binary-arch:
<fabrice_sp> # We have nothing to do.
<fabrice_sp> it's there, in debian/rules
<fabrice_sp> (with nothing to do)
<fabrice_sp> the build is 2 month old. Is it possible to force a rebuild of ia32-libs-tools?
<fabrice_sp> anyway, as it has never been built, when successfully build, it will go to the NEW queue. so is it compatible with FF?
<fabrice_sp> or it needs a FFE?
<c_korn> why is this bug still undecided although someone ACKed it? https://bugs.launchpad.net/ubuntu/+source/scilab/+bug/334362
<ubottu> Ubuntu bug 334362 in scilab "FeatureFreezeException: Please update sivp 0.5.0 from REVU" [Undecided,New]
<ploum> Hello
<RainCT> hi ploum
<ploum> Hi RainCT
<ploum> I was there to ask a question a few hours ago but my wireless router decided to die at that moment
<phil_ps> what is the launch pad pgp keyserver?
<tdomhan> anyone got some time to review a package(http://revu.ubuntuwire.com/p/gpicsync)? :D
<ploum> sorry to the one who was answering me
<ploum> so here's my question
<ploum> I've a full python application in a bzr repository on launchpad and I want to make a deb on a ppa out of it
<ploum> and I've no experience with building python deb files or ppa
<ploum> can anyone help me ?
<ploum> or give me some pointers ?
<ploum> argh
<ploum> there was someone replying me a few hours ago
<ploum> damn wireless router
<ScottK> We do Ubuntu here.  Launchpad does PPAs.  If you were interested in getting your package into Ubuntu more people might be interested in helping.  There is also #launchpad for PPA questions.
<ploum> ScottK : thanks
<ploum> I'm also interested in getting my package in Ubuntu, of course
<ploum> but ppa is the first step I guess
<onnadi3> ploum: this what you're looking for? https://wiki.ubuntu.com/PackagingGuide/Complete
<RainCT> Will the menu be happy if I put a 64x64 PNG into /usr/share/pixmaps instead of a 48x48 one?
<RainCT> (as in, would that be acceptable?)
<ploum> onnadi3: thanks, will take a look at that
<ploum> onnadi3: hmm, it's what I was fearing. It explains all about making packages for C programs. But for python, it should be different I guess
<RainCT> ploum: the debian/rules file will be a bit different, but most of the documentation applies for any sort of package
<onnadi3> FYI, I'm a packaging noob, but it seems like the instructions aren't C-specific; they just seem to need make is all. What part wouldn't work for Pythong?
<RainCT> onnadi3: see http://wiki.debian.org/DebianPython/NewPolicy for what's required for Python
<RainCT> basically you have to get the files to install into the correct place (with distutils, make, dh_install or whatever) and then call either dh_pysupport or dh_pycentral (and add some stuff to debian/control) to get byte-compilation support
<onnadi3> RainCT: I see. Could you please explain why C/Python get special instructions and other languages like Ruby/Haskell don't?
<RainCT> onnadi3: Ruby has no byte-compilation (afaik) or any other special need, so for Ruby applications it's enough to just throw them into a directory
<onnadi3> thanks
<RainCT> You're welcome. Ask if you have any other question :)
<ploum> thanks RainCT
<ianto> Hello; I'm having  some issues regarding my rules fiile in the package that I'm building, here is the current version of it: http://revu.ubuntuwire.com/p/star-merchant
<ianto> any help would be much appreciated ^ :D
<RainCT> ianto: what's the problem?
<ianto> RainCT: /bin/sh: mkdir -p /tmp/buildd/star-merchant-1.1/debian/star-merchant/usr/bin: not found
<ianto> I believe my rules is messed up
<RainCT> (btw, you can remove all the commented out stuff, especially lines 3-7, #docbook-to.. and the commented out dh_ calls)
<RainCT> incorrect: remove the quotes around that line
<RainCT> err, sorry, ianto
<incorrect> i haven't said anything
<rgreening> ScottK: ping
<RainCT> incorrect: sorry, that was for ianto (nice name, btw :P)
<incorrect> openldap 2.4.15 was nice and easy to package and compile on hardy
<ianto> RainCT: Thanks for the tip I'm gonna pbuilder build it now :)
<rgreening> ScottK: I'm doing up my application for motu, and was hoping to apply during (possibly) the next meeting.
<rgreening> JontheEchidna: ^
<rgreening> NCommander: hey
<JontheEchidna> Oh, I need to put my feedback on your application soon
<NCommander> hey rgreening
<rgreening> JontheEchidna: yeah, my app is being written (hopefuly finish tonight).
<rgreening> JontheEchidna: Here's where it will be : https://wiki.ubuntu.com/rgreening/DeveloperApplicationMOTU
<rgreening> not finished yet.
<rgreening> NCommander: when I get my app done, wouldn't mind your comments too.
<NCommander> sure
<rgreening> ty NCommander :)
<ianto> RainCT: Removing the quotes results in the following error: http://paste.ubuntu.com/124032/
<rgreening> building kde takes so long... :)
<RainCT> ianto: where does that "cp" come from?
<RainCT> ah
<ianto> RainCT: hyperair recommended it to me because it relied on the directory to bbuild
<RainCT> cp $(OUTFILE) /usr/bin/$(OUTFILE)
<RainCT> not sure.. try removign the $(OUTFILE) from the end
 * ianto is kinda confused as to where to place that RainCT 
<directhex> aw, i ran out of teh rams
<AdamDH> hi all, hit some snags with my package, took a look at some other packages and they have no .orig.tar.gz in the package? the source is all ready extracted, why is this?
<AdamDH> grr cannot get my package to build on launchpad works fine when built locally
* sistpoty changed the topic of #ubuntu-motu to: Jaunty Feature Freeze in effect - Go fix bugs! | https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Fix RC bugs: http://qa.ubuntuwire.org/bugs/rcbugs | Help to clear NBS list: http://people.ubuntu.com/~ubuntu-archive/NBS/
<RainCT> (Any DD around who is free to sponsor a package update?)
<RainCT> ianto: Sorry, I was away. In the Makefile there's that line - try changing it to "cp $(OUTFILE) /usr/bin/"
<jelmer> RainCT, For which package?
<RainCT> jelmer: screenruler
<jelmer> RainCT, sorry, not familiar with ruby :-/
<sistpoty> jelmer: I'd have another one then: min12xxw (plain c) :P
<directhex> it's a jelmer!
<RainCT> jelmer: I also have another (new) C package for which I need a sponsor :P
<sistpoty> damn RainCT *g*
<jelmer> directhex: dude!
<RainCT> :)
<directhex> my favourite @samba.org!
<jelmer> sistpoty: That one should be doable :-)
<jelmer> sistpoty, please upload to mentors.debian.net and email/privmsg me the link
<sistpoty> jelmer: sure, (I'll just need to find it myself... it's somewhere in collab-maint/ext-main) *g*
<sistpoty> +t
<ianto> RainCT: Same error without that in the makefile
<ianto> cp starmerch /tmp/buildd/star-merchant-1.1/debian/star-merchant/usr/bin
<ianto> cp: cannot create regular file `/tmp/buildd/star-merchant-1.1/debian/star-merchant/usr/bin': No such file or directory
<RainCT> ianto: uhm.. I don't know then :)
<RainCT> jelmer: and mine? *g*
<Laney> directhex: do you have a list of the 1.0 libs (i.e. most important to be transitioned) handy?
<directhex> Laney, the install cd libs are all done, so afaik there's no priority list
<ianto> RainCT: Meh jpds said that it'd be easy and volunteered me for it :p -- I've been stuck for a a fortnight :(
<Laney> well the ones which are going to ftbfs
<directhex> Laney, pick whatever's red on http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO
<Laney> should be done first right
<jelmer> RainCT: sorry, I don't have enough time for a new package right now
<directhex> Laney, remember that the pkg-cli-libs ones can be uploaded to debian straight away, sans ubuntu1
<RainCT> well, I guess I'll get a chance to try how effective mentoris.debian.net is then :P
<Laney> directhex: for sure, I'm just trying to prioritise
<jelmer> RainCT, just out of curiosity, what's the package?
<RainCT> jelmer: vilistextum (a HTML to text converter)
<Laney> directhex: Also lamalex in #gnome-do is moaning about md in Jaunty
<directhex> Laney, what about it? o_o
<Laney> 27/02 22:52:29 <lamalex> it is buggier than from source
<Laney> 27/02 22:52:42 <lamalex> I think it's packaging fails, not a problem with upstream
<directhex> we barely patch it
<directhex> real actual bugs, file against debian
<Laney> dunno what his problem is
<Laney> I told him to come see you or file bugs
<AdamDH> whats the best way to build a source package?
<AdamDH> debuild -S
<AdamDH> ?
<Laney> yep
<AdamDH> in the root with the debian folder etc?
<RainCT> AdamDH: Yes. If it's a new package or a new version, you'll also need  -sa
<RainCT> (to include the .orig.tar.gz in the .dsc)
<AdamDH> thanks RainCT, the problem I have is the way I have versioned my package its causing me some headaches, as I am unsure about the upstream source tarball
<AdamDH> the .orig.tar.gz is the actual upstream source and this is kept outside the root of the package?
<RainCT> uhm.. I should have a look at fsniper, perhaps we can use it to have REVU immediatelly process uploads
<RainCT> well, good night :)
<Laney> night
<directhex> is it? :o
<RainCT> directhex: it's always night :)
<RainCT> .. and always day ^^
#ubuntu-motu 2009-02-28
<AdamDH> grr I cannot build a source package but I can build a working debian package?
<AdamDH> the orig source is in the correct format but I get: dpkg-source: unrepresentable changes to source when running debbuild -S -sa
<directhex> AdamDH, which either means your clean rule doesn't work, or you have binary bits & pieces in your diff
<AdamDH> directhex, in my package folder I have a tar.gz file of the upstream source, would this be the issue?
<AdamDH> I am also getting allot of dpkg-source: warning: ignoring deletion of file
<AdamDH> I could remove that upstream source and create a symlink to the source in /usr/src that might be a better option?
 * sistpoty goes to bed... gn8
<jdong_> directhex: I think as a mono person you might find this interesting: http://scripts.mit.edu/~jdong/wiki/moin.cgi/LangShootout
<jdong_> a bit of a high-level-language shootout that stemmed from a project I was working on the last few days
<jdong_> not that any of the results are surprising IMO
<ajmitch> jdong_: I'm sure it's completely biased ;)
<ajmitch> interesting to see how much slower ironpython is
<jdong_> ajmitch: yeah I was kinda shocked by that
<AdamDH> when building a jaunty package using pbuilder why would it say binutils-source is a virtual package? I have a dev machine and I can do an apt-get install binutils-source fine, pbuilder is having a little trouble, have I missed something?
<ajmitch> do you have universe enabled in pbuilder, in case it can't find that package?
<AdamDH> I think universe was enabeled, how can I check?
<ScottK> pbuilder login and the look in /etc/apt/sources.list
<ajmitch> quickest way is to use pbuilder login, try & install binutils-source in the chroot
<ajmitch> or that
<jdong_> ajmitch: heh irony. it is biased.
<ajmitch> jdong_: in what way?
<jdong_> ajmitch: list.append() in python is a LOT more expensive than I would've thought.
<AdamDH> I am just updating the chroot again just in case something went wrong, will check when that has finished getting a release
<jdong_> ajmitch: repalcing list.append() with indexing a preallocated list brings it down from 80s to 25s
<ajmitch> does it affect ironpython at all?
<jdong_> ajmitch: still IMO (1) slower than the alternatives (2) a ridiculous difference for what seems to be a trivial change.
<jdong_> oh crap
<jdong_> wait
<jdong_> I still leeft psyco in there
<jdong_> *smacks himself*
<jdong_> OK, retesting python and ironpython :)
<ajmitch> skillz
<jdong_> I wouldn't expect 4 * (list.append(foo) to be THAT much slower than list=[0,0,0,0], x[0]= ...
<ajmitch> depends on how many times you're running it
<ajmitch> maybe a chance to play with the python profiler
<jdong_> 81.9s
<jdong_> uhh.
<ajmitch> slower than before?
<jdong_> y.. yeah
<ajmitch> awesome
 * jdong_ attempts to reproduce.
 * ajmitch sees that the RC bugs list thing has grown recently
<jdong_> ajmitch: 77.8, 81.9 vs 77.5, 78.1 ("optimized" vs original)
<jdong_> no significant difference.
<jdong_> now to revisit ipy
<ajmitch> still unbearably slow
<jdong_> indeed
<AdamDH> thanks for the help guys, did not know pbuilder login exsisted, really help full to chroot into the chroot to find out what is happening
<ajmitch> AdamDH: even more useful, you can pass the --save-after-login option to pbuilder if you need to make changes in the base tarball for future builds
<jdong_> ajmitch: brought ironpython from 400+s to 361s.
<jdong_> still ridiculous though.
<jdong_> the magical "-O" optimize flag shaves a whopping... FOUR SECONDS off :)
 * sistpoty prefers ebony-python, makes +4 *g*
<jdong_> ajmitch: oddly, Jython was penalized by the change; 97 -> 112
<AdamDH> thanks ajmitch, that's going to come in handy
<AdamDH> why would I get dpkg-source: warning: ignoring deletion of file? then is no clean rule that affects the files in question?
<AdamDH> its doing it for all the source in my orig.tar.gz file
<AdamDH> if I am running a shell script inside my chroot from my rules files, does it preserve permissions set inside the package folder? eg chmod +x apply_patch? as I get make: execvp: /tmp/buildd/msp430-binutils-2.19-msp430-cvs.0.0.20090228/scripts/apply_patch: Permission denied
<AdamDH> I am running pbuilder as root as well
<jdong_> is the script a part of orig.tar.gz or created in the diff.gz?
<AdamDH> created in the diff.gz
<jdong_> remember that .diff's do NOT represent permissions.
<jdong_> they only represent file content or lack thereof.
<jdong_> in your case you'd want to use your rules file to chmod +x the script before executing it.
<AdamDH> thanks, I will add that to my rules
<AdamDH> I can just do chmod +x inside rules?
<AdamDH> ah yes I can just do that!
<dmz> hey y'all, what is the ubuntu network installation / configuration app thats used during install process? I have a single function kiosk (it boots into 1 function @ a time) and would like to offer the ability to manage the nework. I have X but only xserver & twm, any suggestions?
<directhex> jdong_, interesting. i suspect Ipy 2.0 would do much better - but I don't think it's on the cards for Jaunty, sadly, due to needing Mono 2.2
<directhex> jdong_, i'm mostly impressed by ikvm being usably fast (perhaps the packaging nightmare was worth it ^_^)
<directhex> jdong_, feel like testing another metric, though? look at RAM consumption. java will likely use an order of magnitude more than mono
<goshawk> hi, if someone has free time, can please review http://revu.ubuntuwire.com/p/dsss ? thanks
<geser> goshawk: I just skimmed over the .diff.gz and on a first look it looks ok. Just a small question about the first patch: it replaces several occurances of "rebuild" with "drebuild" but why not for "rebuild.conf" (2nd change in this patch)?
<AdamDH> any one know a package that uses get-orig-source?
<StevenK> AdamDH: maximus, in jaunty
<AdamDH> thankyou StevenK
<goshawk> geser: you are right, it's an error
<AdamDH> does any one mind taking a look at this please? http://revu.ubuntuwire.com/p/msp430-binutils I have the package in my PPA as well, just want some feedback as its my first package
<AdamDH> thanks
<AdamDH> any ideas how I use my ppa in pbuilder? I did a sudo pbuilder login set the sources.list but its not preserved on exit
<RainCT> AdamDH:  --save-after-login
<AdamDH> thanks RainCT
<AdamDH> i am getting allot of dpkg-source: warning: ignoring deletion of file for all the files in my orig.tar.gz, what would cause this? I am buidling a source package with -S -sa
<RainCT> AdamDH: and do the files actually exist?
<AdamDH> inside the tar ball yes
<geser> does the .orig.tar.gz perhaps contain files which are removed after a make (dist)clean?
<AdamDH> I have not extracted the upstream tar ball just left it as .orig.tar.gz
<AdamDH> geser not sure
<AdamDH> the package is up on revu
<RainCT> AdamDH: that's the problem, the .orig.tar.gz is supposed to be extracted
<AdamDH> thanks RainCT I will extract it and try again
<RainCT> Iou can most likely ignore that error, though. If you didn't touch anything outside debian/, the debuild should have worked fine
<AdamDH> it builds the package fine
<AdamDH> I am really starting to enjoy packaging
<AdamDH> my first package took me a few days, the second one a few hours
<RainCT> :)
<AdamDH> I probally took the wrong type of package to start with, a cross compiler, but at least I have a working tool chain, even if there are some fudge factors in the rules ;)
<StevenK> AdamDH: Cross-compilers are hard enough to *build* let alone package
<AdamDH> well I could compile it from source with ease and done it on a few distros, just wanted to package it as there are no packages in debian or ubuntu yet for the msp430 tool chain
<lidaobing>  hello, I need a freeze exception for bug 335796
<ubottu> Launchpad bug 335796 in qterm "Please sync qterm 1:0.5.4-2 (universe) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/335796
<lidaobing> with out this sync, qterm will always crash under QT 4.5
<AdamDH> I am all ready getting feedback and the packages have only been in my ppa for approx 12 hours
<savvas> ScottK: looks like the bmpx powerpc builds fine on debian unstable: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517373
<ubottu> Debian bug 517373 in bmpx "FTBFS(powerpc): configure: error: libsidplay 1.x not found!" [Normal,Open]
<sladen> what's Pete Savage's IRC nick these days?  (or is he just not online as cbx33)
<AdamDH> launchpad is really slow just dputed a package and had no email or anything appear in my ppa for like 30 mins
<AdamDH> so my orig.tar.gz should be extracted into my package dir with the debian folder etc? so all the source is in that folder with a orig.tar.gz outside so a diff can take place?
<AdamDH> wow there are some messy packages out there
<goshawk> AdamDH: hi, if you have free time, please have a look to my package at revu http://revu.ubuntuwire.com/details.py?upid=5296 :) thanks.
<AdamDH> goshawk, I am a new packager, not a MOTU, I can offer some tips from what I have learnt from packaging over the last few weeks, but that's about it, sorry
<goshawk> AdamDH: any tip is appreciated :)
<goshawk> well... don't do it now, i'm fixing one more thing :)
<AdamDH> i submitted my packages to revu today but I just found about 4 bugs!
<savvas> goshawk: use http://revu.ubuntuwire.org from now on :)
<goshawk> savvas: ah yes, sorry, it's the link pointed me out from [revu] New upload for package dsss mail, i think it should be updated to .org too
<savvas> goshawk: do you know which parts are under artistic license?
<goshawk> savvas: no, i should read the whole code to find it :(
<goshawk> but if it's necessary i'll do
<savvas> (I'm not a MOTU either btw) :)
<goshawk> :)
<savvas> let me check
<savvas> Actually, I think the author should've stated clearly about each bit of code under which license is used
<AdamDH> for some reason I cannot view your license file from revu but this might help http://wiki.debian.org/Proposals/CopyrightFormat if your not all ready using that system
<savvas> AdamDH: I have the same problem, some encoding error, right?
<goshawk> AdamDH: thanks i'm reading
<goshawk> AdamDH: but be careful: it's a proposal, i don't read that the policy is changed as described in that wiki
<AdamDH> that format allows you to say what files belong to what packages looks like its ideal for your package
<AdamDH> i have seen a few packages using it, and I asked in here and no one seemed to have a problem using it
<goshawk> ah perfect
<AdamDH> but then I am waiting for some one to look at my packages in revu ;)
<goshawk> so i'll switch to this one
<goshawk> did you adopt this format too?
<goshawk> inyour packages i mean
<AdamDH> if you look at msp430-binutils in revu you will see that I adpoted that format
<AdamDH> example: http://paste.ubuntu.com/124262/
<savvas> goshawk: rebuild/readme.txt has the license covered, it says it's either GPL (version 1) or Artistic License. Most of the files in rebuild have a header saying to read that readme.txt, except for "rebuild/whereami.c" (MIT/X11 (BSD like) as you mentioned) - And unless I'm wrong, Unknown/No copyrights for files: rebuild/nprocs.c rebuild/gnuc.c test/test.sh
<goshawk> it's for rebuild
<goshawk> uhm...
<savvas> goshawk: yes, it's for most files in rebuild :)
<savvas> here's a dirty way to look at file headers/comments: head rebuild/*.c
<goshawk> ah... head i didn't know this program
<savvas> head for first lines, tail for last lines :)
<goshawk> and that rebuild.txt don't really belong to rebuild
<goshawk> but to dmd
<goshawk> This is the source code to the front end Digital Mars D compiler.
<goshawk> well... you should know that rebuild is a code upon the DMD frontend (which is bot gpl 1 or artistic)
<goshawk> so that readme says that the DMD part in rebuild are gpl or artistic
<goshawk> not rebuild itself
<goshawk> i'm contacting upstream to have a better explanation of this licence issue
<savvas> is the project under GPL-2 by the way?
<AdamDH> the next problem I have on a simular issue is I have a binary blob to package with pre compiler modules, and that has no license at all as its closed source and propartery
<AdamDH> *compiled
<savvas> "DSSS, the D Shared Software System, builds upon rebuild and intends to create a standardized system for building, installing, configuring, acquiring and using D software, licensed as Free and Open Source Software under the MIT license: http://www.opensource.org/licenses/mit-license.php "
<savvas> http://www.dsource.org/projects/dsss
<goshawk> yes i was looking for the same page
<goshawk> mit with some parts under gpl v1 or artistic then... isn't it?
<goshawk> i think the best solution is then to say that it's MIT licensed and some parts under rebuild are gpl v1
<goshawk> isn't it?
<savvas> I think so, give me a sec I'll show you an example
<goshawk> you can take also two of them :) thx for what you are doing :)
<james_w> Laney: yo, around?
<savvas> goshawk: something like this: http://paste.ubuntu.com/124272/plain/
<savvas> It's not like the proposal at debian which AdamDH pointed out, but it's humanly readable :)
<goshawk> :)
<goshawk> it's perfect
<goshawk> :)
<goshawk> thx
<savvas> goshawk: Now if you want to be 100% sure about the MIT license, it should've been in the root folder, not in the docs/ - you could ask the authors to put the the LICENSE file in the root folder :)
<goshawk> already mailed :)
<savvas> great!
<c_korn> does anyone know why python-clutter is not in intrepid?
<AdamDH> i am still waiting for launchpad to build my deb so I can go back to work on the 3rd package in the tool chain
<goshawk> AdamDH, savvas, thanks too much for the help you gave me :)
<AdamDH> no worries, I am happy to put back into the open source community
<savvas> RainCT: revu encoding problem - Using firefox, clicking on "dsss_0.78-0ubuntu1.diff.gz" at http://revu.ubuntuwire.org/p/dsss - there's an encoding problem with the diff file inside that archive
<savvas> goshawk: anytime :)
 * RainCT shots at Firefox
<RainCT> If someone figures out what the problem is, patches are welcome. I only support wget myself :P
<savvas> I use dget :p
<savvas> which works heh
<AdamDH> with revu how do I upload a revisied package?
<RainCT> dget actually uses wget (or curl) :P
<AdamDH> *revised
<RainCT> AdamDH: just like the first upload (and without changing the version number, REVU doesn't need that) :)
<AdamDH> great I had to change that for launchpad
<savvas> RainCT: it seems to be encoded twice in gzip
<RainCT> savvas: Yes, but I don't know why.
<savvas> http://paste.ubuntu.com/124282/
<AdamDH> who wrote rvu ;)
<AdamDH> *revu
<RainCT> AdamDH: that's Apache madness :P
<dantalizing> if there are options for depends, is the preference given in order of listing?  In other words if a package depends on "procps | hurd", and neither are installed, will procps be installed?  Is that a rule?
<RainCT> dantalizing: I think so
<james_w> yeah
<dantalizing> thx
<AdamDH> i think revu ate my package
<AdamDH> as nothing has shown up after I ran dput revu msp430-gcc_3.2.3-msp430-cvs.0.0.20090228-0ubuntu1~ppa2_source.changes
<AdamDH> ignore that! its just a tad slow does any one mind having a look at this please http://revu.ubuntuwire.com/p/msp430-gcc? thanks
<james_w> directhex: are the rules the same for the library transition as for the apps?
<james_w> directhex: is there an ordering requirement?
<ScottK> james_w: I like your approach to update notification better than what I read Ubuntu has now.
<james_w> ScottK: that wasn't my approach
<james_w> ScottK: is was just fixing the bug with the existing approach.
<james_w> and it doesn't work with the new notifications
<ScottK> james_w: I understand, but I think fixing the existing approach would have been better.  I read laserjock's problem about not being notified of updates and I find that pretty problematic.
<james_w> with the new notifications we can't fix the existing approach in that manner
<ScottK> I think that limitation with the new notifications is unfortunate.
<james_w> I think it is good
 * Nafallo is with james_w
<Nafallo> notifications wasn't notifications before.
<james_w> I see it not so much as a limitation, but as a feature
<ScottK> So it's good to hide updates from the user?
<james_w> ScottK: that's not what I said at all
<james_w> please don't put words in my mouth
<ScottK> If I understand it correctly the way it works now until the popup opens up there is no indication at all you have updates?
<ScottK> OK.  Sorry.
<james_w> correct
<ScottK> I find that conceptually flawed.
<james_w> I'm unsure about that change
<james_w> however the new notification are a vast improvement in my opinion
<james_w> that does require us to change the way we do some things, but I am willing to make those changes to get a better system
<ScottK> It'll be interesting to se how it works out.
<james_w> for me, I don't need an indicator that I have pending updates
<ScottK> How do you know?
<james_w> I *always* have pending updates
<ScottK> Heh.
<Nafallo> talking about updates...
 * Nafallo starts his jaunty running eeepc ;-)
<a|wen> Nafallo: with intel atom?
<Nafallo> a|wen: no. 701
<a|wen> then no point in asking if you were testing the lpia port...
<ScottK> Do we have any documentation about how to file Internal Compiler Error bugs?
<ScottK> NCommander: ^^^? Do you know
<james_w> a minimal test case is usually desired, but that's the hard part
<ScottK> Yeah.
<Nafallo> a|wen: nope
<ScottK> The one I'm looking at now is Qt4-x11 on powerpc.  It's a huge package and I don't have the hardware.
<RainCT> are simple-ccsm/compizconfig-settings-manager working in Jaunty?
<savvas> RainCT: as in running? yes
<RainCT> savvas: can you please tell me what shabang they have?
<savvas> The following packages have unmet dependencies: python-urwid python-compizconfig python-cheetah python-libtorrent python-libtorrent python-launchpad-integration python-pysqlite2
<savvas> python-compizconfig: Depends: python (< 2.6) but 2.6.1-0ubuntu1 is to be installed.
<RainCT> Yeah, I have an update ready for that
<savvas> what's a shabang? :P
<RainCT> but it will loose 2.5 support, and I don't know if that will break simple-ccsm and compizconfig-s-m
<RainCT> savvas: the first line in the file, starting with #!
<savvas> oh
<RainCT> cat /usr/bin/simple-ccsm | head -n1
<savvas> hold a sec
<savvas> $ cat /usr/bin/ccsm | head -n 1
<savvas> #!/usr/bin/python
<savvas> I'll try simple if you want to
<RainCT> savvas: What does this say?   ls -l /usr/bin/python
<savvas> $ ls -l /usr/bin/python
<savvas> lrwxrwxrwx 1 root root 9 2009-02-27 10:59 /usr/bin/python -> python2.5
<RainCT> OK, so you haven't python2.6 by default yet
<goshawk> RainCT: about #292923
 * RainCT looks at ubottu 
<savvas> RainCT: should I? :\
<goshawk> the https://wiki.ubuntu.com/SecurityUpdateProcedures says me to do tests using the QA regression testing
<goshawk> but... i don't have any thought in how to use it with a php library :)
<RainCT> savvas: Nvm, I don't want to be responsible for breaking your system :). Thanks!
<savvas> RainCT: http://paste.ubuntu.com/124306/plain/
<blueyed> If I want to update a package to build with Python 2.6 (which Build-Depends on python-dev), is it another to adjust the version to "..build1" (instead of e.g. "..ubuntu1") and upload?
<RainCT> savvas: I think there's some PPA with updates packages, check ubuntu-devel (or some other list)
<savvas> nah, I'll wait for aptitude safe-upgrade :P
<savvas> so the shabang makes a problem?
<RainCT> savvas: no, it's what I hoped for :)
<savvas> ah ok :)
<RainCT> if it was python2.5 we'd have a problem
 * RainCT uploads
<goshawk> RainCT: 292923 ready :P
<a|wen> savvas: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-February/000541.html ... expect python havvoc the next short while
<a|wen> and also if you wanted the link for the ppa
<savvas> woohoo!
<savvas> I'll try it on a virtual machine probably
<Laney> hi james_w, am now
<james_w> hey Laney
<james_w> how you doing?
<Laney> excellent, got a frappucino therefore life is good
<Laney> you?
<Nafallo> meh
<Nafallo> damnit
<james_w> good thanks, feeling a bit fragile today though :-)
<james_w> are you up for some mono today?
 * Nafallo knows where he'll be working from tomorrow now ;-)
<Laney> I love a bit of mono
<james_w> where's that?
<Laney> I was hoping to prioritise the 1.0 libs (which will ftbfs)
<Nafallo> james_w: Cafe Brera, Jubilee Place, Canary Wharf :-)
<james_w> heh
<james_w> Laney: sounds sensible
<james_w> Laney: was it you that already did a bunch of the libraries?
<Laney> nop, slangasek did
<james_w> cool
<james_w> Laney: there's no dependency ordering requirement is there?
<Laney> I don't think so
<james_w> I'll start uploading then :-)
<Laney> if you're doing pkg-cli-libs ones it would be cool if you could commit to svn too
<james_w> hmm
<james_w> I was going to suggest you take those ones, as you can commit, and I'll do the others
<Laney> sure
<james_w> libavahi1.0-cil <- should that be renamed?
<Laney> don't think so
<Laney> but... not suer
<Laney> sure*
<Laney> directhex: ^?
<AdamDH> maxb, because msp430-binutils sounded better?
<maxb> There's a mix of foo-binutils and binutils-foo packages in the archive, but there seem to be more binutils-foo than the other
<maxb> Is there any MOTU around who'd have a more official opinion on whether cross-build binutils packages should standardize on <target>-binutils or binutils-<target> for package name? :-)
<AdamDH> maxb, in my binutils I have a build dep on binutils source then do a symlink into my package folder and extract this, is this the best way to do this or just extract the source into my package folder and forget the symlink
<AdamDH> ?
<AdamDH> I followed the avr-binutils package there
<james_w> Laney: when I forward these to Debian, should I add a note that they shouldn't apply the changes yet?
<Laney> the transition has started
<Laney> I know meebey has uploaded some libs already
<james_w> ok
<jelmer> james_w, any chance you can re-approve evolution-mapi? I've fixed some issues mentioned by didrocks
<james_w> jelmer: sure
<jelmer> james_w, I just uploaded the wrong version
<jelmer> james_w, Sorry, will upload the proper one now
<jelmer> james_w, Clumsy me :_/
<maxb> AdamDH: As I mentioned in my REVU comment, I don't think you should use binutils-source at all
<ScottK> Here's a really odd FTBFS if someone is looking for a puzzle: https://launchpad.net/ubuntu/+source/qbittorrent/1.3.1-1/+build/861020/+files/buildlog_ubuntu-jaunty-sparc.qbittorrent_1.3.1-1_FAILEDTOBUILD.txt.gz
<jelmer> james_w: Fixed
<maxb> hmm... need the config.log from that FTBFS really
<AdamDH> right maxb I know what to do now to get the versioning correct on that, I will fix that now and reupload to revu
<AdamDH> thanks again for the help
<maxb> AdamDH: when you're doing a new upload, have a look at the autodetected problems that REVU has flagged
<AdamDH> I think they were moaning about the werid version I was using
<maxb> o
<maxb> * no
<maxb> http://revu.ubuntuwire.com/p/msp430-binutils, See the big red !.  Btw, if you change the versioning as I suggested, you can probably copy the debian/watch from binutils. Though update it to version 3.
<maxb> I don't think it needs any changes other than just bumping the version number
<james_w> jelmer: done
<james_w> didrocks: care to re-review evolution-mapi?
<AdamDH> why do I need a watch file maxb?
<jelmer> james_w, thanks!
<didrocks> james_w: yep. I posted some comments :)
<didrocks> jelmer: if you can have a look at them
<didrocks> let me review the new version :)
<didrocks> jelmer: why didn't you take my advice concerning debian/watch?
<didrocks> jelmer: I think I might have a cache issue because I don't see any change when downloading the source package :/
<jelmer> didrocks, I did fix that issue
<didrocks> jelmer: can you paste somewhere the debian/watch file so that I can check if I have a cache issue, please?
<jelmer> didrocks, http://samba.org/~jelmer/tmp/evolution-mapi_0.25.91-0ubuntu1.diff.gz
<didrocks> jelmer: much better. I think there is something with my ISP :)
<didrocks> jelmer: but I think I would have done:http://ftp.gnome.org/pub/GNOME/sources/evolution-mapi/([\d\.]+)/ \
<didrocks> instead of:
<didrocks> http://ftp.gnome.org/pub/GNOME/sources/evolution-mapi/([\d\.]+)[0-9]/ \
<didrocks> jelmer: let me check before uploading new changes
<didrocks> jelmer: appart from that all seems ok. I can change debian/watch directly if you wish :)
<didrocks> I am just interest in the lintian warning, let me experiment ^^
<didrocks> interested*
<AdamDH> maxb: I have addressed your issues of the source and have corrected this http://revu.ubuntuwire.com/p/msp430-binutils do you mind having another look over it please? Are there any other motus with some free time to look over the package please?
<AdamDH> how do you correctly add a version to something that comes from CVS and has no upstream version?
<didrocks> jelmer: just tell me if you want that I do the change myself or you do it. I will then advocate it and upload it
<jelmer> didrocks, I'm happy with you making the change
<didrocks> ok :)
<didrocks> jelmer: new package uploaded congrats :)
<jelmer> didrocks, thanks
<jelmer> didrocks, no need for a FFE?
<didrocks> jelmer: seb128 gave it
<jelmer> didrocks, ah, cool
<didrocks> jelmer: hum, he didn't write it on the bug. I will ask him on Monday
<pochu> didrocks: he doesn't usually write those ;)
<pochu> "paperwork" :)
<didrocks> pochu: yeah, I'm getting used to know him ;)
<RainCT> Amarok will use MySQL by default in Jaunty, or?
<ScottK> It does
<ScottK> mysqle
<ScottK> There are not choices.
<RainCT> ScottK: OK, thanks.
 * RainCT closes a Brainstorm idea about having MySQL by default
<ScottK> You're welcome.
<savvas> TheMuso: did the bmpx package work on powerpc? :)
<AdamDH> any one know an example of a meta package?
<AdamDH> had a look through packages.ubuntu.com could not find one
<ScottK> savvas: If you're looking for a package to work on keysafe needs some work for Python transition.
<ScottK> AdamDH: ubuntu-meta
<AdamDH> thanks ScottK
 * savvas takes a peek :)
<RainCT> AdamDH: what do you want to do?
<AdamDH> RainCT just playing around, got my 3 packages working and on revu so just wanted to see what else could be done
<RainCT> AdamDH: Ah. Because iirc ubuntu-meta is rather weird; you can get a simple meta-package just by creating a normal, but empty, package
<AdamDH> RainCT do you mind taking a look at my packages here please: http://revu.ubuntuwire.com/p/msp430-binutils and http://revu.ubuntuwire.com/p/msp430-gcc ? thanks
<AdamDH> ubuntu meta does look a little weird
<RainCT> AdamDH: we are in FF
 * RainCT doesn't revu packages anymore unless they have a FFe
<AdamDH> I know we are in FF, just after some feedback as they are my first packages, we are going to use them from my PPA, then when the next cycles comes around I will build them for that
<AdamDH> *cycle
<RainCT> AdamDH: if that mega-long FSF copyright line is for autotools, it isn't necessary
<RainCT> (additionally, I think it's fine to group copyright years..  2001, 2002, 2003, 2004 -> 2001-2004)
<AdamDH> ah just noticed that, the file was created from a script, I will modify that
<RainCT> AdamDH: Maintainer should be MOTU, not Core Dev. Also, if you upload to your PPA please use something else
<RainCT> short description is missing
<jdong_> directhex: interesting (regarding RAM usage); since this app doesn't really remember more than a 1MB text file and a couple KB fragments I don't think it'd be a great candidate, but from anecdotal experience I'm inclined to agree
<RainCT> AdamDH: changelog should close a needs-packaging bug (with "LP: #xxx"), I see no point for the X-Description in copyright, and looks fine otherwise on a very quick look
<AdamDH> so if its in my ppa I can use myself as the maintainer? just that when I ran dpkg-buildpackage -S -sa it said I did not have an @ubuntu email address so I changed it
<jdong_> directhex: btw the testing with Mono was done with a 2.2 build but I was too lazy to bring up a later IPY release
<AdamDH> thanks RainCT
<directhex> jdong_, IMHO it's worth testing ipy2, if you find time
<directhex> jdong_, if anything i'm curious
<directhex> jdong_, since you have mono 2.2, ipy2 should work fine
<jdong_> directhex: the production version of this code was running with stock Hardy Mono and it was nonetheless WAY faster than the python version
<jdong_> but yeah I'll try to get ipy 2.2 here
<directhex> jdong_, well, yes. despite what some people think on the interwebnets, python's a fatass compared to mono ;)
<jdong_> directhex: heh without a doubt I knew from before Python for tightly arithmetic loops could be a factor of 600 to 1000 slower than plain C
<jdong_> I just never expected myself to write a program where that would hurt me
<jdong_> and I thought in that case I'd have to resort to Java or C
<jdong_> but Mono pleasantly surprised me here
<directhex> jdong_, so when are canonical going to drop python for the superior c#? :p
<jdong_> directhex: IMO when Boo gets a bit more mature :)
<jdong_> directhex: C# is great but doesn't replace Python as a quick and dirty prototyping language
<directhex> jdong_, your figures are largely what i expected, except for ironpython which i didn't expect to be incredible suck
<ScottK> I suspect when they get a different set of developers.
<directhex> jdong_, anyway, good for you on making those figures - i trust them a lot more than i trust the shootout on alioth
<RainCT> anyone looking at
<RainCT> python-wxgtk2.6?
<jdong_> directhex: ok ipy 2.0.1 running
<savvas> ScottK: there's version 0.4-1 at debian - the maintainer removed the 2.4 dependencies :) http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=keysafe
<directhex> NCommander, installing jaunty in armel qemu... how long exactly is it meant to hang on "configuring makedev"?
<ScottK> Is it uploaded yet?
<directhex> oh, bollocking hell..... the screen stops updating. that's it. gah!
<savvas> ScottK: no, not yet unfortunately - should I proceed and remove these? There was supposed to be a "0.3.5-4.1" version where they remove the 2.4 dependencies, but can't find it
<ScottK> savvas: I'd look at the proposed package and update ours similarly.
<savvas> ScottK: ok, I'll try :)
<jdong_> directhex: unfortunately ipy2 doesn't seem to perform any better
<jdong_> it has been running for almost 5 minutes now
<directhex> jdong_, hm, shame
<jdong_> directhex: indeed; there's something about this workload that trips it up
<jdong_> directhex: heh I was really surprised how close ikvm got to C# and Java; I expected it to be a second-class .NET citizen
<blueyed> For a rebuild of 0-ubuntu1, should I use 0-ubuntu2 or 0-ubuntu1build1 for the version? (I cannot find a wiki page about it)
<directhex> jdong_, i'm pondering goals for karmic. i wonder whether packaging things like ironruby has any value
<jdong_> directhex: well I'd definitely like to see our Mono stack up to date with upstream again for Karmic...
<jdong_> I'm not sure how mature IronRuby itself is
<directhex> jdong_, 2.2 introduces issues for a bunch of apps, we decided to skip straight to 2.4
<directhex> maybe 2.6 depending on release schedules
<jdong_> directhex: ah, interesting
 * asomething wonders if there's any grunt work for a contributer, maybe with universe python rebuilds?
<Laney> directhex: ^ POUNCE!
<Laney> brb
<directhex> asomething, pfft, python sucks. jdong_ proved it. how about some mono work? :p
<jdong_> haha
<asomething> directhex: what do you got? =)
 * jdong_ has started yet another language war :)
<directhex> asomething, see http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO ?
<jdong_> the last time I did a shootout was in a Java class, I thought the code was running unreasonably slow so I rewrote it in C
<jdong_> to my surprise the C version was even slower.
<directhex> asomething, every red item in the jaunty column needs to be green, following the guide on http://wiki.debian.org/Teams/DebianMonoGroup/Mono20Transition#head-67c13a005dab7f510b0fd1ee8db7a30689e89669
<directhex> asomething, if the maintainer is "pkg-cli-libs" then your work can go directly to debian & be synced
<asomething> directhex: cool, I'll look through it and garb a package or two
<directhex> jdong_, could always discuss the matter at UDS :p
<RainCT> blueyed: ubuntu2
 * RainCT adds jdong_ to his blacklist, right behind directhex :D
<savvas> ScottK: should I make it look like a merge? I can't find the debian packages for keysafe versions 0.3.5-4.1 and 0.3.5-3, so I don't know what are the actual changes
 * directhex uses his pkg-cli-apps powers to purge RainCT's packages
<savvas> package wars, heh
<savvas> better than throwing shoes :p
<RainCT> lol
<directhex> savvas, xchat lacks a /shoe
<ScottK> savvas: I'd just look at their changes and make the appropriate ones to our package to solve the python problem.
<RainCT> directhex: and I'll soon get another package in there.. :(
<directhex> RainCT, which one?
<jdong_> directhex: (0, 241363, 'jackpot is ', 'here!\n\n\n\n\n\n\n\n\n\nafwefj\nwejf\nawejp\nfjaew\nj') 2122.07945251
<jdong_> *YEA BABY*
<directhex> jdong_, ouch :|
<jdong_> obviously ipy2 isn't the end all solution to slow python apps ;-0
<RainCT> directhex: mistelix, it's a video editor from the same author as gbrainy
<directhex> jdong_, worth discussing with #ironpython ?
<savvas> ScottK: oh, the python problem is solved, I just removed '2.4' from the name of the dependencies: http://launchpadlibrarian.net/23231836/keysafe_0.3.5-2_0.3.5-2ubuntu1.diff.gz
 * RainCT raises eyebrows at jdong_ :P
<savvas> ScottK: I thought you also wanted to improve the copyright as the maintainer did :)
<jdong_> directhex: Idon't have the time to follow up on it but if you feel like it, sure
<RainCT> jdong_: what is that supposed to be? :P
<jdong_> RainCT: it's a fuzzy substring matcher
<ScottK> savvas: I didn't look.  If there are other worthwhile packaging improvements, I'd grab those too.
 * ScottK is on the way out the door
<savvas> ScottK: ok, thanks! :)
<jdong_> RainCT: for example, needle="this is a botched song lyric" vs haystack "blah blah this is the real song's lyrics" would match the "this is the real ... " with some positive "edit distance" score.
<directhex> jdong_, i wonder if the slowness is due to the DLR on mono, or ipy in general
<RainCT> jdong_: uhmmmmmm... okay :P
<jdong_> directhex: would be interesting to know, and also interesting to find out which operation in the python code is causing the regression
<jdong_> directhex: but the code for it is on my langshootout page linked earlier
<jdong_> RainCT: it's for a random bot that I wrote which can pick up the next line of a song if you give it the one before
<jdong_> to allow for spelling and memory inaccuracies it uses this fuzzy substring matcher
<jdong_> the python version took 40-50 secs to return a match when the C# version takes 2 or 3 :)
<RainCT> ah, nice
<directhex> jdong_, which version are you deploying then? java?
<RainCT> make a python library :P
<jdong_> directhex: C#
<jdong_> directhex: it's fast enough and in a language I enjoy maintaining.
<jdong_> it also uses Xapian as a top-level filter to weed out 200 candidate songs out of 2000 or so in its library, so the chances of hitting its worst-case runtime are relatively low.
<directhex> "generating locales" on arm in qemu is HELLISH
<AdamDH> I have a full working msp430 toolchain, took a while, but it works
<savvas> wow, launchpad ppa is quick today
<dmz> howdy y'all, i just got my base system live cd running great, now i need to be able to install it onto a local disk. i have install ubiquity but do not know what to run when it boots to get it to install, any suggestions?
<savvas> dmz: I think you should ask that question in #ubuntu :)
<dmz> ok, sorry it was mentioned to me that motu was for people building custom installs
<savvas> dmz: oh, I don't know about that, motu manage the packages in the ubuntu universe repository - but stick around, maybe someone else knows
<a|wen> dmz: you might want to look at uck (ubuntu customization kit) if you are making a custom cd?
<savvas> RainCT: do I have to open a bug number for package keysafe python transition?
<savvas> or anyone else :)
<dmz> thanks i'll check that; too many different references :)
<a|wen> dmz: afaik it has been uploaded to jaunty/universe ... before that they have a deb at their site http://uck.sourceforge.net/
<RainCT> savvas: Do you need sponsorship?
<RainCT> if so, yes
<savvas> RainCT: ah, yes - ok :)
<AdamDH> how do I stop stripping inside my packages? if the package strips the libraries then the result is that nothing will compile with the cross compiler, I have stopped dh_strip but that has not seemed to help
<asomething> directhex: taking a shot at notify-sharp, it builds in pbuilder, how's this look: http://paste.ubuntu.com/124443/
<Laney> asomething: It should be /usr/bin/csc
<directhex> asomething, set GMCS to /usr/bin/csc, and check your build log to make sure it's being used
<Laney> hax
<asomething> ok
<ian_brasil> i just packaged gypsy and out it in my ppa..if someone can take a look
<ian_brasil> https://edge.launchpad.net/~ianlawrence/+archive/ppa
<asomething> alright, changed it to csc and it still builds. and I see "checking for gmcs... /usr/bin/csc" in the log
<Laney> look at the actual build
<Laney> sometimes it's ignored :(
<asomething> how about "/usr/bin/csc -out:notify-sharp.dll"
<directhex> asomething, then it's fine :)
<asomething> should I format the patch for debian and just submit it there?
<directhex> yes
<asomething> will do
<directhex> or just shove it on pastebin & laney or i can add it to svn right away
<Laney> I am too busy eating a home made pork pie
<Laney> nomnomnom
<directhex> home-made? does it still contain 48% aspic jelly?
<Laney> erm
<Laney> the jelly is made from boiled up pig bits
<Laney> mok0: Are you going to patch requestsync to remove the please? ;)
<asomething> here it is formatted for debian: http://paste.ubuntu.com/124456/
<rgreening> ScottK: my MOTU application is completed. Just needs sponsor input. I;ve added myself for March 13th meeting as well.https://wiki.ubuntu.com/rgreening/DeveloperApplicationMOTU
<rgreening> Thanks for all your help ScottK
<rgreening> hey didrocks
<directhex> asomething, seems fine to me, let me test it quicksharp
<didrocks> rgreening: yep? :)
<rgreening> didrocks: I decided to take the next step and apply for motu. finally :)
<didrocks> rgreening: congrats \o/ hope everything will be ok :)
<rgreening> :)
<didrocks> Laney: this is a mandatory, patch requestsync :)
<directhex> dpkg-deb: building package `libnotify0.4-cil' in `../libnotify0.4-cil_0.4.0~r2998-2_all.deb'.
<wgrant> Are we meant to rebuilding everything we run into for Python 2.6, or is there going to be some massive scripted upload eventually?
<james_w> if it needs rebuilding it should be I believe
<wgrant> That's what I thought. Thanks.
<Nafallo> wgrant: if you're going to rebuild stuff, feel free to add revelation to your list :-)
<AdamDH> grr cannot get my package to not strip all libraries are ruined because they are currently been stripped, I am using arch amd64, any ideas how I can stop stripping or suggest a package where stripping has been stopped so libarys can be built correctly?
<AdamDH> dh-strip has been removed from my rules but I can still watch the files been stripped
<geser> AdamDH: have you a build log? pbuilder or buildd?
<AdamDH> there are no errors is only when you come to use the package with test code you get: msp430/bin/ld: skipping incompatible /usr/lib/gcc-lib/msp430/3.2.3/libgcc.a when searching for -lgcc
<AdamDH> so I think the libc is been compiled wrong somewhere
<geser> AdamDH: what does file tell on the contents of that libgcc.a?
<AdamDH> looks like its been compile for my native host instead of the msp430 host
<AdamDH> *compiled
<AdamDH> so its an issue with there Makefile
<geser> cross-compiling is not easy (as far as I can tell). Please check if the upstream Makefile uses the correct compiler
<savvas> mplayer has an easy config for cross compilation hehe
<AdamDH> i might take a look at the mplayer source
<AdamDH> i think there makefile is the problem here as the arguments are not passed
<RainCT> Arr.. wxwidgets is placing the Python 2.6 stuff in /usr/*local*/lib and FTBFS.. :S
<RainCT> pochu: any clue?
<blueyed> Is there a known problem that rebuilds of Python apps land in /usr/local now? (using python-central). Bug 335941 has more details and the build log.
<ubottu> Launchpad bug 335941 in duplicity "duplicity will be removed if one upgrades python in jaunty" [Medium,In progress] https://launchpad.net/bugs/335941
<RainCT> blueyed: just happened to me
<blueyed> Have you found the reason for it yet?
<RainCT> No :(
<pochu> RainCT, blueyed: try with to add --install-layout=deb to the setup.py call
<pochu> s/with//
<RainCT> oh, right
<pochu> RainCT, blueyed: https://lists.ubuntu.com/archives/ubuntu-devel/2009-February/027439.html
<RainCT> damn.. site-packages is hardcoded like 10 times in the rules file
<RainCT> Does {site-packages,dist-packages} work in debian/rules?
<blueyed> Why would you need both?
<RainCT> blueyed: module for all python versions
<blueyed> ok. I'm not sure, if the expansion works. I'd say no.. but don't remember..
<RainCT> well, I'll try with wildcards
<pochu> RainCT: {,} is a bashism, so not sure
<RainCT> oh, didn't know this
<wgrant> It must have been done in some other package already.
<pochu> but wildcards will be fine :)
<blueyed> pochu: thanks for the hint, it works for me/duplicity.
<pochu> I believe doko is using *-packages
<pochu> blueyed: cool
<RainCT> yeah, that's what I've done too
<RainCT> and now I can wait 30 minutes for the package to build..
<RainCT> perhaps I should just update and see if LP fails again, as I'm going to bed soon :P
<wgrant> Hmmm, see http://launchpadlibrarian.net/23118516/smart_1.1.1~bzr20081010-0ubuntu0.8.10.1_1.1.1~bzr20081010-0ubuntu0.8.10.2~ppa1.diff.gz.
<wgrant> *-packages is used, but not everywhere.
<wgrant> I wonder why python.mk wasn't advertised anywhere...
<wgrant> doko: Are we meant to be using python.mk to solve this problem?
<phil_ps> how do I change /etc/apt/sources.list to get the latest?
<wgrant> phil_ps: "the latest"?
<phil_ps> sorry, jaunty
<phil_ps> I want to test my patch in jaunty but I am running intrepid
<wgrant> You probably do not want to upgrade to Jaunty.
<wgrant> Consider using a chroot (perhaps using pbuilder or schroot) to test instead.
<phil_ps> okay thanks
<RainCT> phil_ps: see http://bloc.eurion.net/archives/2009/test-build-debian-packages/ :)
<phil_ps> thanks RainCT
<RainCT> (it's used to build packages but you can also login -Â«pbuilder-jaunty loginÂ»- to try out stuff in the terminal; if you want to test GUI stuff you'll need a VM, though)
#ubuntu-motu 2009-03-01
<phil_ps> okay
<phil_ps> I want to test gui stuff
<phil_ps> I am using a VM (host is windows guest is intrepid)
<phil_ps> so should I upgrade my guest to jaunty?
<RainCT> phil_ps: Ah. Yes, or just make a clean Jaunty installation in a new VM
<blueyed> I'm getting a build failure with the virtualbox-ose merge, but I don't know what may be wrong. build log: http://launchpadlibrarian.net/23237526/build.log (bug 328161).
<ubottu> Launchpad bug 328161 in virtualbox-ose "virtualbox-ose new upstream version 2.1.2" [Wishlist,In progress] https://launchpad.net/bugs/328161
<RainCT> blueyed: int RTASSERTVAR [0]
<RainCT> blueyed: ISO C++ forbids zero-size array 'RTASSERTVAR'
<RainCT> well.. the error says it all :P
<phil_ps> RainCT: Is making a new VM inside my guest os REALLY slow?
<phil_ps> I want to work in linux and I use alot of computers (on campus)
<RainCT> phil_ps: why don't you just create a second one inside the host os?
<RainCT> and.. I don't know, never tried that
<phil_ps> so I have to reinstall virtualbox each time and there is no way to import guests
<phil_ps> you have to recreate them each time
<phil_ps> so I have to make a new one, close virtual box, fiddle with the xml configs and then reopen each time
<phil_ps> maybe I should add import/export support to virtualbox then
<RainCT> blueyed: seems like that's an error which was previously only showed with pedantic but was then moved to fail by default (can be disabled with a 'permissive' flag)
<RainCT> phil_ps: I guess you can just copy the hard disk file
<blueyed> RainCT: well.. I'm not used to C++ though, I've read it of course.. where would I add the flag?
<blueyed> RainCT: that's the code: http://pastebin.com/m46b98c67
<phil_ps> RainCT: I do that, but whenever I make a checkpoint I loose things
<phil_ps> RainCT: because they don't update the hard disk file
<RainCT> pochu: seems like it's still installing into local/
<RainCT> find debian/python-wxgtk2.6/usr/lib/python2.6 -name '*.py?' -exec rm '{}' ';'            find: `debian/python-wxgtk2.6/usr/lib/python2.6': No such file or directory             make: *** [install-gtk-pylib2.6] Error 1
<blueyed> RainCT: your setup.py line?
<RainCT> blueyed: the flag is called "fpermissive", I guess you have to add it to some variable in debian/rules
<RainCT> blueyed: http://paste.ubuntu.com/124495/ line 432
<RainCT> python$* ./setup.py build --install-layout=deb \
<RainCT> errr
<RainCT> that should be in the  "setup.py install" line, right? :$
<blueyed> yes :)
<phil_ps> RainCT: okay, I am done complaining. where can I get a .iso for jaunty...
<RainCT> phil_ps: http://cdimage.ubuntu.com/releases/jaunty/alpha-5/
<AdamDH> phil_ps: http://cdimage.ubuntu.com/releases/jaunty/alpha-5/
<AdamDH> doh RainCT got there first
<RainCT> :)
<AdamDH> just put Jaunty on my MacBook Pro
<AdamDH> RainCT in that cross compilers libc Makefile there was a dirty sed hack that changed where libc was been installed to, took me a while to find it! that was causing some of my issues
<AdamDH> so prefix or destdir would not have worked passed from rules
<RainCT> and it's still failing to build.. argh
<directhex> hm.
<directhex> ogra/NCommander?
<phil_ps> installed jaunty on a virtualbox VM
<phil_ps> mounting share folder is not working
<phil_ps> sudo mount -t vboxsf share /mnt/share
<phil_ps> /sbin/mount.vboxsf: mounting failed with the error: Protocol error
<phil_ps> is this a #ubuntu+1 discussion?
<directhex> :|
<Laney> :O
<directhex> Laney, ready for a screamer?
<directhex> Laney, been fighting for a few nights to get an arm install of ubuntu going in qemu, but keep running out of RAM
<directhex> Laney, as if qemu's "-m" flag is being ignored
<directhex> config-2.6.28-versatile -> CONFIG_CMDLINE="root=1f03 mem=32M"
 * theholyduck lol'z
<theholyduck> phil_ps, try pulling a restart :P
<theholyduck> i seem to remember ubuntu pulling some shit like that in virtualbox the one time i tried it
<theholyduck> mount it as a machine share not transisten share aswell
<Laney> directhex: There an "Ubuntu virtualisation team" ;)
<Laney> there's
<directhex> Laney, and they need stabbing inna face! :o :o :o
<directhex> or maybe it's just ogra
<directhex> generating locales, fr'example, appears to not take 12 mins per locale, as long as one has more than 5 meg of free ram
<directhex> blarg, jaunty's not very installable just at the moment on ARM
<directhex> certainly the MID or Netbook tasks aren't working
<directhex> python rubbish
<StevenK> doko did warn people
<directhex> xubuntu-desktop seems functional though
<directhex> nope, it lied
<jdong_> nothin like a quest for paranoia leading to checkin how SELinux in Lenny.
<ryanakca> Could someone point me to a watch file for an app hosted on google code? I can't seem to get rid of the ``.tgz'' from the version number.
<vorian> ryanakca: chm2pdf
<ryanakca> vorian: thanks
<vorian> no problemo
 * jdong_ questions if mutt is REALLY needed in the base system task...
 * Hobbsee waves, as she sponsors a patch
<iulian> Morning
<sejdong> whoo selinux works
 * sejdong considers switching his server to Debian
<jldugger> ive got a question about  bug #335832
<ubottu> Launchpad bug 335832 in cwiid "cwiid needs to be recompiled for Python 2.6" [Undecided,New] https://launchpad.net/bugs/335832
<jldugger> how does it come to pass that a package can be built for an depricated platform?
<jldugger> i guess i missed an email threda
<jldugger> thread
<ScottK> When it was last compiled when it wasn't deprecated.
<jldugger> so do I just need have it uploaded with a version bump and have doko look at it if it fails?
<ScottK> No.  It's in Universe so it's mostly up to the community to fix.
<ScottK> I'm test building it now.
<rgreening> good evening ScottK
<ScottK> Some packages need changes too.
<ScottK> Heya rgreening.
<ScottK> rgreening: Up for some Python transition fun?
<rgreening> so I finally finished the motu app
<rgreening> what sort of fun :)
<rgreening> 2.6?
<ScottK> yes
<rgreening> and deprecated stuff
<ScottK> I saw, but I haven't had a chance to scribble on it yet.
<rgreening> bzr has lots
<rgreening> well, Im pumped now. kdebindings built first try. I was amazed I didnt have to dance and use voodoo
<rgreening> so sure, I can help with some python stuff
<rgreening> fire away
<ScottK> rgreening: pypoker-eval has some 'fun' mix of source changes needed for the Python 2.6 transition and some kind of autofoo/libtool confusion that's more than I'm up for at the moment.
<rgreening> you used the 'auto' word.. oh no's
<ScottK> Enjoy.
<rgreening> I'll get source and have a peek
<ScottK> jldugger: Uploaded.  I'll warn you that it's bugged though.  It only supports the highest Python version, so it'll now work in 2.6, but not 2.5.
<ScottK> That's a pre-existing problem as the previous package only supported 2.5 and not 2.4.
<ScottK> Debian control claims it'll support all Python versions, so the build system's bugged.
<jldugger> ScottK, the package build system or Canonicals?
<ScottK> The package.
<ScottK> It's late and I'm tired, so I just got it to installable again.
<jldugger> that's fine by me
<jldugger> im just curious how this all works
<ScottK> Well it currently only provides cwiid.so built for one Python version.  It should provide it for all.
 * ScottK heads off for bed.
<jldugger> it seems that intrepid binaries depend on 2.5
<jldugger> so you'd need versioned package names (and builds)
<jldugger> well thanks for looking at it.
<savvas> is there a list of packages for the python transition?
<wgrant> savvas: I see 300 binaries with 'python (<< 2.6)' in their Depends, which is an incomplete list. grep-dctrl is useful here.
<wgrant> I don't know of a real list, I'm afraid.
<wgrant> It would certainly be useful.
<savvas> thanks wgrant, I'll try and filter them using the pythoneers ppa
<Q-FUNK> howdy!  could anyone help with bug #335741 ?
<ubottu> Launchpad bug 335741 in libtorrent-rasterbar "[jaunty]python(<2.6)-based apps cannot meet dependencies" [Undecided,New] https://launchpad.net/bugs/335741
<a|wen> Q-FUNK: try to change the build-depends and see if it works with python 2.6 ... if not, we need to patch it to work or in some cases see if a new upstream version supporting 2.6 is there
<Q-FUNK> it doesn't
<Q-FUNK> ./configure (or however this package checks for python) needs tlo be updated to not be specific about versions to check
<Q-FUNK> right now, it seems to explicitely assume that 2.5 is the one to look for if it cannot find 2.4
<Q-FUNK> ah, uscan indeed reports a newer minor version
<a|wen> try to check what the upstream changelog says of that one
<Q-FUNK> doesn't mention anything about python versions
<Q-FUNK> trying a build anyway, just in case upstream is sloppy about changelogs
<a|wen> Q-FUNK: the configure is failing due to Boost::Python not being avaible ... we have been through a boost transition, so might actually be something in that regard that is the problem
<rgreening> ScottK: bug 336151 - problem fixed as requested.
<ubottu> Launchpad bug 336151 in pypoker-eval "Requires update to build with python2.6" [Undecided,New] https://launchpad.net/bugs/336151
<Q-FUNK> a|wen: noticing exactly what is pulled by pbuilder, it even looks like libboost-dev is not among the build-depends.  could that be it?
<a|wen> Q-FUNK: i'm actually not sure, what the python-bindings part of boost is called
<a|wen> but could be that or something similar
<Q-FUNK> ok, so we went from libboost 1.35 to 1.37, correct?
<a|wen> from 1.34 to 1.35
<a|wen> but 1.37 is in the archives as well
<Q-FUNK> this package already checks for 1.35
<Q-FUNK> and depends on 1.35 too
<Q-FUNK> could it be that libbost 1.35 itself hasn't been rebuilt against python 2.6?
<a|wen> Q-FUNK: it depends on libboost-python1.35-dev ?
<Q-FUNK> the new upstream builds as-is, if we remove the single patch in debian/patches
<Q-FUNK> yup, it depends on 1.35
<a|wen> Q-FUNK: the rebuild of libboost-python1.35-dev against python 2.6 is less than two days old
<Q-FUNK> ah, so it has already been rebuilt?
<a|wen> Q-FUNK: jup ... but might not have hit your archive yet
<a|wen> Q-FUNK: which version does pbuilder (or what you use) pull in of libboost-python1.35-dev?
<a|wen> Q-FUNK: it should be 1.35.0-8ubuntu5 ... if it is 1.35.0-8ubuntu4 it doesn't work
<Q-FUNK> 1.35.0-8ubuntu5
<Q-FUNK> so that's not becuase we don't have the latest libboost
<a|wen> Q-FUNK: okay ... i'm not sure exactly what the configure does; if it only checks for libboost for certain python versions; so yeah, you might want to take a look in it
<Q-FUNK> we're already patching the m4 stuff in the current package.  I wouldn't be surprised if we actualy break things
<a|wen> he, not impossible
<directhex> hm. is there an ETA on python-pysqlite2 and python-launchpad-integration being installable?
<savvas> is anyone working on it?
<geser> I'm looking at the moment at it (but no promises that I will be successful) and I'd need a main sponsor for it
<savvas> hm.. that was a nice patch
<directhex> other than that, i more or less have an ARM system installed in qemu
<StevenK> If both python-pysqlite2 and python-launchpad-integration are in main, then doko ought to have fixed them ...
<geser> StevenK: py-lp-i was already touched my doko, but it still depends on python < 2.6
<geser> and p-pysqlite2 is in universe
<StevenK> geser: I can fix py-lp-i directly, if you wish
<savvas> I also need someone to review the patch for keysafe: https://bugs.launchpad.net/ubuntu/+source/keysafe/+bug/336011
<ubottu> Ubuntu bug 336011 in keysafe "python transition (and package impovements)" [Undecided,New]
<geser> StevenK: sure, so I don't need to for a sponsor
<pochu> geser: why aren't you core-dev yet? :)
<savvas> usr/lib/python*/site-packages/compizconfig.so
<geser> pochu: good question :)
<savvas> oops
<lesterc> Hi - does anyone knows how does the vesamenu on the netboot tarball works?
<StevenK> doko didn't push his changes for py-lp-i into bzr. Bad.
<sebner> geser for core-dev \o/
<StevenK> geser: The Depends for py-lp-i look fine to me ... >= 2.5, << 2.7
<directhex> it  varies per-arch
<directhex> python  (<< 2.7) [i386]
<directhex> python  (<< 2.6) [amd64]
<directhex> and arm is <<2.6
<StevenK> Hmmm
<directhex> http://packages.ubuntu.com/jaunty/python-launchpad-integration
<StevenK> Okay, so I'm betting it was uploaded too early
<directhex> before the default python was updated on all arches?
<StevenK> But it's arch all ....
 * StevenK digs
<StevenK> Helpfully, I run on amd64 here
<directhex> arch all with per-arch depends? beautiful
<directhex> hm, no, looks arch-any to me
<directhex> Architecture: any
<directhex> hm, gotta go
<StevenK> No, python-all-dev
<geser> StevenK: looks like it was a bad build order, I've just rebuild it on amd64 in my pbuilder and the depends are fine now
<StevenK> geser: I'll confirm and then upload a no-change rebuild.
<wattazoum> hello all
<geser> Hi wattazoum, just answered on your mail to ubuntu-motu
<wattazoum> I saw that :-)
<wattazoum> very nice and fast :-)
<wattazoum> thank you
 * RainCT too heh
<wattazoum> Is it possible to make a .deb package Depend on a certain package (and install it) if a third packages is intalled?
<geser> savvas: re keysafe: you missed some python2.4 references in {keysafe,ksed}.in
<wattazoum> basically, if a UI (like GTK)is installed , depends on python-gtk , but if it's QT , depends on python-qt4
<geser> wattazoum: it won't work e.g. on multi-user system where both gnome and kde are installed (and used) or if a gnome user prefers a qt program and has both gtk and qt libs installed
<wattazoum> geser, Indeed :-/ ,
<savvas> thanks geser, I'll check it out :)
<savvas> geser: btw, the debian maintainer was changing files directly - should I do the same? without quilt/dpatch?
<geser> savvas: yes, as using quilt would introduces a mix of changes some as patches and some directly applied
<geser> savvas: and please forward your changes also to the debian maintainer (if not already done)
<savvas> ok :)
<savvas> geser: actually, the maintainer has a new version in mentors.debian.net: http://mentors.debian.net/debian/pool/main/k/keysafe/
<savvas> oh you mean about the quilt build-dep removal
<savvas> alrighty
<geser> savvas: if your changes are already in the next debian packages then of course you don't need to forward them anymore
<geser> savvas: I think more about the changes to unversion the python interpreter
 * savvas checks
<savvas> they're removed, yay! :)
<geser> savvas: the idea is to get any change which is not ubuntu-specific to get also included in the debian package so we can sync it in future again
<savvas> I see
<a|wen> hi geser! ... i'm trying to find some recent sponsors for my motu application; you took at least a few from the arts batch, if you feel adding a short comment: https://wiki.kubuntu.org/AndreasWenning/DeveloperApplicationTemplate
<geser> wattazoum: fyi: [ubuntu/jaunty] python-sqlite 1.0.1-7ubuntu1 (Accepted)
<wattazoum> wonderful !!!
<wattazoum> thanks
<AnAnt> Hello, I'm preparing a package to install a PPA key
<AnAnt> what should I mention in debian/copyright  under Upstream authors ?
<Hobbsee> AnAnt: if you've written it...you?
<AnAnt> Hobbsee: written what ? it's only the PPA keyring
<Hobbsee> if you've written what normally classes as "upstream"
 * Hobbsee is uncertain why you're trying to package something to install a PPA key, but whatever
<savvas> AnAnt: I would say that logically there's no upstream for that, perhaps you should remove upstream authors. ( I'm not a MOTU :) )
<AnAnt> sounds reasonable
<geser> AnAnt: see the copyright file for ubuntu-keyring: http://changelogs.ubuntu.com/changelogs/pool/main/u/ubuntu-keyring/ubuntu-keyring_2008.03.04/ubuntu-keyring.copyright
<geser> as an example
<AnAnt> thanks
<james_w> geser: hey, you say you are working on the python transition today? Anything I can do to help?
<savvas> geser: how does this look like? http://launchpadlibrarian.net/23250898/keysafe_0.3.5-2ubuntu1.debdiff
<geser> james_w: I'm going through the unmet deps list and see what I can fix
<james_w> geser: ah, cool
<james_w> geser: do you think it is worthwhile trying to come up with a list of candidate packages to fix?
<james_w> i.e. parse Packages files to find likely candidates for a rebuild?
<savvas> hm.. what does "reverted:" mean in a patch/debdiff header?
<james_w> I'm pretty sure it should be possible, I just haven't quite worked out the criteria yet
<geser> james_w: that would be a good idea
<james_w> the first target would be "Architecture != all" packages
<james_w> with a python dependency?
<geser> a criterion could be: check the Contents file for packages building python modules and check if they have transitioned yet (have a python 2.6 module)
<geser> in case the dependency on python < 2.6 doesn't catch them
<geser> and those are already listed in the unmet deps output
<geser> savvas: looks good. Although using "/usr/bin/python" is preferred to "/usr/bin/env python" (think of a different python version installed in /usr/local/bin without the needed modules for that version)
<geser> savvas: I'll fix it while building the updated package
<RainCT> james_w: ScottK had a line to get all packages which depend on "<< 2.7"
<RainCT> * 2.6
<geser> james_w: it would be also good to check packages which directly depend on python2.5 (or even python2.4)
<RainCT> >> 17:08 < ScottK> I did finally figure out grep-available -F Depends "python (<< 2.6)"|grep Package for the packages that explicitly need rebuilt.
<savvas> geser: ok noted, thanks :)
<geser> savvas: [ubuntu/jaunty] keysafe 0.3.5-2ubuntu1 (Accepted)
<savvas> woohoo!
<savvas> RainCT: really minor, but for better sync with debian, in compizconfig-python we could use this line instead of the two in debian/install: usr/lib/python*/*-packages/compizconfig.so
<RainCT> savvas: ah, right. I'm still waiting for Sean to answer to my ping from yesterday, though :P
<savvas> ok :)
<geser> james_w: fyi: you can skip python-omniorb as I've already an updated package just waiting on omniorb4 getting build
<james_w> geser: cool, thanks for the heads up
<geser> james_w: if you need something more demanding than a simple change, try setools (I've gave it a quick look at put it to the end of the queue)
<geser> :)
<james_w> heh
<geser> james_w: I'm just looking over your changes to yapgvb (I wanted to look at it again after I was done with the easy ones): will the install-ext-% target do the right thing for python2.5?
<james_w> geser: no, it won't, but it is XS-Python-Version: current
<geser> yes, I just noticed it myself
<ScottK> RainCT: I did later figure out that only works for packages that are or have been installed.
<RainCT> ScottK: oh, too bad
<ScottK> So I did my first cut by apt-cache rdepends python2.4 and installing all those packages in a chroot.
<ScottK> From that list I know of python-codespeak-lib, python-migrate, and python-pypoker-eval are left undone.
<ScottK> rgreening was looking at python-pypoker-eval when I went to bed last night.  Dunno if he got it sorted.
<directhex> yay @ lp-integration
<directhex> i can continue my arm tinkering
<ScottK> In fact, Bug #336151 is waiting for uus.
<ubottu> Launchpad bug 336151 in pypoker-eval "Requires update to build with python2.6" [Undecided,Confirmed] https://launchpad.net/bugs/336151
<Laney> core > arm
<directhex> Laney, true
<ScottK> RainCT: Would you have time to sponsor that one?  I'm on my way out the door.
<RainCT> ScottK: Sure
<ScottK> RainCT: Thanks.
<mok0> Laney: you really thing I should patch requestsync??
<mok0> :-P
<Laney> mok0: It's your idea!
<mok0> heh
 * RainCT is OK with it
 * Laney does it
<RainCT> .. with Ubuntu :)
<Laney> ffs
<Laney> how do I remove a commit?
<Nafallo> uncommit
<Laney> ...who'd have thought? :O
 * RainCT uploads wxwidgets2.6 and hopes it won't FTBFS again
<RainCT> ffs?
<jpds> RainCT: wtf ffs
<RainCT> jpds: Gee...  I don't know what ffs means...
<savvas> free for some :p
<savvas> http://en.wiktionary.org/wiki/FFS ;)
<RainCT> hehe
<RainCT> An expression of anger or frustration.
<sebner> !ohmy | Laney :P
<ubottu> Laney :P: Please watch your language, attitude, and topic to help keep this channel friendly and helpful. Remember, there are kids here!
<Laney> :((((((((
<directhex> python-hildondesktop needs a rebuild too afaik
<StevenK> directhex: Leave that one, I'll deal with it tomorrow
<directhex> okay, cheers
<directhex> just alerting you
 * StevenK adds it to his todo
<Laney> anyone got a sync to make?
<jpds> Laney: Main or universe?
<Laney> doesn't matter
<Laney> just want to test this change
<jpds> I usually use gnupg as a control for main.
<geser> Laney: use staging for testing?
<Laney> geser: Yeah, that requires digging around elsewhere in u-d-t :(
<jpds> Laney: No really, just manage-credentials with the staging flag.
<jpds> .. I think.
<Laney> can I have multiple sets of credentials at once?
<Laney> or will it overwrite my old ones?
<jpds> Backup your old ones, just in case.
<Laney> well, that doesn't work!
<jpds> Whoops.
<Laney> I think it doesn't look to see what service the credentials are for
<RainCT> YEAH!
<jpds> You did use the --lp flag right?
<RainCT> wxwidgets2.6 built!!
<Laney> yes
<Laney> gives a 401 unauthorized error
<jpds> Hmm.
<anakron> Hi all
<anakron> :)
<jpds> Laney: Traceback?
<jpds> anakron: Hola.
<anakron> HI RainCT, Laney
<anakron> hola
<Laney> ey up
<anakron> :O
<RainCT> Hi anakron :)
<Laney> jpds: http://pastebin.ubuntu.com/124792/
<jpds> Laney: Which access level did you give the token?
<Laney> all
<thekorn> Laney, did you use manage-credentials to create the credentials, if so, don't forget to set --level
<Laney> thekorn: oh, I don't remember doing this before
<Laney> (and the usage doesn't mention it)
<Laney> let me try again
<Laney> thekorn: no change
<Laney> thekorn: Is there no way for the tool to tell what access it was given?
<thekorn> Laney, staging or edge?
<Laney> thekorn: staging
<Laney> Here's the line I used: "manage-credentials create -c ubuntu-dev-tools --service staging -l 4"
<thekorn> Laney, no, unfortunatly the API and launchpadlib does not give such information (yet)
<thekorn> there is an open bugreport about it
<Laney> Wouldn't it be more sensible for the application to request the access level it needs?
<Laney> and LP to say "ubuntu-dev-tools wants to read and write non-public data. Is that OK?"
<Laney> jpds: Is the problem that get_launchpad takes a service parameter?
<jpds> Laney: Actually, that might be the thing you'd want to change to STAGING for testing.
<Laney> it'd be better if it could determine it from the credentials file though
<RainCT> Started:   1 hour ago        /me wonders why his PC compiles faster than the buildd's
<RainCT> ah nvm, it's built, I just can't read :P
<anakron> Hi laney
<Laney> hi ho
<anakron> hey, look it, https://bugs.launchpad.net/ubuntu/+bug/335940 , I think that this could be helpful to many people
<ubottu> Ubuntu bug 335940 in nvidia-settings ""Save to X Configuration File" button does not work" [Undecided,Confirmed]
<anakron> it's useful if i "solved" it?
<RainCT> oh, nvidia-settings is FLOSS?
<anakron> mm
<RainCT> that was a retoric question, I've just seen it's in "main".. nice :)
<anakron> :) so it able to add a debdiff file to it?
<anakron> it's so easy to solved, but this is not actually an app that MUST be run with root priv
<anakron> so
<RainCT> anakron: I can't see the bug (LP is slooooow) but if it is about adding gksudo, please don't
<anakron> i think that only this option must requieres root priv
<Laney> the proper way is to use policykit to get root, right?
<RainCT> right
<Laney> for that one op
<RainCT> yep
<RainCT> anakron: please forward the bug upstream and ask them to use policykit
 * anakron learning, writting..:)
<jpds> RainCT: lies.
<anakron> ok
<RainCT> jpds: eh?
<RainCT> if that's an answer to LP being slow, I had to refresh 3 times because it always timed out -.-
<cody-somerville> RainCT, is there a dbus interface to editing xserver configuration?
<cody-somerville> If not, policykey can't magically work
<RainCT> cody-somerville: Dunno, both dbus and policykit are topics into which I still have to digg in. But in any case, it shouldn't be too difficult to create it, or?
<cody-somerville> Take a look at this bug: https://bugs.edge.launchpad.net/ubuntu/+source/startupmanager/+bug/238499
<ubottu> Ubuntu bug 238499 in startupmanager "startupmanager doesnt use policykit" [Wishlist,Confirmed]
<bersace> Hi
<bersace> When will the inclusion window be closed ?
<RainCT> cody-somerville: so, can't they create a dbus interface for that?
<RainCT> and, is there some human-readable dbus tutorial? last time I looked at dbus I didn't understand anything :P
<cody-somerville> RainCT, I dunno. However, saying folks can't use gksudo or whatever doesn't sound right to me.
<RainCT> cody-somerville: they can't use gksudo because that is only a minor feature of the application
<cody-somerville> nvidia-settings?
<RainCT> yes
<cody-somerville> It never seemed to work for me unless I ran it as root.
 * cody-somerville thinks we should bug superm1 about this.
<RainCT> I use it everyday myself and it works fine..
<james_w> if anyone with a bit of KDE/CMake knowledge want to take a look at bug 336295 that would be great
<ubottu> Launchpad bug 336295 in vtk "Changes needed for python2.6 transition" [Undecided,New] https://launchpad.net/bugs/336295
 * JontheEchidna takes a peek
<bddebian> Hey folks, how deep of freeze is Jaunty in now?
<directhex> feature freeze
<geser> Hi bddebian, we are already in FF
<directhex> last time i checked
<bddebian> Hmm, so I'm screwed for a new lordsawar upstream eh?
<directhex> you could file a FFe request
<sebner> bddebian: or is it bugfix only?
<bddebian> Mostly bugfix but I'll ask him
<directhex> hm, nobody got around to updating nvidia-glx-180 to a stable release on intrepid. so when my new pc is fixed, i need to upgrade to jaunty or wait... :/
<RainCT> directhex: it is in intrepid-updates
<directhex> RainCT, 180.11, a beta missing lots of hardware support, is
<RainCT> ah
<alex-weej> The following packages have unmet dependencies.
<alex-weej>   python-tagpy: Depends: python (< 2.6) but 2.6.1-0ubuntu1 is to be installed
<alex-weej> E: Broken packages
<RainCT> directhex: then update it :)
<alex-weej> i have python 2.5 on my jaunty system
<alex-weej> why is it whingeing?
<directhex> alex-weej, because "python" version 2.6 is not "python-2.5"
<RainCT> alex-weej: because python is a package dependency on python2.6
<geser> alex-weej: because of the python 2.6 transition
<alex-weej> so how do we fix this?
<geser> rebuild
<alex-weej> python-tagpy?
<geser> give my a minute
<RainCT> yes
<geser> yes
<alex-weej> geser: you're going to do it?
<geser> I can
<alex-weej> thanks!
<RainCT> directhex: does the stable release have performance improvements or something?
<JontheEchidna> james_w: With your patch it got past cmake just fine
<JontheEchidna> in pbuilder at least
<directhex> RainCT, well, hardware support, lots of bug fixes in vdpau... opengl 3 support
<JontheEchidna> james_w: this is at the start that it's supposed to fail at, correct?
<RainCT> and does it  build on intrepid?
<directhex> RainCT, i don't see why it wouldn't, but i'd be uneasy about touching that stuff without tseliot
<tseliot> directhex: what's up?
<directhex> tseliot, nvidia 180 in intrepid
<tseliot> aah, the SRU
<tseliot> actually I wanted to file a backport request about it
<tseliot> but I haven't had the time yet
<directhex> tseliot, $DEITY-willing i'll have my pc up & running within a week... but there's no driver in intrepid for the 216-core gtx260 yet :p
<tseliot> directhex: would you like to file the backport request yourself? The driver in Jaunty should just work with Intrepid
<directhex> tseliot, no extra mucking about needed? whatever happened to that huge ubuntu-restricted-modules source package with every little thing in it?
<tseliot> directhex: well, there was a reason if I split nvidia from the l-r-m and moved to DKMS too ;)
<tseliot> maintenance is a lot easier now
<james_w> JontheEchidna: no, it fails later for me
<geser> alex-weej: [ubuntu/jaunty] tagpy 0.94.5-2ubuntu1 (Accepted)
<Rhonda> Hi. I would like to have someone to speak to with respect to the required security-related updates for wesnoth in releases other than jaunty (which was synced already).
<james_w> hi Rhonda
<james_w> Rhonda: is there a CVE for it?
<Rhonda> I'm willing to prepare the patches but have absolutely no clue about the procedures on getting it to the right people to have it done.
<Rhonda> james_w: Yes, it's in the changelog for 1:1.4.7-4 in jaunty.
<Rhonda> CVE-2009-0367 (which also requires a change to one campaign to make it still work) and CVE-2009-0366
<james_w> Rhonda: https://wiki.ubuntu.com/SecurityUpdateProcedures is documentation on the subject, but it's a mix of things that you have to do and things you don't need to care about, which is unfortunate
<Rhonda> I did backport the required changes for Debian last week to also 1.4.4 and even 1.2, so I am quite confident that I can help with getting things done within Ubuntu - just I don't know the procedures, and I don't want to have these problems still open here.
<Rhonda> james_w: If I have someone in the Ubuntu team to discuss with that does the Ubuntu part and I only do the source patch preparation that would be extremely convenient, I guess.
<Rhonda> It's not that I totally object to dig into ubuntu pracises, it's just that I so rarely need them that it costs me quite some effort ... to forget it until the next time something would pop up again. :/
<ploum> hello
<ploum> I'm trying to make my debian package
<ploum> so far all seems to be relatively fine but I have the following error :
<ploum>  dpkg-genchanges: failure: cannot read files list file: No such file or directory
<ploum> does it ring a bell for anyone ?
<james_w> Rhonda: that's certainly possible
<james_w> there's a mess of different versions in different releases though, which complicates things
<Rhonda> james_w: 1.4.5 (intrepid) and 1.4 (hardy) aren't that big of a problem, not sure wether 1.2.6 (gutsy) is still needed, but yes, dapper version looks a bit messy to me.
<alex-weej> geser: does tagpy include the python bindings?
<geser> alex-weej: yes, that's the source package for it
<james_w> Rhonda: it's more the version skew between pockets that concerns me
<alex-weej> cool. cheers
<geser> alex-weej: you just need to wait till it gets build and appears on your mirror
<alex-weej> k will wait it out
<Rhonda> james_w: Not sure what you mean with that. Pockets?
<james_w> Rhonda: as well as the "release" pocket we have "-security", "-updates", "-proposed" and "-backports", so there can be multiple copies of the code to update for each release in essence
<james_w> https://launchpad.net/ubuntu/+source/wesnoth shows all the versions in supported releases at the top
<Rhonda> james_w: dapper + dapper-updates aswell as gutsy and gutsy-updates have the same versions.
<Rhonda> I'm at http://packages.ubuntu.com/search?keywords=wesnoth-server  ;)
<james_w> you don't need to worry about that too much, as we have various rules, and try and reduce the duplication at the same time, it will just take me longer to work out what to patch :-)
<Rhonda> .. and about the backports version, I guess the easiest fix is taking the update for the backport, not?
<Rhonda> I mean, that's also what I did in Debian for its backports versions.
<james_w> yeah, we can ignore backports to start with
<james_w> hardy is easy enough
<james_w> https://edge.launchpad.net/ubuntu/hardy/+source/wesnoth/1:1.4-1
<ScottK> Generally for backports we just do a new backport in Ubuntu too.
<james_w> gutsy too
<james_w> https://launchpad.net/ubuntu/gutsy/+source/wesnoth/1.2.6-1ubuntu2.4
<james_w> if you can supply patches that will apply to those two versions then we can get them updated easily enough
<Rhonda> Sure thing.
<james_w> intrepid is harder because there is something in -proposed, I'll see what the rules are for that
<james_w> it's bug 287158 for that, which is without confirmation for a month
<ubottu> Launchpad bug 287158 in wesnoth "wesnoth crashed with SIGSEGV in malloc()" [Medium,Fix committed] https://launchpad.net/bugs/287158
<Rhonda> james_w: Yeah, once again pochu didn't notify me about that one.  %-/
<Rhonda> Hmm, wait, I've seen that bugreport. Ah, right, it's fixed in 1.4.6 (or 1.4.7) so it didn't bother me too much, frankly spoken.
<pochu> Rhonda: which one?
<pochu> Rhonda: aren't you subscribed to wesnoth in Ubuntu?
<Rhonda> In the meantime I am. :)
<pochu> Rhonda: and I'm using Debian in my desktop and don't have Ubuntu handy (other than VMs) so I'm afraid I may not be of much help anyway...
<Rhonda> No worries, and sorry, didn't want to badmouth you with that.
<Rhonda> I'm very happy that we finally managed to get together more properly. :)
<james_w> Rhonda: I can't find documentation of the best way to proceed there, so the best thing may be to leave Intrepid until a security team member is around
<james_w> as for dapper, it's 1.0.2-0ubuntu1.2, which it doesn't sound like you have backported to, is that version affected?
<Rhonda> Depends. Did configure get called with --enable-python? If so it is for the python bug.
<Rhonda> ... which is the more severe.
<james_w> it's not clear
<james_w> there's no explicit --enable-python or --disable-python as far as I can see
<james_w> and no build log any longer it appears
<Rhonda> 1.3.1 was the first version that had python enabled by default.
<Rhonda> So if there is no explicit --enable-python it can be assumed that it isn't.
<james_w> the only thing is that the changelog mentions adding "python-dev to Build-Depends so that the python API is available", is that related?
<Rhonda> hmmm
<Rhonda> I'll take a closer look - after cooking. :)
<Rhonda> Thanks so far, I'll keep you updated. You can expect first patches propably tomorrow (CET here)
<james_w> Rhonda: I've got to disappear soon I'm afraid. Basically if you file a bug against wesnoth, explain the issue, including CVE numbers, and then subscribe the "ubuntu-universe-sponsors" team, and attach any patches you have, then we can work from there
<Rhonda> james_w: Will try that - and have a nice evening too (I guess it's evening for you, too)
<james_w> it is, thank you, enjoy your cooking
<geser> a good idea would be to also subscribe motu-swat and ubuntu-security
<Laibsch> Hi
<Laibsch> Can somebody please push bug 335891 ?
<ubottu> Launchpad bug 335891 in audacious "[jaunty] audacious crashes immediately" [High,Triaged] https://launchpad.net/bugs/335891
<Laibsch> It's about as little work for fixing any bug you'll ever find
<Laibsch> debdiff included
<cristi> hy! i am just getting started, still reading some of the documentation. However i don't understand something. It says that i should make a ssh key in order to upload to launchpad. Where exactly am i supposed to upload the key?
<cristi> i mean what is the remote host's adress
<directhex> cristi, https://launchpad.net/~yourlpname/+editpgpkeys
<superm1> cody-somerville, about what?
<cody-somerville> superm1, about running nvidia-settings as root
<cristi> directhex: bless you
<superm1> cody-somerville, i think its better to get it policykit ified
<superm1> although someone from the ubuntu side would likely have to write the patch and submit it to them.  i dont think they're generally too keen on feature requests
<superm1> looking at scollback looks like thats what someone already suggested
<superm1> it's the right solution.
<RainCT> OT, does someone know where to get an ipk package for irssi?
<superm1> likely need to switch nvidia settings to use xkit first though
<superm1> once it's using xkit, then it's a matter of moving that code into a backend for dbus to operate with
<cristi> directhex: and how do i connect? i tried ssh myaccnmb@launchpad.net and i got refused on standard port
<fabrice_sp> RainCT, about bug #330392.
<ubottu> Launchpad bug 330392 in tellico "[merge request]Please merge tellico 1.3.5-1 (universe) from Debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/330392
 * RainCT looks
<RainCT> fabrice_sp: yes?
<fabrice_sp> did you do something with it?
<superm1> anakron, so if you want a little project, i'd say go ahead and write a patch to convert to using xkit, otherwise it'll probably just live in nvidia's bucket for a bit
<RainCT> Nope
<fabrice_sp> ok. as we are post FF, I need to fill a FFe
<Rhonda> hmmm, what would be the proper version string, distribution and urgency for the wesnoth fix for hardy? (1:1.4-1ubuntu1) hardy-security; urgency=high?
<directhex> ubuntu ignores urgency
<a|wen> Rhonda: what is the current version in hardy?
<Rhonda> 1:1.4-1
<a|wen> Rhonda: i would go with 1:1.4-1ubuntu0.1
<Rhonda> directhex: Well, then it still can help as a hint to the users, not?
<Rhonda> Thanks.
<a|wen> Rhonda: we usually avoid it
<a|wen> Rhonda: https://wiki.ubuntu.com/SecurityUpdateProcedures ... look at the template for the changelog
<ScottK> It doesn't hurt, but it make no actual different.
<savvas> anyone taking care of aptoncd ?
<savvas> for the python transition I mean
<savvas> hm.. good candidate for me :P
<RainCT> damn.. why are there no mips .ikp packages for screen and irssi.. :P
<RainCT> *ipk
 * directhex throws slugs at RainCT 
 * RainCT moves directhex a few places upwards in his blacklist :)
<savvas> I think aptoncd just needs a rebuild - testing currently
 * RainCT has a shot at pykaraoke
<savvas> aptoncd builds fine - just needs a rebuild: http://launchpadlibrarian.net/23268539/buildlog_ubuntu-jaunty-i386.aptoncd_0.1.98-0ubuntu4~ppajaunty1_FULLYBUILT.txt.gz
<savvas>  Depends: python-central (>= 0.6.11), python2.6, libgnomevfs2-0, genisoimage | mkisofs, apt-utils, synaptic (>= 0.57.7), python-gnome2, python-apt, python-glade2, python-dbus, lsb-release, gksu, python-gtk2, gnome-icon-theme
<jcfp> Is there any special procedure or team to notify for all those python 2.6 related bugs?
<RainCT> why is there python2.6 and not "python (>= 2.6)"?
<RainCT> (imho that's actually a good thing, just asking)
<savvas> no idea, I didn't touch the source :)
<RainCT> jcfp: Afaik no. Only this info message: http://paste.debian.net/29528
<RainCT> (from doko)
<savvas> RainCT: Depends: ${python:Depends} and XB-Python-Version: ${python:Versions}  - it uses setup.py to build
<savvas> hm..
<savvas> python$* setup.py build
<savvas> nice :P
<RainCT> ScottK: I have pykaraoke ready
<RainCT> also ScottK2
<ScottK> OK.
<ScottK> So do I.
<ScottK> RainCT: Yours is more than a no-change rebuild?
<RainCT> ScottK: Yes, no-change will place stuff into /usr/local
<RainCT> so it needs the --install-layout=deb
<ScottK> Yes.  That's what I have too.
<savvas> ScottK: is there a bug report that could track requests for a simple rebuild?
<ScottK> savvas: Not generally no.  In this case there was one.
<savvas> ah oko
<RainCT> So who uploads? :P
<savvas> *ok :)
<ScottK> RainCT: I guess go ahead and upload yours, but next time please assign yourself the bug so we don't duplicate work.
<RainCT> ScottK: OK, it's up. I tried, but the page didn't open (two timeouts until I got it a minute ago).. :(. I mentioned that I was working on it here, though
<savvas> anyone working on envyng-core ?
<ScottK> savvas: I'd leave that for tseliot.
<ScottK> OK.
<savvas> cool
<savvas> I think it just needs a simple rebuild as well, haven't tested it
<RainCT> (in case someone else is also suffering Launchpad's slowness and is a beta tester, switching to production makes it much faster)
<savvas> RainCT: here's fast :)
<RainCT> savvas: are you on edge?
<savvas> yep
<RainCT> weird
<savvas> which link is weird?
<savvas> er.. slow? :P
<RainCT> all sorts of bug reports
<savvas> this one? https://bugs.edge.launchpad.net/ubuntu/+source/envyng-core/+bug/292173
<ubottu> Ubuntu bug 292173 in envyng-core "Envy won't start at all in final Ubuntu 8.10 x64" [Medium,In progress]
<savvas> it seems fine here
<RainCT> I've disabled edge for now
<savvas> anyone working on hplip ?
<savvas> ah doko took care of it
<Rhonda> james_w: When you see this in your away log, #336396 contains the patch for gutsy, am working on hardy patch now.
<Laibsch> ScottK: Thank you for taking a quick stab at pykaraoke.  Can I maybe get you interested in the other python 2.6 related problem I documented in bug 331461?
<ubottu> Launchpad bug 331461 in python-defaults "python2.6 support/defaults in jaunty" [Undecided,New] https://launchpad.net/bugs/331461
<tseliot> savvas: yes, that's a bug which I think I fixed sometime ago but I can't find my code. I'll have a look at it (it affects only users who have 2 nvidia cards)
<Rhonda> james_w: ... and #336406 for gutsy. :)
<Rhonda> hmm, was the other way round actually, #336396 was for hardy, not gutsy.
<geser> Rhonda: just for you information: you can mark a bug affecting several releases, no need to open a bug for every Ubuntu release
<Rhonda> geser: There is different patches needed for the different releases.
<savvas> tseliot: hi, what bug? I just saw that python needs to be transitioned to python 2.6 and envyng-core is one of them :)
<Rhonda> But yes, feel free to merge them if that works for you and won't end in a mess if it's fixed for one release but not for the other. I just don't want to get it forgotten because of some workflow problem.
<tseliot> savvas: https://bugs.edge.launchpad.net/ubuntu/+source/envyng-core/+bug/292173
<ubottu> Ubuntu bug 292173 in envyng-core "Envy won't start at all in final Ubuntu 8.10 x64" [Medium,In progress]
<tseliot> savvas: ok if you were referring to the transition to python 2.6 and you want to do it yourself you're welcome ;)
<geser> Rhonda: you can attach several patches to a bug :) as long as the patch description tells which one is which there is no problem
<savvas> tseliot: I'm not a motu unfortunately, but I've looked at the code, I think it just needs a rebuild - I can try it in PPA if you want to :)
<geser> Rhonda: I leave it up to james_w how he wants this handled
<tseliot> savvas: it's just a matter of modifying the debian/rules. I think I can do it, thanks.
<savvas> alrighty!
<Rhonda> geser: I'm not confident with ubuntu handling of stuff, at all. I just want to have the issue solved and try to offer my best. Sorry to not have studied the practices before, but I guess that's still alright.
<ripps> I've created a dshowserver (coreavc-for-linux) package in my PPA, but the code won't compile on amd64, the wiki says to compile the programs with a STATIC parameter and it will work on 64 bit arch's. How do I get the installation script to change it's procedure when the arch is 64 bit.
<ripps> ^ to clarify: how to install precompiled binaries in PPA.
<geser> Rhonda: no problem, it's still alright the way you do it, I just wanted to help you to ease it a bit
<bekks> hi
<ripps> How do I setup my PPA package to compile on one architecture and use precompiled on another?
<geser> not at all
<geser> it must be build from source on every architecture
<bekks> geser: juliux told me to contact you if dholbach isnt around - may i query you?
<ripps> geser: my package doesn't build on amd64, it must be compiled with STATIC on a i386 to work on 64 bit.
<geser> bekks: sure
<geser> ripps: and how does upstream build the precompiled binaries?
<ripps> geser: like that, they tell 64bit users to compile on i386 with static or use a precompile package they supply.
<geser> ripps: ah, so the amd64 users us the i386 binaries?
<ripps> geser: I guess so, but that makes it difficult to use with PPA.
<ripps> http://code.google.com/p/coreavc-for-linux/wiki/DshowserverInstall
<geser> ripps: then you need to build the i386 binaries on amd64 again (cross-compile)
<ripps> geser: how do I do that?
<geser> ripps: I'd avoid it at all and only offer an i386 deb
<ripps> geser: That's currently what I'm doing, I just wanted to make easier for those just adding my PPA apt line to their sources.list.
<savvas> some of the servers for gb.archive.ubuntu.com seem faulty - where do we report this?
<jpds> savvas: To Datahop.
<savvas> datahop at ubuntu.com ?
<jpds> savvas: datahop.com - they run the gb.a.u.c servers.
<savvas> oooh, ok thanks :)
<ripps> How do I compile a single architecure-independent package to be used with all architectures?
<lifeless> ripps: you don't
<lifeless> ripps: sorrry, i read archiecture-dependent, my bad
<ripps> lifeless: Oh, I thought it was possible. I keep seeing packages that have -all instead of -i386 or -amd64
<lifeless> ripps: yes, it is possible, I just misread your question
<lifeless> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture
<lifeless> summary - all -> one binary for all platforms, any -> one binary per platform works on all platforms
<ripps> lifeless: will this work with PPA's?
<lifeless> yes
<lifeless> but building the package you were describing before as a binary-all package is a bad idea
<lifeless> in case thats what you were thinking of doing
<ripps> lifeless: why, if I build it as static, shouldn't work on both i386 and amd64?
<lifeless> for starters, static packages need strong justification because of the security problems involved
<geser> arch:all packages also install on sparc, powerpc, hppa, armel, lpia
<lifeless> we have 32 bit libs available on amd64
<geser> and only on lpia you might have success running the binaries
<lifeless> secondly, as geser says, all is much more than i386 and amd64
<ripps> should I create a seperate package that uses static and specificallly builds only on amd64.
<ripps> no, that won't work...
<lifeless> you should start by filing a bug with upstream :) - its bad not being able to rebuild the someware one is using, and as an amd64 user I'd need a really good reason to install something I can't rebuild
<lifeless> you should be able to get the package to build on amd64 using -mi386 and other such configure flags, with appropriate dependencies
<lifeless> though multiarch isn't finished, it will depend on what you need
<ripps> Upstream is working on it, but work seems to be slow. They haven't made any updates in a long time.
<ripps> "gcc -mi386" in the makefile?
<ripps> If I don't have a amd64 machine, then I can't test the package with pbuilder, can I?
<andersk> Is anyone available to look at the sync request in bug 289921?
<ubottu> Launchpad bug 289921 in open-vm-tools "network interface does not come up after installing open-vm-tools" [Undecided,Confirmed] https://launchpad.net/bugs/289921
<DBO> hello MOTU's
<DBO> is there a document someone to go about getting an FFE for GNOME Do
<DBO> we have another release coming out in a day or two that fixes a lot of crashing bugs
<pochu> !featurefreeze
<ubottu> Sorry, I don't know anything about featurefreeze
<Laney> did banshee release?
<pochu> !ffe
<ubottu> uvf is Upstream Version Freeze.  For an exception, see https://wiki.ubuntu.com/FreezeExceptionProcess#head-9523bc4076ff011324d67cddc97969ec609618d6
<geser> https://wiki.ubuntu.com/FreezeExceptionProcess
<pochu> DBO: check out that link ^
<DBO> thank you all
<DBO> pochu, geser do any of you know anyone familiar with packaging mono apps?
<geser> iirc directhex is familiar with mono packages
<pochu> RAOF usually takes care of gnome-do I think, but he's not around right now
<DBO> yeah he does
<DBO> I am one of the developers of Do
<Laney> Oh
<DBO> we are looking to get 0.8.1 in ubuntu since 0.8.0 has some really nasty crashers in Docky
<Laney> He asked me to do the packaging
<Laney> it's no problem
<DBO> but with RAOF gone right now
<DBO> Laney, oh really? =)
<Laney> oh yes
<DBO> I am happy
<Laney> got a changelog link/
<DBO> we are gearing up
<DBO> it will be within 24 hours
<Laney> I thought it waited for Banshee?
<DBO> so I was coming here to figure out how we went about getting this into jaunty, I didn't know RAOF already hooked it up
<DBO> Laney, we can actually release before then since we develop against banshee svn
<DBO> but you probably wont get a working build until banshee releases
<Laney> ok
<DBO> i thought they were releasing yesterday
<bddebian> Do I need to request a sync and then an FFe or just an FFe for a new upstream release?
<pochu> bddebian: FFe first, and if it's accepted you can sync it
<pochu> bddebian: btw I went yesterday through libsoup2.2 rdependencies and got this: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libsoup2.2;users=pkg-gnome-maintainers@lists.alioth.debian.org
<pochu> we may be able to remove it from the archive soon :)
<bddebian> Sweet, I like RM:s :)
<ScottK> bddebian: Speaking of which weren't you trying to port cstim to a later wxwidgets?
<ScottK> err ctsim
<bddebian> I tried
<bddebian> Who do I need to subscribe to the FFe?
<ScottK> motu-release.
<ScottK> Unless it's in Main.
<bddebian> OK, thx
<bddebian> Actually ctsim is going to have worse problems when we drop Gtk1.2 :)
 * bddebian is such an Ubuntu loser anymore
#ubuntu-motu 2010-03-01
<mohadib> hello
<mohadib> im building a deb to hopefully be included in ubuntu
<mohadib> i am making an ant file for the package
<mohadib> my pacjage depends on swt-gtk, and needs it to compile
<mohadib> should i refrence where apt put the swt lib in my ant file?
<mohadib> or should i include the lib? im pretty confused
<persia> You should reference the system library.
<mohadib> ok, thanks
<persia> Ideally, your package won't contain any libraries, and just use the system libraries.
<mohadib> aye, i made one that does that
<mohadib> but i was told i did it wrong
<persia> The normal way to do this is to set up ant to not care which one is used, and to set the CLASSPATH in debian/rules
<mohadib> and i got to use dh_make and all this stuff
<persia> Please don't use dh_make :)
<mohadib> ok
<mohadib> i have a java app i want to package
<mohadib> can you tell me the most straight forward way to do it?
<mohadib> i have 100 conflicting answers so far
<persia> Hrm.
<persia> So, I have an opinion as to which I think to be the easiest.
<persia> But that's not necessarily the easiest for *you*
<mohadib> please to share it :)
<mohadib> ah
<persia> There's no true way to package :)
<persia> As long as the result package is policy-compliant, it is correct.
<mohadib> do i have to submit source and a make file so ubuntu can compile it?
<mohadib> i cant just submit a jar?
<mohadib> :S
<persia> I tend to recommend not using dh_make because it leaves around lots of extra files and sets some incorrect defaults.
<persia> A source jar is fine :)  But we need to compile it to ensure that the binaries released match the source.  Otherwise we can't know that we can fix bugs in it.
<mohadib> ah
<mohadib> so the idea is to submit a source package with directions to build and install?
<persia> Well, directions to build/install, licensing documentation, and hints on how the package relates to other packages.
<mohadib> i see
<persia> We encode these in the debian/rules, debian/copyright, and debian/control files.
<mohadib> ok, so i hsould have rules call ant?
<persia> We also have a debian/changelog file that tracks changes to the package.
<persia> Right.
<persia> There's lots of different ways to do this.  My current favorite is to use /usr/share/doc/debhelper/rules.tiny for debian/rules
<mohadib> http://openactive.org/pastebin/paste/show/6
<mohadib> does that look ok for rules?
<persia> This will call dh_auto_clean, dh_auto_configure, dh_auto_build, and dh_auto_install to make a best guess as to how to build the package.
<persia> You'll need a clean: rule.
<persia> clean: should return the package to the state it was in prior to the build.
<persia> This usually involves a call to `ant clean` or similar.
<mohadib> ok thanks
<nigelb> A few of the sugar packges have been deleted from karmic and lucid, but the deps are failing rebuild.  Okay to request removal of all of them?
<persia> nigelb: Why were they removed?
<nigelb> we moved to a newer version
<nigelb> in lucid the version is sugar-0.88
<nigelb> but there are a bunch of .84 and .86 packages in failed to rebuild queue
<persia> That's confusing.  Why do the package names change for a version change?
<nigelb> I have no idea :(
<nigelb> sugar seems to have names based on version, sugar-0.84, sugar-0.86, sugar-0.88
<persia> My suggestion would be to investigate this.  While we both have no idea, we're not qualified to say what to do with these packages :)
<nigelb> lfaraone: thoughts on this ^
<nigelb> since you're on the sugar team :)
<nigelb> persia: I'm out of anything I can understand on umet deps and failed to rebuild :(
<persia> nigelb: What don't you understand?  I'd be happy to help for some of these things (where I know something, or generic information is likely to be correct).
<nigelb> I'll take the first unmet dep then
<nigelb> lemme load up the chroot
<lfaraone> nigelb: Uh, .86 was re
<lfaraone> *removed?
<lfaraone> nigelb: That seems odd, since .88 is still not out yet (.87 will eventually become .88)
<nigelb> lfaraone: appologies, 0.84 was removed
<lfaraone> nigelb: so what ftbfs?
<nigelb> some thing that depends on .84
<nigelb> hold on, I'll get the exact packages
<nigelb> sugar-chat-activity-0.84 and sugar-read-activity-0.84
<persia> lfaraone: Do you know why these packages have these names instead of e.g. sugar-chat-activity ?
<persia> (at a sourcepackage level: binary is entirely different)
<lfaraone> persia: because it's an activity (what sugar calls Applixations) and it is called Chat. It only works with sugar.
<nigelb> it makes it a bit different hunting through LP for it, I went by pure instinct
<lfaraone> Oh, didn't see your earlier message.
<persia> lfaraone: That explains the "sugar" and "activity" parts.  I'm presuming the binary version is important for compatibilility.  Why does it have that *source* package name?  Do we really expect parallel installations of different versions of sugar?
<persia> and is there a strong reason to support this?
<lfaraone> No idea, that's imported from Debian. I haven't done much work on sugar packaging in a while
<nigelb> persia: we can't have it anyway
<nigelb> because the main build deps are not around
<persia> nigelb: That's a different issue.
<lfaraone> persia: Well, the Peru and Uruguay deployments are on .84/.82, so no.
<ScottK> Debian does support parallel Sugar versions.
<persia> Yes.  I just don't understand why.
<lfaraone> persia: Because the maintainer, Jonas, decided to do so.
<persia> Oh well.
<nigelb> um, so what can we do now?
<lfaraone> persia: He uses git, which I find incredibily difficult to package with. Attempts to work with him in the past have been futile.
<lfaraone> nigelb: Remove the packages which depend on .84.
<nigelb> will file a bug
<nigelb> lfaraone: take a look at this http://paste.ubuntu.com/386038/
<nigelb> should I request removal of the entire bunch?
<lfaraone> nigelb: Nock yourself out :)
<nigelb> lfaraone: another of my doubts is, when sugar-0.84 is already removed in lucid, why is it showing in my apt-cache
<lfaraone> nigelb: because it's cached :)
<nigelb> ah, so I only request removal of the ftbfs?
<persia> nigelb: Better to request removal of the entire -0.84 stack, if it's not complete.  I suspect some were just missed in the partial removal effort.
<nigelb> persia: on grepping unmet, I find a bunch of sugar packages
<persia> I suspect that once you clean up the FTBFS, you'll find some in unmetdeps, and the last few will end up as (relatively) unmaintained orphans.
<nigelb> dont I have to file a request for each package individually?
<micahg> mozilla team was already going to remove sugar-browser-activity-0.84 nigelb
<persia> Well, don't remove sugar, just the old version that we know is gone :)  The rest may need a bit of work to get both 0.86 and 0.88 in good shape for lucid.
<micahg> s/remove/request removal
<nigelb> ah, well, yaay, I found something to do ;)
<nigelb> micahg: I'll do it for ya :)
<nigelb> micahg: sugar browse 0.84 isn't already removed?
<nigelb> I dont see it in my cache
<mohadib> im looking at an exmple rules file, to build it issues ant -f build/build.xml
<mohadib> for clean it calls the ant task clean that deletes ${build}
<mohadib> wouldnt that delete the build.xml file?
<mohadib> <property name="build" location="build"/>
<mohadib> that means /build in the root?
<mohadib> oh
<mohadib> its create /build/build, sorry
<persia> mohadib: /usr/share/perl5/Debian/Debhelper/Buildsystem/ant.pm has build.xml in ./ which makes me think this is a common practice.
<nigelb> okay, in case of deletion, I follow the same procedure as sponsorship? (since I'm not yet MOTU)
<ScottK> Yes.
<nigelb> thank you :)
<nigelb> bug 529824 good enough? anything more I should be adding?
<ubottu> Launchpad bug 529824 in sugar-chat-activity-0.84 "Please remove sugar-chat-activity-0.84 from Lucid" [Undecided,New] https://launchpad.net/bugs/529824
<micahg> nigelb: yep, already gone
<nigelb> micahg: :)
<persia> mohadib: You may also find #ubuntu-java to be a better place for java-specific questions.
<nigelb> oh no!
<nigelb> I accidentally subcribed main sponsers instead of universe
<nigelb> ugh! how do I fix this ugly mistake
<lfaraone> Just switch it over.
<lfaraone> No big.
<nigelb> I cant remove the main guys
<lfaraone> nigelb: Just sub univ, someone in main sponsors will sort it out.
<nigelb> okay, just did that now.
 * lfaraone is out for the night. 
<nigelb> lfaraone: good night :)
<ScottK> nigelb: Fixed
<nigelb> ScottK: thanks again :)
<nigelb> The epiphany-extensions-more is no longer being maintained and doesn't work with epiphany version in lucid, another target for removal?
<persia> nigelb: I generally try first to fix it, and only seek removal if there is some reason it cannot be fixed (which is different than there being some reason I can't fix it)
<nigelb> persia: but upstream says it won't work with epiphany 2.28 and above
<nigelb> and lucid version is now 2.29
<ScottK> That'd be good enough for me.
<persia> nigelb: That calls into "cannot be fixed" :)
<nigelb> thats what I thought too!
<nigelb> persia: If it were possible to be be fixed, I'd bug you for teaching me how ;)
<persia> I'd be the wrong person: for that bug, I'd point at micahg
<nigelb> well, anyone who could ;)
<micahg> nigelb: epiphany changed to webkit only with 2.28+
<micahg> nigelb: extensions were gecko based
<nigelb> micahg: so now, we end up having to remove it
<nigelb> micahg: it didn't work with karmic either I guess
<micahg> nigelb: wait, it seems like the extensions were ported
<nigelb> micahg: oh?
<nigelb> the gnome site said, it work anymore and they use something new, which is extremely unstable
<nigelb> http://live.gnome.org/Epiphany/ThirdPartyExtensions
<micahg> oh, nm, the regular extenions were, but the -more wasn't
<nigelb> yup
<nigelb> I did a thorough read :)
<mohadib> is this wrong? http://openactive.org/pastebin/paste/show/7
<mohadib> the deb gets made
<mohadib> but my files are not included
<mohadib> just readme and changelog, stuff created by dh_build
<mohadib> ah, think i see the problem
<mohadib> hm no
<persia> mohadib: The last paste you had included a dh_install call.
<persia> mohadib: You probably also don't want to use the cp calls (especially because they install to an unsired location)
<mohadib> well, i changed to debian/syspage/ and it seems to do what i want now
<mohadib> is ok?
<persia> mohadib: creating debian/install with http://openactive.org/pastebin/paste/show/8 adding dh_install, and dropping the cp calls should work.
<persia> If it does what you want, it's OK, but it may not be best practice :)
<mohadib> no, ill do what you said
<mohadib> thank you
<mohadib> no point in getting into bad practices now
<persia> Well, I'm not sure not using debhelper is a bad practice, but in general, debhelper makes things easier and the same model used for dh_install also works for other dh_* calls.
<persia> But I think using cp is poor practice, and if one wants to avoid using debhelper, using the "install" program is better.
 * persia notes that some of the exposition is just for those reading along
<mohadib> can i see how the files will be installed from a deb without installing the deb
<mohadib> like dpkg -L
<persia> dpkg --contents
<mohadib> ahh ty
<mohadib> that worked great, the dh_install thanks
<Anzenketh> Hello I am developing a patch for bug 529744 I have edited it on my karmic system I was wondering how to test the patch to make sure It did what I said I wanted it to do.
<ubottu> Launchpad bug 529744 in gnome-system-tools "When creating a new user, "Shortname" should really be "Username" ." [Low,Triaged] https://launchpad.net/bugs/529744
<persia> Anzenketh: I can't see the patch in the bug report.
<persia> But in general patch testing consists of 1) download or unpack fresh source, 2) apply the patch, 3) build, 4) test
<Anzenketh> Yep I just removed it forgot to so I could change karmic to lucid
<nigelb> Anzenketh: how did you get the source?
<Anzenketh> dget -xu
<ddecator> in everyone's opinion, how much programming knowledge is needed to work on patches? i'm learning basic python, and i'm wondering if by the time i'm done i'll be able to actually do any patch work
<Anzenketh> persia: So just run ./config make make install then launch it from wherever I find the binary.
<nigelb> um, no
<persia> Anzenketh: Depending on your level of familiarity with debian-format packaging, you may find other ways to work better, but that *ought* to work.  You may want to run `debian/rules patch` beforehand: this doesn't always work, but should apply any pending patches.
<persia> (or check debian/README.source for closer guidance : again this isn't always there, but it *ought* be)
<Anzenketh> ok will read README.source
<Anzenketh> the pdbuilder just though me though a loop
<Anzenketh> No clue what it is or how to use it. My familiary with debian-format packaging is close to none
<persia> Anzenketh: Then just ignore the packaging, except for applying patches.
<persia> Anzenketh: And if you're not doing the packaging, talking about patches in #ubuntu-bugs is likely more on topic.
<nigelb> persia: would it be okay if I just packaged it for him and gave credit?
<Anzenketh> Thanks for your help I will go read more of the wiki.
<persia> nigelb: Absolutely.  The usual way to do that would be for you to be listed in the changelog, and to credit Anzenketh in a comment for the specific line you add to Debian changelog when making the change.
<persia> e.g. "Patch to frob quux (thanks J. Hacker)"
<nigelb> ah, I'll get that done in a few
<Anzenketh> I almost got the fixed debdiff up there nigelb
<nigelb> Anzenketh: dont worry on errors.  I'll fix the whole thing up and give you a feedback (though I may just start afresh and credit you with it)
<persia> nigelb: Thanks for helping out the Reviewers team!
<nigelb> persia: are there any requirements to join there?
<persia> nigelb: There's ~2000 more patches in the bugtracker that could use the same attention, if you're up for hitting some of them.
<nigelb> I'm sure I can read patches well enough
<persia> nigelb: You're expected to be competent to review patches and familiar enough with Ubuntu Development to be able to get stuff uploaded.
<nigelb> bah, uploaded
<nigelb> meaning, I should have upload rights or I should have uploaded packages?
<persia> nigelb: You should be capable of getting stuff uploaded.  That can be directly or indirectly.  Doesn't matter.
<nigelb> persia: I'll help out with a few of those ~2000 patches and apply to join :)
<persia> nigelb: Some Reviewers work closely with upstreams to get stuff accepted there, and get it uploaded by the sync/merge process.  Others are Debian developers (or nascent ones) and get stuff uploaded there.  Some are Ubuntu Developers.
<Anzenketh> nigelb: I changed the changelog.
<nigelb> I'm pretty much blind on Debian Development.
<persia> Any of those are good working models: much of patch review is like bug triage, except with code rather than problems.
 * Anzenketh goes back to reading the wiki
<nigelb> I know.  I have had this team in sights for something
<nigelb> persia: I think we need an easier process for new contributors.  Like for fixing a proper bug from launchpad
<nigelb> I'm thinking of writing a small blog post based on this bug fix for future reference.
<nigelb> s/easier process/easier documentation
<nigelb> Anzenketh: okay, a few things you should remember for future.
<nigelb> each package uses its own patch system, so that any new patch can be unapplied if its not working.  When working on a bug fix, you must ensure that you write a patch under this system
<persia> nigelb: I wrote one: https://wiki.ubuntu.com/Bugs/HowToFix?action=recall&rev=16 is the most modern copy available.  Someone else made it complicated, and I haven't gotten around to fixing it yet.  Feel free to wade in if you like :)
<nigelb> this package for example, uses quilt.
<nigelb> persia: I will write a post of my own and ask for review to be included in the wiki.
<nigelb> which seems saner
<persia> Please work to fix what we have, rather than adding more.
<persia> Lots of different conflicting documents just confuse users.
<nigelb> okay :)
<nigelb> Are patching systems like quilt, cdbs used only downstream?  Or does upstream use them too?
<slytherin> nigelb: Why would upstream use a patch system?
<persia> There's no good answer to that question :)
<nigelb> I'm just asking something that just popped in ;)
<nigelb> why is there no good answer?
<persia> So, we have some systems (cdbs-simplepatchsys, dpatch) that are only used in Debian and derivatives.
<persia> Other patch systems are more widely used.
<Rhonda> nigelb: upstream as in Debian uses patch systems too, yes. :P
<nigelb> I counted debian as downstream too :)
<Rhonda> It's upstream from Ubuntu's point of view.
<nigelb> since I *know* debian uses them
<nigelb> I should framed properly
<persia> Generally patch systems are used by various distributors who are *not* the original authors, or for release that are not trunk.
<Rhonda> Ubuntu is downstream from Debian's point of view.
<persia> VCSs that support branches are often used for this as well.
<nigelb> like git having several branches
<nigelb> Rhonda: I wanted to ask from a debian standpoint.  But I framed wrongly :)
<Rhonda> I know one upstream that uses plain patch/diff as patch system, though. For carrying extra patches.
<persia> Original software authors rarely need to maintain sets of patches to their code, generally instead maintaining a single trunk source.  VCSs are commonly used to keep track of patches applied.
<nigelb> ah, that pretty much answers my question and beyond :)
<Rhonda> t-prot carries some patches in the "contrib/" subdirectory, even though the developer produces those patches himself.
<persia> Since distributors (like Debian or Ubuntu) may be pulling from the authors directly, or from some patched version distributed by a more specialised distributor, there exists no correct answer to "Does upstream use patch systems".  Debian certainly does.  upstream from there gets murky.  Original authors are unlikely to use them.
<persia> (except in special cases, as Rhonda notes)
<Rhonda> Isn't there these php patches that are also distributed seperately that gets applied?
<Rhonda> kishino or something like that? Never can remember the name.
<persia> There are.  There's also sets of patches for MAME and vim that get developed as essentially separate upstreams.
<persia> (and likely several more cases)
<nigelb> It does get really murky then
<nigelb> btw, if the new patch tagging guidelines are out, why arent all the patches according to them?
<Rhonda> persia, btw., LP #528957 about that sdl issue, it starts to pop up now from various places.  :/
<ubottu> Launchpad bug 528957 in wesnoth "mouse button clicks not detected in windowed mode" [Undecided,Confirmed] https://launchpad.net/bugs/528957
<persia> nigelb: My rule of thumb is to just submit an ordinary patch upstream unless I'm willing to act as a (nascent) upstream developer.
<Rhonda> nigelb: Because it's a guideline and not a policy must and people are lazy.
<persia> Rhonda: It's all over the place :(  Do you know if a good general solution is available?
<nigelb> persia: makes sense :)
<Rhonda> persia: Not totally sure. Maybe rolling back to 1.2.13 would be worthwhile, depending on the influence of the issue that triggered the sync in the first place. Maybe even the solution for that one could get cherry-picked, I'm unsure. :/
<nigelb> I see like 9 patches in the debian/patches directory and none of them are tagged per debian/ubuntu guidelines.  Is that normal?
<persia> nigelb: Unfortunately DEP3 has little takeup so far.
<Rhonda> persia: If I would have some more time at my hands I really would dig into git bisect and try to pin down which commit did break the click thing in sdl. :(
 * Rhonda really wonders why noone has done that so far. %-/
<nigelb> I'm going to tag if off anyway.
<nigelb> all the bugs I have worked on, I have tagged, going to keep tradition here
<persia> lool: Have you any thoughts on the matter?
<Rhonda> nigelb: Yes, that's completely normal. Like said, it's a pretty new thing, it's not enforced, lintian only recently started to mention it, â¦
<persia> nigelb: Please do tag your patches.  Please don't tag other people's patches arbitrarily.
<nigelb> persia: I dont have the patience to do that for others ;)
<persia> Excellent :)
<persia> Some people do, and it's always frustrating, because their tags are almost universally ignored or rejected when received.
<slytherin> Any members of SRU team around?
<persia> The effort is appreciated, but misdirected.  it's like uploads to Ubuntu that create a variance with Debian to only bump the standards version (with no other changes).
<persia> slytherin: SRU is consolidated: check in -devel :)
<slytherin> ok
<Rhonda> Submit such things back, maybe they are appreciated. :)
<nigelb> I have to learn debian bts one day
<nigelb> It totally scares me right now
<persia> Rhonda: Reports that e.g. Standards-Version can be bumped from 3.8.3 to 3.8.4?  Lots of people got complaints submitting stuff as bugs that was available from the PTS.
<Rhonda> Erm, yes, that doesn't make sense, I agree. :)
<Rhonda> nigelb: It's not that complicated, once you got around that it's mainly a mail interface. :)
<nigelb> Rhonda: I got that figured out only earlier today. :/
<persia> We've had folks that aggressively tested stuff and submitted that class of report.  I think we don't have any right now, but those folk aren't folk I want to share with Debian yet :)
<duanedesign> hello nigelb
<nigelb> Anzenketh: you need a little bit more of eduction with debian packing before you attempt to upload a debdiff
<nigelb> so, I would suggest uploading simple patches for now.  :)
<Anzenketh> I was not planning on doing anything besides string-fixes
<nigelb> Anzenketh: even so.  Take a look at my debdiff once I upload it.  you'll understand what I mean.
<persia> Anzenketh: I'd second nigelb's recommendations.  When I was starting, I found it was much more effective to just fix the bugs with patches, and get someone else to worry about getting it integrated and uploaded.  Looking at the differences between what I produced and what was uploaded helped me to understand how to work with packaging.
<Anzenketh> Ya the link you gave me on how to get started helped a lot
<Anzenketh> I found out what what-patch did
<lool> persia: on DEP3?
<persia> lool: On libsdl1.2 and bugs like 528957
 * lool loads
<persia> crimsun suggested that it fixed some stuff, but you did another merge, and I wonder if you'd had a chance to look at the issues that are keeping .14 out of squeeze as part of that.
<persia> Debian bug #565788 has some of the details, but I don't think anyone has really dug into it.
<ubottu> Debian bug 565788 in libsdl1.2debian-all "Upgrading SDL breaks Wesnoth" [Critical,Open] http://bugs.debian.org/565788
<persia> Right now, we have a situation where some stuff seems broken with .13 and other stuff with .14 and we're shipping .14
<lool> I only merged packaging changes AFAIR; the previous merge had been from experimental and mine was from unstable, I was a bit surprized to see we picked up an experimental package for lucid though
<lool> I personally have many weirdnesses with mouse clicks
<persia> Oh well.  I have a feeling crimsun has far to much already needing to be looked at for lucid.  Maybe someone else can find time to track down the issue.
<lool> I think that someone should talk with SDL upstream mentionning imminence of debian and ubuntu releases affected by this bug and perhaps others
<persia> lool: In apps other than wesnoth, but using SDL, or generally?
<lool> I'm not on top of sdl bugs, sorry; it fixed a static build issue for me
<lool> In one SDL app and generally
<persia> No worries.  I was just hoping that you'd noticed when you merged.
<nigelb> Anzenketh: deleting your patch and uploading my debdiff
<Anzenketh> ok
<persia> nigelb: We usually leave the original patches in the bug for the historical record.
<nigelb> persia: oh no!
<Anzenketh> Ya it does look differnt.
<nigelb> persia: I'll make sure I dont do that next time.  anything to be done now?
<persia> nigelb: Adding a comment when uploading your debdiff like "debdiff applying Anzenketh 's patch" makes it extra clear for sponsors.
<persia> nigelb: Just follow the same procedure as if you're getting your own fix uploaded.
<nigelb> I never wrote a simple patch :(
<nigelb> I never got to learn how to do that
<persia> Read revision 16 of Bugs/HowToPatch :)
<persia> (or any earlier revision, but 16 is the most polished before the attack of the debdiff instructions)
<Anzenketh> Attack of debdiff instructions?
<nigelb> Anything I can do now to rectify the situation
<persia> nigelb: Not really.  Needs discussion.
<persia> Anzenketh: There are continual efforts to update the wiki.  At one point the instructions to create a simple patch were overwritten with instructions to create a debdiff for a candidate upload.  This was done to reduce the number of different ways we instructed people to do things.  Unfortunately, it's a lot more complex to create a candidate upload than to create a patch.
<persia> Until we sort our the procedures and processes for handling different categories of code contributions, it's hard to change the documentation to match current practices.
<nigelb> yea, like patching system, tagging - all needs to get integrated
<persia> So I've not changed it back until more discussion happens (my last email on the subject was in December, but only got one reply)
<persia> nigelb: Right.  I don't think everyone who contributes code should need to learn that stuff, but I do think anyone who wants to be an Ubuntu developer should.
<nigelb> persia: yup.  everyone generating debdiff should know
<persia> I think lots of people agree with that, but there are many people who think we shouldn't have two completely different procedures for code contributors, and that all code contributors should be treated the same.
<persia> That debate is not yet concluded.
<nigelb> In my case maco_ was kind enough to teach me.  So i know.
<nigelb> persia: could you unsubsribe reviewers? I've subscribed main sponsers
<persia> No, but I'll see if I can fix things so I can next time :)
<Anzenketh> So if the current instructions are wrong what are prospective developers to do?
<persia> Anzenketh: Right now, prospective developers are told they have to learn how to make debdiffs.
<persia> And random folk submit random patches that the reviewers review.
<nigelb> persia: the reviews team wiki seems to indicate the same thing
<persia> nigelb: Which thing?
<nigelb> "For patch authors who can't upload yet we have the SponsorshipProcess. Unfortunately, there's also a big list of bugs with patches that are not following the process. Likely, because they are not aware of it. "
<nigelb> Everyone is expected to use sponsorship.  Not just give a patch.
<persia> Oh, yeah.
<persia> I personally disagree strongly with that.
<persia> I don't think everyone needs to do that.
<persia> It's too much work, and most folk just give up because it's hard.
<nigelb> exactly
<nigelb> that isn't fair to prospective contributors
<Anzenketh> I don't even know how to do the sponcership process.
<persia> But I'm not going to overwrite someone's wiki changes without discussion, and I only try to restart the discussion every few months.
<Anzenketh> Directions on that are not verry clear either.
<nigelb> its pretty easy, once you have a debdiff, subscribe sponsors depending on where your package is
<persia> Anzenketh: Don't worry about it.  if you can make patches, submit them and pretend you didn't read the wiki.  Folk like nigelb will be happy to help get those to the right place (sometimes Ubuntu, sometimes upstream, sometimes Debian, sometimes all three).
<Rhonda> persia, I know nothing about gnome-app-install, can you take a look at #82436 with respect to wether gnome-app-install (still?) wants to pull in the wesnoth-core package instead of wesnoth?
<persia> But a discussion of how to create/submit patches *not* using the sponsorship process really doesn't belong here.  it belongs in #ubuntu-bugs (or maybe somewhere else, if there's a channel I don't know about).
<Rhonda> The bug is still open for that somehow.
<persia> bug #82436
<ubottu> Launchpad bug 82436 in gnome-app-install "wesnoth-all meta-package request (for gnome-app-install)" [Undecided,Confirmed] https://launchpad.net/bugs/82436
 * persia suspects that's really a bug in app-install-data-ubuntu
<persia> Or not.  Seems I said gnome-app-install last time I investigated it :)
<Rhonda> :)
 * Anzenketh just relized what they ment by subscribe
<persia> Rhonda: I think that bug doesn't matter anymore.  software-center seems to look at app-install-data, which has the correct package hint to install "wesnoth" rather then "wesnoth-all" or "wesnoth-core".
<persia> And this is unlikely to be fixed as a stable release update.
<persia> So, I think gnome-app-install still has a bug, but I suspect it won't be fixed, and that most users won't encounter it.
<Rhonda> I encounter it in my bugs page. :)
<persia> Which page?  I think that's a bug.
<Rhonda> bugs.lp.net/~rhonda shows it to me everytime I go there
<Rhonda> It's the only five-digit bugnumber on my page. :P
<persia> Aha.  It's there because you commented on it.
<persia> Rhonda: mvo is looking at it, and will apparently sort it.
<Rhonda> persia: I commented it because it was also a wesnoth bug. :)
<Rhonda> It's a bit annoying that one can add "also-affects" but can't remove that anymore it seems. :/
<nigelb> Rhonda: we can :)
<persia> There's a bug open about that.
<persia> nigelb: No, we can't.
<Rhonda> â¦
 * Rhonda nibbles on nigelb. :)
<persia> nigelb: We can reassign, but never remove.
<nigelb> okay, so the last time I did that was quite a while back then
<persia> No, you've never been able to do it :)
 * nigelb got confused with "also affects me" and and "also affects project"
<persia> Well, one could reassign to no package, but that just destroys (likely valid) history.
<persia> heh
 * nigelb notes that Rhonda didn't really elaborate which affects-me it was
<Rhonda> nigelb: Then again, one can't unsubscribe from bugs that one got subscribed through other means, this is also a long-standing bug.
<Rhonda> I got told of to have set that bug back from Triaged to Confirmed because nothing at all happened in over a year â¦  But it's annoying to have it in a state that says "yeah, we know how to do it" for such a long time without any progress, at all. :(
<nigelb> Rhonda: you have a clean bugs.lp page?
<persia> It's bug #204980
<ubottu> Launchpad bug 204980 in malone "bug contacts should be able to unsubscribe from implicit subscriptions" [High,Triaged] https://launchpad.net/bugs/204980
<persia> And bug #484319
<ubottu> Launchpad bug 484319 in malone "Add unsubscribe link in bug mail for structural and implicit subscriptions" [Low,Triaged] https://launchpad.net/bugs/484319
<Rhonda> nigelb: What do you mean with a "clean bugs.lp page"?
<nigelb> Rhonda: everything fix released only ;)
<nigelb> except for this one probably
<Rhonda> No, but like said, this is the only 5 digit issue. :)
<nigelb> oh, is there a difference in number of digits for different bugs?
<Rhonda> I never will have a clean page, that's totally out of scope with that much interests on my hands.
<nigelb> I didn't know
<Rhonda> Sure, there is even LP #1  ;)
<persia> nigelb: fewer digits indicate older bugs.
<nigelb> oh, so this must be really old and ticking you off somewhat ;)
<Rhonda> It in fact is because _I_ did my part of fixing the issue. :)
<Rhonda> Given that LP seems to want to track the same bug in multiple packages not as seperate bugs but rather merges all the packages into it it can get easily annoying, especially since one can't unsubscribe from implicit subcriptions anymore.
<nigelb> haha
<Rhonda> nigelb: You might laugh, it was the thing that got me unsubscribing from irssi because of that multitude-merged perl transition bug that affected tons of packages and I received lots of mails that were totally unrelated to irssi.
<persia> And weren't technically the same bug, but rather the same *class* of bug.
<nigelb> that isn't fun
<nigelb> but look at me, I'm subscribed to rhythmbox.  I'll get mails like ubuntu cheated me of my money, I didn't get my mp3 and they kill kittens
<Rhonda> sigwtf, bug #493299
<ubottu> Launchpad bug 493299 in irssi "irssi does not show notification bubbles" [Undecided,New] https://launchpad.net/bugs/493299
 * Rhonda now is happy to have unsubscribed from irssi all together. â¦  %-)
<persia> Rhonda: Just mark it duplicate to 493297.
<Rhonda> Sure, but â¦ wtf :)
<nigelb> no one packaged it?
<Rhonda> It's a terminal based irc client! libnotify??!
<Rhonda> The world is going crazy. :)
<nigelb> lol, but most users use the libnotify script for irssi
<Rhonda> I extremely highly doubt that.
 * arand does..
<Laney> I doubt that you could ever have evidence to support that, even if it were true
 * nigelb edits
<nigelb> Many irssi users tend to use libnotify scripts for irssi
<Laney> Some ...
<Laney> and regardless, that doesn't make it a bug in irssi
<Rhonda> I still don't buy the "many"
 * nigelb edits to "Some"
<nigelb> and I agree, it does not make it a bug
<Rhonda> In xchat, yes. In kopete, yes. But â¦ hell, irssi usually runs inside screen on a remote system. :)
<persia> Rhonda: You do know about the telepathy irssi plugin, right?
 * Rhonda drops dead.
<Rhonda> persia: Do you want to take over maintenance of irssi? :)
<persia> Rhonda: Not in the least bit :)
<nigelb> Rhonda: if you want help with the bugs I could try :)
<Rhonda> nigelb: I rather want help with the other irssi bugs, triaged. Including those reported in Debian. ;)
<nigelb> Rhonda: I'll make you a deal.  teach me how to deal with debian bts, I'll help you after finishing 1 round of rhythmbox
<Rhonda> nigelb: Install devscripts and reportbug, for a start. :)
<nigelb> both are here
<persia> nigelb: Be careful with reportbug: you may want to read the docs (especially about Ubuntu changes), or install it in a Debian chroot.
<nigelb> yes, a debian chroot is impending, especially to give back upstream.  I've been lazy
<persia> s/impending/pending/
 * nigelb needs to use smaller words
<rawang> hi, when I type "debuild -S", everything looks perfect, but when i dput, it doesn't upload the .orig.tar.gz?
<Rhonda> How do I get bug #493048 linked to the upstream bugreport?
<ubottu> Launchpad bug 493048 in irssi "Tab-completion of channel names cannot be properly used with /join in irssi" [Low,Triaged] https://launchpad.net/bugs/493048
<nigelb> I think flyspray is not supported
<nigelb> (or whatever the upstream is)
<rawang> nigelb, you mean me?
<persia> Rhonda: Also, for bug manipulation, you may find more folk with more developed bug tweaking skills in #ubuntu-bugs (although nigelb is definitely one of them)
<Rhonda> rawang: Also use the -sa switch, it seems that dpkg seems from your version number dpkg seems to think the orig.tar.gz should already bee in the archive.
<nigelb> rawang: nope
<Rhonda> nigelb: Yes, seems to be flyspay.
<persia> rawang: Examine your source.changes file : it likely doesn't include a reference to the orig.tar.gz.  You may want -sa as well.
<rawang> sure
<nigelb> Rhonda: I once ran into same issue.  LP doesn't support flyspray tracking yet.
<nigelb> you'll have to leave it as a comment
<rawang> persia, but why it foget the orig.tar.gz?  I just use "debuilld -S" with lots of packages and without any problem? :)
<Rhonda> rawang: What's the version number? dpkg decides according to that wether it wants to include the .orig.tar.gz or not.
<persia> rawang: debuild believed, based on the revision string, that you didn't need it.
<persia> (version doesn't matter, only revision, but that's a quibble)
<rawang> the package version? it's 0.1.7-1~pre1 in changelog file
<Rhonda> The revision is part of the version</nitpick>
<Rhonda> rawang: Ah, because it's not a plain -1 or -0 it thinks that the source should be in the pool already, yes.
<rawang> but with my other packages, no problem with "x.x.x-1~pre1"
<persia> Rhonda: Ah.  I perhaps have different semantics than you.  I always say that the version and revision are separated by the final '-' in the changelog entry.  Do you know of an authoritative source of correct semantics?
<nigelb> Rhonda: small world
<nigelb> Rhonda: the same bug that I once triaged is what you're trying to link ;)
<Rhonda> nigelb: I just stumbled upon it, yes. :)
<Rhonda> persia: The overall thing is the version. :)
<Rhonda> persia: dpkg --compare-version takes the whole thing, not only the part before the dash.
<Rhonda> --compare-versions even.
<rawang> Rhonda, 0.1.7 and 0.1.7-1, which one is newer?
<Rhonda> persia: A version is compare of (optional) epoch + colon, upstream version, and optional dash + revision.
<Rhonda> rawang: dpkg --compare-versions 0.1.7 '<<' 0.1.7-1 && "echo 0.1.7-1 is newer"
<persia> Rhonda: OK.  and what would you call #\(.*\)-[^-]*# ?
<Rhonda> persia: a regular expression statement
<persia> Ah, ${EPOCH}:${UVERSION}-${REVISION} ?
<persia> I meant the match :p
<Rhonda> rawang: erm, s/"echo /echo "/ of course. :)
<Rhonda> persia: (${EPOCH}:)?${UVERSION}(-${REVISION})? - I said optional. :)
<rawang> Rhonda, http://pastebin.org/99347   is the reason why orig.tar.gz is not include while i type "debuild -S" ?
<persia> Rhonda: Thanks.  I'll adjust my semantic map.
<Rhonda> rawang: And the .orig.tar.gz is referenced in the .dsc file?
<rawang> Rhonda, yes, it was
<Rhonda> was, or is?
<rawang> Rhonda, it is :)
<persia> rawang: That looks suspiciously like it's being packaged for a PPA or other 3rd party repository.  I'll recommend you use a revision like "-0ppaX" or "-0rawangX" rather than "-1~ppaX".
<rawang> and i have compared the sha1 and sha256, it's identical
<Rhonda> persia: trivia: what epoch is considered equal to version x?  :)
<rawang> persia, ok, my goal is to upload to debian archive, that's just a test environment :)
<persia> Rhonda: 0?
<Rhonda> rawang: I wouldn't go musing around what went wrong where too much and just add the -sa switch. Much less trouble and time waste. :)
<Rhonda> persia: Right! :)   0:x = :x = x  :)
<rawang> Rhonda, sure, thanks a lot! :)
 * persia decides to upload the next new packaged project as ~:... just to see what breaks
<Rhonda> epochs aren't allowed to contain ~ so the upload will get rejected.
<rawang> Rhonda, but seems that there is no explanation about "-sa" in debuild manpage
<nigelb> there should be -s and -a
<Rhonda> rawang: Indirect explenation: dpkg-buildpackage(1) options may be given on the command line.
<Rhonda> nigelb: No, there shouldn't.
<rawang> nigelb, Rhonda ok, got it.
<nigelb> Rhonda: my mistake :)
<Rhonda> rawang: A lot of building tools hand over all options they don't know themself to dpkg-buildpackage.
<Rhonda> Actually, I can't think of one that doesn't, or at least has a special flag to pass such options along.
 * Rhonda . o O ( like --debbuildopts in cowbuilder )
<rawang> Rhonda, yes, make sense, -sa option belongs to dpkg-genchanges. :)
<persia> Rhonda: Do you know that to be true for Soyuz ? :)
<Rhonda> persia: No, but then, I wouldn't mind if that thing breaks, so be my guest. :P
<nigelb> I'm off folks, later :)
<rawang> nigelb, byebye :)
<shadeslayer_> nigelb: bye! :0
<shadeslayer_> *:)
<arand> I'm trying to rebuild maxima to use libread6 instead of libread5, would I in this case simply change the line in debian/control from "libreadline5-dev | libreadline-dev" to "libreadline6-dev | libreadline-dev" ?
<hyperair> shouldn't libreadline-dev be enough?
<Laney> not if it's a virtual package
<Laney> (is it?)
<hyperair> it isn't
<Rhonda> It isn't
<Rhonda> And libreadline-dev depends on libreadline6-dev. :)
<hyperair> yep
<Rhonda> arand: Simply drop the "libreadline5-dev | " part.
<arand> Rhonda: Ok, and then just put something in changelog? (No patch-making necessary here?)
 * Laney eyes maxima
<Rhonda> If you change something you need to document that change in the changelog, yes. :)   "drop libreadline5-dev alternative to build with libreadline6" or such.
<Laney> those changes should be forwarded to Debian
<Rhonda> I would expect that there is already such a bugreport.
<Rhonda> There was some massbug filing about that issue.
<Laney> not readline, all the other ones
<Laney> http://changelogs.ubuntu.com/changelogs/pool/universe/m/maxima/maxima_5.20.1-5ubuntu1/changelog
<hyperair> why not readline?
<Laney> that's just not what I was talking about
<randomaction> the readline change was already made in 5.20.0-1
<arand> Hmm, I'm getting failed builds for no-changes now on maxima (karmic)
<arand> randomaction: Yea, but it's not in karmic.
<arand> hence Bug #529902
<ubottu> Launchpad bug 529902 in maxima "maxima tries to find /lib/libreadline.so.5 but 9.10 has .6" [Undecided,Fix released] https://launchpad.net/bugs/529902
<arand> So if I'm getting build errors and failure to build when using a fresh pbuilder (after dpkg-source, debuild -S -uc -us), something bad is afoot?
<shadeslayer_> arand: probably
<shadeslayer_> arand: is the chroot updated and working?
<arand> I just ran a "pbuilder --create" that should be sufficient?
<shadeslayer_> arand: can you pastebin the errors?
<arand> http://pastebin.ubuntu.com/386252/
<shadeslayer_> arand: not necessarily... the main servers are a bit wobbly these days,i failed 3 times to create a chroot with the main servers
<shadeslayer_> and then i used a local server in india
<shadeslayer_> arand: any errors while creating the chroot?
<arand> I do not think so, I can recheck..
<shadeslayer_> please do :)
<shadeslayer_> arand: if its fine,then i cant think of the solution :P
<arand> It's just using the downloaded cache now I guess, but no errors on creating the chroot...
<shadeslayer_> hmm.. no idea then :(
<arand> more bork in maxima, bleh!
<arand> So in this case i should be reportin a "fail to build from source" bug?
<persia> Well, best to try to fix it :)
<persia> And if you're fixing it whilst you're working on the unmetdeps bug, no need to file a new bug.
<arand> Eh, well, I have no idea how to fix it though, which is the crux..
<persia> arand: Well, are you willing to try?
<arand> persia: Definitely.
<persia> If it was my bug, I'd start by trying to run the build under gdb in a chroot.
<persia> You seem to be using pbuilder, so pbuilder-dist lucid login, apt-get install gdb, apt-get build-dep maxima.
<persia> Grab the sources.
<randomaction> arand: which version of maxima are you building, and for which release of ubuntu? (sorry, I've been disconnected and may have missed this information)
<persia> Do a local build with debuild -b (you'll discard this, so don't worry about it not being clean)
<arand> persia: it's for karmic.
<persia> arand: Once it fails, rerun the last entry from debian/rules under gdb, and dig up a backtrace.
<persia> Then s/lucid/karmic/ :p
<arand> persia: ok, I'm on it
<arand> persia: Hmm, something is a bit odd, I get no prompt in "pbuilder-dist karmic login" and no bash-completion, etc...
 * persia doesn't use pbuilder, and so is poorly-qualified to troubleshoot this class of issue
<guardian> hello, when i want to build a 32bit package on a 64bit box, I'm launching ./configure CC="gcc -m32" -- are there cross compiling options that would let autoconf pass the -m32 option to gcc? I mean explicitly telling "the compiler is gcc and it has to be invoked with the -m32" kinda defeats the purpose of autoconf isn't it?
<persia> guardian: What is your larger goal?
<joaopinto> guardian, it's easier to setup a 32bits schroot and build from there
<guardian> the large goal is to be able to build my package for any 64b or 32bit platform that supports autotools
<bjsnider> is the cdrkit vs. cdrtools fight ever going to be resolved?
<guardian> the next step, after linux build, is to use autotools on mac but i'm still polishing linux builds on ubuntu :)
<persia> bjsnider: No.
<bjsnider> then someone is going to have to write brand new software that does what cdrtools does
<persia> guardian: I'm not that familiar with cross-compilation, but we generally build stuff in a way such that it doesn't matter if the underlying hardware is 32 or 64 bit, but rather the environment as a whole.
<persia> bjsnider: It's been done a couple times before.
<bjsnider> i don't mean a fork, i mean brand new code
<persia> guardian: So, we tend to build in managed chroots (using pbuilder or sbuild/schroot) that are constructed to believe they are 32-bit or 64-bit.
<guardian> ok
<persia> bjsnider: Yes, so do I :)  Anyway, the easiest way to resolve it is for optical drives to become obsolete.
<guardian> so, invoking configure --host=x86_64-pc-linux-gnu isn't supposed to work?
<guardian> apparently it lloks for x86_64-pc-linux-gcc that doesn't exist
<persia> It's suppsoed.  We just don't do it that way :)
<joaopinto> cross compiling is not trivial
<persia> Not at all.
<bjsnider> persia, i was hoping for a less depressing answer than that
<guardian> it's not trivial and it often is as trivial as invoking configure with CC="gcc -m32 or CC="gcc -m64", that's why I was looking for an option that would let autoconf do it
<guardian> i'm building a shared library btw
<bjsnider> i don't have enough coffee in me right now to handle that
<guardian> that only has the C runtime as a dependency
<persia> guardian: -m32 vs. -m64 ignores a whole heap of valid -m values in Ubuntu :)
<persia> We have 6 mainline architectures, most of which have a couple of different available personalities.
<guardian> ok so the way to go is to chroot and let autoconf decide, that's what you're telling
<persia> That's what we usually do, because it's easier to write portable software than to write cross-compilable software.
<guardian> side question, let say I want to ease someone's life for a corporate internal tool, so that she launches "make" and it builds both x86 32b and 64b versions of my library -- according to what you just said, I'm better of writing a shell script that asserts gcc has multilib support and then launches configure 2 times from different build trees (one for i386, one for x86_64) with either CC="gcc -m32" or CC="gcc -m64" and finally invoke make one time in
<guardian> build tree?
<persia> guardian: For that case, I'd probably want to make cross-compile work.  It's just not how we do it :)
<guardian> persia: and in case of cross compiling, what should i pass to the --host option? x86_64-something-but-what ?
<persia> I'm not an especially good person to ask.  Like I said, we don't usually do it that way.
<guardian> ok
<guardian> thank you anyway
<arand> Does these lines indicate why it fails to build: http://pastebin.ubuntu.com/386283/ ?? Or do I need to look further into the automake procedure?
<persia> arand: That's likely the issue, yes.
<persia> arand: Now you just have to track down where gcl-depends.mk is supposed to be created.
<arand> persia: Hmm and how would I do that?...
<persia> arand: I'd probably start with `grep -rin gcl-depends .` in the base directory.
<arand> persia: What i found; http://pastebin.ubuntu.com/386303/ (ignoring./share/contrib/lurkmathml/maximadiffs.txt AND ./ChangeLog) With what little I can tell to mee it looks as though it should be created in src...?
 * persia consults the make manual
<bjsnider> persia, what i can't figure out is why opensuse agreed to include cdrtools
<persia> bjsnider: Does it matter that they did?
<persia> Even if it does, does it matter why?
<persia> And even if it matters why, does it matter for Ubuntu?
<bjsnider> persia, because they should be facing the same issues ubuntu is with regard to cdrtools
<eolo999> hi, i' trying to package sphinx-search for hardy, everything works out except when i try to install the package i got a wronge version dependency error: sphinx depends on libpq5 (>= 8.4~0cvs20090328); however: Version of libpq5 on system is 8.3.9-0ubuntu8.04. Where does that dependency came out if the only thing I addded in control file was postgresql-server-dev-8.3?
<eolo999> and another question: how much time does it take to a package to be shown in launchpad PPA?
<persia> arand: I'm getting confused about when include directives happen.
<persia> arand: But try running the command that's supposed to generate the file, and see what happens.
<kreuter> hi, #ubuntu-motu.  can anybody help me make some progress on a sync request?
<arand> eolo999: Depends on build queue, you can check the status of build and get a rough ETA
<persia> kreuter: Sure.  Where are you now?
<eolo999> arand: where do i find the queue?
<kreuter> persia: https://bugs.launchpad.net/ubuntu/+bug/520610
<ubottu> Launchpad bug 520610 in ubuntu "mongodb sync request" [Undecided,New]
<arand> eolo999: view package details, and on that page "view all builds"
<eolo999> ok
<eolo999> thx
<kreuter> I'm not clear from the last comment what I'm supposed to do next.
<arand> eolo999: However, that will only say something useful if you do have packages that are building..
<persia> kreuter: The last comment isn't actually that helpful, unfortunately.
<persia> kreuter: it's a new package, so the first step is to request a freeze exception from the release managers.
<kreuter> okay.  how do I do that?
<persia> kreuter: Update the description to indicate why mongodb is so cool that it *must* be in lucid, and subscribe ubuntu-release.
<kreuter> does "we (10gen) receive continuous requests for Ubuntu packages" suffice?
<arand> persia: I'm not quite sure what to do with all the $VARs ...
<kreuter> and should I create a new lp bug, or just append to the current one?
<persia> arand: Try running "make gcl-depends.mk" in ./src/
<persia> kreuter: I'd just keep reusing the bug, for easier tracking of all the history.
<kreuter> ok
 * persia has never done an FFe for a NEW package, and hopes someone else has a good hint for rationale
<Laney> don't forget about lucid-backports
<persia> Laney: There's a bit of history here: kreuter came by just around FF and asked for inclusion, and was told to talk to Debian, and has done so.  Do you know if there's a way to start populating lucid-backports prior to lucid release?
<Laney> I'm not sure when it opens (ScottK or jdong might know though), but I guess that it can be pre-approved in any case.
<arand> persia: just "make" gives "no rule..." and if I secify the makefile: http://pastebin.ubuntu.com/386319/
<eolo999> is it possible that debuild take dependencies version from my karmic install and doesn't use pbuilder environment?
<persia> arand: Ah, right, you'd have to generate all the makefiles first.
<Laney> eolo999: not just possible, but certain
<Laney> you need to call it with pbuilder build xxx.dsc or pdebuild
<persia> arand: do you not get a Makefile with debuild -b ?
<kreuter> I'm supposed to subscribe "Ubuntu Release Team"?
<persia> kreuter: Yes.
<kreuter> ok.  done.
<kreuter> now I wait?
<eolo999> Laney: great! so i can "run pdebuild -S"?
<LimCore> hi, I was thinking, would it be nice to have a security tool that interactivly warns when a new application tries to connect to internet, and then remember user's decissions? (sort of like well known ZoneAlarm or Outpost products where for windows)
<arand> persia: if you mean Makefile.am I do have one in src/ (and in ../)
<persia> arand: No, I mean Makefile
<persia> arand: Makefile.am probably generates Makefile.in which probably generates Makefile
<eolo999> I created the env with: sudo pbuilder-dist hardy amd64 create. How do i use it to build a source package based on that env?
 * eolo999 is really a newbie
<Laney> you don't need to build a source package in the chroot
<persia> Well, for some packages you might, depending.
<persia> For instance, if you're running MoeOS, and you want to compile for lucid, and the package has versioned build-depends required for building sources ...
<Laney> alright, if you can't satisfy the build-depends required to run clean: then yes you do.
<arand> persia: No I have none of that, hmm, I found this bit earlier in the debuild -b output, is it relevant?: http://pastebin.ubuntu.com/386322/
<eolo999> ok, found something in the packaging guide, i stopped reading too early
<persia> arand: That looks like the output of the call to clean.
<persia> arand: Did you manually delete anything or run clean after your call to debuild -b?
<arand> persia: I still get that error if I dpkg-source in a fresh dir and run debuild -b again
<kklimonda> LimCore: most people don't even read what is written on the popup dialog so they would probably just press "Allow" to dismiss it faster and use the program they have installed. I'm not sure if it's going to help them.
<persia> arand: That's expected.  The trick is that once you have run debuild-b, you are at the point of the crash.
<LimCore> kklimonda: it will help thoes users that do read
<persia> arand: And *then* you can run `cd src; make gcl-depends.mk` to try to replicate.
<LimCore> the users that do not read can not be helped, but then other then general secure by default system, they can only blame themselves, if they will run a binary from internet or smth
<persia> arand: and if you're extra lucky, you can edit Makefile to add a debugger call, and get a backtrace, and fix it.
<kklimonda> LimCore: but to answer the question you have asked on #-bugs the libboost and wxwidgets are kinda heavy dependencies and wxwidgets is not in the main so getting such an application to the default cd would be hard task
<eolo999> it seems that even dh_make should have run with different env settings
<arand> persia: Yea, ok, now it seems I have all the makefiles as they should be
<arand> persia: So I would want to add $(how do I add a debugger call?) somewhere in here?: http://pastebin.ubuntu.com/386327/ (that's from the makefile)
<persia> arand: Right.  I'd probably insert echo at the beginning, and then add another line with gdb $(EXECUTEGCL)
<persia> You can then add the arguments back inside gdb
<persia> There are, of course, lots of other ways to do it :)
 * persia grumbles at the massive dependency list for aptitude in sid
<arand> persia: http://pastebin.ubuntu.com/386330/ like so?
<kreuter> persia: so now I'm supposed to get a sponsor review.  how do I do that?
<persia> kreuter: Wait for me to finish building the package :)
<kreuter> ok :)
<persia> At this point the rest is out of your hands.  Just watch the bug traffic, and it should tell you the status.
<kreuter> <nod>
<persia> Unless something unexpected happens, it will probably be available in the next week or so.
<persia> kreuter: Once it is accepted, you probably want to subscribe to bugmail, and try to make sure fixes are made available.  You may also want to subscribe to the package in the Debian BTS.
<arand> persia: And then run "gdb make" "makefile" "break EXECUTEGCL" and "run" ?
<kreuter> persia: okay.
<kreuter> thanks again!
<persia> No, just run make `gcl-depends.mk`the gdb call inteh makefile will run gdb.
<persia> But like I said, there's lots of ways.  You can run gdb outside make too.
<kreuter> hm.  was I also supposed to have subscribed ubuntu-main-sponsors?
<arand> Ok, I'll try that.
<kreuter> (and is it still important for me to do so now?)
<persia> kreuter: No, and no.
<kreuter> okay and okay!
<arand> persia: That just gave meMakefile:2398: *** missing separator.  Stop.
<persia> kreuter: For now, MOTU remains in charge of new packages.  This ought change at some point, but it's not yet clear how to implement that.
<persia> arand: That means there's a syntax errror in your makefile.
<arand> persia: Hmm, seems I ran make at the wrong point before, now when I simply removed the gdb things from the makefile (I apparently didn't fit them in syntax properly) i instead get this on "make gcl-depends.mk": http://paste.ubuntu.com/386344/
<persia> arand: Excellent!  You've found the bug,  Try typing ":H" for help.
<persia> I have no idea how to tell you to fix this, but you're getting to the point where you can probably track it down.
<persia> (and it's a great opportunity to improve your lisp)
<arand> I don't know a single bit of lisp :(
 * persia suspects that will no longer be true in a couple hours
<hyperair> any motu-release people around?
<persia> hyperair: MOTU Release is going away.  Go find ubuntu-release in -devel.
<hyperair> oh whoops
<ScottK> Gone, not going.
<hyperair> heheh
<persia> Oh cool.
<ikt> gone?
<hyperair> ikt: yeah, archive reorg.
<ikt> opps
<ikt> read that wrong
<ikt> motu release is going away
<ikt> not motu
<persia> ikt: No, MOTU still exists.
<persia> ikt: But please feel free to participate in the discussion of the transitoin from Masters of the Universe to Masters of the Unseeded (or whatever MOTU ends up expanding as)
<persia> (on the ubuntu-motu@ mailing list)
<ikt> that's cool, I'm just getting used to bug triage, so I'm sure I'll be more active here soon >.>
<hyperair> unseeded eh
<hyperair> heheh
<hyperair> i think masters of the universe sounds cooler =p
<hyperair> but it wouldn't make much sense if universe itself disappears.
<persia> Me too, but that requires a definition of "universe" that doesn't include lots of stuff, which is tricky once there are no components.
<arand> persia: https://bugs.edge.launchpad.net/ubuntu/+source/maxima/+bug/296643/comments/12 :( Should I just fix the dependency and test-build it in ppa instead?
<ubottu> Launchpad bug 296643 in maxima "Please merge maxima 5.17.1-1 (universe) from Debian unstable (main)." [Wishlist,Fix released]
<hyperair> persia: components are going away?
 * persia thinks people should actually read mail and check the references
<persia> https://wiki.ubuntu.com/ArchiveReorganisation/Components
<ScottK> Universe of everything else.
<lbrinkma> I have a problem with my anjuta-extras package: I can't get away the lintian warning: pkg-has-shlibs-control-file-but-no-actual-shared libs. I've no idea how to solve that, please help me. You can get the package at https://launchpad.net/~lbrinkma/+archive/ppa
<kamalmostafa> I would like a clarification about the "motu-release is gone" situation please:  How does that affect the FFe process?  (https://wiki.ubuntu.com/FreezeExceptionProcess still advises that "motu-release" should be subscribed).  What about all the bugs in the motu-release queue right now?
<jbernard> lbrinkma: have you tried passing the '-I' flag to lintian? I find that often sheds light on what's going on
<jbernard> lbrinkma: er, '-i' i meant
<lbrinkma> jbernard: I've tried running 'lintian-info -t pkg-has-shlibs-control-file-but-no-actual-shared libs' and the information was not very helpful. I think, cdbs is causing this problem.
<ScottK> kamalmostafa: motu-release/ubuntu-release.
<lbrinkma> I've tried running with '-i'. It's the same as running lintian-info. I've no idea what to do next and I want to get the package to lucid. Everyday later makes it harder to get it accepted.
<hyperair> featurefreeze is on already. i don't think you can get in any new packges.
<lbrinkma> hyperair: It's not really new. The splitted up the anjuta package into anjuta and anjuta-extras.
<hyperair> lbrinkma: can you check the contents of the deb with dpkg-deb -c package.deb? if there is a library in /usr/lib/ then dh_makeshlibs will create a shlibs control file.
<kamalmostafa> ScottK: I think you're saying that motu-release is replaced by ubuntu-release, so I'll subscribe that to my pending FFe request.  thanks.
<lbrinkma> hyperair: there are files in /usr/lib/anjuta/
<hyperair> lbrinkma: got a build log?
<hyperair> lbrinkma: and is the package uploaded somewhere?
<wrapster> how do i list out all the diverts that have currently been provided by dpkg?
<LaserJock> hey all, I'd like to file a sync request for a new upstream bug-fix-only release, is there anything special I need to do for that?
<lbrinkma> hyperair: yes, in my ppa https://launchpad.net/~lbrinkma/+archive/ppa
<hyperair> okay lemme download and see
<wrapster> guys anyone knows about it?
<hyperair> wrapster: man dpkg-divert
<hyperair> dpkg-divert --list
<hyperair> lbrinkma: well, i'm not sure why, but dh_makeshlibs is misbehaving.
<hyperair> lbrinkma: solution is to make it not run, somehow.
<hyperair> or rather, workaround.
<hyperair> lbrinkma: or just get rid of cdbs.
<lbrinkma> hyperair: how to do that? I'm not very familiar with cdbs
<hyperair> lbrinkma: just get rid of it and use dh7
<lbrinkma> hyperair: How to do that best? I could rebuild the package and copy over the files or what to do?
<hyperair> just change debian/control and debian/rules
<hyperair> rewrite the debian/rules
<lbrinkma> what to do in the control file: just delete cdbs dep
<hyperair> delete cdbs dep, make debhelper's version 7.0.50
<hyperair> replace the rules with this:
<hyperair> %:
<hyperair> <tab>dh $@
<hyperair> override_dh_makeshlibs:
<hyperair> the override_dh_makeshlibs is empty to avoid dh_makeshlibs from being called.
<lbrinkma> hyperair: thank you very much for helping me
<hyperair> lbrinkma: no problem.
<LaserJock> curse you v3 dpkg format!!!
<bdrung_> LaserJock: why?
<LaserJock> bdrung_: because I'm needing to backport a package to karmic
<LaserJock> bdrung_: which means I need to un-v3 it
<LaserJock> bdrung_: which meant that I needed to repack the .orig.tar.gz since it was a bz2
<LaserJock> which meant I have to reupload a tarball for the exact same thing that's already in the archives
<bdrung_> LaserJock: yeah, backporting v3 is a PITA, but i love it nonetheless
<LaserJock> I haven't seen a package that really used it in a way that I was like "oh awesome" but I'm sure there are some about
<bdrung_> LaserJock: ist a cleaner debian/rules and a not-repacked bz2 source awesome enough?
<LaserJock> I haven't seen much cleaner debian/rules, but yeah bz2 is great ... unless you're trying to backport :-)
<Rhonda> bdrung_: I'm not that sure how much cleaner v3 makes debian/rules, to be honest. Sounds like buzzword merchandizing to me, can you clearify?
<bdrung_> Rhonda: you don't need a patch system in there (and you can drop the patch system from B-D)
<geser> LaserJock: backporting from lucid+1 to lucid won't have this v3 format problem
<Rhonda> LaserJock: And yes, the pain that the v3 format brings doesn't really work for its benefits.
<LaserJock> geser: sure, but that doesn't help me now ;p
<Rhonda> bdrung_: That doesn't make it much cleaner, and actually, one does need a patch system if one wants to work properly with it.
<azeem> hey LaserJock
<LaserJock> hi azeem
<azeem> Rhonda: patch system cluttering up debian/rules
<LaserJock> azeem: I'm trying to get gchemutils 0.10.12-1 into Debichem PPA
<azeem> yay
<bdrung_> Rhonda: you don't have to. you can extract, edit the source, debuild, and the patch will created for you.
<LaserJock> azeem: which is causing this v3 mess due needing newer goffice
<Rhonda> azeem: Sorry, but that's a plain bullshit. A single include line and an patch and unpatch requirements to two targets are *FAR* from "cluttering up debian/rules".
<azeem> Rhonda: please watch your language in here
<Rhonda> s/bullshit/intentionally false advertising/, sorry.
<azeem> LaserJock: hrm, which packages have been converted to v3? The debichem ones or goffice?
<LaserJock> it seems like Debhelp 7 has more going for debian/rules maybe
<LaserJock> azeem: goffice
<azeem> ok
<bdrung_> Rhonda: compared to a three line debian/rules - it's a huge benefit ;)
<LaserJock> anyway, there will be benefits to v3 in the future for sure
<LaserJock> being able to do bz2 orig.tar. files is great
<Rhonda> bdrung_: A three line debian/rules is a very bad idea and a regression to readable debian/rules IMHO. It might make things easier for 80% (where things already were easy) but makes it a lot harder for the remaining 20% of the packages.
<azeem> nobody said you have to use 3-line debian/rules for all packages
 * Rhonda points azeem at bdrung_
<Rhonda> azeem: Unfortunately the documentation isn't there anymore to not get a 3-line debian/rules to start off from.
<bdrung_> Rhonda: yes, some packages needs more than this
<Rhonda> It's hiding the posibilities that some packages actually _do_ require behind its three lines, and doesn't document properly how to work.
<LaserJock> *anyway*  it's not a peeing contest, debian/rules is as long (hopefully) as it needs to be to get the job done
<Rhonda> That's a huge regression from a usability point of view.
<Rhonda> hmmmmm
<Rhonda> The requested URL /changelogs/pool/main/d/dpkg/dpkg_1.15.5.6ubuntu1/changelog was not found on this server.
<kees> when motu-release folks get a moment, can two members ACK bug 530309 please?
<ubottu> Launchpad bug 530309 in ltp "FFe: sync ltp with Debian" [Undecided,New] https://launchpad.net/bugs/530309
<geser> kees: motu-release is getting merged into ubuntu-release, but I don't know what's the status is right *now*
<kees> geser: yeah, that's why I figured I should just follow existing processes
<iulian> kees: Done.
<kees> iulian: thanks
<alkisg> How can I discard a bzr push done by someone else? The launchpad tree is in rev. 79, in my local disk I have 78, and I want to discard 79...
<jpds> alkisg: bzr pull; bzr uncommit; bzr revert; bzr push --overwrite?
<alkisg> jpds: thank you :)
<wrapster> hi
<wrapster> are there any docs available to learn how APT works?
<jcastro> lucas: I owe you a beer, the debian squid maintainer seems receptive to having the deb proxy thing an optional config
<lucas> jcastro: perfect :)
<matttbe> Hello nhandler_ and ScottK
<matttbe> I'm part of the Cairo-Dock team and we need 1 'ack' in order to accept our update on Ubuntu Lucid asked more than 2 weeks ago...
<matttbe> it seems that you can help us :)
<matttbe> this is the two bugs: https://bugs.launchpad.net/ubuntu/+source/cairo-dock/+bug/521534 & https://bugs.launchpad.net/ubuntu/+source/cairo-dock-plug-ins/+bug/521536
<ubottu> Launchpad bug 521534 in cairo-dock "Please update cairo-dock to 2.1.3-3 version" [Undecided,Confirmed]
<matttbe> or maybe someone else can help us?
#ubuntu-motu 2010-03-02
<kirkland> pbuilder is giving me some wonky output
<kirkland> throwing a bunch of 404's for old library debs, which aren't in the archive anymore
<kirkland> do i need to clear some cache files or something?
<kirkland> i'm all apt-get updated ...
<SoftwareExplorer> How does dpkg handle upgrading a package that has a configuration file with new defaults, when the user hasn't changed the defaults? Does it stay at the old defaults?
<persia> kirkland: Is your pbuilder chroot all apt-get updated?
<persia> SoftwareExplorer: It replaces it if the checksum of the installed conffile matches the stored checksum of the conffile installed by the last version of the package, and asks the user for guidance if the checksum doesn't match.
<kirkland> persia: i thought it was, let me check again
<SoftwareExplorer> persia: Ok, thanks!
<persia> kirkland: I usually only encounter that when there's skew between the apt-cache in my chroot and my other apt-caches (since I have about 20 different apt-caches this happens frequently)
<kirkland> persia: doh, i fatfinger that step in my script; sorry for the noise
<rawang> hello, I just disable dh_auto_test, what should i do?  I just have "dh_auto_test:" with nothing to do, but it doesn't work :(
<rawang> just want
<persia> kirkland: No worries.  Took me about 20 tries to get it right, and now I keep it on p.u.c/~persia so I never have to reimplement :)
<persia> rawang: If you have that, dh_auto_test is disabled.  Are you sure something else isn't running the test suite?
<rawang> persia, yes,
<rawang> I just want to know, how to disable dh_auto_test :)
<rawang> is it 'override_dh_auto_test'? :)
<rawang> persia, and nothing under that "override" ? :)
<persia> rawang: Oh, right.  Sorry, not thinking.  Yes, it's override_dh_auto_test: with no actions.
<rawang> persia, alright, got it, thanks a lot! :)
<SoftwareExplorer> What happens when a user changes a normal (non-configuration) file and the package is updated?
<RAOF> The file gets overwritten silently.
<SoftwareExplorer> RAOF: Thanks.
<tgm4883> I'm trying to fix a package that is Section: multiverse/metapackages, although debian/control tells it to go into the graphics section instead. Is there somewhere else that section is set in packaging?
<nigelb> whats the package name?
<tgm4883> mythtv-themes
<nigelb> it is in multiverse, but the graphics is the category in Synaptics I guess
<tgm4883> right, but I need to remove it from multiverse/metapackages, as it causes issues when being removed from ubuntu software center
<tgm4883> basic multiverse would be fine I guess, just out of metapackages
<tgm4883> specifically for bug 529740
<ubottu> Launchpad bug 529740 in myththemes "mythtv-themes metapackage needs to be != metapackages section" [Medium,Triaged] https://launchpad.net/bugs/529740
<persia> tgm4883: pastebin debian/control ?
<nigelb> ah, the expert's here :)
<tgm4883> persia, ok sec
<tgm4883> persia, also, there is a debian/control.in, do you need that too?
<tgm4883> persia, http://pastebin.com/qEHHs2Zg
<persia> Doesn't matter.  I just didn't want to hunt on LP or download the package :)
<tgm4883> persia, heh
<tgm4883> I guess I could have linked you to the bzr source too
<persia> tgm4883: As easily :)  Anyway, that's a bug in the archive overrides file, not in the package, based on that debian/control.
<persia> It's clearly "Section: graphics". by preference.
<tgm4883> yep
<persia> I don't know how to fix that: you likely need an archive admin.
<tgm4883> archive overrides file?
<tgm4883> ah ok
<tgm4883> so it's not something in the packaging then?
<persia> The archive management tools have a way to override incorrect section stuff, set components, etc.
<persia> Doesn't look like it to me, but confirm with an archive admin.
<tgm4883> ok, so do I need to open a bug somewhere for that or should I ping someone?
<rawang> hi, when building a python packages, all packaged which was in 'site-packages' goes to 'dist-packages', and some of them goes to 'pyshared' directory, what is the standard way?
<persia> tgm4883: Check wiki.u.c/ArchiveAdministration, find the archive admin of the day, and ask them how to proceed in #ubuntu-devel
<persia> tgm4883: This might end up as a bug, or a package change, or just the request on IRC may be enough.
<tgm4883> persia, ok will do, thanks
<rawang> persia, hi, :)
 * persia ignores contentless pings
<rawang> persia, , when building a python packages, all packaged which was in 'site-packages' goes to 'dist-packages', and some of them goes to 'pyshared' directory, what is the standard way?
<porthose> rawang, http://www.debian.org/doc/packaging-manuals/python-policy/
 * persia is also the wrong person to ask about python packaging
<rawang> porthose, great, that's very useful, thanks :)
<persia> rawang: Always ask your questions generally, unless you *know* one person has special knowledge.  There's lots of folk here, and most are happy to help.
<rawang> persia, alright, thanks all the same :)
<porthose> :)
<rawang> sure
<nigelb> is there something I should do if deletion requests dont get ack'd?
<persia> nigelb: Wait.  Complain here if we reach BetaFreeze
 * nigelb goes to check dates
<nigelb> ah, well 9 days more, thats plenty of time
<micahg> what's the difference between the math.h in libc6-dev and the one in libstdc++6-4.4-dev
<persia> micahg: diff may tell you more, but I suspect it's different language bindings.
<micahg> persia: to use one of the other is based on the rules file?
<nigelb> micahg: based on the whether it uses gcc or g++ perhaps?
<nigelb> (I'm guessing)
<persia> micahg: I'm guessing it's based on the include directives in the source.  I'd expect both of those packages to be installed from build-essential.
<LLStarks> guys. i don't think making nvidia-current a build-dep for mplayer is a good idea. it breaks libgl on systems with intel graphics.
<LLStarks> The following NEW packages will be installed:
<LLStarks>   dkms libavcodec-dev libavdevice-dev libavdevice52 libavformat-dev
<LLStarks>   libavutil-dev libcdparanoia-dev libdts-dev libfaac-dev libfribidi-dev
<LLStarks>   libgif-dev liblircclient-dev liblivemedia-dev liblzo2-2 liblzo2-dev
<LLStarks>   libmp3lame-dev libopenal-dev libopenal1 libpostproc-dev libsmbclient-dev
<LLStarks>   libswscale-dev libvorbisidec-dev libvorbisidec1 libx264-dev libxvidcore-dev
<persia> LLStarks: I disagree.  I suggest instead that the issue lies in ending up with compiled bits that don't work on arbitrary graphics cards.
<LLStarks>   libxvmc-dev libxxf86dga-dev libxxf86vm-dev nvidia-185-libvdpau-dev
<LLStarks>   nvidia-current nvidia-current-dev nvidia-settings vstream-client-dev
<persia> !paste
<LLStarks>   x11proto-xf86dga-dev x11proto-xf86vidmode-dev
<ubottu> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<LLStarks> my bad.
<persia> LLStarks: So the way to fix it is to fiddle debian/rules to not break things, rather than exclude the build-dep.
<LLStarks> file a bug?
<persia> Depends on your level of skill and/or motivation, really.  Either fix it or file a bug, yes.
<LLStarks> this is what happens: http://img94.imageshack.us/img94/7263/ohgodo.png
<LLStarks> it's imperative that this is fixed.
<LLStarks> https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/530481
<ubottu> Launchpad bug 530481 in mplayer "nvidia-current build-dep breaks libgl if hardware isn't nvidia" [Undecided,New]
<persia> LLStarks: It's hard for me to find the specific mplayer error in that screenshot.
<superm1> that looks more like a screenshot from the upside down chrome extension to me
<superm1> but surely a build-dep won't affect usage of the app
<superm1> but also it shouldn't build-dep on nvidia-current-dev, but instead libvdpau-dev probably
<rawang> porthose, hello, I just read the debian python policy, but seems like there are two ways to pack python package, python-support and python-central, which way is  mostly used for debian package?
<porthose> rawang, I would suggest dh7 with python-support
<persia> rawang: They are both commonly used.  The last answer I got was "If you're uploading to Ubuntu directly, use python-centtral, and if you're uploading to Debian use python-support".
<persia> rawang: They will both go away soonish, being replaced by the renewed dh_python (for some definition of soonish)
<rawang> porthose, what does this mean? I've already use debhelper >=7.0.50
<rawang> persia, ah, i see, i guess that's what porthose wants to say :)
<LLStarks> superm1. persia. doing a "sudo apt-get build-dep mplayer" will cause this once everything is installed and compiz is activated.
<LLStarks> that's why this is a pants-****ting bug.
<persia> LLStarks: OK.  You filed the bug?
<LLStarks> https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/530481
<ubottu> Launchpad bug 530481 in mplayer "nvidia-current build-dep breaks libgl if hardware isn't nvidia" [Undecided,New]
<persia> LLStarks: Are you planning to work on it?
<LLStarks> i'm not a coder
<LLStarks> why would i?
<LLStarks> nor can i package.
<superm1> bjsnider, siretart, ^ it's just a matter of needing libvdpau-dev support instead of nvidia-libvdpau-dev
<persia> LLStarks: OK.  If you're not working on it, you'll want to either wait until someone else wants to work on it, or encourage them to do so.  Complaining to people generally causes them to want to remove themselves from the situation in which they receive complaints.
<LLStarks> even my most detailed bug reports aren't acted on for at least 2 months unless i bring them up on mailing lists or irc.
<LLStarks> i apologize for my lack of proper protocol though.
<nigelb> is it just a matter of changing deps?
<persia> Yeah :/  We don't have enough folk fixing stuff.  That's part of why I hoped you'd want to work on that one.
<nigelb> If its just changing dep and repacking, I could probably help :)
<persia> nigelb: Needs some thought as to which are the right deps, and then testing on a variety of hardware, so mostly build-deps, but maybe some changes in debian/rules
<nigelb> okay, not my cup of tea then
<persia> nigelb: You can try.  There is a suggestion in backscroll as to which might be the right build-dep.
<persia> LLStarks: would probably be happy to help with testing.
<persia> I'm sure other testers could be found in #ubuntu-bugs, etc.
<nigelb> so, I change to libvdpau-dev  instead of nvidia-libvdpau-dev, build, and upload to PPA for testing?
<superm1> libvdpau-dev is the correct build-dep now.  that's the same change that was made for ffmpeg, mythtv, etc
<LLStarks> i guess so. if it's only a matter of purging the proper packages and then doing a build-dep command.
<nigelb> superm1: shall I change and propose a debdiff then?
<superm1> sure
<nigelb> I dunno what needs to be done in the rules file if anything needs to be done
<superm1> debian/control
<persia> The only reason for debian/rules changes would be if the build system needs a hint about the other changes (in terms of --enable --disable, etc.)
<nigelb> LLStarks: where did you see nvidia-libvdpau-dev as a build depends?
<nigelb> (I can't find it)
<nigelb> nevermind, got it
<LLStarks> nvidia-185-libvdpau-dev nvidia-current nvidia-current-dev
<nigelb> I can only find 'nvidia-185-libvdpau-dev' listed in debian/control
<nigelb> where are you seeing the others?
<nigelb> LLStarks: what page/file are you seeing the build deps?
<LLStarks> ?
<LLStarks> i don't understand.
<nigelb> where are you checking for build dependencies?
<LLStarks> apt-get build-dep
<nigelb> ah
<nigelb> so now worries, its just the nvidia package depending on the others I guess
<LLStarks> should i amend the bug report to reflect other packages?
<nigelb> nope
<nigelb> its only the ''nvidia-185-libvdpau-dev' package
<nigelb> Almost fixed, i'm test building now.
<nigel_nb> mplayer is a hell of a package to build ;)
<persia> !ohmy
<ubottu> Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
<nigel_nb> I guess it will take a good 30 mins
<persia> (and yes, it is :) )
<nigel_nb> woops, sorry :(
<nigel_nb> is it because of the graphics libs that it depends on that it takes so much time?
<persia> Well, also because of all the various optimised flavours and assembly.
<nigel_nb> ah :)
<nigel_nb> okay, something went wrong in the build
<nigel_nb> any idea whats going wrong? http://paste.ubuntu.com/386786/
<persia> nigel_nb: That's not really enough of the log to tell, but I'd guess that nobody defined vs_info_x264.opts
<nigel_nb> that was where the problem happened.  You want me to paste the whole log (where do I get it anyway)
<nigel_nb> how do I fix this issue?
<persia> You want to go look at the source in the place where the failure happened, and see if you can figure out why things aren't initialised.
<persia> Also, compare the libraries you were using to the libraries you are now using.
<persia> You need to identify what is different between the two builds.  From there, you'll be in a strong position to fix it.
<nigel_nb> between the 2 builds?
<nigel_nb> you mean the old dep and the new dep?
<nigel_nb> and the build seems to show a huge number of warnings
<persia> Right.  Between building with the old build-dep and the new one.
<nigel_nb> I didn't try building with the old one.
<nigel_nb> lemme try now
<persia> nigel_nb: There's a build log on LP from the old way.
<persia> nigel_nb: It might be a bit different, but may save you a bit of time.
<nigel_nb> yes, it definitely wil
<nigel_nb> I can't find the 've_info_x264.opts' file in the source
<nigel_nb> i.e., a grep returns blank
<persia> even grep -rin . ?
<persia> And it may not be a file.
<nigel_nb> I did a grep -R 've_info_vfw.opts' *
<persia> That usually works.
<persia> I tend to use -rin because sometimes things end up strangely capitalised, and I want line numbers in my report.
<nigel_nb> well, -R and -rin returned nothing
<persia> Now, it's possible that this comes from a generated file.
<nigel_nb> but I tend to think, thats not the trouble
<persia> did you try a grep in a failed-build tree?
<nigel_nb> because that warning is there in the old build logs too
<persia> Aha!
<persia> So, go find something else :)
<nigel_nb> something related to make.  Who's the subject matter expert?
<nigel_nb> its the "make[1]: *** [libmpcodecs/ve_x264.o] Error 1" that is giving me trouble
<persia> That usually means that it couldn't make that file.
<persia> So, you need to look up and try to figure out how it tries to make that file.
<nigel_nb> how?
<persia> Yes, how.
<persia> So the Makefile provides instructions on how to make files.
<persia> (or targets, but usually targets are files)
<persia> So you look in your partial build tree to find the makefile that tries to make libmpcodecs/ve_x264.o
<persia> and you try running the command to create that file manually.
<persia> That should narrow down the issue.
<nigel_nb> I see "SRCS_MENCODER-$(X264)             += libmpcodecs/ve_x264.c" in makefile
<persia> OK.  That just adds that value to that variable.
<persia> Now go find how that variable is used.
<nigel_nb> I can see a few references in the configure.in file
<nigel_nb> nothing I can decipher
<persia> OK.  Where did you find the first line you found?
<nigel_nb> the first few defines the options that can be passed
<nigel_nb> later on, each of the option is correctly defined with code, that uses this variable
<persia> RIght.  So you're looking for a rule to make the variable.
<persia> Or you're looking for some rule that makes files based on a transformation of this variable (e.g. .c -> .o)
<nigel_nb> dont see that
<nigel_nb> where in the partial build tree would I find the make file usually?
<Rhonda> I would think configure generates them for you, there should be Makefile.in files before that.
<nigel_nb> I'm running into some build troubles
<nigel_nb> me and persia were trying to figure how to fix it.  but I'm still lost
<nigel_nb> ugh! where do I find the build log now?
<nigel_nb> Im so lost when pbuilder gives me troubles
<Rhonda> pbuilder puts them into /var/cache/pbuilder/result if you used the --pkgname-logfile switch.
<rawang> persia, hello there.
<nigel_nb> I only see the final .debs there of the successful packages
<rawang> persia, I found look at the dh_python manpage, and it says the dh_python is deprecated, but you said dh_python will be used for new package, which one is correct? :)
<Rhonda> Then you probably haven't used that switch.
<nigel_nb> oh
<nigel_nb> so, without that switch the logs wont be generated?
<nigel_nb> which means i have to compile again - ugh!
<Rhonda> rawang: Well, you should settle for either dh_pysupport or dh_pycentral from what I understand . o O ( haven't packaged any python modules yet, though )
<persia> rawang: Both.  The revivified dh_python is still being assembled, and the electrodes have not yet been attached.  The switch will likely be thrown in the next few months.
<Rhonda> nigel_nb: No, you only will see the messages on your screen without any logfile.
<persia> rawang: So if you want to do something now, use python_support or python_central.
<dholbach> good morning
<rawang> persia, is it okay if you use dh_python only?
<nigel_nb> this a paste of the trouble I ran into earlier, if its too short, I'll run it by again with the log file switch http://paste.ubuntu.com/386786/
<nigel_nb> and good morning dholbach
<rawang> persia, i mean if 'I' only use dh_python :)
<dholbach> hi nigel_nb
<rawang> Rhonda, thanks :)
<persia> rawang: Yes, but you may have to wait many months before you can upload, and there currently exist no documents on how to use it correctly (please read this response as a carefully couched "No")
<rawang> ok, and another question, when i use dh_pycentral, what's the target?  I found a examle "binary-install/python-pyatspi::" why there are two colons?  is that a typo?
<Rhonda> rawang: No worries. :)
<rawang> :)
<nigel_nb> persia: "So you look in your partial build tree to find the makefile that tries to make libmpcodecs/ve_x264.o" - means inside the pbuilder/build/1234/ folder?
<persia> nigel_nb: I'd probably use something like pbuilder --login (I really use schroot -c) and try a local build there with debuild -b -nc to get the partial build tree.
<persia> nigel_nb: Someone who actually uses pbuilder may be able to suggest other strategies.
<nigel_nb> I got a hook to get me in the chroot when something goes wrong
<nigel_nb> so now I'm in the chroot
<persia> Excellent.  If you're in the chroot, that's the place to be looking.
<nigel_nb> all of it will be in /tmp of the chroot I suppose?
<rawang> persia,  So when i use dh_pycentral, what's the target?  I found a examle which has "binary-install/python-pyatspi::" why there are two colons?  is that a typo? or it's intented? could you please review my rules file?   http://pastebin.org/99827   thank you so much
<nigel_nb> okay, the grep has returned 3 matches which might be significant
<persia> rawang: I'm the wrong person to ask.
<rawang> persia, sorry, :)
<persia> rawang: I have worked with one (1) python package in any depth, and last touched it in gusty because I couldn't make it work.
<persia> Like I said earlier, please ask questions generally.
<rawang> yeah
<suji11> hi
<rawang> so hello everybody,   if the target has two colons  like "binary-install/python-pyatspi::"   is that a typo?
<persia> Usually it's just CDBS, unless it's special in some way.
<nigel_nb> I think I found that ve.o file that we were looking for earlier
<suji11> my package iok(indic onscreen keyboard) was accepted for lucid, can i add this in the previous stable releases of ubuntu?
<nigel_nb> suji11: no
<suji11> nigel_nb: ok
<persia> suji11: You need to request a backport, and it only goes into -backports
<persia> https://help.ubuntu.com/community/UbuntuBackports
<nigel_nb> I finally did find the 've_info_x264' variable, but how do I figure out what is going wrong?
<suji11> persia: ok, i go through that.
<persia> nigel_nb: You need to figure out which command is used to create the file that isn't being created.
<nigel_nb> oh no.
<nigel_nb> the 've_x264.o' is called only in 1 file and its not a create command
<persia> nigel_nb: Paste the makefile that contains 've_x264.o'
<nigel_nb> its not a make file.  I can't find a make file
<nigel_nb> I'm looking at '/tmp/buildd/mplayer-1.0~rc3+svn20090426' inside the chroot and this seems to be the result after building
<nigel_nb> where in the chroot do i see the make file?
<persia> Is there no Makefile?
<persia> Previously you identified a bit of code you found which was in make syntax.
<nigel_nb> that was directly in the code, not in chroot
<nigel_nb> I didn't read what you asked me to do
<nigel_nb> now, i'm inside the chroot
<persia> nigel_nb: You don't have the code in the chroot?
<nigel_nb> I'm looking.
<nigel_nb> ah, I see the same code I saw earlier 'SRCS_MENCODER-$(X264)             += libmpcodecs/ve_x264.c'
<persia> OK.  And that's in a makefile?
<nigel_nb> yup
<persia> OK.  Do you read make?
<nigel_nb> nothing more than that line in the make file
<persia> It's a one-line makefile?
<nigel_nb> its a huge makefile
<persia> Excellent!
<nigel_nb> 1125 lines
<persia> So, You know that libmpcodecs/ve_x264.c is being added to SRCS_MENCODER-$(X264)
<nigel_nb> This might help here.  its a grep result
<nigel_nb> http://paste.ubuntu.com/386828/
<persia> Next, find where something happens to SRCS_MENCODER-$(X264)
<nigel_nb> now, you have an idea of where to ask me to look.  (since i'm thoroughly lost
<nigel_nb> SRCS_MENCODER-$(X264) is only referenced in the make file
<persia> nigel_nb: Well, here's an interesting line:
<persia> libmpcodecs/ve_x264.d:1:libmpcodecs/ve_x264.d libmpcodecs/ve_x264.o: libmpcodecs/ve_x264.c config.h mp_msg.h
<nigel_nb> thats the line you were looking for? 0_0
<persia> To me, that looks like a rule definition to create  libmpcodecs/ve_x264.o which is the file that filed.
<nigel_nb> s/filed/failed
<persia> So, under that line there should be some commands that explain how the file is created.
<persia> And if you're still in the interrupted build, you could run them one-by-one to find out which fails.
<persia> And once you know which is failing, you can probably debug back to the larger change.
<nigel_nb> here you go http://paste.ubuntu.com/386829/
<nigel_nb> oh, how do I do it one by one?
<persia> That's just the rule definition (\ indicates not to really break the line)
<persia> What do you have after that, before the next rule?
<nigel_nb> thats the entire file
<persia> I thought you said the file has 1125 lines.
<nigel_nb> that was the make file
<persia> OK.  What was the file from which you generated http://paste.ubuntu.com/386829/
<nigel_nb> oh, you want the next line of make file, ah
<persia> No, I don't.
<nigel_nb> libmpcodecs/ve_x264.d
<nigel_nb> the one that the grep revealed
<persia> I want you to read the next section of the make file, and identify what is done to create libmpcodecs/ve_x264.o based on that rule.
<persia> I'll help if you get stuck, but remember that the goal is to solve the issue, not to give me information.
<nigel_nb> okay, now I get it :)
<persia> (otherwise I'd have downloaded the source and be looking it it myself)
<nigel_nb> :)
<nigel_nb> I'm learning but I'm hungry, tired, and fatigued.  that might contribute to me giving you the info
<persia> Take a break.
<nigel_nb> I've ordered lunch, when it comes I will
<persia> I'd like you to spend 86400 seconds a day fixing bugs, but I'm certain that if you spend 21600 seconds well rested and well-fed, you'll get more done.
<nigel_nb> this line is a declaration right "SRCS_MENCODER-$(FAAC)" ?
<nigel_nb> persia: I will from tomorrow, my work timings change :)
<persia> nigel_nb: That's just a variable.  It might be a declaration or a use.
<nigel_nb> so, now, I have to figure out the line in the make file, that executes all these ?
<nigel_nb> what is the variable name there?
<nigel_nb> is it SRCS_MENCODER or is it X264?
<persia> It depends.
<persia> The value varies based on the expansion of the referenced variable.
<nigel_nb> because I feel strange reminders of Cpp, like object.variable
<nigel_nb> so probably "OBJS_MENCODER  += $(addsuffix .o, $(basename $(SRCS_MENCODER)))" has some significance?
<persia> Oh, most likely :)
<persia> nigel_nb: If you haven't before, you might want to read the Make manual.
<persia> It's fairly well written, and will help you understand this.
<nigel_nb> thats a good idea, I haven't.  reading now
<persia> It will also help with debian/rules files.
<lifeless> or scar you for life.
<lifeless> Probably help you.
<persia> That too, but I don't usually advertise that feature :)
<lifeless> I know one person ended up writing lisp.
<lifeless> in GNU Make
<persia> That's brilliant!
<nigel_nb> persia: I absolutely cannot make any sense of this mess.  I give up :(
<lifeless> see, scarred for life
<nigel_nb> lifeless: not the make help
<nigel_nb> I'm talking about the makefile
<lifeless> nigel_nb: I was finishing the sub-thread with persia
<persia> nigel_nb: Read the manual.  Have lunch.  Come back later.  I'll walk you through it.
<nigel_nb> lifeless: ah, apologies
<nigel_nb> that does sound better than staring at a terminal.
<nigel_nb> persia: Just realized.  I've been awake for 22 hours now.
<persia> nigel_nb: Then set it aside, have lunch, finish your day, and get your schedule adjusted.
<persia> That is, unless you think better on little sleep.
<nigel_nb> nope.  I'm more determined to finish this and sleep or I'll not get a peaceful sleep
<persia> OK.  Come back after lunch then, but do take a break and at least skim over the manual, especially about variables and built-in functions.
<nigel_nb> what are you talking about variables?  I dont see it here
<persia> http://www.gnu.org/software/make/manual/make.html#Using-Variables
 * persia meant the full manual, not just the output of `man make`
<nigel_nb> I'll go through it after lunch.
<nigel_nb> persia: I'm back after lunch and brief run down through the manual :)
<persia> Excellent.
<nigel_nb> now, I can make sense of the make file :)
<nigel_nb> (at least parts of it)
<persia> Even better :)
<persia> So, can you determine which commands are *supposed* to generate the failed .o file?
<nigel_nb> is it MENCODER_DEPS = $(OBJS_MENCODER) $(OBJS_COMMON) $(COMMON_LIBS)
<nigel_nb> that seems to be the one line all the += ends in :)
<persia> No.
<persia> So, basically makefiles consist of a set of targets.
<nigel_nb> yes
<persia> You can set variables and do conditional things, and define functions, and all sorts of fun and games, but generally it's all about the rules.
<nigel_nb> hm
<persia> There exists a rule to build libmpcodecs/ve_x264.o
<nigel_nb> huh?
<persia> And that's the file that didn't get generated, right?
<nigel_nb> yes
<persia> huh? at what?
<nigel_nb> There exists a rule to build libmpcodecs/ve_x264.o
<persia> So a rule is defined as a line starting fully left-justified that contains a colon.
<persia> So the rule to build libmpcodecs/ve_x264.o is at http://paste.ubuntu.com/386829/
<persia> Or at least that's the rule declaration.
<nigel_nb> yes
<persia> They syntax of makefiles, conditionals and variables and the like aside consists of target declarations followed by sequences of shell commands required to generate the target
<persia> (or at least do something related to the target: it doesn't always result in an output file, although it usually does : read about .PHONY and .SECONDARY and similar in the make manual for more info)
<persia> So, since you have found the target declaration, you can find the sequence associated with that target.
<nigel_nb> yes
<persia> By executing each command in the sequence in order, you can replicate the behaviour make would take to create the target.
<persia> And if there is an issue, you can debug the issue with the specific command that is causing the issue, rather than dealing with the huge build system.
<nigel_nb> which is what you've been urging me to do
<persia> Yes :)
<nigel_nb> and I've been stuck figuring out how it is supposed to be done + what is the exact line
<persia> But I realise that there may be a gap between what I request and what is understood, so please ask lots of questions along the way.
<persia> OK.  Are you still stuck?
<nigel_nb> I think I figured out the line which does the actually making
<nigel_nb> this is what I have understood, all the rules go to one variable.
<nigel_nb> which is then converted to an object
<nigel_nb> and then equated to a buld_dep variable
<persia> I think our semantics are different.
<persia> Because that doesn't make any sense to me
<nigel_nb> its probably because you understand the code and I dont, at least not well
<persia> So, build-dep is completely independent.  It just controls what's available on the system at the time the build happens.
 * persia has never looked at this particular code
<nigel_nb> SRCS_MENCODER will end up containing all the rules.  Yes?
<persia> I define an object as some binary blob (libmpcodecs/ve_x264.o in this case).
<persia> A rule creates that object.
<persia> TO me, a "rule" consists of a target declaration *and* the sequence of commands run for that target.
<nigel_nb> SRCS_MENCODER-$(X264)             += libmpcodecs/ve_x264.c in this statement, what would you call SRCS_MENCODER?
<nigel_nb> a variable, yes?
<persia> A string
<nigel_nb> (I'm trying to understand the whole thing before I actually think of how its going to be done)
<persia> I'd call "SRCS_MENCODER-$(X264)" a variable name.
<nigel_nb> oh, the entire thing only will be a variable.
<persia> I'd call "SRCS_MENCODER-$(X264)             += libmpcodecs/ve_x264.c" an additive assignment to a variable
<persia> Right.
<nigel_nb> is it something like an array or list?
<nigel_nb> like everything under SRCS_MENUCODER can be called together?
<nigel_nb> like we would for a C array
<persia> Depends on how it's called.  Generally variables either contain strings or lists.
<persia> A list can be treated as a string or an array depending on what function consumes it.
<nigel_nb> what I'm trying to ask is about what happens in this statement OBJS_MENCODER  += $(addsuffix .o, $(basename $(SRCS_MENCODER)))
<persia> Do you want a raw explanation, or information on how to unpack it so you can look up the answer to this question in the manual next time?
<nigel_nb> information on how to unpack it
<persia> OK.  So it's nested.
<persia> At the top level, we're appending to the variable OBJS_MENCODER (that's the +=)
<nigel_nb> okay
<persia> What we're appending is the result of the addsuffix function called with the arguments ".o" and "$(bas..."
<persia> $(basename ...) is another function call.
<persia> And it takes as an argument the value of the variable SRCS_MENCODER
<persia> So, look up the basename function in the manual.
<nigel_nb> ah, it gets the names of all the file names
<nigel_nb> so we just get all the file names and add an .o at the end and add it to OBJS_MENCODER
<persia> Almost.  basename also strips the last bit off, so foo.c becomes foo.o
<nigel_nb> yeah, so file name - the extension
<nigel_nb> basically, we're changing the extension.
<persia> Right.
<persia> For each file in the list in SRCS_MENCODER
<nigel_nb> so this is also part of whats wrong for me.
<nigel_nb> since I dont seem to be getting a .o for one file
<persia> nigel_nb: But you have a completely separate rule that creates that file, so you don't care.
<nigel_nb> ah, ok
<nigel_nb> following along, is this statement
<nigel_nb> DEPS = $(filter-out %.S,$(patsubst %.cpp,%.d,$(patsubst %.c,%.d,$(SRCS_COMMON) $(SRCS_MPLAYER:.m=.d) $(SRCS_MENCODER))))
<nigel_nb> persia: what does EXSUF mean in mencoder$(EXESUF): $(MENCODER_DEPS) ?
<persia> It's a variable.
<nigel_nb> that is the make statement, right?
<nigel_nb> the colon and all
<persia> That's a target declaration.  It claims that in order to construct  mencoder$(EXESUF) it needs $(MENCODER_DEPS) to be present
<nigel_nb> ah, okay :)
 * nigel_nb still can't find the make statement. :(
<persia> What kind of statement are you looking for?
<nigel_nb> oh
<nigel_nb> install-%: %$(EXESUF) install-dirs
<nigel_nb> does that make sense as a make rule?
<persia> Yes.
<nigel_nb> finally, I understand this stuff.
<persia> It creates a series of rules install-% and each of them depend on a different ${EXESUF} and on install rules.
<nigel_nb> so how will I locate where my problem starts?
<persia> You already did that :)  It's from http://paste.ubuntu.com/386829/
<nigel_nb> its from there down to the last install line, anything could have gone wrong?
<nigel_nb> sweet!  It'll probably take another few hours to figure out where i went wrong
<persia> No.
<nigel_nb> My guess is that something wrong in the first file itself
<nigel_nb> which is then ending up as a problem down below when making
<persia> Either your initial work was incorrect, or the thing that went wrong is between there and the next target declaration
<persia> Makefiles have no reason to execute sequentially
<nigel_nb> um, meaning
<nigel_nb> ?
<persia> OK.  Make is a functional programming language, rather than a procedural programming language.
<persia> So one defines a set of functions that interact.
<persia> The order is only important if there are parse-time dependencies.
<nigel_nb> I still dont see anything wrong then :(
<persia> But at runtime, the order of the targets is completely unimportant (although the order of each sequence is important)
<persia> OK.  Paste the target declaration and sequence starting from http://paste.ubuntu.com/386829/
<nigel_nb> i.e., from the make file?
<persia> Yes.
<nigel_nb> http://paste.ubuntu.com/386892/
<persia> nigel_nb: That's a set of variable definitions.  It doesn't look like a sequence.
<nigel_nb> persia: I dont understand the difference, at least in the case of this file.
<persia> nigel_nb: So http://paste.ubuntu.com/386894/ is a basic makefile (except make likes tabs)
<nigel_nb> here's the entire make file http://paste.ubuntu.com/386895/
<nigel_nb> I think line 886 from the second pastebin is what you need then
<persia> Not at all.  That's the install rule.
<persia> (or I'm reading it wrong)
 * nigel_nb is sooo lost 
<persia> Now I'm confused.  Where did http://paste.ubuntu.com/386829/ come from?
<nigel_nb> see line 694
<nigel_nb> the pastebin is the content of libmpcodecs/ve_x264.d
<persia> Yes, but where did you get the text in http://paste.ubuntu.com/386829/
<nigel_nb> libmpcodecs/ve_x264.d
<nigel_nb> we did a grep for something and this turned up
<persia> Aha.  I had thought that was from a Makefile all along, which may have added to the confusion :)
<nigel_nb> We did a grep for ve_x264.o and this file turned up in the result
<nigel_nb> well, I was reading out the proper code for you then :/
<persia> anyway, we're creating a .o file, so the rule at line 803 is the one we want.
<persia> Do you have the .m file?
<nigel_nb> aha
<nigel_nb> it would be in the same dir?
<persia> Most likely yes.  Doing it otherwise requires extreme hackery
<nigel_nb> its not there
<persia> Are other .m files present?
<nigel_nb> find . -name '*.m' results in ./libvo/vo_macosx.m
<persia> That's not enough :)
<persia> Try `make libmpcodecs/ve_x264.m` to see if that generates it.
<nigel_nb> make: *** No rule to make target `libmpcodecs/ve_x264.m'.  Stop.
<persia> Hrm.  And libmpcodecs/ve_x264.m doesn't exist?
<persia> OK.  That might be the issue.
<nigel_nb> doesnt exist
<nigel_nb> well, if there were it would have turned up in my find command anyway
<nigel_nb> I must be really tired
 * nigel_nb edits
<nigel_nb> well, if it were there, it would have turned up in my find command anyway
<persia> nigel_nb: Next try: read http://www.gnu.org/software/make/manual/make.html#Catalogue-of-Rules
<persia> When the rule doesn't appear in a makefile, sometimes it's one of the implicit rules.
<nigel_nb> hm, so something is wrong with the make part?
<persia> Hrm?
<nigel_nb> oh, sorry.
<nigel_nb> I get the point nw.
<persia> I don't think anything is wrong with the makefile.  We just want to figure out how to build the failure manually.
<nigel_nb> ah, yes
<nigel_nb> so you want me to apply the c command for this one?
<persia> Try it.
<persia> If everything we've found to date is correct, you'll get an error message.
<persia> But we hope this message helps us understand why it fails to build.
<nigel_nb> um, what do I do in the terminal?
<nigel_nb> how do I type the rule in?
<nigel_nb> persia: I didn't understand how Im supposed to apply it :(
<persia> nigel_nb: So the manual says "n.o is made automatically from n.c with a command of the form `$(CC) -c $(CPPFLAGS) $(CFLAGS)'. "
<persia> $(CC) is probably gcc.
<nigel_nb> okay
<nigel_nb> so I type "gcc -c ...." ?
<persia> CFLAGS is constucted from the various bits starting at line 850 in the makefile
<persia> CPPFLAGS is not found.
<persia> nigel_nb: It appears to me that none of the entries between lines 850 and 880 apply to this file.
<nigel_nb> I was about to ask you that
<nigel_nb> so a simple gcc filename.c?
<persia> nigel_nb: So just `gcc -c -o libmpcodecs/ve_x264.o libmpcodecs/ve_x264.c` ought be close.
<persia> (unless CFLAGS was defined in debian/rules
<nigel_nb> a huge bunch of errors
<persia> Excellent.  That's the problem :)
<nigel_nb> mostly due to header files not found
<nigel_nb> I think like 853 of the make file could be causing those header file issues
<persia> So now compare the contents of the package that used to be in build-depends and the contents of the package now in build-depends.
<persia> Well, was that changed in the upload that added the nvidia-specific build-dep?
<nigel_nb> compare what?
<nigel_nb> contents = source?
<nigel_nb> persia: how do I ask gcc to include a few header files at build time?
<nigel_nb> that is the source of the errors I just saw
<nigel_nb> $(DEPS) $(MENCODER_DEPS) $(MPLAYER_DEPS): codecs.conf.h help_mp.h version.h
<nigel_nb> the 3 headers mentioned are missing
<persia> nigel_nb: Download the two .deb files for the two competing build-dependencies.
<persia> Use dpkg --contents to see what they contain.
<persia> I strongly suspect that one of them contains the missing stuff, and the other doesn't.
<nigel_nb> NO.  There is a separate issue
<persia> Then, go back to the person who told you it was safe to switch, with your build data and your missing deps, and ask for more guidance.
<persia> What's the separate issue?
<nigel_nb> "codecs.conf.h help_mp.h version.h"
<nigel_nb> these aren't included, but should be.
<nigel_nb> they are meant to be included per the makefile
<persia> nigel_nb: Usually header inclusion is specified at the top of source files, not in makefiles.
<nigel_nb> oh
<nigel_nb> these are the errors
<nigel_nb> http://paste.ubuntu.com/386915/
<nigel_nb> getting debs
<persia> nigel_nb: Some of those errors seem unrelated to the library.
<persia> Is there really no config.h in you partial build tree?
<nigel_nb> ok, wgetting debs
<nigel_nb> Idk
<nigel_nb> whoever told me it was easy seriously underestimated me :/
<persia> well, you're learning.  Go do something else if you want, but I suspect you know *lots* more about makefiles and about debugging build failures than you did previously.
<nigel_nb> thats the +1 to all this
<persia> I suspect you're also a lot more cautious about the idea that a quick build-dep swap is an easy bug :)
<nigel_nb> you taught me about making and build fixing
<nigel_nb> it was supposed to be.
<nigel_nb> how would i know it was tied deep into the source
<persia> No, actually build-dep changes are often tricky.
<persia> It really depends on how the build works, etc.
<nigel_nb> someone shoulda warned me ;)
<persia> Nobody does that here.  Anyone who wants to try to fix something gets a chance to try :)
<persia> Because we all come from different backgrounds, we don't like to tell anyone "That's too hard".
<nigel_nb> ok, what am I looking for in the debs?
<persia> You were going to compare the header contents.
<persia> *but* I don't think you want todo that yet.
<nigel_nb> means, stop it here an say "buddy, I have no clue how to do this?"
<persia> So C sources have two kinds of include.  "foo.h" and <bar.h>
<persia> "foo.h" indicates a local file, and <bar.h> indicates to search for the file in the system headers.
<nigel_nb> yes, one is in lib, one is current directory
<persia> And http://paste.ubuntu.com/386915/ shows a lot of missing headers which look like they are current directory headers.
<persia> Are you sure you are in a chroot that contains a half-built package?
<nigel_nb> yup
<persia> Then I'd recommend starting with trying to figure out why there's no config.h
<persia> That's usually created fairly early in the build, and before the issue you're encountering.
<persia> YOu may want to look at your local build log to see if the gcc call is different there.
<nigel_nb> how do I do that?
<nigel_nb> (unless I start the pbuilder by calling for logs?)
<persia> For pbuilder, I have no idea.
<nigel_nb> lfaraone: when you come online, can you ack the deletion of the sugar 0.84 packages?
<nigelb> persia: can you sponsor an upload of mine?
<persia> Add it to the sponsors queue.  If I get to sponsoring whilst it's still there, yes :)
<nigelb> its already there
<nigelb> its that username vs short name thing
<persia> Well, someone should get to it soon.  THis is just my most busy evening of the week (and I'm currently in two simultaneous meetings :/ )
<nigelb> 0_o
<dholbach> mok0: "when that d*mn archive-reorg is finalized, perhaps we can start work again" makes it sound like work was blocked?
<mok0> dholbach: yes...
<dholbach> which work was blocked?
<mok0> In my head
<dholbach> I'm not sure I understand
<mok0> ... and also the heads of others
<mok0> dholbach: it
<mok0> dholbach: it's kinda like... when you know you've been thrown out of your appartment at the end of the month, you don't plan painting the walls and getting your rooms nice and livable
<mok0> :-)
<dholbach> mok0: there has been back-and-forth with Permissions Reorg and things that weren't clear which is very unfortunate and it's been dragging on, but nobody was every going to get thrown out of their appartment
<mok0> dholbach: yeah....
<dholbach> mok0: I'm not having a go at you now or anything, I'm just very surprised that if there is frustration it was never brought up anywhere else before
<mok0> dholbach: Oh, I have
<mok0> dholbach: ... and I know others are frustrated too
<dholbach> I can't remember it having been on ubuntu-devel@ or in a TB meeting or anything
<dholbach> frustrated about what exactly?
<mok0> dholbach: seeing the team disbanded without a replacement
<mok0> dholbach: not knowing what the future of the team is
<mok0> dholbach: not being able to make initiatives are start new things, because the team is ending
<dholbach> I was lying before, I just remembered that Scott brought it up in a thread somewhere
<persia> It's been a regular feature of traffic in this channel since UDS Jaunty
<mok0> dholbach: yes he did, encouraged by a chat here on IRC
<persia> mok0: Do you think we're getting enough clarity now?
<dholbach> in any case I think it'd be good to discuss the plans for the future together now
<mok0> persia: I've been away for a week, so I haven't followed the latest
<mok0> dholbach: I still don
<mok0> I still don't know where I belong in the new structure
<persia> mok0: Just (slow) discussion in the email threads, with sporadic queries as to who does what on IRC.  Laney got the CLI/Mono team approved.
<persia> mok0: Where do you want to be?
<mok0> persia: what are the choices?
<dholbach> mok0: the email thread is good to follow up on
<persia> mok0: MOTU, core, kernel, ubuntu desktop, kubuntu, mythbuntu, CLI/Mono, or any combination of the above.  If the selections aren't wide enough, request another option.
<dholbach> maybe there should be a short summary of it ;-)
<dholbach> and a "this is decided" and "this needs decision" and "this needs proposal"
 * persia is incapable of writing a "short summary"
<dholbach> persia: we all know ;)
<mok0> persia: I am very interested in science packages, but I have a very long experience as a sysadm, and I have fiddled with all possible kinds of software, also server- side
<persia> mok0: Well, there's an active server team.  I don't know why they haven't requested to have separated upload rights.  You could probably convince them to set it up and join.
<dholbach> in any case the motu team is going to stay
<persia> For science, you might want to leave that with MOTU, or contact other interested parties and set up a Science team.
<Laney> I wonder if it would ever be appropriate for motu to be a member of a package set upload team
<Laney> or would it just not be worth forming a team in that instance?
<persia> Laney: I'd hope not.
<mok0> persia: The I'd want to continue with MOTI
<mok0> MOTU
<persia> My personal preference for MOTU is to concentrate on the overall health of stuff, and the more packages that dedicated teams are willing to manage, the better for MOTU.
<persia> mok0: In that case, you don't have to do anything at all :)
<persia> mok0: You are already MOTU, so jump into the discussions and help craft our future.
<mok0> persia: ah. OK. /me likes that
<persia> We have a definition approved by the DMB and TB, but we still need to figure out operational stuff, like how we govern ourselves, and how we manage our mandate, etc.
<persia> (see the "Future of MOTU" thread on the mailing lsit)
<mok0> persia: My postings to the list today reflect what I'd like to work with: REVU (alias public relations) and documentation
<persia> There you go then :)
<mok0> persia, dholbach, now you are both here , we could briefly discuss documentation?
<persia> Sure.
<mok0> AFAIU, the doc team has more-or-less decided to go to Mallard for lucid+1
<mok0> That is why I did dare to suggest it for MOTU docs
<mok0> But the main reason is that the Wiki is really impossible to maintain
<mok0> partly because you don't know what's there
<mok0> ... and because that web based editor system sucks big time
<Laney> Yeah, we would benefit from some light gatekeeping here IMO
<persia> mok0: editmoin can help a bit, but yeah, I agree with most of that.
<dholbach> Laney: gatekeeping?
<persia> I just think there's some issues that need resolution before we can switch.
<dholbach> Laney: which contributions do you want to gatekeep?
<mok0> Having the docs in a directory tree on your machine, where you can use your favourite editor would help a lot
<dholbach> there's really not a lot going on in terms of people contributing
<Laney> Well, maybe not gatekeeping, but coordination.
<dholbach> ok
<mok0> Laney: that would be easy to do if the docs were in a bzr branch
<mok0> You could work on your little corner
<Laney> right
<dholbach> it might be good having a chat with nhandler, Augustina and in general the docs team
<Laney> I guess it would become something like devref or newmaint?
<persia> mok0: So, let's take the ase assumption that we all agree with the benefits of the change.
<Laney> is that what you have in mind?
<persia> mok0: Could you help address the issues I raised?  How can we make those less painful?
<mok0> persia: let's see...
<directhex> hm
<mok0> persia: Ad 1) of course we need to identify the MOTU specific docs
<persia> I think dholbach had a good solution for #3.
<dholbach> I set up the ~packaging-docs team a while ago but unfortunately didn't have the time to put more work into it, but it has a number of people who are interested in helping out with package docs
<dholbach> and there's already a mail archive with a bit of discussion
<persia> mok0: Are there any?  I really think there's about 4 pages.  Maybe 5.
<mok0> persia: huh? All the packaging stuff for newbies?
<directhex> WRT freezes: is it better to upload a monodevelop 2.2.1+dfsg-1ubuntu1 package with a new binary (monodevelop-moonlight) with unsatisfiable deps, or wait for the mozilla team to upload all the xulrunner 1.9.2 stuff they've been doing which i'm blocking on?
<persia> mok0: Isn't MOTU specific.
<mok0> persia: who's gonna maintain it?
<persia> directhex: Ask in #ubuntu-release
<persia> mok0: All the developers.
<persia> mok0: Specifically, MOTU is no longer the gateway for new folk.
<persia> (although some new folk may come to MOTU)
<mok0> persia: Then I should s/MOTU/Devs/
<nigelb> persia: MOTU isn't?
<persia> That's the entirety of my point 1, and to take it to a different ML :)
<persia> nigelb: No.
<nigelb> persia: so what is the path for new developers?
<dholbach> s/no longer the gateway/no longer the only entrypoint
<nigelb> contributing developer?
<persia> nigelb: If you want to work on Kubuntu or Ubuntu Desktop, or Mythbuntu, you can do so directly, without working with MOTU.
<dholbach> to sound a little bit less dramatic
<persia> nigelb: There's *lots* of paths.
<mok0> persia: Ad 2) the very team specialized docs should be taken care of by that team.
<persia> mok0: For 2) my issue was mostly about coordinating with other teams.
<persia> I very much want to see good relations and shared memberships between developers, testers, and bugsquad.
<artfwo> persia, you told me once, that debian/ubuntu use fake sonames if there are none provided by upstream. what's the right soname version to substitute then? is lib.so.0d okay?
<nigelb> persia: now its totally confusing + I'm lost as to what to be working for
<persia> And I think we have to consider the effect on those teams if we change, and perhaps coordinate with them.
<persia> nigelb: Work on what interests you.  Fix the bugs you want fixed.
<mok0> nigelb: many feel the same way
<persia> artfwo: .0d is what I tend to use.
<nigelb> persia: but what goal am I working to if not MOTU (thats more or less my question)
<artfwo> persia, thanks
<persia> artfwo: Actually, .0d is what I tend to recommend.  I generally complain at upstream to get a SONAME.
<mok0> persia: Ad 3) Even if the docs are in Mallard, the HTML should be published on a known website. Wrt. searching, I don't know how that is possible
<persia> nigelb: There's no reason you *can't* work towards MOTU as a goal if you wish.  There are just several other paths available.
<persia> mok0: Yeah, 3 is easy.
<mok0> persia: Ad 3) We'll have a version of the docs for each supported release
<persia> just needs infrastructure and coordination.
<nigelb> I need to read up then.
<persia> nigelb: We can address this more easily.  What do you like doing best in Ubuntu Development?
<mok0> persia: Ad 4) It's a stumbling block... but Mallard is just another SGML dialect, AFAIR not much different from docbook
<persia> mok0: But back to 2).  How to we ensure easy stable links between documentation for different teams?
<nigelb> persia: Fixing bugs
<persia> nigelb: OK.  Any particular bugs?
<nigelb> persia: anything thats easy but more or less oriented to desktop
<persia> mok0: 4) is just pain, so the benefits have to be strong enough to be worth it (which may be possible).
<mok0> persia: I don't have a fixed answer for that one. Is it possible to have sub-trees within mallard? I don't know
<persia> nigelb: If you're mostly intersted in Desktop but willing to chase anything, I'd say you'd do well to spend time both here and in #ubuntu-desktop.  Depending one where you land more fixes, you may want to apply to be either MOTU or Ubutnu Desktop Developer.
<persia> mok0: I don't know either.  It's because I don't know that I think we need to do more research before we change.
<mok0> persia: of course, we could make an experiment. Make a test with a small part of the docs and see how it works out
<nigelb> persia: ah, so now, I can directly apply to desktop without being a MOTU
<persia> We used to have the packaging guide in bzr.  We pulled it *out* of bzr and into the wiki because it wasn't being maintained.
<persia> nigelb: Right.
<persia> nigelb: There are now several different paths, depending on your interest.
<mok0> persia: heh.
 * persia thinks this is good and wishes it wasn't quite so confusing
<nigelb> persia: we need a good flowchart
<persia> nigelb: As we no longer accept the concept of hierarchy between different development groups, that gets hard :)
<mok0> uhm, how many conversations do we have going on at the moment?
<persia> mok0: Three.
<mok0> Wow.
<persia> Usually I keep this to multiple channels :)
<persia> Anyway.
<mok0> persia: I know. I've watched you.. impressive  :-
<persia> mok0: So My recommendation would be to investigate the issues around 2) make sure we have good docs for 4) and then approach the wider community to address 1)
<nigelb> mok0: you'll see 3 per channel in around 5 channels ;)
 * persia can only do about 3 before getting mixed up
 * mok0 's head just exploded
<persia> Why?
 * abogani found discussion about Teams really interesting...
 * mok0 is a 1-armed octopus :-)
<persia> Ah.
<mok0> persia: so, what's your opinion about making an experiment?
<persia> mok0: I'd suggest experimenting with writing docs on how to use mallard and bzr to write docs for Ubuntu.
<mok0> persia: of course, it only makes sense if more that just a couple of people contribute
<persia> That needs doing, and it addressed my point 4) and it provdes an example for discussion.
<mok0> dholbach: are you still around? You are happy about the wiki?
<persia> dholbach: Is just better at the wiki than the rest of us
<dholbach> mok0: I'm not saying that I'm happy about the wiki - it's better than it was like 2 years ago, but it lacks some love which would take newcomers by the hand and explain better how one things works with the other and why
<dholbach> mok0: and unfortunately I've had too many other things on my to lead any efforts there
<mok0> dholbach: It's just very, very difficult to motivate people to do something about documentation. I've tried several times, writing a draft, but when I've needed input, things have stopped.
<dholbach> the last thing I did was get input from a few people who are passionate about it and they're on the ~packaging-docs team
<dholbach> I just didn't get around to doing anything
<mok0> dholbach: One thing is writing a draft, I can do that in a couple of hours, but to make full documentation alone takes weeks
<persia> When I write docs, I usually post my draft as official, and tell everyone to help fix it if I'm wrong.
<mok0> I once wrote a "Getting Started" draft, but it was never finished. I ran out of steam ( https://wiki.ubuntu.com/GettingStartedDraft )
<eagles0513875> j ubuntu-mozillateam
<dholbach> I think it'd be important to define what the purpose of the new documents is exactly, which docs can be reused, etc, flesh out a plan and then see who'd be interested and who'd take on which part of the TODO
<dholbach> ... as a start
<dholbach> if there's no interest it probably doesn't make sense to debate it any further on the mailing list :-/
<mok0> dholbach: yeah... but perhaps it would be good to let the ideas simmer a bit before jumping into a huge undertaking
<mok0> dholbach: that why I think it would be good to make an experiment, with a small subset of the documentation. We could see how it works in practice.
<dholbach> right :)
<dholbach> for that I'd probably follow a similar approach :-)
 * dholbach hugs mok0
<persia> mok0: GettingStarted is a particularly rough place to work also, as there's already two competing documents with completely different philosophies.
 * mok0 hugs dholbach 
<dholbach> I think it's great you're spearheading that initiative
 * persia too
<mok0> persia: yes
<mok0> ... so, where would be a good place to put a bzr repo?
<persia> Somewhere temporary.
<mok0> Under what team?
<persia> Because the teams need discussion.
<persia> Maybe it's ~ubuntu-dev
<mok0> persia: you mean, like a +junk branch?
<persia> Maybe it's wider.
<mok0> ah ok
<persia> mok0: I'd suggest starting there, yeah.
<mok0> ok
<persia> And once you get some traction, moving it somewhere sensible.
<mok0> (I filed a bug to get them to change the derogatory +junk to e.g. +user)
<persia> I actually like +junk being derogatory, because it discourages it from being a permanent home.
<mok0> persia, dholbach, I'll think a bit about it, snoop around the wiki, and come up with something to work on
<persia> That said, I've lately just been pushing stuff to people.ubuntu.com instead of using repos.
<dholbach> mok0: awesome
<mok0> persia: There are valid reasons for not creating a big project for something. It doesn't mean it's junk you have there
<nigelb> upstream seems to have changed the a particular dep to recommends, which is causing installation failure in ubuntu.
<mok0> persia: I think it sound childish, unprofessional and stupid with "+junk"
<persia> I guess, but you can't file bugs against people, so I'd rather see projects identified.
<nigelb> changelog confirms it.  anyway to know why it was done?
<persia> Like the sponsoring overview is at a +junk URL, but has a project (and ought move to a real URL soon :p )
<jdong> I thought +junk was a trash directory at first
<mok0> persia: I have branches in +junk that are perfectly useful, but I don't want to distribute them as finished projects, because that entails making it into a distribution with README, Licenses and all kinds of things I don't want to spend time on
<persia> I don't think there's a need for releases just because there's a project.
<persia> But I think we think about these things differently.
<mok0> persia: If you maintain a 20 line python program, would you make a project for it?
<persia> No, but I wouldn't have a branch for it either
<mok0> persia: I still resent that LP calls it junk
<persia> I put stuff like that on p.u.c
<mok0> persia: how does that work? Never used it
<persia> mok0: sftp mok0@people.ubuntu.com
<mok0> persia: but it's not a bzr repo?
<persia> No.
<persia> I don't see the point for small scripts, really.
<mok0> persia: I see.
<persia> I suppose you *could* put a bzr repo there if you figure out how to push bzr over sftp.
<mok0> persia: I maintain everything in bzr or git these days
<persia> bzr pulls over http just fine.
<james_w> bzr push sftp://mok0@people.ubuntu.com/home/... ?
<mok0> persia: I like the functionality of LP, I just resent the fact that the call my software junk. That's all
<mok0> james_w: hm
<mok0> james_w: I guess it's useful for stuff you don't really want or need to advertise
<persia> Well s/home/public_html/
<hyperair> mok0: what a blasphemous comment about your software!
<mok0> hyperair: indeed!
<hyperair> heresy! kill them with fire!
<mok0> :-)
<hyperair> ;-)
 * mok0 is sensitive
<hyperair> who wouldn't be, about their software? =p
<nigelb> I'm just posting again.  A few changing to control were made in debian wrt to dependancies.  Changelog doesn't mention why, but those changes are causing breakage in Ubuntu, okay to fix it back?
<james_w> persia: no
<persia> james_w: No?
<persia> Aha, /home/mok0/public_html/ ... _
<james_w> yes
<james_w> newer bzr you can put ~ in
<james_w> but it's not like sftp
<mok0> Hmm, you can't ssh there
<persia> Only sftp.
<persia> scp fails too (which catches me often)
<nigelb> superm1: the mplayer depends issue that we talked about earlier today, I ran into build troubles that I couldn't fix
<jdong> sftp:// has always supported ~ in bzr, for a while now.
<jdong> bzr+ssh and ~ is new in 2.1.0
<mok0> persia: hm, sftp still denies me access... I need to upload my ssh public key somehow
<Laney> it gets it from launchpad
<mok0> Laney: apparently not
<persia> Supposed to do.  If not, go ask why not in #canonical-sysadmin
<mok0> persia: ok
<mok0> persia: you're supposed to be able to use sftp's interactive mode, right?
<persia> mok0: I have used it, so I presume so.
<Laney> I have a bookmark for sftp://laney@p.u.c in nautilus
<mok0> Laney: cool
<mok0> Laney: does that work in dolphin I wonder
 * hyperair too
<persia> Ought do.
 * iulian is interested in science packages as well.
<persia> showard (our new Contributing Developer) also.
<iulian> mok0: I'm wondering how many science packages are in the archive.  I'm also interested if it's worth creating a team.
<randomaction> there's a "MOTU science" team, FWIW
<randomaction> and here's a list: http://qa.ubuntuwire.com/multidistrotools/science.html
<iulian> Ah, right, forgot about multidistrotools.  Thanks randomaction.
<randomaction> Looks like ~600 of them, that's a lot.
<randomaction> 700 even
 * iulian nods.
<hyperair> isn't there a debian science team? should get some ubuntu devs in there and interface with them =p
<iulian> hyperair: I'm currently a member of that team.
<hyperair> oh cool =p
<ScottK> So is mok0, IIRC.
<mok0> iulian: it came up on the ML
<mok0> hyperair: I'm in the debian science team
<iulian> mok0: What came up and where? :)
<mok0> iulian: Creating a "science" team
<mok0> iulian: it came up on the Teams ML
<mok0> iulian: I don't think the team has enough traction
<iulian> mok0: Oh.  I'm not subscribed to that ML, unfortunately.
<mok0> iulian: I know
<iulian> mok0: Indeed.  It appears that the Debian science team is not pretty active as well.
<iulian> mok0: And if I'm not wrong, ~motu-active is not active at all.
<mok0> iulian: right. Full of busy scientists I guess :-)
<iulian> s/motu-active/motu-science/
<iulian> Possibily.
<mok0> iulian: there are 5-10 ppl in the team; my impression is that they do take care of the science packages
<iulian> s/possibily/possibly/
<iulian> mok0: I used to look after science packages before I was a motu but it seems that I lost interest.
<persia> Based on todays DMB meeting, I believe there is special attention paid to those 6-700 packages.
<iulian> mok0: Anyway, I'm now interested again. :)
<mok0> persia: can you elaborate?
<mok0> iulian: you wanna be a member again? \o/
<persia> mok0: showard applied for Contributing Developer, and had a good story to tell about work on science packages.
<mok0> persia: good for him!!
<mok0> showard was the one asking about a new science team
<persia> That's what I thought :)
<persia> But if folk are talking about reviving the science team, makes sense to include him.
<mok0> persia: he already is in motu-science
<iulian> mok0: Yea, sure.
<persia> The list may need review/pruning if it's to be granted separated upload rights.
<persia> (depending on current membership, etc.)
<mok0> Well, if interest can be raised for a science team, I am all for it
<mok0> persia: Indeed
<kamalmostafa> fwiw, I also recently joined the motu-science team, and my level of interest/activity in maintaining the science packages is quite high.  :-)
<iulian> Excellent!
 * iulian dances.
 * mok0 jumps
<persia> heh.  "Ubuntu Science Developers" gets closer to reality every moment.
<kamalmostafa> otoh, since I've not earned "Contributing Developer" stature, I think I'd be one of those that would need to be "pruned" due to the upload rights issue.
<mok0> How granular is the "per-package" upload rights?
<mok0> Can it be a single package, or two?
<persia> mok0: Yes.
<persia> mok0: Why?
<mok0> persia: Because that may be a good way to start contributing developers
 * persia much prefers to see teams work on packagesets than to see individuals work on specific packages
<persia> I really think that'sw a bad idea.
<persia> I don't like the idea of people "maintaining" packages.
<persia> Ubuntu is about collaboration.
<persia> I'm more than happy to see teams with lots of packages and several members, because that's still collaboration.
<persia> And there's cross-team collaboration.
<persia> But I think "Here, go take care of this package" is a poor model.
<persia> I'd rather say "Help the team by doing as much as you can for this package" and go through sponsoring and point the interested developer at another package.
<mok0> persia: I think it may be a good way for ppl to get introduced to a team.
<persia> mok0: By granting upload rights?
<mok0> persia: yes
<persia> mok0: How doesn't sponsoring work?
<persia> And further, how doesn't sponsoring *increase* coordination with other team members?
<mok0> persia: that would work for all the other packages that person touches
<persia> But why not start them touching all of them through sponsoring?
<persia> And then grant them upload to all of them once they show their skills (both social and technical)?
<persia> To me, that's the Ubutnu way.
<persia> No one-person-one-package stuff.
<mok0> persia: I think it motivates people to slowly progress getting more and more upload rights
<kamalmostafa> I agree with persia - the sponsorship process has been extremely useful to me, and I'm very glad that I've been "forced" to use it.
<mok0> ok...
<persia> mok0: I think people who are motivated like that should work in Debian :)
<kamalmostafa> Had I been granted upload rights for the packages I've been taking care of, I would probably still have gotten the job done, but would have missed learning a lot of important procedural things that get passed down by "word of mouth" via the sponsorship process.  just my $0.02.
<mok0> kamalmostafa: if you're happy I'm happy :-)
<persia> kamalmostafa: Your opinion is probably the most important, as you're currently the one experiencing that side of it.
<persia> We can only guess as to how it's received.
<persia> (and may well guess wrong because of historical disparities in main/universe sponsoring)
<mok0> persia: ... I am just a wee bit concerned about how these teams will work in practice. Currently, I am a member of I don't know how many teams, and none of them require anything or grant any privileges (apart from -dev)
<MTecknology> hurray, my schedule is clearing, I might have some time to make those packages if I fix some bugs next week :D
<persia> mok0: I think it depends on the individual.  I'm fairly comfortable being simultaneously in several teams.
<mok0> persia: I mean... what is _really_ the point of a team if all it offers is an emblem on your LP page?
<persia> mok0: coordination within the team, communication channels, perhaps meetings, etc.
<persia> If it's just am emblem, there's little point.
<persia> For most of the teams in which I participate, we have meetings (sometimes weekly, sometimes monthly), and set out lists of stuff to do.
<mok0> persia: mailing list membership, to mailing lists without any activity...
<persia> Then we do it, coordinating in IRC channels or mailing lists.
<persia> mok0: You're being pessimistic :)
<mok0> persia: I know
<persia> mok0: The point is to have *active* teams.
<persia> If a team isn't active, there's no point to the team
<mok0> persia: yeah, so my concern is, how to achieve that?
<persia> (which is why, although it was a constant example during discussions, the ubuntu java team has not yet and may never apply for upload permissions)
<mok0> persia: so, I may be old fashioned, but I think that a mix of rights and duties interest people
<persia> mok0: It gererally requires 3-4 motivated central members who are very active and constantly work to attract more folks.
<persia> Teams seem maximally effective around 10-12 people.
<mok0> persia: Probably
<persia> There's a lull there, and they get effective again around 20.
<persia> From there isn't mostly downhill to somewhere in the 100-150 range, after which if the team doesn't split, most folk won't consider it a primary identity.
<mok0> 150 rings a bell
<mok0> maximum network capacity kind of thing
<mok0> Dunbars number?
<mok0> Mmm
<persia> Indeed.
<persia> Some people think that the real value of Dunbar's Number is lower for groups with less tight-knit social interaction (such as distributed online teams).
<mok0> ... uhm, I don't think we have to worry about hitting that number
<persia> The loweest I've seen claimed is 60, but I think that's overly pessimistic.
<mok0> !50 in one group without sub-groups seems a bit large to me
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<persia> As developers we did, or hit some limit, at which point growth slowed or ceased.  My memory was that it was at about 100 that the system started to fall apart.
<hyperair> what system?
<mok0> hyperair: group identity or whatever
<hyperair> huh?
 * hyperair stares blankly
<mok0> hyperair: we're talking about Dunbar's number
 * hyperair starts wiki-ing
<persia> hyperair: When we had 80-90 developers, we had lots of active collaborative teams, a smooth process to get new folk in, lots of new folk (successfully) joining, etc.
<hyperair> ah i see.
<persia> Once we got to to somewhere in the 106-108 range, things started to really break down.
<persia> A lot of the subteams went quiet or inactive.
<mok0> persia: To be fair, it also is a function of how those individuals feel about the project.
<persia> The rate of developer applications slowed
<persia> etc.
<persia> mok0: Very much so, and there could have been other things that happened around the same time.
<mok0> persia: Even a well functioning team can get worn out
<persia> I just find the coincidence interesting.
<hyperair> users being too satisfied with a product can also lead to them not turning into developers ;-)
<hyperair> i started on ubuntu development because i was dissatisfied with something.
<persia> Especially because the big complaint then was that people were having difficulty keeping track, and that complaint hasn't gone away since.
<hyperair> something or other broke and i was impatient.
<mok0> hyperair: did you fix it?
<hyperair> mok0: yeah, that was my introduction to debian packaging.
<mok0> hyperair: I'm glad you stuck around :-)
<hyperair> mok0: i didn't at first, you know? i came back =p
<mok0> hyperair: Ah, even better
<hyperair> =p
<hyperair> mok0: but yeah, you see, if ubuntu had been that perfect product at that time, i wouldn't have touched ubuntu development at all.
<mok0> Most people I know who have used Linux stick around
<hyperair> mok0: it's not that i moved away from linux, it's that i moved to archlinux and came back when i realized my archlinux was growing to be an ubuntu with a different package manager.
<hyperair> my archlinux installation i mean
<mok0> hyperair: ... it appears that the things that need fixing are more and more specialized
<mok0> hyperair: I.e. drivers and stuff
<hyperair> mok0: i can see why.
<mok0> hyperair: Yeah, some industries don't want to give back to Linux
<mok0> hyperair: I'm stuck with a stupid, unsupported Intel graphics driver in my netbook
<hyperair> mok0: there's that, yeah, but there's also the fact that not many people can hack on drivers or even write drivers from scratch.
<mok0> hyperair: Indeed.
<mok0> hyperair: especially since the hardware docs are secret
<hyperair> mok0: the difference between the number of people who know how to program userspace C programs and kernelspace things is vast.
<persia> mok0: I was at a conference last weekend, and there was a talk from MeeGo.  Apparently they have a PSB driver for modern X and kernel.  Dunno if it can be ported.
<mok0> hyperair: ... or you need some proprietary binary blob for it
<hyperair> mok0: right. exactly.
<mok0> persia: Aha!!!
<hyperair> mok0: and the bulk of our new developers touch userspace things mostly.
<mok0> hyperair: yes
<hyperair> stuff like hibernation still leaves much to be desired =)
<hyperair> but nobody really knows how to touch that code
<hyperair> well nobody new
<hyperair> there's always tuxonice, but mainline is so resistant to it.
<mok0> hyperair: Hibernation only works on Macs
<hyperair> mok0: that's no true
<hyperair> not*
<mok0> hyperair: only works *well* on Macs
<hyperair> mok0: hibernation works *well* on my laptop, just not as reliably as i'd like it to.
<mok0> hyperair: exactly.
<hyperair> the failure rate is 20%
<mok0> hyperair: on my mac, the failure rate is 1%
<hyperair> =O
<mok0> hyperair: ... and wireless is up in 5 seconds after I open it
<hyperair> mok0: mac os?
<mok0> hyperair: yes
<hyperair> mok0: or linux on mac
<mok0> OSX
<hyperair> well windows has a pretty reliable hibernate as well
<hyperair> and it's pretty damn fast too
<hyperair> just that windows + long uptime = fail.
<mok0> hyperair: that's hibernate. On the mac it's more like suspend, except it uses almost no power
<hyperair> mok0: huuh? seriously?
<hyperair> mok0: how do they achieve that?
<mok0> hyperair: don't know. But I think it's recognized that they do it much better than Windows and Linux
<hyperair> mok0: not surprising, they get full control over their hardware.
<mok0> hyperair: I can't leave my Dell mini 10 with the lid close over night without it loosing power
<hyperair> mok0: okay, that sucks. my lenovo can last longer than that.
<mok0> hyperair: I _have_ to shut it down
<mok0> hyperair: ... or leave it plugged in, which is what I usually do
<mok0> hyperair: when I open it (runs jaunty) it takes almost a minute before network comes up
<hyperair> mok0: i haven't actually tried testing my battery with standby, but from 50%, i've gone out for around half a day and came back and it's fine.
<hyperair> i'm not willing to stay away from my notebook long enough for it to drain the battery on standby >_>
<mok0> hyperair: how long do they last on continuous use?
<hyperair> mok0: 4h
<hyperair> mok0: it only jumped up to this duration in recent ubuntus.
<hyperair> i think around intrepid
<mok0> hyperair: my netbook claims it has ~2.5 h
<hyperair> prior to intrepid, 2h was lucky.
<mok0> hyperair: if I close it, and leave it overnight, it's dead
<hyperair> mok0: sucky battery =D
<mok0> hyperair: could be
<hyperair> my wireless comes on instantly after resuming, by the way.
<hyperair> it even does the WPA authentication and all
<mok0> Hm, must be some driver thing then
<hyperair> and that's after pm-utils unloads iwlagn and reloads it
<hyperair> i put that line during the time iwlagn was buggy. i think it isn't so buggy these days so i should probably remove it
<mok0> hyperair: well I am using an unsupported driver from a PPA somewhere
<hyperair> mok0: why are all your drivers unsupported?
<hyperair> mok0: go poke some dell fellows
<hyperair> mok0: we have some in our ranks.
<mok0> hyperair: because they are not supported from Intel
<hyperair> =\
<hyperair> that sucks.
<mok0> hyperair: Dell offers a hardy version of the driver
<hyperair> mok0: bleargh. source code?
<mok0> hyperair: but last I heard, it was incompatible with newer kernels and not maintained by intel. Some ppl made it work with jaunty
<mok0> hyperair: source code unmaintained by intel, and binary blobs as well
<hyperair> mok0: why did you even get that machine? =\
<hyperair> mok0: it sounds like a tarball of pain
<mok0> hyperair: Now persia says the drivers have been revived for MeeGo
<mok0> hyperair: I will check up on that... I believe persia also has a poulsbo machine
<hyperair> poulsbo, you say?
<mok0> hyperair:  yeah the name of the chipset
<hyperair> wasn't that the only libva-enabled intel graphics chip?
<mok0> hyperair: I don't know
<hyperair> i think it is.
<mok0> hyperair: (what's libva?)
<hyperair> mok0: video accel
<mok0> ah
<hyperair> http://www.freedesktop.org/wiki/Software/vaapi
<hyperair> basically you can view all those hi-res HD videos that i can't.
<hyperair> even with a core 2 duo for decoding >_>
<mok0> hyperair: Hmmm
<hyperair> 1080p fails here.
<hyperair> mok0: poulsbo == GMA500, right?
<mok0> hyperair: I never watch video on any of my computers
<hyperair> mok0: what a waste =p
<mok0> hyperair: Yup. Thats the buger
<mok0> bugger
<persia> mok0: I have two: a netbook and a MID.
<mok0> persia: ah poor you
<persia> Indeed.
 * hyperair is interested to see if his desktop can be revived using nouveau.
<hyperair> nvidia and their stupid legacy blobs make my screen flicker like hell.
<persia> The MID was a waste of money.  The netbook was an experiment that made me conclude that I dislike large-size netbooks as much as I dislike small-size ones, and worth the (low) cost to learn the lesson.
<mok0> persia: hehe
 * hyperair doesn't need a netbook to realize that he doesn't like netbooks.
<mok0> persia: I am actually quite happy with my netbook, except for the fact that I fear not being able to upgrade it
<hyperair> small keyboard, small screen, underpowered machine
<hyperair> not being able to upgrade?
<hyperair> you mean to a newer kernel?
<persia> hyperair: See, I like to experiment with form factors.  I'm fairly sure that my best mix is a 2.5", a 5" and a 14-15" at ~100g, ~350g, and ~1500g.
<mok0> I just took me netbook on a trip, and I was pleased to experience how little hassle it was to bring it along, compared to my 15" Powerbook
<persia> But the 14-15"/1500g machine needs to be a real computer, not stripped down.
<hyperair> persia: ah i see.
<persia> mok0: You ought to try something actually small :)
 * hyperair uses 14.1"
<hyperair> it should be around... 1.7kg?
<mok0> persia: you mean like a smartphone ?
<persia> hyperair: Anyway, I tried netbooks at 7" and 10" just to check.  I find them too small to do significant work, and too large to carry easily.
<hyperair> persia: heh, you'd need a bag for it, right?
<persia> mok0: No.  I have a 5" laptop (Netwalker).  Smartphones are in an entirely different category.
<hyperair> persia: i carry around my backpack everywhere so i don't really care what size it is as long as it fits in and doesn't slow me down.
<persia> hyperair: Right.  That which doesn't fit in a pocket doesn't fit in a pocket.
<hyperair> persia: words of wisdom =p
 * hyperair adds to personal list of quotes
<mok0> I have all my photos, and EVERYTHING on my 15" laptop. It is too valuable to loose, and there is so much stuff on it, that if border police somewhere got hold of it, I can't guarantee they wouldn't find something illegal
<mok0> For example, I have some pictures of my daughter in the bubble bath when she was 3.
<hyperair> .......
<mok0> Some sicko border police might make a big deal about that
<hyperair> are you worried that can be considered as child porn?
<mok0> hyperair: exactly
<hyperair> good god.
<hyperair> that is too extreme.
<hyperair> mok0: stash them away in a truecrypt hidden volume ;-)
<mok0> hyperair: I can't rule out they could find documents with reference to explosives or chemistry, since that is my field and interest
<hyperair> hehehehe
<mok0> hyperair: yes, but if you travel to the US, you are required to unlock it
<hyperair> mok0: hence hidden volume ;-)
<hyperair> mok0: hidden volumes look like they're not there.
<mok0> hyperair: I'd rather take a small, clean netbook
<hyperair> mok0: the volume within a volume thing.
<mok0> hyperair: yeah, too much hassle
 * hyperair agrees
<mok0> hyperair: I'd rather leave it at home :-)
<hyperair> i wonder if they arrest you for pirated material.
<mok0> They might
<hyperair> =(
<hyperair> my notebook is not going anywhere near that part of the world then.
<mok0> I cannot rule out that I have MP3s that are not legal somehow
<mok0> ;-)
<hyperair> i cannot rule out that i have mp3s that are legal.
<hyperair> i mean.. i can almost rule out that i have mp3s that are legal?
 * hyperair coughs
<mok0> I own the vinyls so I figured it was ok :-)
<hyperair> heheh
<hyperair> i suppose it would be
<mok0> hyperair: Uhm... yes...
<hyperair> oh yeah, aren't the mp3 codecs illegal over there too? =p
<hyperair> you'll have to purge gstreamer first
<BlackZ> if an add-packaging request has been submitted before the featurefreeze, it can be appropiate for exception request?
<mok0> hyperair: Well, if they get hold of 100Gb of stuff, and are intent on finding something on you, who knows what they will come up with?
<mok0> BlackZ: what kind of request?
<mok0> BlackZ: New software: no chance
<mok0> BlackZ: new version of software, that fixes known bugs: perhaps
<hyperair> mok0: maybe i'll get charged for having a copy of aircrack on my system >_>
<BlackZ> mok0: ok, thanks.
<mok0> hyperair: I am sure they could if they wanted to
 * hyperair facepalms
<hyperair> oh and wireshark
<mok0> hyperair:  you're on your way to prison already
<mok0> :-)
<BlackZ> oh
<BlackZ> poor hyperair !
<hyperair> "possession of a linux installation" "must be a hacker" => prison
<mok0> "possession of Linux == communist => labor camp
<mok0> :-)
<hyperair> ouch
<hyperair> possession of Linux, is chinese. therefore must be communist.
<mok0> ..stealing Intellectual Property
<hyperair> olol
<mok0> heheheh
<hyperair> linux infringes various microsoft patents that nobody knows about. you own linux. hence you are stealing from microsoft!
<hyperair> whee prison
<mok0> So, watch this video, very interesting: http://video.google.com/videoplay?docid=6014022229458915912#
<mok0> ... and this one http://video.google.com/videoplay?docid=6014022229458915912#docid=8167533318153586646
<mok0> Gotta go, se you later
<persia> So, as much as I like to see lots of social chat for teambuilding, some of this probably belongs in #ubuntu-offtopic :)
<persia> But if interleaved with on-topic stuff because people are simultaneously working, nobody is going to notice
<persia> Who here is a sponsor?
<persia> There's a really useful thread on ubuntu-devel@ which needs your input.  dholbach and I have been stalled for a very long time on this, and the time has come to come to resolution.
<persia> ("Role of the Sponsorship Queue").
<persia> Also, any of you who are regularly sponsored, please share your thoughts on how it ought to work.
<persia> The more input we get the more likely we can implement something sane.
<kamalmostafa> For bug 260406, slangasek advised me to "prepare an upload to Lucid" with my patched gnuradio package, instead of sync'ing the package and then patching it.   I have such a .dsc ready, but where should I upload it?   Is my own http: space an acceptable holding pen?
<ubottu> Launchpad bug 260406 in gnuradio "Sync gnuradio 3.2.2.dfsg-1 (multiverse) from Debian unstable (main)" [Wishlist,In progress] https://launchpad.net/bugs/260406
<randomaction> kamalmostafa: I think you can just attach a debdiff against 3.2.2.dfsg-1 to the bug.
<kamalmostafa> randomaction: well, I actually did do that, but (because 3.2.2.dfsg-1 won't build if we were to sync it) slangasek advised me to "prepare an upload" instead -- see his comment #11 in that bug.
<persia> kamalmostafa: A debdiff against the debian that results in the package you'd upload to Ubuntu *is* preparing an upload.
<randomaction> kamalmostafa: I think he meant that you'd need to modify the debdiff to account for the RC bugs
<randomaction> that debdiff counts as preparing an upload, IMO
<kamalmostafa> ok, that's easy to do , and the debdiff is actually extremely small even -- but then somebody will have to sync it before applying it, whereas slangasek said "if additional patches are needed to get the package to build, I don't think there's any point in syncing it".    Anyway, if the motu folks will be happy with a sync-then-apply-attached-debdiff, then that's what I'll do.
<randomaction> no, it should be done in one step: uploading 3.2.2.dfsg-1ubuntu1
<randomaction> there's no "sync" part in it
<kamalmostafa> randomaction: i may be confusing the terminology regarding the actions that the motu will take....  I guess I imagine that they'll have to somehow get Debian's 3.2.2.dfsg-1 that my patch will apply to -- i guess that isn't really a "sync" -- just an intermediate step?
<persia> kamalmostafa: Your sponsor will just download from Debian, apply the diff, and upload.
<persia> Right, an intermediate step.
<persia> A "sync" requires action by archive-admins and updates the publishing history on LP.
<kamalmostafa> persia, randomaction: okay, got it.   all the behind-the-scenes magic slowly becomes clearer.  thanks folks.
<randomaction> that's no different from any other upload, where the sponsor grabs package, applies patch and uploads
<randomaction> and it is "one step" in terms of package archive state, not sponsor's actions
<persia> kamalmostafa: If you have questions about how things are done, just ask.  You'll need to know if you gain upload rights anyway.
<kamalmostafa> randomaction: sure, i guess its just a matter of where they grab the package from, right?
<randomaction> yes, it's just Debian vs Ubuntu
<persia> dget works against ftp.${CC}.debian.org just fine :)
<randomaction> working with branches may be a bit different though
<persia> Well, different steps.
<persia> I suspect it's something like grab Ubuntu, pull the Debian tar.gz, merge-upstream, merge debian, verify changes, push.
<persia> But I also suspect there's *much* better documentation on the UDD pages.
<fabounet> Hi guys, is there anyone with the proper rights to make an 'ack' on a bug here ?
<kamalmostafa> its all much clearer now, thanks again folks.  really my only confusion was the idea that it would be allowed to pull from Debian *without* an explicit sync.  but now that its been explained, I can't see why it wouldn't be fine to do so.
<fabounet> we need it before we can upload the patches
<persia> fabounet: Depends entirely on the type of bug.  Which bug?
<fabounet> this one :
<fabounet> https://code.launchpad.net/~cairo-dock-team/cairo-dock-core/ubuntu
<persia> That's not a bug: that's a branch :)
<fabounet> I mean, this one https://bugs.launchpad.net/ubuntu/+source/cairo-dock/+bug/521534 ^^
<ubottu> Launchpad bug 521534 in cairo-dock "Please update cairo-dock to 2.1.3-3 version" [Undecided,Confirmed]
<matttbe> hello persia :)
<matttbe> we have open this bug more than two weeks
<fabounet> it's waiting fot its ack for more than 2 weeks now
<fabounet> I would be really nice if anyone could acknowlegde it
<persia> That's new features, right?
<matttbe> ues
<matttbe> yes
<matttbe> I think that nhandler and ScottK can help us
<persia> You need a member of the release team to approve that.
 * persia subscribes the (changed) correct team
<matttbe> but I don't know if there are here and if it's right
<matttbe> persia: oh, I just follow the doc
<persia> matttbe: NO worries.  That team has been in transition the past few weeks, and is only now finally getting sorted.
<matttbe> ok :)
<persia> Anyway, You'll want to edit the description to indicate why it's really important that lucid have this version.
<fabounet> I can do that.
<fabounet> then do you know someone who could acknowledge it ?
<matttbe> 1) because we have introduced two bugs in order to update this branch :)
<matttbe> both before the FF
<persia> RIght now that bug is indistinguishable from "I want a pony".  So if you highlight some inforamtion about all the bugs it fixes and the use cases it enables, it will get a better response from ubuntu-release.
<fabounet> there are so many ... ^^
<persia> Pick the ones that make the best argument :)  The worst bugs and the best features.
<persia> Doesn't need to be compkete, but the release team person reviewing it may not have any prior familiarity with the package.
<fabounet> ok, let's do that then first.
<matttbe> persia: ok thanks for the help
<matttbe> (but we just need an ack now, we know another guys that can upload it)
<matttbe> but ok, the changelog is already done, we'll chose the better bug :)
<matttbe> *choose
<persia> Hrm?
<persia> What's the other bug?
<matttbe> mmh, it's a bit old bug :) => posted in November
<persia> What's the bug *number*
<matttbe> ok, let me search
<matttbe> 460001 & 460028
<persia> Bug #460001 Bug #460028
<ubottu> Launchpad bug 460001 in cairo-dock "Please update cairo-dock to 2.0.9-karmic2 version" [Undecided,New] https://launchpad.net/bugs/460001
<ubottu> Launchpad bug 460028 in cairo-dock-plug-ins "Please update cairo-dock-plug-ins to 2.0.9-karmic2 version" [Undecided,New] https://launchpad.net/bugs/460028
<persia> Those are clearly outdated and wrong.
<persia> Only in minor ways, but still.
<persia> Will addressing 521534 solve those as well?
<matttbe> yes of course
<persia> OK.  I'll mark them duplicate (in reverse)
<persia> In general, it's better to track one bug per purpose.
<matttbe> ok, good idea
<persia> matttbe: Next point of confusion.  On 2010-02-19 BlackZ said "I'm still working on it, please, be patient!".  Does your comment from 2010-02-23 supercede this?
<matttbe> my comment ?
<kamalmostafa> persia, randomaction: since my gnuradio issue is no longer a "sync request" -- is it appropriate to call it a "merge request" (in the bug title)?
<persia> I usually titile them "Please merge ...", but sure.
<randomaction> yes, even if all previous changes were dropped
<kamalmostafa> very good, thanks
<matttbe> persia: in fact, both branches (CD and CD-plug-ins) are ready to be uploaded but I can't do that :)
<randomaction> (I was confused about this terminology last year)
<persia> matttbe: No worries.  Just wanted to make sure.  Looks to me like you're just waiting for release manager time (which can be tricky.
<kamalmostafa> randomaction, persia: thanks again for the help -- bug 260406 is now in the u-u-s queue, and (i think) ready to go.
<ubottu> Launchpad bug 260406 in gnuradio "Please merge gnuradio 3.2.2.dfsg-1 (multiverse) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/260406
<persia> Once you get that, subscribe the sponsors, and you'll get a review of your work, and after some give & take it'll be uploaded (might be the first time, but this is not so common).
<matttbe> persia:  in fact... yes :-/
<matttbe> ok persia, thanks for help but we just need an ack :-/
<persia> Why :/ ?  Have you had poor experience with the sponsors?  Most of the feedback I get from those sponsored is that the sponsors are helpful and provide eduction,  I'd like to resolve any counterexamples.
<matttbe> yes we had some poor experiences but we know one guys that can upload too but he said to us that we need only one ack :)
<persia> Could you give me the bug numbers of the poor experiences? (/query is fine if you don't want to highlight someone in public).  One of my roles is administration of the sponsors team for universe, and I'd like to address that with the sponsor.
<RoAkSoAx> anyone around who can review a couple of backports?
#ubuntu-motu 2010-03-03
<pochu> is Marc Deslauriers here?
<persia> pochu: Goes by mdeslaur usually.
<pochu> mdeslaur: hey
<pochu> mdeslaur: I see you've uploaded a new revision of liferea
<pochu> mdeslaur: I wonder if this change doesn't introduce regressions:
<pochu>   * debian/patches/01_ubuntu_feedlists: updated some outdated feeds
<pochu>     (LP: #341969)
<pochu> mdeslaur: can you still reorder the feeds in the left pane by drag and dropping them?
<ejat> can someone porting this http://paste.ubuntu.com/387442/
 * persia notes that mdeslaur's reported timezone in LP is UTC -5, so there may be a delay for a response
<lucent> I was advised to ask my question here. "Where do I learn modern methods for generating a debian package from source code?"
<lucent> searching Google turned up some pretty dated methods for me
<randomaction> modern, as in debhelper 7?
<lucent> would the steps to create a package for Ubuntu be any different than the steps outlined in maint-guide ?
<lucent> and really I am familiar with creating packages for a system, it is that I am new to how to make a proper package for apt/deb and Ubuntu
<lucent> with Gentoo some years ago I learned about installing a package with a modified destination dir, and accounting for differences in the build system with the destination rootfs
<lucent> apt/deb is still kind of foreign to me
<randomaction> we have a https://wiki.ubuntu.com/PackagingGuide
<lucent> okay, I missed that one. I will look at it now.
<randomaction> and there's a session log at https://wiki.ubuntu.com/MeetingLogs/devweek0909/PkgFromScratch
<randomaction> which could also be helpful
<lucent> noted. great!
<randomaction> and manual page for debhelper is a valuable source of detailed technical information
<randomaction> and Debian policy, of course
<dholbach> good morning
<abogani> dholbach: to you
<dholbach> hi abogani
<directhex> bugger. need to un-register for UDS sponsorship
<rawang> hello, does anybody know if my package A depends on a just python module(a directory), but the module have to different implementation and they are not coexisted (have same directory but two different implementations.) how to write Depends field in debian/control file?
<rawang> oh, my package A is a python package
<lifeless> rawang: so, A uses B, where B is a python package
<lifeless> but there are two different package names both of which contain B ?
<rawang> yep, but B have 2 implementations.
<rawang> yep
<lifeless> what are the package names for them
<rawang> lifeless, let me say more clearly, my python package strongwind needs pyatspi, at-spi and at-spi2 ship the same directory
<rawang> strongwind could work on at-spi OR at-spi2
<lifeless> at-spi doesn't look like it has python in it
<rawang> ok, the python package is python-pyatspi
<lifeless> what is the actual package name
<lifeless> and the othe rpackage name
<rawang> python-pyatspi2, which is built by myself
<lifeless> depends: (python-pyatspi | python-pyatspi2)
<rawang> ah, got it
<lifeless> uhm, the syntax may be a little wrong - check policy if needed
<rawang> could a append version?  like depends (python-pyatspi >= 1.28 | python-pyatspi2 >= 0.1.7)  ?
<lifeless> but seriously consider not using the same python module name for pyatspi2; its almost guaranteed to end badly
<lifeless> yes, that can be done
<lifeless> python-pyatspi (>= 1.28) | ..
<rawang> lifeless, python-pyatspi and python-pyatspi2 could not be coexist
<lifeless> right, which means you'll have to change 5 other packages to be able to have people install python-pyatspi2
<lifeless> also
<rawang> because some files are conflicts,  (has same 'pyatspi' dir )
<lifeless> it means that python-pyatspi2 will *not follow* the python packaging policy
<lifeless> the package name for a python package 'pyatspi' is 'python-pyatspi'
<rawang> lifeless, yes, i did, my package name is python-pyatspi2, what's the problem with that? :)
<lifeless> the python package you install is 'pyatspi', Debian python policy is that your dedbian package name must therefore be 'python-pyatspi'
<lifeless> thats the problem.
<lifeless> if you call the python package you install 'pyatspi2' its all ok.
<lifeless> or if you call your debian package name 'python-pyatspi' its also ok (though you still need to replace the package in the distro, and thats non going to be simple as you have radically different version numbers)
<rawang> lifeless, i'm sorry I don't understand. :(   python-pyatspi2 is follow the python- prefix policy
<lifeless> the policy is not just a prefix
<lifeless> its an exact match
<rawang> lifeless, ok.....    so what's your suggestions? :)
<lifeless> I gave them to you
<rawang> named it as pyatspi2 ?
<lifeless> either generate a python module 'pyatspi2'
<lifeless> or patch pyatspi
<rawang> oh
<lifeless> actually, thats a new suggestion :)
<lifeless> those are your best options.
<rawang> could you please look at it to see if there is a problem, of course if you have time. :)   https://launchpad.net/~raywang/+archive/uia2atk/+sourcepub/982612/+listing-archive-extra
<lifeless> I'm just entering a meeting sorry
<rawang> lifeless, ok, sorry :)
<rawang> and thanks a lot!
<duanedesign> i made a fix on a typo bug. DL source made a patch and uploaded it to a bug upstream. Now the bug has been commented on. Not sure what that means. http://sourceware.org/bugzilla/show_bug.cgi?id=11330
<ubottu> sourceware.org bug 11330 in ld "ld manual page has typo" [Minor,Resolved: fixed]
<Laney> it means it was fixed
<duanedesign> Laney: ok i just wanted to make sure that i did the right thing and that wasnt someone 'fixing' what i did :)
<duanedesign> thank you
<mdeslaur> pochu: hmm...let me check that. It would be the _other_ changelog entry that would have introduced the regression.
<mdeslaur> pochu: yes, it appears to have introduced a regression. I'll fix it or revert it today.
<wrapster> how do i downgrade a pkg version?
<wrapster> I mean lets say I have P-5 pkg installed.. How do i install P-4 if i want to?
<Laney> find a deb and dpkg --install it
<Laney> add a repo which contains it and apt-get install pkg=version
<Laney> it might be in /var/cache/apt/archives if you had it installed before
<wrapster> ok
<nigelb> bdrung: the epiphany-extensions-more removal bug, you want me to change it to sync request?
<bdrung> nigelb: yes
<nigelb> just a doubt though
<bdrung> nigelb: it will require a feature freeze exception
<nigelb> I checked live.gnome.org and it said that the epiphany-extensions-more won't work with 2.28 and above
<bdrung> nigelb: look at http://packages.debian.org/changelogs/pool/main/e/epiphany-extensions-more/current/changelog
<nigelb> the javascript based ones are a bit unstable
<nigelb> (as per upstream)
<bdrung> nigelb: then it's up to you - do we want to distribute possible unstable extensions or none instead?
<nigelb> one side is - I'd rather have something than nothing.  second side - I'd like the LTS to be stable :)
<nigelb> what would be the usual protocol? to sync it anyway and let the user decide?
 * bdrung agrees.
<Laney> you could disable the unstable ones
<bdrung> nigelb: i doubt that we have a protocol for that
<nigelb> Laney: you mean sync it and let the user decide since she/he can disable it anyway?
<Laney> no, I mean *you* disable the extensions which aren't suitable for production use
<Laney> you don't want to mislead users
<nigelb> there is epiphany extensions an epiphany extensions more
<Laney> that doesn't make it clear that they are experimental
<nigelb> the more package is the one with trouble.  its not just an extention.  the javascript based stuff is entire unstable is what upstream says
<nigelb> s/entire/entirely
<Laney> I dunno, I'd think hard about whether you want to put it in lucid at all
<nigelb> me too
<nigelb> here's the upstream page: http://live.gnome.org/Epiphany/ThirdPartyExtensions/Epiphany228AndLater
<nigelb> I'm -1 because of this unstability, though upstream seems to say we'd have better luck with 2.29.5 and above (we're at 2.29.91)
<nigelb> bdrung: so, we keep it or remove it?
<nigelb> I'm trying to investigate why the 'imagemagick' dependency for 'shutter' package was dropped to recommends in debian.  Not having 'imagemagick' around is causing it to be not installed.  Where can I look to figure this out?
<bdrung> nigelb: upstream says: "Unfortunately you are highly likely to have Epiphany crash on you if you use these extensions with Epiphany 2.28.0"
<nigelb> ugh! my bad
<nigelb> I'll change to sync request :)
<bdrung> nigelb: if you want to gain extra points, test the extensions :)
<nigelb> I will :)
<nigelb> this is going to take the whole evening though ;)
<nigelb> I'll test it first and then decide :)
<bdrung> great, thanks
<nigelb> any thoughts on the shutter thing?
<nigelb> ah, I see debian bug 567612
<ubottu> Debian bug 567612 in shutter "missing dependency on imagemagick" [Important,Open] http://bugs.debian.org/567612
<umang> Hi, I want to know whether a package (pbuilder) is eligible for a backport request. Is the right place?
<ScottK> umang: It could be.  Do you want to backport it to get a bug fix or because there's a new feature you'd like to use?
<umang> ScottK, I guess that would be a bug fix (I've figured out a work around). I know backports aren't for bugfixes, but I've read that the latest pbuilder should be in backports. ATM, pbuilder cannot create a base tarball with the default settings, that means pbuilder doesn't work unless you find out what to change.
<umang> s/figured/found out about/
<ScottK> umang: What do you have to change?
<umang> ScottK, pbuilder doesn't ask debootstrap to include apt, but it needs apt to function.
<umang> (Fixed in the latest version, currently in sid and squeeze I believe)
<ScottK> umang: Is it fixed in Lucid?
<umang> ScottK, yes.
<umang> Lucid has 0.196, which has the fix.
<nigelb> umang: you mean to say pbuilder chroot does not have apt in below lucid?
<umang> nigelb, http://packages.debian.org/changelogs/pool/main/p/pbuilder/current/changelog (last but one point).
<nigelb> umang: ah :)
<umang> :)
<nigelb> okay, there is a dependency problem in shutter, the bug has been filed against debian and maintainer has marked as high.  Should I wait and reqeust sync or fix in ubuntu directly?
<slytherin> umang: I believe this is a rare use case and not a general scenario. I have been using pbuilder since hardy and this suddenly not a bug in general usage.
<Laney> no, there was a change (I believe apt stopped being Essential: yes) in Debian which broke it
<umang> slytherin, but that means there is no way to get the latest pbuilder in karmic?
<ScottK> slytherin: Laney's right.  It's a real (but new) problem.
<slytherin> Oh. Then the issue does not affect karmic. Hence the backport will not serve any real purpose.
<umang> Does that make it ineligible for backports?
<ScottK> umang: File a bug against karmic-backports, indicate (assuming it does) that the new pbuilder builds, installs, and runs on Karmic and I'll approve it.
<ScottK> slytherin: It does if you want to make a Lucid chroot.
<Laney> it affects building sid chroots on karic
<ScottK> (or Sid, I don't recall if Lucid is affected too)
<Laney> I just hacked my debootstrap scripts to make it work
<umang> Laney, Can't expect everyone to do that, no?
<Laney> no, I didn't say that I do
<umang> ScottK, so I build it from source on Karmic, (take the source package from Lucid) and see if it builds and works. If it does then I file a bug?
<slytherin> ScottK: I have crated lucid chroot long time back. Was this broken recently?
<ScottK> umang: Yes.
<ScottK> slytherin: I don't recall for sure if Lucid is affect. Sid/Squeeze definitely are.
<umang> ScottK, OK. I'll do that tomorrow morning (free internet usage :P )
<ScottK> OK.
<umang> Thanks all! :)
<RoAkSoAx> ScottK, do you nthink this two bugs should be SRUs instead of backports? bug 530945 and bug 530972
<ubottu> Launchpad bug 530945 in keepalived "Please backport keepalived 1.1.17-2 to Karmic from Lucid" [Medium,Confirmed] https://launchpad.net/bugs/530945
<ubottu> Launchpad bug 530972 in usbmount "Please backport usbmount 0.0.19.1 to karmic from lucid" [Medium,Confirmed] https://launchpad.net/bugs/530972
<ScottK> Looking
<ScottK> RoAkSoAx: Commented both.
<RoAkSoAx> ScottK, thank you :)
<RoAkSoAx> ScottK, in the case for the SRUs, should I attach a diff showing the changes between the version in karmic with the one in lucid, or should I just specify to push the lucid package into karmic?
<ScottK> You should have a minimal diff for just the SRU worthy change
<RoAkSoAx> ScottK, so only show the part of the changed to fix the bug?
<ScottK> Yes.  For the SRU we just want the patch that fixes the bug, not the entire new version.
<RoAkSoAx> ScottK, what if the entire new version is a bugfix release?
<RoAkSoAx> we still place the patch fixing it i guess
<ScottK> For SRU we only fix important bugs.  We want the minimal fix to deal with the SRU worth problem.
<ScottK> There are a few packages that have exceptions to this, but that has to be tech board approved.
<RoAkSoAx> i see
<slytherin> RoAkSoAx: backport the patch form new release to release in repositories.
<RoAkSoAx> slytherin, i cannot do that with usbmount exactly because upstream did various changes adding new features, so I;m just using the original patch in debian BTS
<slytherin> RoAkSoAx: You don't want those features right? Only the fix for a bug.
<RoAkSoAx> slytherin, well I requested a backport mainly because of that fix, but new upstream also contains new features like support for UUIDs, but that's not essential I guess
<slytherin> RoAkSoAx: Ok. I thought you were discussing SRU.
<RoAkSoAx> slytherin, i first requested a backport, now I'm chagning it to SRU just to fix the bug
<pochu> mdeslaur: if you get to fix it, let me know, since we reverted it upstream :)
<mdeslaur> pochu: I reverted it for now
<mdeslaur> pochu: thanks for the head's up!
<pochu> mdeslaur: no problem
<RoAkSoAx> ScottK, done with SRUs, could you please take a look at them? bug #530945 and bug #530972
<ubottu> Launchpad bug 530945 in keepalived "[SRU] keepalived in karmic" [Medium,Confirmed] https://launchpad.net/bugs/530945
<ubottu> Launchpad bug 530972 in usbmount "[SRU] usbmount in karmic" [Medium,Confirmed] https://launchpad.net/bugs/530972
<ScottK> RoAkSoAx: I'm not on the SRU team.
<RoAkSoAx> ScottK, oh thought u were lol :) sorry about that then
<jdong> RoAkSoAx: both are now ACKed, thanks for taking care of the SRU :)
<RoAkSoAx> jdong, glad to help :)
<\sh> micahg: thx for the backports :)
<RoAkSoAx> \sh, did a small test with pacemaker/ldirectord/ipvsadm works nice :)
<\sh> RoAkSoAx: ah well...we are setting it up now :)
<RoAkSoAx> awesome
<RoAkSoAx> anways I have the setup here : https://wiki.ubuntu.com/ClusterStack/LucidTesting#Load%20Balancing%20with%20Pacemaker/ldirectord
<\sh> so heading now for home...;)
<RoAkSoAx> ok have a good one
<RoAkSoAx> im off tyo lunch
<micahg> \sh: thanks for the blog post :)
<DreamDemon> There is a problem with the way a pacgage works with the current server ( karmic 9.10) kernel works
<DreamDemon> package*
<DreamDemon> ipset will NOT work with a default install even though the package is avail thru universe via apt-get
<DreamDemon> This causes problems with mass white/black listing block CIDR addresses for multiple countries as iptables takes entirely too long to process large requests as such
<DreamDemon> eg: blacklist of all countries except US, HU, DK, DE, GB = approx 100k lines of CIDR adresses
<DreamDemon> eg2: whitelist countries US, HU, DK, DE, GB = approx 30k lines of CIDR adresses
<vincs> Hi everyone.
<vincs> I am an beginer at packing and I have some questions on uploading to revu. Is it the rigth channel to ask them ?
<highvoltage> it's the perfect channel to ask in
<vincs> I have upload a package. (debuild -S  -sa --lintian-opts -i; cd ..; dput revu mypackage.changes)
<vincs> I have some changes to do.
<vincs> Let's say only on the rule file.
<vincs> Should I basicaly edit rules file and upload changes?
<vincs> (I forgot the get-orig-source rule)
<vincs> Or should I also change the changelog file ?
<RainCT> So Canonical is going purple?
<lucas> purple?
<RainCT> https://wiki.ubuntu.com/Brand
 * sebner facepalms
<oojah> I've got a program I'm converting to use upstart instead of sysvinit. In the packaging, what's the recommended way of creating the symlink that is /etc/init.d/<name> -> /lib/init/upstart-job ?
<ScottK> cody-somerville: Is blue a traditional xfce color?
<Laney> oojah: You should use dh_link
<cody-somerville> ScottK, Yes.
<ScottK> cody-somerville: Thanks.
<ScottK> jono: Was someone from Kubuntu involved in this rebranding effort (if so, who)?
<jono> ScottK, Riddell
<ScottK> jono: Thanks.
<oojah> Laney: Great, thanks.
<strycore> Hi
<strycore> I'd like to learn how to fix bug 531629
<ubottu> Launchpad bug 531629 in xdebug "xdebug can't be installed : wrong virtual package" [Undecided,New] https://launchpad.net/bugs/531629
<strycore> the virtual package is outdated
<sebner> ScottK: do you look for a person to complain to ?^^
<ScottK> sebner: No.  I'm looking to find out the plan for Kubuntu since jono's announcement didn't have Kubuntu material in it.
<jono> ScottK, just no completed Kubuntu logo tet
<jono> yet
<ScottK> Ah.  OK.
<jono> the logo font is still in the works, so not all the letters are complete yet
<sebner> tell me mighty jono, why purple xD
<jono> when the font is done, a logo will be shortly arriving :)
<ajmitch> zul: another php extension rebuild for you ^
<jono> sebner, I think it looks cool :)
<jono> thats the not the reason though
<jono> :)
<sebner> jono: is that our feminine side :P
<vorian> I think the purple is hot
<vorian> & very close to blue :)
<sebner> better than brown but still ..
<DktrKranz> sebner: turn off monitor, and you'll see the real dark theme ;)
 * sebner likes dark themes *muaahaahahaha*
 * ajmitch has the sparkly coloured lines theme on the laptop, it's so vibrant & jumpy...
<milli> ScottK: I'm hoping and praying that Rails 3.0 releases before lucid is done, since it would be a real shame to not have Rails 3 for the next 6 years...
<micahg> is anything in universe extended to the 5 yr support window?
<ScottK> micahg: It's all community supported and so to the extent the community supports it, the window is the same as Main.
<micahg> ScottK: k, so in theory anything that's server only could br patched for 5 yrs?
<ScottK> micahg: Yes.
<ScottK> Personally, I'm still supporting clamav on Dapper.
<micahg> ScottK: cool, thanks
<micahg> ScottK: can we backport universe packages as well in -backports?
<ScottK> micahg: Yes.
<micahg> very cool :)
 * micahg thinks he'll be testing backports for Lucid for a while :)
<crimsun> perhaps we need a "sponsor day" or something suitably silly
<jdong> if bug days are called hug days, I *cringe* at the non-PG name for sponsor bribing days
<jdong> (kidding!)
<ScottK> No you aren't.
<persia> crimsun: Why a "sponsor day"?  Lately the universe queue rarely grows beyond 10 bugs.
<crimsun> persia: it's half tongue-in-cheek
<persia> Oh, heh.
<crimsun> I'll gladly switch places with someone to work on it, though :-)
<persia> Given how you used to be too busy with stuff to help with the old-style bug days (when we actually got stuff fixed), I don't imagine many could take your place, even for a day.
<crimsun> nah, just need a lot of incentive^Wcoffee^Wtea
 * persia remembers "I already have a bug, thanks" being the response to bug day findings back then
<crimsun> hmm, armel buildds now fail after encountering implicit declaration warnings, correct?
<persia> I didn't think they had any special logic that differed from other buildds.
<crimsun> yeah, they do (and ia64 as well)
<crimsun> otherwise I wouldn't have located those bugs in pulse.  D'oh, bad memory.
<crimsun> arb is such a crufty source package
<persia> heh
#ubuntu-motu 2010-03-04
<Laney> james_w: hi, got the next lot â http://dpaste.com/167584/
<Laney> been slacking a bit, sorry
<james_w> Laney: LP is taking a nap, ping me tomorrow and I'll process them
<Laney> oh, I didn't actually expect you to be around at midnight
<james_w> well, you are :-)
<crimsun> xmonad-contrib is 528803
<Laney> I forgot to -f on agda
<duanedesign> i have done a few patches to fix some easy bugs and posted the patches upstream. I am now wondering what i should attempt next? What would be a good next step?
<persia> duanedesign: Towards which goal do you seek a next step?
<duanedesign> hello persia
<duanedesign> persia: my eventual goal is to be a MOTU and help maintain and add to the Universe and Multiverse
<persia> OK then.
<duanedesign> persia: is that too broad :)
<persia> Two areas which need current work are unmetdeps and patch review.  I'd be happy to lead you through getting started with either of those, if you have time.
<persia> No.  broad is what MOTU is all about :)
<duanedesign> oh yeah, definetly!
<persia> If you'd no preference, I'd rather point you at patch review, as there are recent logs of my pointing someone at unmetdeps
<persia> Does that sound like something you're up to doing?
<duanedesign> sounds good.
<persia> So, we have millions of users, and they submit thousands of patches, and one of our roles is to process those patches to improve the software.
<persia> This generally involves testing the patch, potentially porting it to the newest revision, determining the state of the patch in upstream, making sure it does things in a sane way, etc.
<persia> If a patch is good, clean, well-reported (or already upstream), we can just upload (freeze observations permitting).
<persia> If a patch needs work, we can either work on it or work with the patch submitter to have them work on it.
<persia> But the idea is to collect all the patches, make sure they are as good as they can be, and get them into the software (either in Ubuntu or upstream).
<persia> There's lots of useful links at http://qa.ubuntuwire.com with stuff that needs attention.  One of those is "Ubuntu Bugs with the "patch" tag.  This is our target for today.
<duanedesign> I have not done a ton of patches yet, but it seems like most patches go upstream?
<persia> Lots of them, yeah.  There are rare cases where we want a patch only in Ubuntu, but most patches should get passed upstream so that everyone benefits.
<duanedesign> I also see a link on /MOTU/TODO/Bugs for Universe and Multiverse bugs with patches attached
<persia> That works too :)  There's lots of links to this list.
<persia> I like the "patch" tag because those tend to have gotten some triage, but any of the methods works.
<duanedesign> ill stick with the one you gave for know. Just want to make sure i am understanding :)
<persia> There's about 2000 patches out there, and about 250 with the patch tag.
<duanedesign> ok great persia
<persia> So, once you've gotten to one of the lists, pick a bug.  I recommend starting either with a package you've seen before, or with a package that you think doesn't have so many developers working on it: these tend to have easier-to-process patches.
<persia> Please share the bug number once you picked it so I can follow along :)
<funkyHat> Is there an automated way to deal with merge diffs?
<funkyHat> Or should I just delete the lines that I don't want?
<persia> funkyHat: There are a few, but we've not found any that are smart enough that we can remove humans from the loop.  The algorithm used on MoM is our best current stable attempt.
<funkyHat> persia: I mean is there a tool I can use to step through the parts that need merging and choose one or the other?
<persia> funkyHat: No, that's the part where we still need human intelligence :)
 * duanedesign is looking through the 'patch' bugs now 
<funkyHat> So I have to manually remove the <<<<<<<< blah-version (ubuntu) and ======= and >>>>>>>> blah-version (debian) lines
<persia> If you're using MoM, yes, and you have to think about the other stuff.
<funkyHat> ok
<persia> Also, you'll want to think about *any other* changes.  MoM merges some stuff cleanly which needs attention.
 * zul cries
<persia> Why?
<zul> ajmitch: fixed
<ajmitch> zul: I should have done it myself, but it took awhile to update my lucid VM :)
<zul> ajmitch: slacker
<funkyHat> If the debian maintainer has changed, should I update XSBC-Original-Maintainer to match?
<persia> funkyHat: Please.
<persia> duanedesign: Did you find a good bug with a patch?  Do you need a suggestion?
<funkyHat> Oh I guess that's what will happen anyway if I keep the debian maintainer headers and then run update-maintainer...
<duanedesign> persia: i think i might of found something
<duanedesign> bug 40925
<ubottu> Launchpad bug 40925 in db4.2 "No man pages for db-utils" [Low,Confirmed] https://launchpad.net/bugs/40925
<persia> Oh, that's a good one!
<duanedesign> looks like there is a patch upstream waiting
<persia> From the description, the manpages might already be included in the upstream tarball.  Download the source to check.
<funkyHat> Does it make any sense to use apport-bug to file a merge bug?
<persia> funkyHat: Not really, no.
<duanedesign> persia: kk
<funkyHat> Didn't think so :)
<funkyHat> Oh... launchpad isn't being awkward about filing bugs anymore
<funkyHat> that's nice
<funkyHat> I was just digging for the firefox quicksearch I made to get around it
<bjsnider> if an original tarball already contains debian build scripts
<persia> bjsnider: Are they good ones?
<bjsnider> yeah, good ones
<bjsnider> libxine
<bjsnider> what is the procedure as far as preparing it for the build system
<persia> Typically the same as usual, only one patches (if necessary) upstream stuff rather than starting from scratch.
<bjsnider> what i mean is ordinalrily i would add .orig to the name, then add the build scripts to the local directory and do debuild -S -sa
<persia> But that sounds like a package we've had around for a while.  Try looking at what was done last time upstream was integrated.
<persia> Same basic idea.
<bjsnider> or -sd if it's already in the archive somewhere
<bjsnider> so if i do an -S -sa with th orig fie already containing the build scripts, it's fine?
<bjsnider> i have to add a new changelog entry
<bjsnider> i don't see how that would work
<bjsnider> the diff would just change the build scripts?
<bjsnider> instead of creating them?
<persia> Right.
<bjsnider> i see
<persia> debhlper has an --ignore feature if you need to ignore some file provided by upstream.
<funkyHat> Is there a proper format for the contents of debian/changelog?
<funkyHat> Not sure what to put, or how
<bjsnider> use dch -i
<funkyHat> I used dch, yeah, just wondering what else I need to put
<funkyHat> I'm putting (LP: #531681)
<persia> funkyHat: That will parse as the correct syntax to close a bug.  Double check by reading your source.changes file when you build the source.
<persia> duanedesign: Were you able to get the code?
<funkyHat> Trying to run debuild but ubuntu one hasn't synced my gpg key -_-
<persia> There should be no need to wait for keyring sync for debuild.  What error do you get?
<funkyHat> gpg: skipped "Matt Wheeler <m@funkyhat.org>": secret key not available
<funkyHat> gpg: /tmp/debsign.KA3BldE0/amule_2.2.6+debian0-7ubuntu1.dsc: clearsign failed: secret key not available
<persia> funkyHat: The most common issue is that you have a comment in your identity in your GPG key.  Run `gpg --list-secret-keys`  If you have an entry in parentheses between "Matt Wheeler" and "<m@funkyhat.org>" you need to include that in debian/changelog
<funkyHat> persia: ~/.gnupg@ is empty
<persia> Then you don't have a key available on that account.  This is entirely unrelated to any status on the keyservers.
<funkyHat> Yes I know, the issue is with Ubuntu One
<funkyHat> The lucid VM isn't collecting the contents of .gnupg that I put in my Ubuntu One folder
<persia> You really don't want to put that there.
<funkyHat> What's a better way to move stuff in and out of kvm VMs?
<persia> Unless you have some reason to *know* that the cryptography used for that remote store is sufficient, you may have compromised your key.
<persia> I use ssh.
<persia> But I also don't worry about signing stuff in VMs.
<persia> If I get a good result, I can always use debsign to sign it.
<persia> So I usually use `debuild -S -us -uc`
<duanedesign> persia: ok, looks like the upstream documentaion that was included was in .html format
<persia> (I do the same thing in chroots, which I use more frequently than VMs)
<persia> duanedesign: But no upstream manpages in 4.2?
<duanedesign> duanedesign: not in the package. But the patch is the html files converted and then minor edits by hand.
<persia> duanedesign: OK.  So since you've determined that you understand the issue, and can work on it, set the bug to "In Progress" and assign yourself.
<persia> Then make the necessary changes in the source, etc.
<persia> Check the upstream mailing list, and see if someone already submitted db4.2 manpages (which may differ from db4.3 or higher manpages).
<persia> (this could save you some work).
<persia> If they *do* differ, and upstream doesn't have any for 4.2 yet, please submit them.
<persia> Once you have a working solution, add that to the linked Debian bug.
<persia> Once that's done, you get to decide: if you think it's important that Ubuntu fix this, prepare a candidate for upload.  If you think it should be fixed in Debian or further upstream, mark the Ubuntu task wontfix with an explanation.
<persia> Any questions?
<duanedesign> the source i got from the oracle9upstream) contains the /doc directory with the .html documentation. The Debian and downstream does not
<persia> Really?  So there's a new upstream tarball of db4.2 that isn't yet integrated into Debian and Ubuntu?
<duanedesign> persia: i dont think its new. I think for some reason they just took that directory out. Is there a bias towards .html documentation
<duanedesign> because the Ubuntu/Debian Read Me even references the missing /doc directory. Saying to see the documentation load docs/index.html into your web browser
<duanedesign> guess that needs to be changed too :P
<persia> duanedesign: There's a bias towards manpages.  There exists a framework for handling HTML docs, but most developers are neutral about it (use it when it's there,but don't create it when it's not).
<persia> duanedesign: That makes it sound intentional.  I'd recommend wontfixing the bug, unless you want to argue with the Debian maintainer about it.
 * persia checks a couple things
<duanedesign> persia: they might of just moved the .html help pages. Ill search
<funkyHat> http://paste.ubuntu.com/388017/ I'm getting an error with pbuilder that I don't understand
<funkyHat> Oh I missed off the bit further up where it says that package is broken...
<persia> funkyHat: So you understand now?
<funkyHat> persia: sort of, I don't know why it's broken
<funkyHat> Or how to fix it
<funkyHat> As it's broken inside the pbuilder thing, not my actual system
<funkyHat> http://pastebin.com/DrnqNGWG Here's the whole output, in case it's any use
<funkyHat> Oh, I've worked it out. I need to configure pbuilder to use universe
<persia> Good identification of the issue :)  Just take care to switch back to main-only if you are working on a package in main.
 * persia frequently fails when dealing with main packages due to having enabled universe
<funkyHat> Would it be worth it/possible creating separate base.tgz images for universe and main?
<persia> Depends on how much you work in both areas.
<persia> Some people do that.  Some people don't.
<duanedesign> persia: ok,  db4.2-utils has no man page. Because there is a seperate package db4.2-doc. Its 9.8 MB of HTML pages, lol
<duanedesign> so thats where they went
<funkyHat> Well so far I've only submitted 5 debdiffs, and pretty sporadically, but I'm planning to do more as time allows â¢). I'll hold the thought and perhaps do it if I find reconfiguring an issue
<duanedesign>  there is a 4.3man page. Should be easy to make a 4.2 manpage by looking at the diff from the 4.2 ->4.3doc package
<funkyHat> This thing is taking so long to build :/
<funkyHat> Oh, VM. Duh.
<persia> duanedesign:  Just make sure to check if there were changes in usage or options between the 4.2 utilities and the 4.3 utilities, and that those are accurately represented as changed in the 4.2 manpages.
<duanedesign> persia: ok. Thank you for all your help and patience ;)
<persia> duanedesign: Thanks for helping out with the patch review team.
<funkyHat> Oh... I think I might have just wasted a bunch of time there with this merge...
<funkyHat> It looks like there's actually no changes left (which I actually wrote in the changelog, but it didn't click), so we should just take the debian version
<ScottK> That's the best kind.  It means it doesn't need someone to bother with merging it next time.
<ScottK> Discovering that and asking for a sync is not a waste of time.
<funkyHat> ScottK: Shall I change my merge bug to a sync request, or make a new bug?
<ScottK> funkyHat: Just change it.
<ekimmargni> If I'm interested in ubuntu getting a package of the gerrit code review tool for git, where should I start on that process?
<funkyHat> ScottK: which team should I subscribe?
<ScottK> Is the package in Main or Universe?
<funkyHat> Universe
<funkyHat> Ah is it ubuntu-universe-sponsors?
<ScottK> Yes
<funkyHat> Thanks â¢)
<funkyHat> I updated merge-o-matic too
<persia> ekimmargni: How much effort are you willing to put into creating and maintaining the package?
<ekimmargni> persia: None. I've never packaged anything - that's totally beyond my capabilities.
<funkyHat> If MoM hasn't encountered any problems with a merge are there any standard places I should check for issues, or is it enough to simply attempt to build?
<persia> ekimmargni: OK.  Let me see if I can dig up the appropriate guidance docuemtnation.
<ekimmargni> *nod* thanks :)
<persia> ekimmargni: My apologies: I can't find quite the page I wanted.  https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages talks about a general overview.  The "Criteria" and "Requesting a new package for Ubuntu" sections are the ones in which you'll likely be ost interested.
<funkyHat> Looks like debian-faq is another one to be synced
<ekimmargni> persia: thanks, I'll take a look
<funkyHat> I just uploaded debdiffs to https://bugs.edge.launchpad.net/ubuntu/+source/debian-faq/+bug/531711 - it's a really straightforward merge
<ubottu> Launchpad bug 531711 in debian-faq "Please merge debian-faq 4.0.4+nmu1 (universe) from debian unstable (doc)" [Undecided,Confirmed]
<persia> funkyHat: Cool.  And you've subscribed the sponsors.  This is a quiet time of day, LP was recently down, and there's about 15 other items in the queue right now, but it ought get hit sometime soon.
<wrapster> dpkg -l lists out a particular pkg as installed but if i check for the same pkg in /var/cache/apt/archives I cannot find that pkg.. how so
<persia> wrapster: There's no requirement that /var/cache/apt/archives includes any installed package.  It starts out empty on a new install, for instance.
<wrapster> ok.
<lifeless> the relationship is even weaker
<lifeless> *apt* is a tool for downloading and installing packages
<lifeless> the cache has no correspondence to installed or uninstalled packages; its just things that apt has been asked to download, and hasn't deleted yet.
<persia> Oh right.  I forgot that apt will happily cache stuff without installing it.
<lifeless> update-manager can be configured to download but not install security fixes, as an example o f that
<lifeless> or if you start an install and hit cancel after some things download they stay in the cache.
<persia> Right.
<artfwo> is it okay to insert line breaks in debian/control fields like Build-Depends?
<lifeless> yes, if continued properly; see policy for the format specification
<micahg> an enum in a .h file that's included should be accessable in a function, right?
<micahg> nm...
<jayvee> G'day â I've had a libvirt bug sitting around a while, and I have a debdiff attached. I was wondering how I could help move it forward, or get the ball rolling.
<jayvee> I've been told I need to get it into a sponsorship queue of some kind, but not sure how to go about it.
<persia> jayvee: What's the bug number?
<jayvee> persia: https://launchpad.net/bugs/528934
<ubottu> Launchpad bug 528934 in libvirt "IPv6 shouldnât be disabled by default in libvirt" [Wishlist,Confirmed]
<jayvee> My debdiff bumps the version number from ubuntu8 to ubuntu9. But 13 hours ago, an update to libvirt also bumped the version to ubuntu9. Would it be useful for me to re-do my debdiff with ubuntu10 instead, or is that not a problem?
<persia> I'm not sure why zul didn't just upload it Monday, really.
<persia> You could subscribe the ~ubuntu-main-sponsors team to add it to a list of stuff to get uploaded.
 * persia will do that now
<persia> But I'd expect the server team to just upload it.
<jayvee> heh
<persia> Have you also submitted the bug to upstream?
<jayvee> Yep.
<jayvee> But obviously that won't get into Lucid in time.
<lifeless> upstream are a little insane though
<jayvee> Which is why I'm also submitting it here.
<persia> !sponsorship
<persia> !sponsor
<persia> Grr.
<persia> So https://wiki.ubuntu.com/SponsorshipProcess outlines the process.
<persia> This is likely to change soon as the ~ubuntu-main-sponsors and ~ubuntu-universe-sponsors teams are merged (ideally to make it simpler)
<persia> But unfortunately the main sponsors seem not to get to things quickly.
<persia> Since zul has an interest in this bug (based on his triaging it on Monday), you might ask him if it needs something else to be uploaded.
<persia> You might also check with the folk in #ubuntu-server as they tend to care for libvirt and friends.
<jayvee> okay
<jayvee> is pinging zul in here enough to grab his attention?
<persia> Not at this time of day (it's 1:22 there), but when he's awake yes.
<persia> But I'd really recommend trying the ping in #ubuntu-server, as more folk there have an interest in libvirt, so someone else might also grab it.
<jayvee> Do you think I should re-do the debdiff with the new version number, or is there not much point?
<jayvee> persia: oh cool, all I have to do to get it magically in the sponsorship queue is add it to ~ubuntu-{main,universe}-sponsors
<jayvee> now I get it
<persia> jayvee: I think it's a good idea to update the debdiff if it needs updating.  In my view, when you submit a debdiff, you *are* an Ubuntu Developer, and should be submitting something that would create precisely what any developer would upload.
<jayvee> lol, http://qa.ubuntu.com/reports/sponsoring/ is serving utf-8 text with an iso-8859-1 content-type header
<persia> That said, if it's trivial, most sponsors will just fix it (but it's more work for the sponsor, and some folk are picky).
<jayvee> okay, I'll update it right now
<persia> jayvee: Please file a bug against the sponsoring overview :)
<jayvee> haha
<jayvee> Content-Type: text/html
<persia> https://bugs.launchpad.net/ubuntu-sponsoring/+filebug
<jayvee> actually they don't specify any encoding
<persia> Oh, then it's a bug in your browser that it doesn't default to UTF8 :p
<jayvee> every browser I know of out there defaults to iso-8859-1
<jayvee> you can change it in the settings, but that only fixes it for one person
<jayvee> I do agree though â utf-8 should be the default everywhere.
<lifeless> jayvee: on ubuntu ff defaults to your locale
<lifeless> jayvee: and our locales default to utf8
<persia> Which is how we solved the bug.  Other environments may need other ways to solve it.
<jayvee> lifeless: I don't know any of the technicalities, but I would have to disagree based on past experience
<persia> For instance, in environments where the locales default to UCS-2, it makes sense to hack the browsers to default to UTF8, because almost nobody sends UCS-2 over the wire.
<jayvee> Well launchpad.net explicitly defines utf-8, and given that the page scrapes launchpad.net directly, it should do whatever launchpad.net does. ;)
<persia> The page should explicitly report it's charset anyway.  There's two bugs: 1) the page not giving enough information to read it, and 2) the browser having non-ideal defaults.
<persia> It's not precisely scraping LP, but using the LP API to collect details.
 * jayvee is testing the shiny new debdiff in pbuilder
<jayvee> well, shiny new debdiff attached to bug
<persia> Well, now comes the frustrating bit: waiting for someone to upload it.
<jayvee> yeah :(
<persia> Check with Zul in 9-10 hours in #ubuntu-server (or maybe something more like 18 if you're in a timezone that makes that more convenient)
<jayvee> well either I'll ping him at like
<jayvee> 2 AM
<jayvee> or when I get up tomorrow morning :)
<persia> That's about what I figured :)
<jayvee> well thanks for the pointers anyway
<jayvee> I learnt a lot just now.
<jayvee> persia++
<persia> jayvee: Thanks for helping fix stuff, and stopping by to ask questions.  The folk here and the folk in #ubuntu-server are both likely to be happy to help you with just about anything if you get stuck again.
<jayvee> hopefully one day when I get enough of these patches in, I can apply to become an ubuntu member
<alkisg> I'm trying to make a *simple* script and it's failing because "$plugin" is empty inside the `for` loop (i.e. line #8) - could anyone see why? http://alkisg.pastebin.com/3q22Sxd8
<alkisg> for plugin in file1 file2; do echo $plugin <== empty there :-/
<alkisg> Ugh sorry I just saw it
<alkisg> I need to escape $ in \$plugin
<persia> hrm?
<persia> where?
<persia> What sort of script is this?  shell?
<alkisg> persia: yeah it's a shell script, but nm, I found the solution, I needed to escape \$plugin
<alkisg> Silly me
<persia> Where?
<alkisg> I gave a pastebin link just above
<persia> Yes, I'm looking at it.
<persia> I'm just not seeing what you needed to escape, and hoping to learn.
<alkisg> Ah, well, the problem was this:
<alkisg> $plugin was evaluated while writing to >/tmp/script
<alkisg> So it was empty
<alkisg> I should escape it so that cat >/tmp/script <<EOF doesn't evaluate it
<alkisg> ..so that it gets evaluated later on, at sudo sh /tmp/script...
<alkisg> persia: if you run the script and then `cat /tmp/script`, you'll see what I mean...
<alkisg> Well apostrophes make it more readable than <<EOF and escaping, so: http://alkisg.pastebin.com/TidxHEuR
<persia> alkisg: Heh.  I understand now.  I completely ignored that this was a here-file.  Yes, you need to escape everything :)
<persia> Why are you doing this as a here file, rather than directly in the script?
<alkisg> persia: yup, it took me some minutes to see it, tricky...
<alkisg> persia: I want to put it in a web page for people to copy/paste it directly on the terminal, and sudo makes it tricky, as it kills the clipboard contents
<alkisg> So I need to put "sudo" at the end...
<persia> I'm generally against putting scripts on web pages.  What problem are you trying to solve?
<alkisg> The new beta flash player finally allows for greek chars
<alkisg> So I need to provide for an easy way for teachers to upgrade it
<alkisg> "go to the adobe site, download the tar.gz, extract to /tmp, and run the script"
<persia> And this isn't better achieved by providing updated packages?
<alkisg> It's beta, so I'm not sure that the download location will stay there
<persia> Just make a custom flashplugin-installer that will be perceived as an upgrade that pulls the beta.
<alkisg> I.e. `wget http://download.macromedia.com/pub/labs/flashplayer10/flashplayer10_1_p3_linux_022310.tar.gz` will fail when they get the new beta out
<persia> Then update the package.
<alkisg> What package?
<alkisg> doesn't flashplugin-installer download it on the fly from the adobe site?
<persia> Yeah.
<alkisg> So, for betas this can't work, since the link isn't stable...
<persia> And anytime you want it to download from a different place, or use a different checksum, you have to update the pacakge.
<alkisg> Ugh, I wouldn't want to do that each day :D I really prefer to leave some instructions for them to follow :)
<persia> What I'm suggesting is that you make a special beta version to distribute temporarily, and when it comes out, encourage people to use the regular version (which would be updated in the archives).
<alkisg> I'd need to update the beta package every week or so
<persia> It shouldn't change every day.
<alkisg> E.g. the tar.gz above is "022310" - 10 days ago...
<persia> Yeah, that's why there's no flashplugin-beta-installer :)  It's a lot of work.
<alkisg> Yup, so in this particular case, putting scripts on a web site is an acceptable way to do it for me :)
<persia> But if you move package-provided files around manually, you end up with a system that can't be reproduced from packages.  You may also cause issues with upgrades.  A security upgrade could break your updates, etc.
<persia> There are just too many things that can go wrong, and then you have to deal with annoyed users who followed your instrutions.
<alkisg> Sure, it's something temporary which I do hope to see resolved in Lucid (i.e. a non-beta 10.1 flash)
<persia> Well, OK.  I just think it's 1) poor service for users and 2) encourages poor practices in users/
<dholbach> good morning
<alkisg> persia: I completely understand what you're saying, it's just a matter of weighting available solutions & resources. Adobe offers a manual installation of 10.1 beta for now, and I don't have the time to package & keep packaging it, so the users will need to do it the adobe way. I can only give them some instructions on how to do it, I can't help them more.... sure, it's not good practice and it may break on updates, I'll warn them about that. Than
<zooko> Folks, this bug is urgent and the fellow who I thought would do it hasn't responded: https://bugs.launchpad.net/ubuntu/+source/tahoe-lafs/+bug/529350
<ubottu> Launchpad bug 529350 in tahoe-lafs "please upgrade Tahoe-LAFS in Lucid to v1.6.1 of Tahoe-LAFS" [Undecided,New]
<persia> OK.  I just argue against what I consider poor practice when I see it.  If you understand why I think it's poor practice, and are willing to accept the costs, then go ahead.
<zooko> It is urgent because it is to upgrade a version of a package for Lucid
<persia> rockstar: Do you need a hand with that, or are you expecting to get to it soon?
<jayvee> zooko: you're the guy that helped me test Wesnoth for OLPC :-)
<zooko> jayvee: :-)
<zooko> Me and my son Irby.
<persia> zooko: I seem to remember you confirming that it was 100% bugfix, so it's not incredibly urgent.  Let's see if rockstar can get to it (or at least tell us that he needs help) in the next day or two.
<persia> zooko: Just to confirm, rockstar *did* tell you to assign him, right?
<duanedesign> persia: if i add the manpages to the Debian directory, i then need to put install 'instrucions' in the debian/rules folder?
<persia> duanedesign: debian/rules isn't a folder :)
<persia> duanedesign: And you probably want debian/db4.2-doc.manpages (read `man dh_installman`)
<duanedesign> persia: ha ha. d'oh
<zooko> persia: yes it is 100% bugfix.
<zooko> Just to re-iterate, here is the NEWS file: http://allmydata.org/trac/tahoe-lafs/browser/NEWS
<zooko> I *think* rockstar agreed to do it, but he didn't actually say "And please assign that launchpad ticket to me". :-)
<persia> zooko: Cool.  That means we aren't under quite as much pressume (no freeze exception required).
<persia> Oh, assigning people when they didn't explicitly ask for assignment and you're not in charge of what they do (e.g. being their boss) is poor form.
<zooko> Okay.
<persia> But that makes it mostly up for grabs.
<persia> jayvee: Feel like processing an update?
<zooko> I'm familiar with a different work flow where assigning people to a ticket is more like a suggestion and them "accepting" the ticket is the committing thing.
<zooko> But now I know.
<persia> We don't have any accept feature, so we double-load assignment.  We use subscription for the suggestions.
<persia> No worries.
<jayvee> persia: what sort of update?
<jayvee> zooko's update?
<persia> Indeed.  Apparently rockstar didn't actually commit to it, and so the assignment was based on different semantics than those we usually use.
<jayvee> so that would involve basically downloading the new source, moving debian/ across, and making sure it all compiles?
<persia> And updating debian/ if necessary, and adding a changelog entry describing what you've done, yes.
<jayvee> sure
<jayvee> I'll have a bash
<zooko> Cool!
<zooko> Thanks!
<persia> zooko: Please stick around and help jayvee with any tests, etc. to make sure that the update works properly in lucid.
<jayvee> I'm running karmic myself, but I can test in chroots, pbuilder-dist, etc.
<zooko> I will try! However, I might fall asleep in my chair and if m head rests on the keyboard and sends a stream of characters, you'll know what happened.
<jayvee> zooko, what is the time there?
<zooko> 0:21
<zooko> jayvee: if you need help or any questions answered about Tahoe-LAFS, please join the #tahoe-lafs channel.
<zooko> I have to fall asleep now.
<jayvee> sure, no problem
<persia> zooko: There are people likely to be awake in that channel for more hours?
<zooko> persia: not sure.
<rawang> I want a newer package which is built in lucid, how can i make it depends on the package in lucid while i'm build karmic package?
<persia> rawang: Could you give a little more detail?
<rawang> persia, sorry for confusing. I need at-spi >= 1.29, and it's in lucid, but it's 1.28 in karmic
<rawang> but i need to build my package for karmic
<persia> rawang: Is the at-spi >= 1.29 a dependency or a build-dependency?
<rawang> persia, i think both
<Rhonda> rawang: Use a chroot environment like pbuilder or cowbuilder for that.
<rawang> Rhonda, yes, but i want to publish it on PPA
<Rhonda> So? :)
<rawang> so i have to handle with the dependency :)
<RainCT> rawang: I guess you can backport at-spi too then
<Rhonda> I still don't understand why a lucid chroot won't help you then?
<persia> rawang: Well, if it's a build-dependency, go read the upstream changelog carefully.  It may not be possible to build against an earlier version.
<persia> Rhonda: backport targeting karmic
<rawang> karmic only provides at-spi = 1.28, but at-spi 1.29 that i want is in lucid
<Rhonda> persia: Ah, the "how can i make it depends on the package in lucid" confused me seriously.
<rawang> Rhonda, i have to build against for  karmic
<Rhonda> rawang: Change that dependency in the source. If it's generated automatically it should get adjusted the same too.
<Rhonda> If it's though in the source as hard depends there probably is a reason behind it.
<Rhonda> So don't change it in the source if you don't know the impact.
<rawang> ok, let me explain more clearly,
<rawang> i want to build my package for karmic, so i have this "blah (blah) karmic; urgency-low" in changelog, and have dependency like "at-spi (>= 1.29.0)" in control file. but apparently, karmic don't have at-spi >=1.29, but it's in lucid repository.
<rawang> karmic repository on ubuntu PPA don't have at-spi >=1.29, but it's in lucid repository.
<persia> rawang: Right.  So you need to find out *why* it requires >= 1.29.0 of at-spi.
<Rhonda> rawang: Then it's like I said, yes. Find out why it has >=1.29 in it and what would break if you lower that to 1.28
<rawang> persia, the package source code depends on the newer at-spi :)
<persia> And either patch the source to not need that, or first backport that.  If at-spi >= 1.29 is not ABI compatible with at-spi << 1.29 then you have to also backport *all* at-spi rdepends.
<Rhonda> Then you would need to backport at-spi too.
<rawang> persia, Rhonda ahhhh, i see, i got your ideas
<rawang> thanks :)
<rawang> so karmic won't like to have a big number version increased, right?
<rawang> it just want to its packages stable
<persia> rawang: Such a change will not happen in the 9.10 release.  What you do in some third-party repository is up to you.
<rawang> k, i understand :D
<jayvee> persia: well I reckon it's working
<jayvee> just attempting to get ubuntu-vm-builder to build a lucid VM for me to test in
<persia> jayvee: Cool!
<jayvee> zooko will be happy
<jayvee> uploaded it to my ppa for him to grab
<persia> jayvee: If you're confident it works, attach the diff.gz to the bug and subscribe the correct sponsors queue.
<persia> May as well just dunk it in lucid if it's in good shape and get wider testing.
<jayvee> persia: Just one question though: the original tarball used the wrong initial directory, allmydata-tahoe-1.6.1, instead of tahoe-lafs-1.6.1. Does that mean I also have to upload a new .orig.tar.gz?
<jayvee> And if so, is it okay to attach the .orig.tar.gz to the launchpad bug report?
<directhex> the dir name in the orig tarball doesn't matter
<jayvee> directhex: that's good â how does that work?
<Laney> --strip-components=1
<jayvee> mkdir $package-$version && tar -xvf $orig --strip-components=1?
<jayvee> oops, insert a "cd $package-$version" in there
<directhex> something like that. i don't look at dpkg-source guts
<jayvee> aha
<jayvee> just have to rename the tarball, I spose
<Laney> yes
<persia> jayvee: You're going to want to upload a new orig.tar.gz for the new upstream.  What name and initial directory name upstream used is unimportant.
<jayvee> kewl
<jayvee> persia: looks like I can use the untouched upstream one though
<persia> Yeah, you just need to rename it.
<jayvee> what's interesting is that the 1.6.0 orig.tar.gz doesn't match upstream's 1.6.0 tar.gz
<persia> zooko takes care to make sure their tarballs work with us well.
<jayvee> so evidently paul@ubuntu.com didn't know about that
<persia> How don't they match?
<jayvee> the initial directory is changed :)
<persia> And nothing else?
<persia> No removals or anything?
<jayvee> don't think so, let me check
<jayvee> nope
<jayvee> no difference
<jayvee> diff -ur says no difference â only the inital directories are different
<jayvee> yeah, you're right â can't believe I didn't test it before
<jayvee> debuild -S works perfectly with the upstream tar.gz
<jayvee> cool
<jayvee> so I'll just paste a URL to it in the bug report
<jayvee> in the meantime, ubuntu-vm-builder is crashing as usual
<jayvee> every single time I use it, it crashes for some reason or another â buggiest piece of software I have ever used
<jayvee> time for a lucid netinstall instead, methinks
<persia> jayvee: Yeah, that repack is just a case of undereducated developer and insufficiently careful sponsor.  We do that sometimes, although we try to avoid it.  Thanks for catching it and asking for the update.
<jayvee> heh
<jayvee> well you learn something new every day
<ara> to get a list of installed packages and their versions, is `dpkg -l | grep ^ii` correct?
<jayvee> I use `dpkg --get-selections`
<ara> jayvee, but that does not give versions, does it?
<jayvee> no, you're right
<jayvee> your solution isn't bad at all â use it :)
<persia> ara: In most cases you can drop the grep.  Anything where that grep doesn't matched has leftover config files.
<persia> (so you did install it, and didn't completely purge it)
<ara> persia, jayvee: thanks
<POX> ara: aptitude search -F "%p %V" ~i
<POX> probably with --disable-columns
<jetienne_> q. anybody familiar with minidinstall ? can i just copy the .deb in mini-dinstall incoming if i dont have the changes and all ?
<Laney> james_w: Here's the list again http://dpaste.com/167585/
<Laney> I'll close the xmonad-contrib sync bug
<Laney> oh, no it already got done
<james_w> woop
<Laney> please leave that one out then
<james_w> ok
<Laney> StevenK: you forgot to set the bug to fix released ;)
<jetienne_> DinstallException: 'Unknown distribution "karmic" in "/home/jerome/public_html/ubuntu/mini-dinstall/incoming/media-services_1.00_i386.changes"'
<jetienne_> this is from a mini-dinstall... any idea why he think karmic is not a distribution ?
<nigelb> I want to request a sync of a package from debian, but before that I'd like to build and test it.  I got the package from debian.  Anything to change other than the maintainers?
<Laney> don't change anything to do a sync
<geser> nigelb: how to you want to build the package? pbuilder or PPA?
<nigelb> pbuilder
<nigelb> and then tell it to use the current X
<geser> then just take the unmodified Debian package and throw it at your pbuilder
<nigelb> oh, now why didn't I think of that one :o
<geser> pbuilder doesn't care about distribution names in debian/changelog or the Maintainer field
<nigelb> only I have to satisfy deps before actually doing the install. right?
<geser> right
<jetienne_> nobody on my "why minidinstall think karmic is no distro" question ?
<geser> jetienne_: I don't use mini-dinstall, so I can't help you. Try looking at the configuration if there's a list of acceptable release names (and if this doesn't help look at the code)
<jetienne_> media-services (1.00) karmic; urgency=low !<- this is a line from changelogs ... is this correct ? (apparently karmic is picked up from here)
<jetienne_> geser: ok looking
<nigelb> dont worry about changelog
<nigelb> thats not where you should be looking
<geser> in this case it might matter as mini-dinstall is an archive software
<nigelb> oh
<jetienne_> geser: nigelb: thanks it got fixed
<jetienne_> apparently the repository names in mini-dinstall must be the same as package distribution
<jayvee> fcuk112: your username is a little edgy
<nigelb> bdrung_: built and tested epiphany-extensions-more, works beautifully :)
<bdrung_> nigelb: great
<nigelb> I'm changing that bug to ffe request
<nigelb> just a doubt though, the changelog diff means, I get upstream changelog and current ubuntu changelog and run a diff on it?
<bdrung_> nigelb: i will unsubscribe u-u-s, please resubscribe once the FFe is granted
<nigelb> will do
<nigelb> bug 529835
<ubottu> Launchpad bug 529835 in epiphany-extensions-more "[FFE] Please sync epiphany-extensions-more 2.29.90+nmu1 from Debian" [Undecided,New] https://launchpad.net/bugs/529835
<nigelb> (in case you have to hunt for it )
<bdrung_> nigelb: yes, the diff between current upstream changelog of the debian package -> upstream changelog from to debian package
<nigelb> thank you, I'll do that in a minute
<nigelb> where does the logfile from --logfile option of pbuilder get saved?
<Rhonda> nigelb: Where you specify. :)
<persia> What's the default?
<nigelb> oh no, I just specified the file name
<Rhonda> There's no default for --logfile because it requires an argument.
<Rhonda> But I would expect relative paths to go from the results directory.
<Rhonda> Likewise with where --pkgname-logfile is put into, /var/cache/pbuilder/result/
 * persia hugs sbuild harder for doing sensible things with logs by default
<nigelb> its not there in /var/cache/pbuilder/result
<Rhonda> persia: I consider putting the logfile into the result directory to be very sensible, but then that might be just me.
<nigelb> ugh, I have to build again, for a log file.  still better than the floundering with gmake that persia helped me with
<Rhonda> nigelb: Use --pkgname-logfile, that's quite convenient.
<nigelb> it gets saved in the results folder
<persia> Rhonda: That's not bad.  sbuild puts all my logs in a logfile hierarchy or mails them to me (if I give it my email address).
<nigelb> ?
<persia> (but most excitingly, I don't have to add any parameters, or think about it)
<nigelb> Rhonda: wasn't it you who wanted help with irssi bugs? ;)
<Rhonda> nigelb: Yes, the --pkgname-logfile gets saved in the result directory.
<Rhonda> Always!
<nigelb> thats kinda cool.
<nigelb> I can deal with Lp bugs :
<nigelb> :)
<Rhonda> Thanks for the offer. :)
<nigelb> rhythmbox is getting saner by day now ;)
<nigelb> Rhonda: only 6 bugs? wow, thats nice ;)
<Rhonda> I did do what I could.
<Rhonda> At least the obvious parts are gone - sorry. :)
<toabctl> how can i install the new ubuntu light theme? (i use lucid devel)
<nigelb>  --pkgname-logfile needs an arugment?
<nigelb> because I dont find the log anywhere
<c_korn> toabctl: this question is more approriate in #ubuntu+1
<Rhonda> nigelb: No, it doesn't. Like said, it gets stored into the /var/cache/pbuilder/result/ directory.
<Rhonda> nigelb: <sourcepackage>_<version>_<architecture>.build should be the name.
<nigelb> Rhonda: not there for me.  so I deleted everything from that folder and tried building again
<nigelb> (well, the build is still going on)
<Rhonda> nigelb: You didn't do the rm after you started the build, just in case?
<nigelb> it was on the same terminal, so I started the build after the deletion
<nigelb> I only see 4 files after the build is over: a deb, a tar, a dsc, and changes
<dholbach> "Running a Packaging Jam" session in 9 minutes in #ubuntu-locoteams
<persia> Glah!  That reminds me that I completely failed to run a session today.  Handy nobody showed up for it.
<nigelb> persia: when was your session?
<persia> Was supposed to be at 6:00 UTC.
<nigelb> persia: you could have told me to advertise, I could have spammed identica/twitter ;)
<persia> nigelb: I'm glad I didn't, given that I remembered about it about 8 hours before it started and 8 hours after it ended, and not a moment between.
<nigelb> persia: haha.
<gnomefreak> is there someone dedicated to mplayer?
<gnomefreak> all i get is code devs and debain* devs
<gnomefreak> siretart: do you have a minute about a changelog entry you have for mplayer
<dbell> Hey, I'm wondering if I could get some advise about packaging my python game. I've tried following https://wiki.ubuntu.com/PackagingGuide/Python and managed to build a deb. However, since I'm new to python I've not had any experience in creating setup.py so I'm having problems with being able to run my program. Anyone able to give me some pointers on setting up my setup.py so that I'm able to build a deb and be able to r
<dbell> un and distribute my game?
<vorian> dbell: it might help to look at some other python apps, chm2pdf for example
<vorian> I have a feeling motu-release has changed ...
<vorian> what is different than the past cycles?
<ScottK> vorian: No more motu-release.  Now it's just ubuntu-release in one team.
<vorian> ScottK: so as for the freeze approval, any motu/core can approve?
<vorian> I know that was being discussed last time around
<ScottK> vorian: No, it's ubuntu-release team now instead of motu-release, but the motu-release members who were active at the time are in ubuntu-release.
<ScottK> So other than you subscribe a different team, not much has changed.
<ScottK> We did get rid of the two ack's rule.
<vorian> okie dokie
<ScottK> That's the biggest change.
<vorian> ok
<christoph_debian> hmmm I'm quite sure I sent out a cl-irc sync request but can't find it anywhere ... shall I re-request?
 * persia hunts
<persia> Please do.  It appears to have found a grue.
<christoph_debian> Sync request mailed.
<christoph_debian> that one Â»justÂ« fixes an rc bug
<zooko> Good morning! (UTC-8)
<iulian> Hi.
<zooko> How are you today iulian?
<iulian> zooko: I'm about to go to bed.
 * iulian yawns.
<iulian> zooko: You?
<bjsnider> siretart, so you intend for ffmpeg 0.5.1 to be the version that goes into lucid?
<sebner> bjsnider: it's already in
<bjsnider> yes but lucid isn't officially released yet
<Philip5> hi guys! anyone know of a good pbuilder hook to use with sun java to accept the license agreement during build? and at the same time how would I build with sun java on launchpad without the hook?
<geser> with debconf preset
<geser> I know that LP had this set in the past, don't know if it still the case
<geser> doesn't the app work with openjdk and really needs sun jdk?
<lifeless> Philip5: there is a ebconf setting
<lifeless> Philip5: its documented in the wiki, under java
<Philip5> lifeless: thanks... i'll have a read then
<debfx> siretart: a new keepassx release is ready, orig tarball: http://downloads.sourceforge.net/keepassx/keepassx-0.4.2.tar.gz
#ubuntu-motu 2010-03-05
<jayvee> zul: ping
<zul> jayvee: pong
<jayvee> zul: I was told to ping you with regards to a bug report of mine
<jayvee> actually, looks like I got a response from somebody else, but this is it: https://bugs.launchpad.net/libvirt/+bug/528934
<zul> jayvee: ok whats the bug report?
<ubottu> Launchpad bug 528934 in libvirt "IPv6 shouldnât be disabled by default in libvirt" [Wishlist,Triaged]
<zul> can you attach the upstream bug report to it?
<jayvee> zul: just done
<jayvee> I was sure that Iâd done it before, but I guess I mustnât have.
<zul> thanks
<jayvee> I presume youâre ~zulcss on Launchpad? :)
<zul> yep
<getxsick> anyone around?
<persia> !ask
<ubottu> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<getxsick> i'm reading that Ubuntu Policy and it's written about different package versioning schemes (Ubuntu uses ubuntuX). well, i just downloaded the source via apt-get source and what i see in debian/changelog, there is no that ubuntuX
<funkyHat> getxsick: use dch -i to update the changelog, it will add an entry with the correct version number
<persia> Which version do you have, for which package?
<getxsick> persia: i'm updating scripts for pypy* packages, because we are releasing 1.2 version
<getxsick> the last time we did it for long time ago and it was for Debian
<persia> getxsick: Seems like Ubuntu is using the Debian source of that unmodified.
<getxsick> persia: possible
<persia> That's why you find that versioning.
<getxsick> persia: at least, we are not really interested in supporting Debian, we would like to use launchpad PPA...
<persia> It also looks like pypy was removed from Debian and that removal was synced to Ubuntu.
<persia> Oh, then the version doesn't matter at all.
<getxsick> ah
<persia> In fact, I recommend using -0ppaN where N is incremented for each rebuild as the revision.
<persia> But this really isn't the best place to ask about PPA stuff: we don't support PPAs.
<getxsick> what if we would like to include pypy to next ubuntu release?
<persia> If you'd like it in Ubuntu, I'll recommend putting it back in Debian: that's the easiest way.
<getxsick> persia: why?
<funkyHat> getxsick: because Ubuntu syncs from debian automatically
<funkyHat> getxsick: also if you submit a package to Ubuntu and later a newer version gets uploaded to Debian that creates more work because someone has to check the the Ubuntu version doesn't have any changes that need to be kept.
<funkyHat> woo long sentence
<persia> getxsick: Because of what funkyHat said, and because there are no dedicated maintainers in Ubuntu, so unless something is particularly popular, it usually gets deleted after a while if it's not in Debian.
<getxsick> we can maintain it, that's not a problem
<persia> well, except you can't, unless you can continuously convince some developer to upload any changes.
<persia> Based on past history it usually takes 18-36 months for someone pushing changes to only one package and not otherwise acting as an Ubuntu Developer to be granted upload rights to that package.
<funkyHat> Also why do you want to leave Debian out?
<persia> If you can maintain it, why not sign up as the Debian Maintainer.
<getxsick> persia: actually i don't know, have to check in maling list ;) i just knew that there were some different opinions between us and them ;)
<persia> Hrm.  Depends on the difference of opinion.  If it was mainly personal, we may be able to help work around that.  If it was technical, we tend to share their opinions.
<getxsick> persia: it was 2-3 years ago
<getxsick> anyway, our buildbots run under Ubuntu
<persia> Things may well have changed.
<getxsick> persia: sure
<getxsick> well, i will talk with others what they think about
<persia> Yeah.  I understand the goal is to get it in Ubuntu, and I support that goal, I just happen to think getting it into Debian is the easiest way to get it into Ubuntu and make sure it stays in Ubuntu.
<getxsick> persia: ok. i understand this point
<persia> But I'd be happy to help you try to get it into the Ubuntu 10.10 release if you really want, I just have a sense that without sorting the issue with Debian, it would be dropped for 12.04 if not sooner.
<getxsick> persia: 12.04? :)
<persia> Yes.
<getxsick> isn't 2012?
<persia> We plan things out a fair bit in advance.
<persia> Yes.
<getxsick> michael hudson (who is one of the pypy developer) said that it should be included in 10.10 AFAIR
<getxsick> well, when do you freeze debian unstable for 10.10 ?
<persia> Based on https://wiki.ubuntu.com/MReleaseSchedule it looks like 24th June.
<persia> But we can pull new packages until 26th August, if we need, it's just not automatic.
<getxsick> persia: cool
<persia> I'd suggest targeting mid-late June, and leaving the rest as a gap for coverage if anything goes wrong.
<getxsick> we are releasing final 1.2 by the end of March
<getxsick> so it shouldn't be any problem
<persia> Cool.
<funkyHat> I'm looking at the merge report for sensors-applet https://merges.ubuntu.com/s/sensors-applet/REPORT - everything looks great, I'm just running a test build now. But I've found this bug https://bugs.edge.launchpad.net/ubuntu/+source/sensors-applet/+bug/380669 which wants to upgrade to 2.2.5-3
<ubottu> Launchpad bug 380669 in sensors-applet "Please merge sensors-applet 2.2.5-3 (universe) from Debian (unstable)" [Unknown,Fix released]
<funkyHat> Should we upgrade to 2.2.5-3, or only to 2.2.4-2. ...5-3 is only in unstable
<persia> funkyHat: Which one works better with lucid?
<funkyHat> persia: I don't know. How do I grab the debian source packages for 2.2.5-3?
<persia> pull-debian-source works, or visit packages.qa.debian.org and use dget or visit qa.ubuntuwire.com/multidistrotools and use dget or ...
 * persia tends to open a sid schroot and apt-get source stuff
<funkyHat> Ok, building 2.2.5-3 now
<funkyHat> persia: well I've hit a limitation of using a VM which is I don't have any sensors, so I can't really test properly
<funkyHat> Other than that I can't see any problems with 2.5.5-3
<persia> Then you either need to find some testers, or upgrade :)
<persia> Given that we're past FeatureFreeze, I'd recommend doing both.
<funkyHat> I'm going to be buying a wacom tablet soon, and I heard that Lucid didn't support them a while ago... I'll have to investigate whether that's been resolved
<AnAnt> Hello, could someone grant FFe to LP 530204 ?
<ubottu> Launchpad bug 530204 in libbasicplayer-java "FFe: Sync libbasicplayer-java 3.0-5 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/530204
<AnAnt> especially it also closes LP 491784
<ubottu> Launchpad bug 491784 in openjdk-6 "Sound does not work with openjdk" [Undecided,New] https://launchpad.net/bugs/491784
<dholbach> good morning
<jayvee> hmm, no feedback from zooko or his team about the tahoe-lafs package
<GheRivero> morning
<wrapster> i have a control file like so.. http://pastie.org/855217 .. which in turn builds a lot of other pakcages.. and i wanted to say that in a particular pkg 'spjadbx' it conflicts with ss12.. So i enter that that pkg declaration and built that pkg..But when i tried installing it.. it fails saying that there is a file present in this pkg as well as another pkg(the very reason why i added conflicts)... and when i open the control file again.. the conflicts 
<siretart> bjsnider: exactly!
<siretart> debfx: i've just filed a debian bugreport to not forget it! thanks for notifying me
<debfx> siretart: okay, packaging branch should be ready for upload
<hakaishi> Hi, Iâd like to remove qt-shutdown-p from revu, since there is a newer package of it with a new name and is already uploaded to debian. What can I do, who can I ask (to remove it)?
<hakaishi> Does nobody know?
<hakaishi> X-P
<falktx> hi there
<falktx> I've sucessfully send a package to revu and it was accepted
<falktx> now I need to fix a bug in the package
<falktx> I've made the needed changes and it's ready for upload
<falktx> how should I do it?
<falktx> using 'dput ubuntu *.changes' doesn't work
<falktx> ideas?
<geser> let me guess, it complains that's it's already uploaded?
<geser> dput -f ...
<falktx> nope
<falktx> it uploads
<falktx> then I receive an email saying it was been rejected
<falktx> message says: "The signer of this package has no upload rights to this distribution's primary archive.  Did you mean to upload to a PPA?"
<falktx> I am the maintainer of the package
<falktx> I did try now just 'dput *.changes', no mail answer so far
<falktx> the wiki revu page says I should manage the package through launchpad
<falktx> but I guess it doesn't allow new uploads (?)
<falktx> (just got the rejection mail again)
<falktx> should I upload to REVU again ??
<geser> ah, then you are not uploading to REVU but to the official archive
<geser> "dput revu yourpackage_source.changes"
<falktx> but I though I could just upload to universe and not going for the revu stuff all over again...
<falktx> if the package is assigned to me, isn't there a faster way to do this?
<geser> your package is already part of official archive?
<falktx> yes
<falktx> https://launchpad.net/ubuntu/+source/zyn
<falktx> (this is the first time I do this, please be patient)
<geser> then you don't need to go through REVU again
<falktx> - thanks -
<falktx> so how?
<geser> create a debdiff with your changes (or alternatively prepare a bzr branch for merging (if you like))
<geser> open a bug and attach your debdiff (or link merge proposal) to the bug and subscribe ubuntu-universe-sponsors for sponsoring
<geser> see also https://wiki.ubuntu.com/SponsorshipProcess
<falktx> i'll look into that, thanks again
<porthose>  it may need a FFe https://wiki.ubuntu.com/FreezeExceptionProcess
<geser> not for a fix of a bug
<porthose> key word *may* :)
<falktx> thanks guys, you rock!
<falktx> I created a debdiff, now into sponsorship...
<falktx> I'm unsure about what to do next...
<falktx> https://bugs.launchpad.net/ubuntu/+source/zyn/+bug/532590
<ubottu> Launchpad bug 532590 in zyn "Install path is wrong" [Undecided,Confirmed]
<falktx> should I just wait ? or is it something missing ?
<randomaction> falktx: I mean, subscribe the team to your bug
<randomaction> there's a "Subscribe someone else" link on the right-hand side
<falktx> done
<falktx> thanks
<JamieBennett> I'm trying to push a revision of a package up to REVU: http://revu.ubuntuwire.com/p/webservice-office-zoho but its not appearing even though I get a successful upload message. I pushed around an hour ago and still nothing. Any idea's (I signed the package with a different key this time, would that cause problems?)
<mok0> JamieBennett: If it's a revision, better do through a bug in LP.
<mok0> JamieBennett: because it needs to clear through as an SRU anyway
<JamieBennett> mok0: sorry, its me not being clear, this is a new package but I made changes to it today and tried to upload
<mok0> JamieBennett: ah
<JamieBennett> Its currently not in the archive
<mok0> JamieBennett: the signing key must be the same as the one you have in LP
<JamieBennett> mok0: Oh, maybe thats it, I'm not sure if LP has this new key
 * JamieBennett goes to check
<c_korn> hello. the scilab package in lucid is currently broken because the build for amd64 timed out. I added a watchdog process which prints a message every ten minutes (because the compilation just needs some time but it is still going on). do I need a FFe for this change ?
<c_korn> (would be a new revision to sync from Debian)
<mok0> c_korn: yes you would
<geser> mok0: why a FFe?
<mok0> c_korn: because there are new features in a new version
<geser> mok0: is only a revision bump, no upstream version bump if I understood c_korn correctly
<mok0> ah
<c_korn> new features ? I already got a FFe granted for scilab 5.2.1-3 the new one is 5.2.1-4 which adds the watchdog
<c_korn> yes, geser is right
<mok0> But you need to file a sync request then
<c_korn> yeah, I just talked to the Debian maintainer. he is currently building it. so I have to wait for the package to be in Debian.
<c_korn> I thank you
<mok0> c_korn: I remember scilab 5.1 had lots of problems compiling etc. Is that better now?
<mok0> c_korn: I helped push a bunch of dependencies through AFAIR
<c_korn> yeah, we required a lot of packages synced from Debian last time. and because we were a bit late we also required a FFe for them. should be easier this time. it already compiled fine in a PPA. just times out on amd64 when building for the archive.
<mok0> c_korn: what do you mean "times out"?
<geser> mok0: if there is no output for 150min the build gets killed
<mok0> Weird
<mok0> What is it waiting for?
<c_korn> yeah, and the compilation of the docs is "slow like hell" :)
<c_korn> mok0: it is not waiting. it is compiling. it is java :)
<geser> either the build is bugged or a very long running process (which is it in this case)
<c_korn> it just takes some time. 4h in a PPA: https://launchpad.net/~getdeb-package-managers/+archive/ppa/+build/1527822
<c_korn> the build for the archive times out after 3h: https://launchpad.net/ubuntu/+source/scilab/5.2.1-3/+build/1525155
<StevenK> The PPA builds are slightly faster, I think
<geser> btw: does somebody know if ghc6 on armel is still building (for over a week now) or stuck?
<lan3y> probably stuck :(
<lan3y> wait what is this nick
<ogra> its unlikely that you have packages that build a week ... even on armel
<Laney> it took 6 days on debian
<Laney> but yeah i would expect it to have done by now
<ogra> Laney, what kind of armel builders does debian use ? we have 800MHz/512MB machines
<ogra> ubuntu builds should be generally a bit faster than debian ones
<Laney> ogra: http://db.debian.org/machines.cgi?host=ancina http://db.debian.org/machines.cgi?host=arcadelt http://db.debian.org/machines.cgi?host=argento
<Laney> there must be some other difference that makes the build hang on Ubuntu but not Debian :(
<ogra> debian doesnt optimize for ARMv7
<ogra> we use v7 and thumb2 optimizations
<ogra> sad there is no cpuspeed info on the pages
<Laney> you could check in #debian-arm
<bjsnider> siretart, you're the ffmpeg expert, not me, but isn't the 0.5.1 code actually older than what is in karmic?
<JamieBennett> still no luck with REVU. I've added my key to launchpad, is there a delay before it works with REVU?
<JamieBennett> are there any admins around to poke REVU and see whats happening for me?
<mok0> JamieBennett: All I can see is that you have a rejected upload at 15:01
<JamieBennett> mok0: does it say why it was rejected?
<mok0> No
<mok0> JamieBennett: Nothing I know about, anyway
<mok0> But it very likely has to do with your gpg key changes
<JamieBennett> mok0: Shame, I'm getting a 'Successfully uploaded packages.' message. Maybe its a key propogation problem, my key is in launchpad, maybe there is some delay?
<mok0> JamieBennett: Indeed there is
<JamieBennett> mok0: OK, I'll leave it for a while, thanks for the help so far.
<mok0> JamieBennett: NP
<JamieBennett> and as that is said, the package magically appears this time :)
<ogra> :)
<mok0> Ah, patience is a virtue
<JamieBennett> mok0: bah
<JamieBennett> ;)
<mok0> That said, can anyone tell me why I'm getting two different popup notification every time?
<mok0> Because it annoys the hell out of me...
<JamieBennett> ls
 * JamieBennett is having one of them days
<mok0> No files found
<hakaishi> Hi everyone! Could someone tell me how a package from Debian gets into the Ubuntu sources?
<hggdh> usually it is via a sync request
<hakaishi> hggdh: and where could I do that?
<hggdh> hakaishi: please see https://wiki.ubuntu.com/SyncRequestProcess
<hakaishi> cool, thank you
<mok0> hakaishi: bear in mind that we are now in FF, and syncs will only happen if they fix bugs
<nigelb> hakaishi: if its something for lucid, please see https://wiki.ubuntu.com/FreezeExceptionProcess too
<hakaishi> Since my packages only got uploaded to debian, it'll take some time till I can do a sync request...
<donkyhotay> can someone help me figure out why my package isn't showing up in revu? I followed the instructions at https://wiki.ubuntu.com/MOTU/Packages/REVU including logging in, uploading GPG key and using dput. Didn't get any errors or messages but it hasn't shown up yet.
<hakaishi> donkyhotay: did you get an e-mail for successfully uploading? - If not it would be something wrong with your dput.cf
<donkyhotay> I didn't get a confirmation Email, I didn't change my dput.cf since it sounded like the default file on a standard karmic would work so long as I used "dput revu filename_source.changes" which I did
<hakaishi> donkyhotay: please look at https://wiki.ubuntu.com/MOTU/Packages/REVU
<donkyhotay> As I mentioned before, I followed the instructions on that page. I even checked my dput.cf file and confirmed it has the revu entry the wiki says is preconfigured from 6.06 and on
<hakaishi> donkyhotay: and dput did the upload without any warnings/errors? - That's strange... Then I don't know how to help you, sorry  -.-'
<donkyhotay> Yeah, thats the part that confuses me. I did everything exactly, dput gave me no warnings or errors. Confirmed my key was uploaded, even redid the package to confirm dpkg-buildpackage wasn't giving my warnings of this being unsigned (which I did get earlier but have since resolved)
<hakaishi> mok0: From which Debian version will the packages be included into the new Ubuntu version? (I'll have to do the sync request till the next DebianImportFreeze, right?) - Will it be sid, or squeeze?
<mok0> hakaishi: for lucid, it is testing
<mok0> hakaishi: normally, it's unstable
<mok0> (Lucid is a LTS release)
<mok0> hakaishi: So for lucid+1, the sync will be from unstable. It will get synced automatically when the cycle starts
<mok0> hakaishi: therefore, if the sync you request is for lucid+1, there's no need to do anything
<hakaishi> mok0: okay, thank you for your help^^
<mok0> hakaishi: my pleasure .-)
<donkyhotay> Oh wait... my old key is the one currently registered? I thought I checked that... Well I feel a little silly now. I think I found the problem.
<hakaishi> donkyhotay: then I'll wish you goog luck ;)
<hakaishi> *good
<donkyhotay> I'm updating my keys, should work this time around.
<hakaishi> mok0: There is still one more thing I'm wondering about. If my packages from sid get into lucid+1, will I have to upload them into sid+1 to get the packages into lucid+2 again?
<mok0> hakaishi: once the package is in Debian, it will be synced for every Ubuntu release
<mok0> hakaishi: so if you maintain your package in Debian (sid) all is dandy
<hakaishi> mok0: cool XD, thanks again^^
<hakaishi> bye bye ;)
<hyperair> any archive admin around?
<hyperair> bug #529340 could use some love
<ubottu> Launchpad bug 529340 in taglib-sharp "FFe: Sync taglib-sharp 2.0.3.6+dfsg-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/529340
<lightnin> Is there a debhelper script that installs / registers .desktop files?
<lightnin> or do I just use dh_install desktop_file /usr/share/applications?
<hyperair> lightnin: the latter.
<hyperair> lightnin: a dpkg trigger from one of the packages will register it.
<sebner> lightnin: you might want to use a .install file though
<lightnin> hyperair:Thanks! How do I go about making a "dpkg trigger" happen?
<hyperair> lightnin: just put the file in /usr/share/applications, it'll trigger automatically.
<donkyhotay> Yep, outdated GPG key was definitely my problem as my package is now on revu. Now I just need to wait for some MOTU's to check out my game and either advocate it or tell me whats wrong with. (c:
<vincs> Hi.
<lightnin> cool. Do I  need to run "gtk-update-icon-cache"? It's in my postinst script, but it seems like it's not needed if I've installed the desktop file (and it breaks in KDE)
<hyperair> i'm not sure
<vincs> When debian/watch file is used, do a get-orig-source rule is needed in debian/rules file ?
<sebner> hyperair: will you wait for banshee 1.5.5 until updating?
<hyperair> sebner: i'm waiting for taglib-sharp. our archive-admins are asleep, i think?
<hyperair> sebner: at the rate we're going, it's better to wait for 1.5.5, yeah.
<hyperair> sebner: assuming taglib-sharp gets in before 1.5.5 appears.
<sebner> hyperair: I guess, it's nearly weekend after all. Wondering if some update will fiXX0r my crashes/halt whatever
<hyperair> sebner: taglib-sharp's been like that all week.
<hyperair> hmm maybe it's because i forgot to remove the FFe tag
<hyperair> sebner: http://www.facebook.com/video/video.php?v=101470883219048
<hyperair> er shit
<hyperair> https://bugs.launchpad.net/ubuntu/+source/taglib-sharp/+bug/529340
<ubottu> Launchpad bug 529340 in taglib-sharp "FFe: Sync taglib-sharp 2.0.3.6+dfsg-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed]
<hyperair> stale clipboards ftl.
<sebner> heh
<sebner> hyperair: nah, we just have to wait. Or you bug the archive admin which is on duty today
<hyperair> sebner: who?
<hyperair> sebner: (and the facebook video is pretty funny all the same, if you feel like viewing it)
<sebner> hyperair: jdstrand
<hyperair> sebner: how do you tell?
<sebner> hyperair: nvm, I'm not at facebook
<hyperair> heheh
<sebner> hyperair: https://wiki.ubuntu.com/ArchiveAdministration#Archive%20days
<hyperair> ah cool
<lightnin> Should I use dh_installmime to install xml files describing new mimetypes? Seems like it must be in /debian directory for this to work, but mimetype .xml file is in upstream tarball...
<vincs> When debian/watch file is used, do a get-orig-source rule is needed in debian/rules file ?
<randomaction> vincs: it's a good idea if there's no tarball that corresponds to the current state of the package (e.g. it's a snapshot or it was repackaged)
<vincs> It is a new package (not in debian or ubuntu).
<vincs> But the tarball is in upstream.
<randomaction> if the tarball for the version you're packaging can be obtained from upstream, there's no need for get-orig-source rule
<vincs> Ok. Thanks for your reply.
<hyperair> lightnin: the stuff in /usr/share/mime is debian-specific
<lightnin> hyperair: Oh, ok, so it doesn't really need to be in upstream tarball. I guess it doesn't hurt to be there though. (Btw- I am upstream and packager...)
<mok0> hyperair: can you help me out?
<hyperair> mok0: what's up?
<mok0> hyperair: bug 489845
<ubottu> Launchpad bug 489845 in karmic-backports "Please backport codelite" [Undecided,Incomplete] https://launchpad.net/bugs/489845
<mok0> hyperair: What version is in lucid?
<hyperair>   codelite | 1.0.2893+dfsg-0ubuntu2 | karmic/universe | source, amd64, i386
<hyperair>   codelite | 2.2.0.3681+dfsg-0ubuntu1 | lucid/universe | source, amd64, i386
<mok0> yes just got that
<mok0> hyperair: is it relevant to backport it?
<hyperair> mok0: i suppose so. there weren't many packaging changes. i think it can be ported directly.
<hyperair> mok0: i haven't testbuilt it though
<mok0> hyperair: I can do that
<mok0> hyperair: don't think it will be a problem, there aren't many toolchain changes
<hyperair> mok0: please do, then. i have to drag my ass out the door (and walk back to my hostel) pretty soon =)
<mok0> hyperair: right, thnx
<mok0> See you
<hyperair> mok0: not yet, but soon enough that i can't finish a testbuild ;-)
<hyperair> mok0: i own a pretty modest dual core machine, see
<mok0> hyperair: don't I know it? It takes forever...
<mok0> :)
<jdong> lol I just found out to my dismay that this new cluster I have access to is a lie.
<hyperair> mok0: yep. it was the first compilation that managed to overheat and shutdown my notebook =p
<jdong> it claims to be octo 3.06 xeon with 24G of RAM
<jdong> but apparently is all running virtualized.
<mok0> hyperair: great package to choose for maintenance, then ;-)
<jdong> was kinda surprised when python took longer to ./configure there than build locally.
<mok0> jdong: hehe
<hyperair> mok0: hehehe. i learnt my ^Z trick then ;-)
<jdong> hyperair: haha I have a script called heatlimit.py here
<jdong> that monitors ACPI thermal zones and throttles tasks based on temp.
<hyperair> jdong: that's made of win. =p
<jdong> stupid laptops.
<jdong> :)
<hyperair> jdong: i went the phc way.
<hyperair> jdong: undervolted my CPU, and cut the temperature by 20 degrees celcius =p
<jdong> I should just open up the stupid thing and blow it out with some compressed air
<jdong> it's just dust clogging up the fan.
<jdong> too lazy.
<hyperair> oh that's your case eh?
<hyperair> my fan is clean.
<hyperair> it overheats anyway
<jdong> ah ,ouch
<hyperair> overheated*
<hyperair> and the stupid thing is that it never generates enough heat when i want it to.
<hyperair> i was feeling particularly cold in this air-conditioned room earlier, and started a kernel compilation, turned off phc, and it didn't go past 60 degrees.
<jdong> hahaha
 * hyperair sighs
<jdong> one of my friends keeps a quad-core P4 Xeon in his room for that purpose.
<hyperair> heheheh
<jdong> he's told me that he tripped a circuit breaker with folding@home once.
<jdong> whoops bet that didn't help with heating :)
<hyperair> heheheh
<hyperair> yeah, i can imagine
<lightnin> Hmm... I don't seem to be able to make my binary package register it's new mime filetype on the target system. dh_installmime doesn't seem to do it...
<sebner> hyperair: syncs are processed in some hours so we might be lucky ones just before weekend ;D
<hyperair> sebner: cool
<vincs> I have reupload my fisrt package in REVU. REVU shows now no warning or common error. Do new packages are processed in a certain order or do I need to ask for an first person to advocate ?
<ScottK> vincs: We are past feature freeze for Lucid, so reviewing new packages is a low priority at the moment.
<vincs> ScottK: I know but as I am new at packaging and I would like to upload 4 packages for lucid+1. I start early.
<ScottK> OK, as long as your expectations aren't high ....
<vincs> No. If someone comments my package early I will make the necessary  changes. If not, I will wait.
<lightnin> If I need to run update-mime-database after registering a new filetype for my application, should I declare it as a dependency? It doesn't seem to come with kubuntu...
<randomaction> yes
<randomaction> you can use dh_installmime, which adds necessary fragments to maintainer scripts and adds necessary packages to ${misc:Depends}
<funkyHat> I've attached a compiled .deb for sensors-applet 2.2.5-3 to https://bugs.edge.launchpad.net/ubuntu/+source/sensors-applet/+bug/380669
<ubottu> Launchpad bug 380669 in sensors-applet "Please merge sensors-applet 2.2.5-3 (universe) from Debian (unstable)" [Unknown,Fix released]
<funkyHat> Don't know if that is a normal thing to do but it was suggest I find testers for the new version.
<funkyHat> I suppose a 32bit version would probably be helpful too
<siretart> bjsnider: no, but how do you come to this opinion?
<bjsnider> siretart, i tried building the 0.5.1 release in pbuilder using the build scripts for the karmic ffmpeg. the result failed because the vhook stuff was still there. but the build scripts do not contain the --disable-vhook flag, and the reason is that the vhook code isn't in the karmic version. i then explicitly asked the ffmpeg devs in that channel when vhook was removed from the code and they gave me an exact date: march 3 2009. i then asked if the
<bjsnider>  rest of the 5.1 release is at least that old and the answer was: yes.
<superm1> siretart, are you aware that mplayer FTBFS right now?
<siretart> superm1: no, but I'm aware that I really should revisit and finally upload the local changes to the package I have on my laptop
<superm1> siretart, indeed :)  I was considering looking into the FTBFS but figured its better to check with you first and not trump what you might have going on
<siretart> superm1: anyways, why does it ftbfs?
<bjsnider> it pulls in nvidia-current because of the build-depends on nvidia-xxx-libvdpau
<siretart> bjsnider: the version between the version in karmic and 0.5.1 should be pretty close. the difference is mainly that many patches that were in karmic got committed upstream for 0.5.1
<superm1> siretart, libmp4codec/ve_264.c or something like that (i dont have the log handy)
<bjsnider> easy to fix
<mok0> jdong: ping
<bjsnider> siretart, i just downloaded the tarball. maybe i got older code
<siretart> bjsnider: check the diffstat: http://wiki.tauware.de/~siretart/ffmpeg/diffstat.txt
<bjsnider> siretart, but your version doesn't have the two soname changes int he recent code
<bjsnider> and also, they told me there's a .6 release coming this month
<bjsnider> i guess that isn't enough time to get it into lucid
<sistpoty> no
<siretart> bjsnider: or you can check the diff here: http://git.debian.org/?p=pkg-multimedia/ffmpeg.git;a=shortlog;h=refs/heads/upstream-0.5
 * sebner waves as sistpoty :D
<siretart> bjsnider: no, 0.5.1 does not introduce any soname change. We need versioned symbols deployed before we can do that
<sistpoty> huhu sebner
<siretart> hey sistpoty!
<sistpoty> hi siretart
<sebner> sistpoty: In 4 Tagen hab ich GrunzÃ¼ge der Informatik WiederholungsprÃ¼fung. WÃ¤re recht mal anfang zu lernen xD
<sistpoty> sebner: better do that than ;)
<sistpoty> then even
<sebner> sistpoty: b000000000000ring :P
<sistpoty> heh
<siretart> sebner: 2nd or 3rd try?
<bjsnider> siretart, did you have to explicitly disable vhook in the 5.1 build?
<sebner> siretart: 2nd or course :P well, if I'm that lazy again it might turn out in a 3rd one xD
<siretart> bjsnider: vhook is disabled since ffmpeg-debian_0.svn20080925-1
<siretart> bjsnider: so that's no change since karmic AFAIUI
<bjsnider> i couldn't find that build flag in the confflags file or the rues file
<sebner> siretart: unless you wanna give me a hand :P
<siretart> bjsnider: debian/confflags, line 75
<bjsnider> strange
<siretart> don't horrify me like that
<siretart> ;-)
<bjsnider> it's not in these build scripts i'm using
<bjsnider> where did i get them
 * siretart points bjsnider to http://git.debian.org/?p=pkg-multimedia/ffmpeg.git;a=summary
<blueyed> "bzr branch lp:ubuntu/apport" does not result in the current sources. By design?
<geser> probably an error during package import into bzr
<geser> yep, see http://package-import.ubuntu.com/status/apport.html#2010-02-22%2011:47:45.304032
<jpds> lolsiretart .
<siretart> jpds?
<jpds> siretart: See log above. ;)
<siretart> oh, seems I'm holding some lock :-)
 * siretart passes a lock to jpds 
 * jpds hugs siretart.
<siretart> :-)
<blueyed> oh.. is there no more reasonable automatic timeout?
<james_w> blueyed: you want lp:apport for the moment
<blueyed> james_w: thanks, I've used the line from "apt-get source apport" already.
<sebner> christoph_debian: persia: I'm going too FFe sync supertux, are you ok with that? (Uhm, I already filed the bug though ^^)
<persia> sebner: Always.  Except where freezes get in the way, the Games Team likes to be in sync.
<sebner> persia: Great :)
* sistpoty changed the topic of #ubuntu-motu to: Feature Freeze in effect | Lucid Alpha 3 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.
<sebner> persia: haha, new record for me. 16 minutes until FFe granted and archive admins subscribed :D
<persia> sebner: Clearly you have some work to do.
<sebner> persia: hmm? rationale, changelog, buildlog, installing + screenshot all done
<persia> sebner: You might want to start digging into RCbugs.  At this point none of them need FFes, but once the freeze gets firmer, we end up needing release approval for every upload.  Building a background in RCBug work should get your turnaround time down to a minute or two once we get there.
<persia> sebner: The work is on reducing the 16 minutes, not on that bug :)
<sebner> persia: ah sure, but I might wait until next week (some important exam on tuesday and still a lot to learn)
<persia> Of course.  $study (like $life and $work) must necessarily take priority over Ubuntu, else you'll burn out and be unable to help.
<sebner> persia: heh, I have to defend myself. Building supertux took surely ~5-10 minutes :P
<sebner> persia: http://qa.ubuntuwire.com/bugs/rcbugs/ is still the place to start right?
<persia> sebner: If that's not the place to start, complain loudly.
<persia> sebner: If something is wrong, the most likely thing would be that it's still targeting karmic, but that usually changes around DIF time
<christoph_debian> sebner: was going to ask for it myself
<sebner> christoph_debian: heh, done already :)
<sebner> persia: aye :)
<sistpoty> thanks christoph_debian for packaging it in the first place :)
<christoph_debian> :)
 * sebner ^5 christoph_debian 
<sistpoty> superm1: I'm inclined to accept the FFe for bug #532933, any objections from your side?
<ubottu> Launchpad bug 532933 in imdbpy "Sync imdbpy 4.5.1-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/532933
<micahg> how do I force a build with a non-ubuntu maintainer address to build?
<persia> Easiest way is to use an unmangled dpkg-buildpackage
<micahg> persia: for upload...
<persia> You can also fiddle with dpkg-source
<micahg> sorry, I meant source build for upload
<persia> Yes.
<jdong> micahg: unset DEBMAIL?
<jdong> DEBEMAIL?
<persia> micahg: So, what's the top line of the changelog, and what's the maintainer?
<micahg> persia: it's for a no source change rebuild of openJDK
<micahg> to PPA
<persia> micahg: So, what's the top line of the changelog, and what's the maintainer?
<micahg> persia: not what they should be...
<persia> There is no "should"
<superm1> sistpoty, not that i can think of
<persia> So, I'll help you with the tools.
<persia> I won't help you get it into a PPA.
<micahg> ubuntux and not an ubuntu.com address
<sistpoty> superm1: thanks!
<persia> With luck, the former will result in the latter.
<micahg> I normally do debuild -S -sd, but that obviously doesn't work
<micahg> let me ask him if there's a reason that he doesn't update the maintainter for Ubuntu
<micahg> not around...
<persia> micahg: The easiest way is to use an unmangled dpkg-buildpackge.  You can also  fiddle with dpkg-source if you won't want to backport.  If you give me the top line of the changelog and the Maintainer entry, I may be able to suggest something else.
<sistpoty> superm1: another question: would you volunteer as delegate for mythbuntu packages in universe for ubuntu-release again? or would you suggest someone else=
<jdong> micahg: as mentioned, if the DEBMAIL environment variable is blank, the maintainer check isn't done.
<sistpoty> s/=/?
<micahg> jdong: k, I'll just do taht
<persia> jdong: That's not actually the case, depending on the changelog entries.
<jdong> micahg: DEBEMAIL rather
<jdong> with the E.
<jdong> persia: oh?
<micahg> this is still unofficial and I don't want to fiddle too much
<superm1> siretart`, i'm still the one that sponsors for all of ~mythbuntu (none of them have gotten motu or ~mythbuntu-dev yet, so yes, i'm fine)
<persia> jdong: At least I almost never set DEBEMAIL, and I get the check.
<micahg> persia: openjdk-6 (6b18~pre1-1ubuntu1.0ffox36.1) lucid; urgency=low
<sistpoty> superm1: thanks!
<micahg> jdong: no go
<persia> micahg: OK.  The issue you're encountering is that you have "ubuntu" in the version.  Don't do that.
<micahg> persia: that's what the current revision has.
<jdong> "  - scripts/dpkg-source.pl: Check that debian/control complies with
<jdong>     https://wiki.ubuntu.com/DebianMaintainerField: If $DEBEMAIL contains
<jdong>     '@ubuntu.com', refuse to build a source package if we have an Ubuntu
<jdong>     version number, but Maintainer: is not an Ubuntu address. Output a
<jdong>     warning if $DEBEMAIL contains 'ubuntu' but not '@ubuntu.com', or if
<jdong>     there is no XSBC-Original-Maintainer: field for packages with an
<jdong> gah
<micahg> it is currently ubuntu1 and it built for him
<jdong> that was a nastty paste
<micahg> so I'm just wondering what switch I need to override
<jdong> it doesn't appear to have a switch to bypass the check.
<geser> unset $DEBEMAIL temporarily
<persia> This whole "let's support third-party repositories" thing probably needs some tools work.
<jdong> geser: that's what I said initially, and it seems like it didn't work
<sistpoty> asac: would you be willing to act as ubuntu-release delegate again for universe packages related to mozilla packages?
 * micahg gives up and updates maintainer
<vincs> I have upload my first package to REVU. I am looking for someone to comment it. I have already amend all common errors. I understand that it is not the right time for packaging so I won't be upset if no one answers the call.
<sistpoty> cody-somerville: would you volunteer as ubuntu-release delegate for universe packages of xubuntu again?
<persia> micahg: Aren't you the primary mozillateam maintainer these days?
<micahg> persia: I wouldn't exactly say that...but I am one of the maintainers
<cody-somerville> sistpoty, Provided mr_pouit is permitted to also volunteer, yes :)
<sistpoty> cody-somerville: sure, if you can convince him ;)
<micahg> persia: but I don't have upload rights
<micahg> yet
 * persia thinks we should have a single release delegate for each delegation to preserve a small well-knit release team
<persia> micahg: Ah.  Nevermind then :)
<sistpoty> micahg, persia: yes, I'm trying to be a little bit conservative, but I guess a fallback might come in handy though
 * micahg will probably be pushing through most of the changes to mozilla universe packages in any case
<sistpoty> persia: redundancy eliminates a single point of ... blocking ;)
<sistpoty> micahg: would you want to volunteer for the position?
<micahg> sistpoty: do I need upload rights?
<sistpoty> micahg: you'll mainly need to know if a proposed FFe is good, so not necessarily
<persia> sistpoty: Well, yes, but I'd hope the redundancy could be found elsewhere within the release team.  Maybe I'm optimistic.
<sistpoty> persia: we've used more than one delegate for a package set in the past, the results were usually good
<micahg> sistpoty: I just don't know if I have the time...in fact this cycle it's probably not a good idea, but maybe next cycle
<sistpoty> micahg: ok, fair call. I'll treat you as fallback, if that's ok, and just ask you (either on irc, or via bug-report subscription) for input in case of mozilla-related package updates, ok?
<micahg> sistpoty: sure, that's fine
<sistpoty> :)
<micahg> thanks
<sistpoty> persia: I've no clue about netbook and edubuntu atm, do you have some suggestions? should we drop one of these for delegation?
<sistpoty> (or anyone else of course)
<persia> For edubuntu I'd probably target highvoltage or stgraber
<persia> Netbook and Desktop seem to be merging: I'd suggest seb128 or didrocks for netbook.
<sistpoty> highvoltage, stgraber: would you volunteer for edubuntu as ubuntu-release delegate for universe packages?=
<sistpoty> persia: thanks!
<persia> sistpoty: Out of curiosity, why just for universe packages?
<persia> sistpoty: More pointedly, I don't think Netbook has anything left in universe, and edubuntu has precious little (plus the edubuntu team is before the TB requesting a packageset currently)
<sistpoty> persia: basically based on slangasek's mail.
<sistpoty> persia: I guess main packages have a high overlap so ubuntu-release should take care
 * persia hopes that ArchiveReorg/components can follow closely now that ArchiveReorg/permissions is essentially complete
<persia> sistpoty: My issue is that the set of people caring for a package doesn't typically differ just because a package happens to be in one component or another, given the new permissions structure.
<persia> For example, the CLI/Mono team handles stuff in both main and universe.
<persia> as does MozillaTeam
<persia> For some stuff, it matters.  For example, some Xubuntu stuff is part of the core set, so shouldn't be delegated.  But I don't understand the point for stuff in main that isn't in core.
<sistpoty> persia: CLI/Mono does have lots of rdepends in other seeds, at least I believe so. Hence there needs to be a central point of syncrhonisation
<persia> sistpoty: Sure, but that's completely separate from main/universe
<persia> http://people.canonical.com/~cjwatson/packagesets is a handy resource
<sistpoty> persia: I guess delegations might be better thought of as packages seeded only by one team
<persia> Yes :)
<persia> Or rather, within one packageset
<sistpoty> whatever it's called :=
<sistpoty> :)
<persia> (some packagesets, like CLI/Mono are not generated from a seed currently)
<persia> This probably matters most to the edubuntu folk, as they have lots of stuff that is only in their packageset yet happens to be in main.
<sistpoty> persia: I guess the main rationale is that a package (atm) is currently easily visibe to fall under main or universe
<persia> That's why I pointed you at the packagesets output list.
<persia> That makes it more easy to figure out which packageset(s) apply.
<sistpoty> persia: yes, but everyone involved must know this by hart, so I'd rather suggest to go step by step
<persia> Well, OK.
<stgraber> sistpoty: it'd make sense for both of us to do that yes
<persia> But for next release, can we please use packagesets, even if components still exist?
<sistpoty> stgraber: thanks!
<sistpoty> persia: I don't object to this.
<sistpoty> persia: at least in the hope that the main<->universe merge of release-teams will have settled during lucid (still biting a little bit at it)
<persia> sistpoty: If you happen to move from there to "I support this" in the next 5 months, I'll be happy, but I'll also take it to others.
<persia> sistpoty: Oh!  Yeah, if that's still not smooth, then I agree it doesn't make sense to add more complexity now.
<sistpoty> persia: well, give it some time, everyone is still adjusting to it ;)
<sistpoty> (it's neither rough, nor smooth, it just takes some time so that everyone is aware of it)
<persia> Understood.
<asac> sistpoty: yeah.
<sistpoty> thanks asac!
<asac> welcome
<LLStarks> hi. what are the chances of a tiny bugfixing debdiff being accepted for gstreamer -bad a day or two after tonight's release?
<sistpoty> LLStarks: bugfix only debdiffs aren't subject to feature freez
<sistpoty> +e
<LLStarks> what would be subject to freeze rules?
<sistpoty> LLStarks: anything that introduces new features
<LLStarks> define "features"
<slangasek> persia: the set of people caring about the packages doesn't differ, but my willingness to wholesale delegate the freeze decisions does
<LLStarks> nvm.
<sistpoty> LLStarks: that's difficult. anything that fixes a bug isn't a feature ;)
<persia> slangasek: OK.  What would it take to change that willingness?  That feels like something leftover for resolution to make components go away.
<sistpoty> LLStarks: if in doubt, just file a FFe, it'll get sorted
<slangasek> persia: it's really about components as a proxy for seeds, for me
<slangasek> persia: I would still not want to delegate decisions about packages seeded on the Ubuntu CDs
<LLStarks> so, if blah 0.0.1 comes out tonight but bugfix just  misses the upstream deadline but is accepted to the git, 0.0.1-ubuntu1 or 0.0.1-1 would be allowed to fix it ahead of an upstream release?
<sistpoty> slangasek: actually I would, if the team is responsible for the image in question (and the package doesn't influence any other CD)
<persia> slangasek: OK, so your issue is mostly that we only have the one report about packagesets, and you need better tools?
<sistpoty> is *solely* probably
<LLStarks> also, is an ffe more likely to be attended to faster than a simple a bug report that contains a patch/debdiff?
<slangasek> persia: which report are you referring to?  I'm not concerned about reporting for my own sake, I just don't know that there's a very clear way to communicate to delegates what's being delegated to them at present if we describe it in terms of seeds
<sistpoty> persia: btw.: ok with my interpretation: http://paste.ubuntu.com/389257/
<sistpoty> *nod* slangasek
<slangasek> LLStarks: if a bug requires a feature freeze exception, it needs to be touched by *both* the release team and a sponsor, which are normally separate roles, so... no
<persia> slangasek: http://people.canonical.com/~cjwatson/packagesets
<persia> sistpoty: Yes.  I'm seeking someone for studio, but probably not until the next release cycle.  I strongly recommend didrocks also for Netbook.  The final paragraph seems sane to me.
<sistpoty> persia: you could volunteer for -studio though ;)
<sistpoty> persia: thanks for proofreading though :)
<persia> sistpoty: I'm not convinced I'd be a good delegate.  There are reasons I haven't volunteered for the release team previously.
<sistpoty> heh
<slangasek> persia: so by packageset, the ones I would not want to delegate are: core, desktop-core, langpack (well - delegate it to pitti, same thing), mobile, ubuntu-desktop, ubuntu-server, unr
<persia> slangasek: Why only those?  Why not to arbitrary packagesets?
<persia> slangasek: nvm  misread.
<persia> slangasek: So I think you shouldn't delegate core or desktop-core, or langpack: those are clearly central.  I don't know why you shouldn't delegate to ubuntu-desktop, ubuntu-server, and unr for non-central packages.  If mobile is still there, that's a bug, and I'll try to fix it.
<persia> slangasek: That said, I'd hope you'd pick your delegates carefully.
<slangasek> persia: and the fact that packages that are in the intersection of sets are listed as being in both package sets makes this report suboptimal, yah
<persia> slangasek: So would you be amenable to delegation of anything not in core or desktop-core that wasn't part of an intersection between packagesets?  (note that this is requirements gathering for lucid+1 policy, not for immediate implementation)
<slangasek> persia: I think the field of people those decisions could be delegated to for server, unr, desktop is so small that there would inevitably be conflicts of interest and they would properly be referred back to the release team; so I think it's simpler to not delegate in the first place
<slangasek> anyone I would see delegating those to is someone who should be on the release team anyway :)
<persia> slangasek: given that, would it make sense to expect each packageset maintaining group to contribute a member to the release team if they sought to be involved in release discussions?
<persia> (pitti and Riddell being current good examples of such)
<slangasek> I'm not sure the requirement holds for arbitrary packagesets
<persia> Why not?
<slangasek> hmm, trying to think through it
<persia> slangasek: Mind you, my only objection is the implication "some packagesets are better than others" for stuff not core or core-desktop.
<persia> slangasek: So it makes sense to me to either delegate for everything (else) or not delegate at all, and tell people to get involved in the release team.
<slangasek> if a team such as mythbuntu wants to be autonomous in making decisions about their particular packages, but doesn't have anyone who can commit to helping with the release team generally, what do you think is the correct course of action?
<slangasek> well, I don't see it as "better than"
<persia> I don't either, but believe it to be potentially misconstrued.
<persia> Well, how much extra burden is it to participate in the release team generally?
<persia> Is it not just reading one more mailing list and one more IRC channel, and attending one more meeting?
<Riddell> there's a mailing list?
<persia> https://lists.ubuntu.com/mailman/listinfo/Ubuntu-release
<slangasek> persia: hum; abstractly, if we're going to expect each member of the release team to be able to represent the whole release team, then there needs to be some shared model for how this works; that model doesn't come from the mailing list and the meetings, and we haven't really made an attempt yet to scale it
<slangasek> Riddell: yes, there is :-)
<slangasek> (not heavily used)
<slangasek> persia: so I think in practice there has to be some committment to actively engage
<persia> slangasek: That makes lots of sense.  Would you be willing to think about this for the next few months, and see if you can come up with a model that doesn't depend on components?
<slangasek> sure
<persia> Because I agree with most of your criticisms, although I also suspect most of the identified delegates will have the same conflict-of-interest issues that you cite for the ones that concern you more.
<slangasek> yep
<persia> Thanks for digging into this.  Please let me know if I can be of any help.
<sistpoty> slangasek: btw, can you whitelist stefan.potyra@informatik.uni-erlangen.de for ubuntu-release? (work address), thanks!
#ubuntu-motu 2010-03-06
<sistpoty> (and don't ask about my mail setup, it's just horribly broken atm, and I'm using kmail at work box even from home)
<slangasek> sistpoty: done
<sistpoty> thanks!
 * sistpoty needs some sleep now... gn8 everyone
<mdeslaur> pochu: would you object to me backporting the GtkStatusIcon stuff to lucid's liferea so the tray icon looks pretty with the new theme?
<Linux000> Is this where anyone wanting to start out fixing bugs/developing for ubuntu should be?
<mok0> Yep
<persia> Linux000: This is one of many places that it's good to start.
<Linux000> thanks
<persia> Linux000: What sort of work do you like to do, and how familiar are you with debian-format packaging?
<Linux000> persia: I am just starting out with packaging, so not much
<persia> Are there any particular areas that interest you?
<Linux000> Right now, I don't know much about it, so not really
<persia> In that case, I'll recommend you get started with bugsquad.  Reviewing the bugs, and working with packages to test things is a great way to build deeper understanding of how things work.
<Linux000> Thanks
<persia> Since you have an interest in development, you're sure to encounter some bugs that you have some idea how to fix.  Ask questions here, and we'll help or send you to people who may know better.
<persia> The bugsquad tends to hang out in #ubuntu-bugs, and there's lots of good docs in the /topic there.
<Linux000> Anyone know how to search for bytesize bugs in launchpad?
<Pici> !bitesize
<ubottu> A list of bugs that are considered easy to fix and good for beginners to attempt can be found at: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize
<Pici> Linux000: ^^
<Linux000> didn't know that(new to irc) thanks
<itachi> hello
<pochu> mdeslaur: not really, but test it thoroughly :)
<pochu> mdeslaur: why does it look bad, the new theme is transparent?
<itachi> pochu: what up, d0c?
<mdeslaur> pochu: bug #532789
<ubottu> Launchpad bug 532789 in light-themes "ambiance: pidgin icon in status area has light background (liferea too)" [Low,Confirmed] https://launchpad.net/bugs/532789
<itachi> ejat: wah...
<ejat> ?
<itachi> ejat: orang indo?
<zgreg> I'm still a bit confused about the feature freeze exception process.
<zgreg> https://bugs.launchpad.net/ubuntu/+source/libass/+bug/529860
<ubottu> Launchpad bug 529860 in libass "Update libass to bugfix release 0.9.9" [Undecided,Confirmed]
<zgreg> "please go ahead", that's not meant for me, is it? since I don't know what I should do :)
<dbell> Hi, I'm wondering if anyone can help me here. I've packaged my game and I've got a .desktop file that gets placed in /usr/share/applications and when installing package it says that its rebuild the desktop.cache file (and my game is listed in there, and seems to be complete). I can see my icon in the /usr/share/applications folder - but it's not appearing in the Menu. This is lucid btw (and I've tried installing on karmi
<dbell> c and it appears in the menu). Is there anything specific I need to do to get my icon in the menu on lucid?
<randomaction> zgreg: if you don't have the upload rights, the sponsors will pick this bug up
<randomaction> dbell: try installing the icon in /usr/share/pixmaps
<dbell> in addition to having them in /usr/share/icons/hicolor?
<zgreg> randomaction: ok
<zgreg> that's all I need to know, thanks
<randomaction> dbell: I thought you had the icon in /usr/share/applications. Anyway, one instance of icon should be enough. Refer to http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec and http://freedesktop.org/wiki/Specifications/icon-theme-spec
 * persia notes that if several versions of an icon are available, hinting the icond cache can provide a better user experience
<dbell> randomaction: thanks. I think my .desktop file is fine, desktop-file-validate ran fine, and in karmic, it appears in the menu. Just when installing in lucid it doesn't.
<persia> dbell: Could you pastebin the .desktop file (or otherwise point me at it)?
<dbell> yea sure, gimme a sec
<dbell> persia, http://pastebin.ubuntu.com/389509/
<persia> Try "Categories=Game;ActionGame;" or "Categories=Game;ArcadeGame;"  There's some logic in the games menu to group/select games which might cause that.  I can't see anything else that might cause it not to appear.
<dbell> ok I'll give it a try
<persia> dbell: Hrm.  That doesn't seem to be it.  There's something else wrong, which is masking lots of .desktop files.
<dbell> yea, was just about to say... did not work
<dbell> is /usr/share/applications the only place I need to install the .desktop file?
<persia> Yes.
<persia> There appears to be a regression in gnome-menus.
<dbell> so the mistake is on lucid and not with my package/.desktop file?
<persia> The only issue your .desktop file had was with not specifying the *type* of game.
<persia> That's a minor bug, but worth fixing.
<persia> There's something else wrong.
<dbell> well, I changed that now - added ArcadeGame as suggested.
<persia> dbell: I don't understand what happened.  I had your bug replicated, even refreshing the menu cache a few times.  I moved a file, copied it back, and edited it.  Then the menu worked, without a cache refresh.  I moved the original file back overwriting my edits.  I then refreshed the cache a few times, and it's still fixed.
<persia> dbell: If you can figure out what changed that made it not work, please report a bug, but I can't figure it out from the state of my local environment :(
<dbell> persia: thanks for your help anyway :(. When you say find out what changed to make it not work, do you mean what changed in karmic version to lucid version?
<persia> Actually, I suspect it was in the last few days.  Test with Lucid Alpha 3: that likely works.
<persia> Wouldn't surprise me if it was a side effect of work on bug #517616 although it might be something else.
<ubottu> Launchpad bug 517616 in gnome-menus "User's menus are always kept unchanged" [Low,Fix released] https://launchpad.net/bugs/517616
<dbell> ah good idea. Thanks I will do (and then if It works in alpha 3, and doesn't work with "current" lucid - which it doesn't) I should file a bug, saying that it works in a3 and broken now?
<sebner> Please tell me that there is a gconf value for the changing the windows controls back (from the left to the right) or /me waves goodbye
<persia> dbell: Looks like it's an artifact of continuous upgrades, and one has to regenerate the cache if one ever had a buggy version.
<dbell> Ah, so all the upgrades might have caused this?, How do you regenerate the cache?
<persia> See comment #10 in that bug.  If that doesn't work for you, something else is wrong.
<persia> I don't know why mine works right now, or how I made it work.
<dbell> persia: sorry for delay. comment #10 didn't work. I'm going to try it with alpha-3 soon. Also didn't work with moving and copying the files back that you suggested earlier.
<persia> dbell: I wouldn't actually expect what I did to work.  There's no good reason for it.  But the half of my menu items that were missing magically appeared again (and I don't know why)
<persia> That *should not* have done anything.
<persia> That's why I'm asking you to file a bug, because you still have the symptom.
<dbell> yea, I will. Which package? gnome-menus?
<persia> dbell: If you're using GNOME: gnome-menus.
<persia> If you're using something else, your menu provider.
<jetienne_> q. i got a .deb generated by checkinstall. And i would like to upload it in a repository managed by mini-dinstall. but mini-dinstall seems to require a .changes and checkinstall doesnt provide it. Any suggestion on how to fix this ?
<persia> don't use checkinstall :)
<jetienne_> persia: well this is not me using it :) aka not in my control
<persia> more seriously, it's potentially possible to make it work, but the amount of effort required is likely larger than packaging it properly in the first place.
<persia> jetienne_: Do you have source?
<jetienne_> persia: i was thinking about building my own .changes... is that ferasable
<persia> It is, but there are easier ways to work around it.
<jetienne_> persia: yep
<persia> Excellent.  If you have source, you can package it properly.
<jetienne_> persia: ok listening for anything easy :)
<jetienne_> you said easy :)
<persia> I did.
<jetienne_> ok building a pacakge of a full window manager, which i didnt wrote, is not easy for me
<persia> Do you need to do anything special to build it, or is it just python-distutils, or simple ant, or make; make install, etc. ?
<persia> I will attempt to prove you wrong :)
<jetienne_> believe me, you cant :) i wrote like 4 packages this weak, and the 5th is not under my control
<jetienne_> persia: all repositories managers requires the .changes ?
<persia> All the good ones.
<jetienne_> persia: ok what are the bad ones :)
<persia> The only one I know is manual management of files and manual editing of the Packages file.
<persia> That's completely unautomated, likely to break in unexpected ways, and infinitely flexible.
<jetienne_> yep
<jetienne_> ok so no good solution for me .... not sure what to do
<jetienne_> persia: i understand your point about proper packaging tho. thanks for your h
<jetienne_> elp
<persia> Shouldn't take more than 30-45 minutes to package it.  Are you sure?
<persia> (can take 5 if the licensing is clean)
<persia> (can take weeks if the licensing is insane and the buildsystem is dysfunctional)
<jetienne_> persia: for you. for me this is like 3h with proper help. and then 1 week to convince external people, then *i* have to maintain his package for life :)
<jetienne_> persia: but be sure i do appreciate your help. may be back soon if i can convince the other personn
<persia> For me, it usually takes about 20-30 minutes to teach someone to package something properly whilst they do it.  You sure you don't want to try?
<jetienne_> :)
<jetienne_> persia: im sure i dont now, yes. because my wife is calling for lunch ;)
<persia> OK.  I'll likely be in prolonged idle when you get back from lunch, but catch me another time.
<persia> Cool!  edit-patch hit lucid.  No more worries about which patch system is in use.
<persia> (but no manpage for edit-patch :( )
<sebner> persia: hrm hrm hrm?
<persia> sebner: Feel like writing a manpage?
 * sebner doesn't even know that edit-patch is (besides I should really quit IRC and start learning)
<persia> If you're not studying for your exam, you can be learning about edit-patch :)
<sebner> persia: that's the problem, If I don't start studying soon I'll not doing it at all which is good for Ubuntu but really bad for me ^^
<persia> Then you might want to close/hide your IRC client :p
<sebner> persia: If that would be that easy .. :P
<persia> You set up your computer to have IRC in a hard-defined region of your root window?
<sebner> heh
<sebner> persia: citat: The spirit is willing but the flesh is weak.
<persia> Anyway.  It's not that hard to stop paying attention.  Watch:
<sebner> persia: I'm watching ;)
<sebner> persia: Do you intend to write something? ^^
<mok0> sebner: I think he's paying attention... to other things :-)
<sebner> mok0: I thought he wanted to write something after "Watch:"
<mok0> sebner: "watch me paying attention to other things" :-)
<mok0> ScottK around  yet?
<sebner> mok0: ohohoo, I missunderstood xD
<mok0> sebner: IRC will be your doom :-)
<sebner> ACK
<sebner> christoph_debian: around?
<mok0> Hmm, sunny outside today... time for a walk. BBL
<sebner> hf mok0
<mok0> sebner, thx
<christoph_debian> sebner: ja
<dbell> persia: I've filled a bug #533264 is there anything that I've missed that should be included?
<ubottu> Launchpad bug 533264 in gnome-menus "Installing package that contains a .desktop file does not appear in the Application Menu" [Undecided,New] https://launchpad.net/bugs/533264
<sebner> christoph_debian: supertux misses a .desktop file. There is supertux2.desktop but it doesn't get installed, I edited *.install to ship it but there is the problem with the icon which is in ./games/supertux2/images/engine/icons/supertux.png
<christoph_debian> sebner: oh
<christoph_debian> hm probably adding the icon to *.links can have a look later (awesome user so don't necessarily see fdo menus)
<sebner> heh
<sebner> christoph_debian: anyways, I wait until the sync is processed and then we have to fix it, just wanted to let you know as I'm now really out studying
<lfaraone> Can I use CDBS to build a Python C extention which uses a makefile for all supported Python versions?
<lfaraone> (preferably with minimal overrides)
<lfaraone> I understand how to do so if upstream used setup.py, but alas....
<DktrKranz> lfaraone: yes, IIRC
<DktrKranz> dh7 (from 7.3.5) for sure, though
<lfaraone> DktrKranz: in "zen mode"?
<DktrKranz> oh... no. I misread. It works only for distutils-based packages
<lfaraone> DktrKranz: so I figured :(
<DktrKranz> lfaraone: if you need a working example, I can provide one (it uses dh7, but can be easily adjusted)
<lfaraone> DktrKranz: I'm not wedded to cdbs, I'll suse what ever works.
<DktrKranz> lfaraone: http://svn.debian.org/viewsvn/python-modules/packages/pyparted/trunk/debian/rules
<dupondje> somebody feels working on opensync/synce ?
<azeem_> dupondje: in which way?
<dupondje> well It needs some adjustmens
<dupondje> cause now
<dupondje> its just doesn't work ... :(
<azeem_> I don't think it will work even with adjustments
<dupondje> had it working once
<dupondje> but its a mess :( sadly
<dupondje> seems like there was put some work in multisync etc, but its useless without good backend imo :(
<dupondje> azeem_: you know if there is an alternative ? :(
<azeem_> for synce?
<azeem_> there's syncevolution for evolution<->syncml syncing
<dupondje> azeem_: to sync evolution with windows mobile device
<azeem_> I don't think syncevolution does that yet
<dupondje> its sad :(
<ryanakca> Is it possible to sync package foo from Debian when foo_1.0.1.orig.tar.gz differs in Ubuntu and Debian?
<Caesar> crimsun: I've just uploaded a new pacparser to unstable that pretty much addresses all of the changes you made to it in Ubuntu
<jpds> ryanakca: No.
<ryanakca> jpds: *sigh*, thanks
<Caesar> crimsun: how do I get 1.0.9-2 into Lucid?
<crimsun> Caesar: simply request a sync of pacparser 1.0.9-2 from Debian unstable main
<blueyed> Is it expected behavior that "sudo strace -p $(pgrep X)" freezes the system after some seconds? (from KDE konsole)
<hyperair> no, i don't think so
<randomaction> Can I assume that clean target is always called before building? This seems to be true for buildds, but Debian policy is a bit unclear about this.
<AnAnt> clean target is called before build target, yes
<randomaction> So if I unpack the source package and call "fakeroot debian/rules binary", the build is not guaranteed to succeed, right?
<paissad_> hi all, do you think possible to get dpkg tools, maintainers tools & so on ... every tool needed to create a .deb package in another system like freebsd for example ?
<randomaction> paissad_: Debian has a freebsd port
<paissad_> randomaction, i googled some, .... i thought about debootstrap
<paissad_> actually, i will use slackware ... not a bsd !
<randomaction> so, can you run debootstrap on slackware? I don't know
<paissad_> randomaction, what were you thinking ?
<randomaction> I think I didn't understand your question
<paissad_> randomaction, did you already try debootstrap once ?
<randomaction> I only ran it on Ubuntu
<paissad_> ok
* sistpoty changed the topic of #ubuntu-motu to: Feature Freeze in effect | Lucid Alpha 3 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
<sistpoty> mr_pouit: would you be willing to act as ubuntu-release delegate for xubuntu packages in universe?
<mr_pouit> sistpoty: yeah, sure, no problem
<sistpoty> mr_pouit: cool, thanks!
<sistpoty> highvoltage: would you be willing to act as ubuntu-release delegate for edubuntu?
<arand> How do I change the editor used for dch, and where are the settings trored anyway?
<arand> s/trored/stored/
<jdong> $EDITOR
<jdong> environment :)
<hyperair> or $VISUAL
<arand> jdong: hyperair: hmm, neither of those seem to have a value set if echoed..
<jdong> arand: sensible-editor is the fallback of dch when no value is set.
<jdong> but per-user, the recommended way to change the editor preference is EDITOR or VISUAL
<jdong> a lot more commands obey the environment variables compared to the sensible-editor fallback.
<arand> jdong: So that is what the initial prompt does?
<hyperair> sensible-editor seems to use VISUAL and EDITOR as well. so if dch just uses sensible-editor all the way, it'd work too
<sistpoty> ScottK: got some insight for FFe bug #527982? would you be willing to do new handling?
<ubottu> Launchpad bug 527982 in ubuntu "Sync ibid 0+bzr881+dfsg-1 (universe) from Debian experimental (main)" [Undecided,New] https://launchpad.net/bugs/527982
<arand> hyperair: Ah, got it. ~/.selected_editor *facepalm
<duanedesign> what is the LP tag for a bug report that has a patch attached?
#ubuntu-motu 2010-03-07
<Mage__> Hey! they suggested I come here to propose programs for packaging.  Is this true?
<sistpoty> Mage__: partially, we're in feature freeze right now, so new programs will most likely only make it to lucid+1
<Mage__> Oh alright, well I just wanted to suggest two games to be packaged for the repository, not necessarily included by default
<persia> Mage__: The freeze applies to things not included by default as well.
<persia> !newpackages
<ubottu> 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
<Mage__> Oh alright, thanks for the info:)
<micahg> persia: I'm gussing a missing man page doesn't need an FFE?
<ScottK> Missing man page is a bug.  No.
<micahg> ScottK: thanks
<YokoZar> Are http://packages.ubuntu.com/lucid/pidgin-mbpurple  and http://packages.ubuntu.com/lucid/pidgin-microblog  competing packages of the same software or two different plugins with the same purpose?
<micahg> YokoZar: same thing, apparently debian chose a different name
<YokoZar> micahg: actually I think they might be entirely different packages - different original maintainers
<YokoZar> micahg: here, I sent out an email to -motu
<micahg> YokoZar: no, one was made in ubuntu, one in debian
<micahg> same upstream code
<YokoZar> right that's what I mean
<YokoZar> same upstream, different packaging
 * micahg is not sure exactly what to do
<ScottK> If it's just Debian picked a different name, add a transitional package to the Debian one and ask to have our copy of the source removed.
<micahg> ScottK: will debian take transitional names for our packages or is that an ubuntu change?
<micahg> YokoZar: did you want to do that or should I?
<ScottK> micahg: It's an Ubuntu change.
<micahg> ScottK:
<micahg> oops
<micahg> k
<ScottK> It can be dropped after Lucid releases.
<micahg> ScottK: the ubuntu package was in karmic as well
<YokoZar> meaning we need to at least have a dummy package
<ScottK> micahg: That's why we need the transitional package.  So that upgraders get moved to the new one.
<micahg> ScottK: ah, you meant in lucid + 1?
<ScottK> micahg: Yes.  In lucid+1 "after lucid releases".
<micahg> ScottK: k
<micahg> YokoZar: so, did you want to do that?
<YokoZar> micahg: sure.  I'll email the person at the top of the changelog too
<Some_Person> pbuilder can't build packages that depend on virutal packages?
<persia> Some_Person: It can, but packages should never depend on a pure virtual package: the dependency should always be of the form <real-package> | <virtual package>
<Some_Person> What if the real package isn't known by the packager?
<Some_Person> I'm trying to build a package where all I know is that it depends on gnome-desktop-sharp2
<persia> Some_Person: Check your local apt cache.  I'm sure there exists some real package that provides that.
<Some_Person> my local apt cache?
<persia> Sure.  You have an installed system for testing, right?
<Some_Person> yes
<Some_Person> but I don't know how to do what you're asking
<persia> So, what package actually gets installed when you try to install the virtual package there?
<Some_Person> all the ones it depends on, i suppose
<YokoZar> do you mean metapackage
<YokoZar> or virtual package?
<persia> virtual packages don't have dependencies.
<YokoZar> *or dummy package
<persia> virtual packages are provided by non-virtual packages that may or may not have dependencies.
<Some_Person> pbuilder-satisfydepends-dummy: Depends: gnome-desktop-sharp2 which is a virtual package.
<YokoZar> virtual = named in a Provides line
<YokoZar> meta/dummy = depends on other packages, has no files but is a "real" package (is contained in a source package)
<Some_Person> I have it installed on my actual system though
<Some_Person> According to Synaptic, it is a metapackage
<persia> Some_Person: You can't have it installed.  virtual packages cannot be installed.
<ScottK> metapackages can, however, be installed.
<YokoZar> persia: apt-cache show gnome-desktop-sharp2 (on karmic) looks like a real package though
<YokoZar> or rather metapackage
<jdong> main vs universe?
<persia> jdong: Indeed.
<jdong> yup, it's in universe.
<jdong> Some_Person: your pbuilder likely is not universe-aware :)
<Some_Person> Ah, so I need to add universe to my pbuilder then
<vish> duanedesign: "patch"  ;)
<Some_Person> thank you, it seems to be working now
<Some_Person> (by that I mean it's downloading a buttload of packages right now)
<Some_Person> now how do I resolve this: http://paste.ubuntu.com/390092/
<Some_Person> nvm, got it
<Some_Person> (wow, that's the first time i've used netspeak in years besides 'lol')
<nigelb> persia: got some time? need a little bit of training :)
<persia> nigelb: As always, ask a question generally, and someone who is around may be able to help.
<nigelb> i'm really not sure where this goes
<nigelb> I'm trying to understand cdbs and dh and how to port from one to other
<persia> Why?
<nigelb> well, the desktop team has some plans for porting a few in lucid+1 cycle
<persia> Bother.  We should really be following Debian on these.
<persia> What bits don't you understand?
<nigelb> um, I was looking for a starting point to play around first
<persia> I'll encourage you to play with something else :)  Moving from one class of magic to another should be essentially invisible.
<nigelb> huh?
<persia> So it's probably something like `dh --with gnome $@` that is the equivalent of including the gnome entry for CDBS, with the same lack of anything else.
<persia> But getting into why and how is very in-depth.
<nigelb> I guess this is not something I could learn fast enough then
<persia> Well, rather, learning how and why won't necessarily help you participate in migration.
<persia> You could certainly learn, but unless you're planning to participate in the development of the magic, it has questionable value.
<nigelb> actually when I asked seb what's there in desktop team todo, he referred me to this porting
<persia> Personally, I think it's better for you to concentrate on other things until you've learned more.  Perhaps work with some CDBS and dh(1) packages to get a feel for how the systems work.
<persia> With no documentation?  Go ask in #ubuntu-desktop for help then :)
<nigelb> haha
<nigelb> lemme look for more unmet deps then
<persia> nigelb: Or help with patch review.  That always needs work, and I'm sure you encounter a fair number of patches in your work with bugsquad.
<nigelb> ah, yes.  I did plan on doing that 15 patches
<persia> There you go then :)
<persia> Something to keep you busy, and you'll surely encounter some CDBS and dh(1) stuff along the way which will help you understand how they work.
<nigelb> ah, that leads to a question I had earlier
<nigelb> if a patch is submitted and upstream comment is awaited, what tag does it get?
<persia> nigelb: I don't know it gets a special one.  I just usually leave a comment that the patch is awaiting comment upstream.
<nigelb> hm
<persia> nigelb: I think the workflow for that stuff needs work: maybe we can discuss it at the next bugsquad meeting, or on the mailing list?
<nigelb> persia: does reviewer's team have a mailing list?
<persia> (and I think this is more on-topic in #ubuntu-bugs, although not entirely off-topic here)
<nigelb> per topic would be #ubuntu-reviews I guess
<persia> nigelb: Yes, but it's crammed with all the bug comments (I don't subscribe)
<persia> Oh.  Yes!
<persia> (but I think it *should* be of interest to bugsquad and MOTU also)
<nigelb> can someone help me port a bug fix to karmic?
<persia> nigelb: Sure.  Which bug?
<nigelb> bug 401028
<ubottu> Launchpad bug 401028 in papyon "telepathy-butterfly crashed with TypeError in b64decode()" [Low,Fix released] https://launchpad.net/bugs/401028
<persia> nigelb: OK.  The first step is to nominate it for the target release.
<nigelb> nominated for karmic
<persia> Next step is to get someone to approve your nominations.  I'll approve pymsn.
<nigelb> its not pymsn I think
<nigelb> its papyon
<persia> Grr, there's a bug :/
<persia> You nominated both :p
<persia> I can't approve pymsn.
<nigelb> ubuntu-drivers have to approvE?
<persia> No.  It's a UI issue.
<persia> Anyway.
<jdong> lol yay launchpad bugs
<persia> Next check http://people.canonical.com/~cjwatson/packagesets to find out which team handles papyon
<jdong> ubuntu-desktop
<hyperair> arand: huh? .selected_editor? i haven't heard of that file before
<nigelb> okay, ubuntu-desktop :)
<jdong> at any rate, ping me when the SRU team needs to poke the bug
<nigelb> jdong: will do :)
<jdong> my best friend authored the original patch, so I'm sure he'll nag me too when it happens :)
<jdong> but until then, it is 3AM and sleep would be nice
<persia> nigelb: So go get someone in #ubuntu-desktop to accept the nomnation for papyon
<jdong> persia: does the button that shows up under papayon not work?
<nigelb> persia: oh, well.  they tend to wake at eu timings
<persia> jdong: For me it works too well.  I'm not a core dev, but LP things I am, and I can't accept the nomination for pymsn without accepting papyon.
<persia> s/things/thinks/
<jdong> persia: ah, papayon shows up for me first and the approve-decline button under it seems to appear, though I'm afraid what might happen if I click it....
<jdong> I'm not core-dev either
<nigelb> any of the core devs can approve?
<jdong> but IMO nigelb can still continue preparing a SRU debdiff and preparing a SRU-able bug description in the meantime while we wait for the right person to press shiny buttons.
<persia> jdong: Then you are also experiencing the bug I'm filing.  If you're around for a bit, I'd appreciate a confirm.
<jdong> persia: I'll try to keep my eyelids open for a couple more minutes then! :)
<persia> jdong: True.  I want to file this bug: if you have time to lead nigelb through the next step now, that would be great.  Otherwise I'll get back to it in a bit (and it's day in the EU now anyway)
<nigelb> persia: desktop tends to take a break on weekends :)
<nigelb> s/desktop/desktop team
<jdong> nigelb: if you haven't already, please read https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<jdong> nigelb: namely, (2) takes a chunk of time to write up
 * nigelb has second thoughts now
<nigelb> hehe.. kidding
<jdong> and for the mentioned "patch", a ready-to-sponsor debdiff is preferred
<nigelb> basically, I just add a comment and a ready to sponsor debdiff?
<nigelb> and the comment explains (2)
<jdong> that is correct.
<jdong> and subscribe the ~ubuntu-sru team.
<nigelb> yes, that would be understood :)
<persia> jdong: It's bug #271697
<ubottu> Launchpad bug 271697 in malone "Javascript for approving / declining nominations is confusing " [Undecided,Triaged] https://launchpad.net/bugs/271697
<jdong> persia: thanks
<jdong> ok I'm going to sleep now
<persia> nigelb: Do you still have outstanding questions, or are you deep in the SRU process?
<nigelb> persia: deep in :)
<persia> nigelb: Excellent :)
<nigelb> um, what does "sending a malformed SHA1C value via an msn_object avatar"
<persia> bad checksum of some type, I'd guess.  But if you're doing an SRU, and you don't know, you get to learn.  It's always important to understand what you're doing.
<nigelb> I was afraid you would say that
<nigelb> now I get to create an msn account
<nigelb> but if its merged in upstream code, do I still have to do all this?
 * nigelb feels lazy
<persia> Yes.
<nigelb> and I have to reproduce the problem again too?
<persia> Consider that what you're doing will deploy code to millions of users.  Consider whether you want to be the person who broke stuff.  Now, consider whether you want to learn about this :)
<nigelb> *groans*
<persia> Why?  Surely it will help you be a better developer, and surely you'll derive enjoyment out of helping millions of users.
<nigelb> yes, but signing up for another mail ID is not fun ;)
 * wgrant ended up creating two fake Passport accounts for debugging telepathy-butterfly.
<nigelb> fake enough to share? ;) or reproduce this issue?
<wgrant> Not that fake.
<nigelb> hehe, I was just being hopeful ;)
<wgrant> But it's trivial to create extra ones, particularly if your mail provider supports + extensions.
<nigelb> wgrant: can I ask for your help?
<wgrant> nigelb: Sure.
<nigelb> or else I'll have to create one more live id hehe
<nigelb> can you befriend my fake Id with your fake id?
<wgrant> Let's be fake friends!
<nigelb> lol
<persia> Warning: this is not an actual friendship.  It exists only for testing purposes.  If this were a real friendship, it would be evidenced by significant interaction.
<nigelb> haha
<nigelb> we interact enough to be friends alpha
<nigelb> we'll get to the Beta stage once empathy decides what do with friendship requests on msn
<persia> heh
<wgrant> (progress is being impeded by it being just about impossible to add MSNP contacts in Empathy)
<nigelb> persia: wgrant have successfully gone on to Friend RC ;)
<nigelb> thoughts on this explanation for an SRU http://paste.ubuntu.com/390209/
<skwashd> hi all
<skwashd> is it too late to push for a package to be synced from debian for lucid?
<persia> hey skwashd
<skwashd> hi persia
<persia> skwashd: Depends on the nature of the changes.  What package, and why?
<skwashd> solr because 1.2 is dated and debian testing has 1.4
<skwashd> i am trying to minimise the amount of stuff i need to port from debian for my own lucid repo
<skwashd> persia: and 1.4 has far nicer replication support
<persia> skwashd: Looking at upstream, it would need a freeze exception.
<persia> skwashd: And unless it's *much* better, completely stable, and doesn't have any reverse dependencies, the chances are low.
<skwashd> persia: checking debian bugs now
<persia> Finding a release critical bug is always helpful justification.
<iulian> skwashd: Also, you might want to take a look at https://wiki.ubuntu.com/FreezeExceptionProcess.
<skwashd> iulian: thanks ... i've got things through in the past ... will check it next
<iulian> Alrighty.
<skwashd> ok quick look at the debBTS suggests it looks pretty solid http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=solr
<skwashd> this ubuntu bug can probably be closed as WONTFIX ... 1.3 is no longer in debian ... https://bugs.launchpad.net/ubuntu/+source/solr/+bug/321889
<ubottu> Launchpad bug 321889 in solr "Please merge solr 1.3.0+ds1-1 (universe) from Debian unstable (main)" [Wishlist,Triaged]
<persia> skwashd: Or taken over to be the request for 1.4.
<skwashd> persia: happy to update it if you think that is the best way to do it
<persia> skwashd: The advantage there shows that a merge was started some time back, but not completed pending the resolution of build issues that 1.4 fixes.
<skwashd> ok
<persia> skwashd: I think so, just because 1.4 fixes a FTBFS, and we would have sync'd 1.3 if we hadn't had a patch.
<persia> skwashd: Note also that I'm not convinced we *can* sync directly: one needs to consider if a merge may be required.
<skwashd> persia: i haven't gone back through the history of the ubuntu package ... about to pull up the debian/changelog in karmic in a sec
<persia> From the changelog it looks like it could be a sync, but some investigation and explanation is warranted.
<skwashd> got lots of tabs open
<skwashd> ok
<skwashd> persia: comment added https://bugs.launchpad.net/ubuntu/+source/solr/+bug/321889/comments/5
<ubottu> Launchpad bug 321889 in solr "Please merge solr 1.3.0+ds1-1 (universe) from Debian unstable (main)" [Wishlist,Triaged]
<skwashd> persia: should i sub ubuntu-release to it or just nominate it for release?
<skwashd> or both? :)
<persia> Just subscribe.
<persia> We tend to use nominations for past releases.
<persia> But change the bug title :)
<skwashd> oh yeah
<persia> The description too :)
<skwashd> also noticed that tomcat5.5 has been dropped from lucid
<skwashd> so hardy solr-tomcat users have no upgrade path
<persia> Then maybe it needs a different patch :)
<skwashd> no ... debian ships solr-tomcat that depends on tomcat6
<persia> Making the metapackages handle the upgrade patch cleanly is another good argument for update :)
<skwashd> should i prepend FFE to the title?
<nigelb> um, any idea if brian will be around today?
<persia> nigelb: He often doesn't spend much time around on the weekends.
<nigelb> persia: I thought so.
<nigelb> take a look at bug 401028
<skwashd> persia: i think i am all done on it now
<skwashd> look right to you?
<nigelb> it seems ken already attached a karmic debdiff
<ubottu> Launchpad bug 401028 in papyon "telepathy-butterfly crashed with TypeError in b64decode()" [Low,Fix released] https://launchpad.net/bugs/401028
<persia> bug #321889
<ubottu> Launchpad bug 321889 in solr "Please merge solr 1.4.0+ds1-1 (universe) from Debian testing/unstable (main)" [Wishlist,Triaged] https://launchpad.net/bugs/321889
<skwashd> got 1 week before beta1 freeze :)
<persia> skwashd: You need an explanation of why the prior Ubuntu patch can be dropped.  The rest looks good.
<persia> nigelb: Excellent.  Just shepard it through then.
<skwashd> persia: comment 5 doesn't cover that or it should be in the description?
 * persia rereads
<skwashd> persia: Solr 1.4 (1.4.0+ds1-1) is in debian unstable and testing. Ubuntu has been shipping 1.2 since hardy.
<persia> skwashd: No.  You need to identiy the prior patches and why they are no longer required, specifically.
<skwashd> oh the ubuntu patches?
<persia> Right.
<skwashd> now i get you
<nigelb> if someone replied to me, I missed it.
<skwashd> persia: you mean the section titled "Merge from debian unstable, remaining changes:" from the changelog at https://launchpad.net/ubuntu/+source/solr/1.2.0+ds2-5ubuntu1 ?
<skwashd> quick check the of debian diff they are both no longer needed ... and have justified that in the comment i am about to post
<skwashd> anything else i need to add? don't want to add 4 comments in ~1hr to the same but with no follow ups ... people will start thinking i talk to myself
<persia> skwashd: That's usually it.  Wait for response from the release team.  They will advise if more is required.
<skwashd> done
<nigelb> when building a debdiff for sru, I make it against the release that we are proposing SRU?
<persia> nigelb: ${release}-proposed
<nigelb> oh
<nigelb> can you take a look at bug 401028
<ubottu> Launchpad bug 401028 in papyon "telepathy-butterfly crashed with TypeError in b64decode()" [Low,Fix released] https://launchpad.net/bugs/401028
<nigelb> there is an attachment, 401028.debdiff which seems to do the job
<persia> nigelb: Almost.  Needs to be against karmic-proposed.
<persia> nigelb: Also, needs SRU team ack.
<persia> All the justifications, test case, etc.
<nigelb> I put that there
<persia> And it needs upload.
<persia> but the sponsor can s/karmic/karmic-proposed/ : that's not worth redoing the debdiff.
<nigelb> no more changes right?
<persia> You need someone to approve the nomination to karmic.
<persia> That solves it for the papyon task.
<persia> The pymsn task is entirely separate, and needs different thought.
<persia> So, pymsn appears fixed upstream: I suspect it's also fixed in lucid (needs a double-check of changelogs, etc.)
<nigelb> oh well desktop team member is here )
<nigelb> chrisccoulson: need a nomination approval :)
<chrisccoulson> nigelb - a bug nomination?
<nigelb> yes, bug 401028
<ubottu> Launchpad bug 401028 in papyon "telepathy-butterfly crashed with TypeError in b64decode()" [Low,Fix released] https://launchpad.net/bugs/401028
<nigelb> the papyon task.  there is already a debdiff attached.  you only need to change karmic to karmic-proposed I guess
<persia> chrisccoulson: If you want to accept or decline, and LP won't let you, make a comment indicating your determination, and I'll approve the nomination.
<persia> (this would be a bug if it is required)
<chrisccoulson> persia - thanks. LP let me approve the nomination for papyon though, so i've done that now
<persia> Oh cool.  I feared there'd be a bug about packageset teams.  I'm glad to hear it just works.
<persia> chrisccoulson: For extra points, feel like sponsoring Ken's debdiff (after retargeting to -proposed)?
<chrisccoulson> persia - i'm not sure how it works at the moment, I don't seem to be able to approve nominations for all packages i can upload to
<chrisccoulson> i will review the debdiff there today though
<persia> chrisccoulson: There's a bug.  You might have been able to approve it because of bug #110195
<nigelb> you want a new debdiff, let me know
<ubottu> Launchpad bug 110195 in malone "Nomination for a release on one source package shouldn't affect any others" [High,Triaged] https://launchpad.net/bugs/110195
<persia> chrisccoulson: Have you filed a bug about not being able to approve some nominations?  If not, please do so.
<nigelb> persia: 1 down 2075 to go, *sigh*
<persia> nigelb: you picked a hard one to start :)  Most are easier.
<chrisccoulson> ah, right, the bug has a task against pymsn which is in universe. that might be why i could approve the papyon nomination then
<persia> Right, but you should have been able to anyway, because you can upload it.
<nigelb> question,
<nigelb> why is there is a pymsn task there?
<nigelb> because i dont find what pymsn has got to do with this
<nigelb> the whole bug is with telepathy-butterfly and python-papyon.  where does pymsn come to the picture at all?
<nigelb> or am I looking at it wrong?
<persia> nigelb: Maybe one could also use pymsn?
<persia> Maybe pymsn also has the bug?
<persia> Note that there was an upstream task marked "Fix Released" for pymsh.
<nigelb> the bug was opened against telepathy-idle
<nigelb> s/idle/butterfly
<nigelb> and the deb is also against butterfly
<nigelb> someone who's not even in bugsquad changed it
<persia> As is the upstream task, although incorrectly attributed.
<nigelb> I was getting there :)
<persia> Well, you could make the pymsn tasks Invalid (with an appropriate comment)
<nigelb> or change to telepathy-butterfly?
<persia> Or ask pedro, who set the pymsn task triaged (and this belongs in #ubuntu-bugs)
<nigelb> I suspect pedro only saw that upstream task was opened and set it to triaged
<nigelb> he goes through loads of bug reports
<nigelb> oh no, someone subscribed reviewers instead of sponsors? bug 458677
<ubottu> Launchpad bug 458677 in file "File report iso image application/octet-stream" [Low,In progress] https://launchpad.net/bugs/458677
<nigelb> persia: can you unsubscribe reviewers from this bug ^
<nigelb> I'll subscribe sponsors
<persia> done
<nigelb> ah, fixed that one :)
<nigelb> pbuilder does not use a patch system?
<hypera1r> as in pbuilder's source package?
<nigelb> yup
<nigelb> there is that bug that does not allow building a sid chroot
<hypera1r> pbuilder appears to be a native package.
<hypera1r> no patch system needed/possible
<nigelb> ah :)
<hypera1r> just make the changes directly
<nigelb> I thought that might be it
<hypera1r> =)
 * nigelb puts off for later.. sigh
 * hypera1r wonders if lucid is worth upgrading to yet
<sebner> hypera1r: sure, never used something else :P
<hypera1r> sebner: how can you not have ever used something else?
<hypera1r> maybe i'll upgrade tomorrow night
<sebner> hypera1r: I mean, I'm using lucid since the repo opened
<hypera1r> heh
<hypera1r> that sounds assuring
<sebner> hypera1r: (virtual) life without breakage is b0ring
<hypera1r> and that sounds not so assuring
<hypera1r> =p
<hypera1r> i kinda need this machine to work.
<sebner> dito
<sebner> now you see where the excitement starts :P
<hypera1r> sebner: too much excitement leads to a shorter life.
<sebner> hypera1r: It's *positive* excitement :P
<geser> who wants to live forever?
<hypera1r> not me. =p
<Nafallo> geser: vampires
<hypera1r> but i'd like to live for a considerable amount of time.
<hypera1r> Nafallo: who says vampires like their immortality?
<Nafallo> and zombies don't really care... they just die and live and die and liv...
<hypera1r> lol
 * sebner doesn't need immortality but the other abilities of vampires :P
<Nafallo> hypera1r: well, that's why they are vampires in the first place... immortality.
<hypera1r> Nafallo: that doesn't mean they *want* to be vampires =p
<Nafallo> the blooddrinking bit they can do as regular humans if they'd want too...
<geser> sebner: like getting burned to ash in sunlight?
<hypera1r> geser: that's not an ability.
<hypera1r> but yes, i'd like the other abilities as well
<sebner> hypera1r++
<Nafallo> what would be the other abilities? :-)
<hypera1r> superstrength?
<hypera1r> the ability to go without sleep?
<geser> hypera1r: so you would prefer to be a "daywalker"?
<hypera1r> sure i would
<Nafallo> hypera1r: the hulk has strength. probably more so than vampires.
<hypera1r> Nafallo: vampires are cooler. hulk's... big.
<Nafallo> and vampires sleep in their coffins during daytime, no?
<sebner> ~charisma~
<Nafallo> sebner: http://content6.flixster.com/question/57/74/63/5774636_std.jpg <-- not a vampire
<Nafallo> so not mutually excluded to them :-)
<Nafallo> regular humans can have it.
<sebner> Nafallo: ????
<sebner> transformation into a bat
<sebner> *hahaha*
<Nafallo> lol
<hypera1r> oh yeah! that'd be cool
<hypera1r> i'd like to be able to fly =p
<Nafallo> well... seen batman!? ;-)
<hypera1r> meh =.=
<hypera1r> he can't fly.
<Nafallo> he's not a vampire!
<hypera1r> exactly.
<hypera1r> i'd like to fly
<Nafallo> for flying I'd propose someone like superman :-)
<Nafallo> so basically a specific kind of alien.
<Nafallo> I like vampires eyes though... not sure it'd be worth giving up life for though -)
<Nafallo> and not all vampires can fly btw ;-)
<sebner> guys, we tend to drift off a little bit .. *OT* :P
<hypera1r> hmm i don't mind being superman, minus the responsibilities
<Nafallo> sebner: oh. I thought "Masters Of The Universe" was all about comics, but you're proably right ;-)
<hypera1r> then i don't need to wait for those damned buses in the morning
<hypera1r> Nafallo: =D
<geser> that http://www.video123.net/something-new-section/ we be a coffin for a modern vampire :)
<sebner> We should be called Masters of Disaster though :P
<hypera1r> sebner: disaster? why so?
<sebner> hypera1r: see our talk xD
<sebner> geser: wanna have :D
<hypera1r> sebner: what talk?
<sebner> hypera1r: the last 15 minutes here
<hypera1r> sebner: i don't see how that's considered disaster =\
<sebner> hypera1r: we a obviously not doing serious talk/work :P
<Nafallo> sebner: bonding... "team building exercise"
 * hypera1r agrees heartily
<sebner> Nafallo: hehehe, right but I'm wondering when the next will complain that we are OT. On the other hand it's sunday and it seems everybody is lazy anyways
<hyperair> sebner: actually i usually do most of my FOSS work on weekends =\
<BlackZ> how can I import my personal pgp key in gnupg ?
<sebner> hyperair: heh, yeah but I was referring to the chan activity
<hyperair> =p
<sebner> hyperair: .. and again I'm wasting my time here instead of studying xD
<hyperair> sebner: as am i. >_>
<geser> BlackZ: how did you create the key?
<hyperair> sebner: well then, i'm really off to study this time.
<BlackZ> geser: with gnupg, and I have uploaded & confirmed it in launchpad
<sebner> hyperair: that motivates me too :D
<hyperair> sebner: shutup, stop pinging me and go study >:O
<BlackZ> geser: but I haven't it now as my personal pgp key
<sebner> !ohmy | hyperair  :P
<ubottu> hyperair  :P: Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
 * hyperair attempts to put a fierce face to scare sebner into studying
<hyperair> sebner: urusai!
 * sebner hides
<sebner> hyperair: bacca!
<hyperair> that's baka.
<geser> perhaps we should ban sebner from this channel till his exam
<hyperair> hehee
<sebner> hyperair: damn
<sebner> geser: hehehe, same goes for hy
<sebner> geser: hehehe, same goes for hyperair
<iulian> And hyperair. *G*
<hyperair> X_X
 * hyperair runs away
<geser> BlackZ: what you mean with "personal pgp key"?
<geser> with sebner gone he can't highlight hyperair anymore and distract him :)
 * hyperair coughs.
<hyperair> and there you go highlighting me
<sebner> geser: you are mean :P
 * hyperair glares
<sebner> geser: and hyperair distracts me and not the other way round :P
<BlackZ> geser: the pgp key. If I import it from keyserver.ubuntu.com it doesn't work - in seahorse is listened as "Other keys"
<BlackZ> so I can't sign packages with debuild
<geser> BlackZ: you need the private (secret) part of the key which is also generate together with the key
<BlackZ> geser: I have lost it, where can I found it?
<geser> in your backup
<geser> without the secret part your gpg key is useless
<BlackZ> ok, so I must recreate it
<geser> so you lost the secret part after you registered the key in LP?
<geser> as you need the secret part to decipher the mail from LP
<BlackZ> geser: exact, but I can check also if I think I'll not found it, btw I have signed a package for the upload on revu with the old key. Should I change the key in that package?Ã¹
 * geser points BlackZ to https://help.ubuntu.com/community/GnuPrivacyGuardHowto just in case
<geser> BlackZ: as long as REVU still knows your (old) key, you can upload already signed packages to REVU (but obviously don't sign new ones anymore)
<BlackZ> geser: can I re-sign it with new key?
<nigelb> I'm trying to propose an SRU for debootstrap for the bug that doesn't let building a sid chroot in pbuilder
<nigelb> when I add entires to the changelog, it should read karmic-proposed?
<ScottK> nigelb: Yes.
<nigelb> thank you :)
<nigelb> so, testing would involve me creating a karmic chroot?
<comutamike> hi guys - I'm stuggling trying to package wallpapers and themes.  I've tried copying the format used in the ubuntu-desktop package but I'm stuggling - mainly to do with the rules file.  Do we have any guides somewhere?
<geser> BlackZ: yes, debsign thepackage_source.changes
<geser> nigelb: is the bug fixed in lucid?
<nigelb> geser: yep
<geser> comutamike: where are you stuck?
<BlackZ> geser: if I should modify a package (debian/control) and in (debian/changelog) is present the line: package (1.0-2) unstable; urgency=low should I add (1.0-0ubuntu1) lucid; urgency=low with dch -i ?
<geser> 1.0-2ubuntu1 (it's the first Ubuntu modification to 1.0-2)
<geser> (and versions should be monotonous increasing)
<BlackZ> geser: http://pastebin.ubuntu.com/390453/ can be it ok so?
<geser> BlackZ: mostly yes, the changelog entry itself is almost ok (missed the # before the bug number). But we shouldn't update the standard-version for packages imported from Debian (it has no real benefit but only increases the Ubuntu delta) and I hope you thought of updating the maintainer field (it shouldn't be documented in the changelog entry)
<nigelb> anyone can confirm bug 533369?
<ubottu> Launchpad bug 533369 in debootstrap "Fails to debootstrap squeeze chroot due to missing apt-get" [Undecided,In progress] https://launchpad.net/bugs/533369
<cody-somerville> persia, re: "Confusing intertwining of Ubuntu Development teams for Membership", alternatively couldn't we make any team that should grant membership a direct member of the ubuntumembers team?
<randomaction> I'm looking at mit-scheme, which is a package that build-depends on one of its own binaries. It was bootstrapped using a .deb from Debian back then for feisty, and this patch has been kept in a couple of merges. This is not good, is it?
<cody-somerville> persia, I think this provides a number of benefits including making it easier to audit to ensure only teams intended to give membership give membership.
<debfx> siretart: could you please ack the keepassx sync request (bug #533873)?
<ubottu> Launchpad bug 533873 in keepassx "Please sync keepassx 0.4.3-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/533873
<nigelb> can someone help debug this build error? http://paste.ubuntu.com/390671/
<geser> for which ubuntu release do you try to build?
<nigelb> karmic
<nigelb> its for an SRU request
<geser> try logging in into your pbuilder "pbuilder-dist karmic login" and see what happens when you try to "aptitude install debhelper"
<nigelb> got the trouble
<nigelb> it was a rogue line on pbuilderrc that I created to test a bug
#ubuntu-motu 2011-02-28
<MTecknology> I need some help with some packaging... (http://bazaar.launchpad.net/~nginx/nginx/debian/files) An old version of nginx installed files for nginx-{full,light,extras} to /etc/logrotate.d/nginx-{full,light,extras}. The file was removed and put into nginx-common which installs /etc/logrotate.d/nginx. That part works perfect. The issue is upgrade from a broken version.
<MTecknology> No matter what I try, I can't make the old file get properly removed.
<MTecknology> nginx-common.{preinst,postinst,prerm} are using dpkg-maintscript-helper to deal with that but they don't seem to be doing anything. I don't see any errors, warnings, or anything during the upgrade either. Just looks like it worked great and then doesn't end up removing the old conf
<MTecknology> I've been fighting this for over a month now and I'm just utterly lost.
<Ampelbein> MTecknology: can you pastebin your debian/rules?
<Ampelbein> MTecknology: and pre/post-inst/rm
<MTecknology> Ampelbein: ya, you could just checkout that link too; it has those files
<MTecknology> http://bazaar.launchpad.net/~nginx/nginx/debian/files
<Ampelbein> true, I could do that. was feeling lazy ;-)
<Ampelbein> but will do ;-)
<MTecknology> :P
<Ampelbein> MTecknology: maybe I need more coffee, but you don't have a preinst?
<MTecknology> Ampelbein: no; do I need to add that file for this to work?
<Ampelbein> MTecknology: yes, you do. in the pre-inst, dpkg-maintscript-helper determines what to do with the file and renames it to either *.dpkg-remove or *.dpkg-backup and in the postinst deletes or keeps this renamed file
<MTecknology> oh......
<MTecknology> that'd make a crap done of sense then..
<MTecknology> Ampelbein: I'll try that and see how things work :D
<Ampelbein> MTecknology: it does ;-) you need the snippet in the preinst, the postinst and postrm
<MTecknology> hm.. might need to wait a little bit to redo this package
<MTecknology> Ampelbein: so this is all I need in there? http://dpaste.com/456611/
<Ampelbein> MTecknology: that looks about right
<MTecknology> and now build time
<Ampelbein> for me it's now oscar's time ;-)
<MTecknology> hm?
<Ampelbein> MTecknology: the academy awards 2011
<Ampelbein> MTecknology: you know, that movie stuff, like youtube, only on big screen.
<MTecknology> amoh
<MTecknology> oh*
<MTecknology> hm.... if anyone could help me figure out the rest of the conversation above..
<MTecknology> This is what I end up with now - http://dpaste.com/456739/
<MTecknology> I guess that's progress from where I was; things are at least trying to happen
<lesliev> hi people! another question: when trying to follow daniel holbach's deb building tutorial, "debuild -S -sa" is not making a .diff file
<lesliev> it is making a new .debian.tar.gz source file
<lesliev> why doesn't it make a .diff.gz?
<lesliev> this is the file it seems to be creating instead: ed_1.5-0ubuntu1.debian.tar.gz
<micahg> lesliev: because it's using source format 3.0
<lesliev> ok, so this is an improvement in debuild?
<micahg> lesliev: here's where you can read more about it and its benefits: http://wiki.debian.org/Projects/DebSrc3.0
<lesliev> ok, will look at that
<lesliev> debuild also seems to be angry about the line I put in changelog
<lesliev>   * Initial release.
<lesliev>   * Repacked .tar.lz to .tar.gz, no other changes
<lesliev> That second line it complains about
<lesliev> parsechangelog/debian: warning: ed-1.5/debian/changelog(l4): unrecognised line
<lesliev> LINE: 	* Repacked .tar.lz to .tar.gz, no other changes
<lesliev> is there a problem with it?
<micahg> lesliev: maybe it's your spacing
<paultag> lesliev: looks like you did a tab?
<micahg> MTecknology: seems like the postinst failed on nginx-common
<paultag> that or irssi is barfing again
<paultag> I have a package I'll be requesting a sync for soonish. Since we're in FFe, what must I do for the sync? If it helps, it closes a RC bug (in Debian, but same issue is in Ubuntu)
<lesliev> oooooh, tab
<paultag> lesliev: two spaces, jabroni
<paultag> :)
<micahg> paultag: is it bug fix only?
<paultag> micahg: no, new upstream version with bugfixes, plus a dfsg repack, one theme is non DFSG
<paultag> I missed that for the last few releases. Upstream is willing to relicense that, but in the meantime :)
<MTecknology> micahg: does the postinst i pasted (http://dpaste.com/456611/) look obviously wrong?
<micahg> paultag: if the new upstream isn't bug fix only, pass -e to requestsync to request an FFe
<lesliev> :)
<paultag> micahg: it's a fluxbox release -- it's been less then two days since the major number release last -- it's both upstream and debian bugfixes, I don't think there are new features. What would you do?
<micahg> MTecknology: I'm not familiar with that type of scripts so I can't help you there
<paultag> Oh jeez, two weeks
<paultag> sorry, my fault
<MTecknology> micahg: alrighty; thanks :) I couldn't even figure out which file it was yelling at me for
<micahg> paultag: bug fix only, wherever they are, doesn't need an exception, only new features
<paultag> micahg: cheers, thanks
<MTecknology> micahg: the package I'm doing now is bug fixes to packaging only; no exception needed, just bug report?   and a new app I write would need to pass through an exception (and probably wouldn't make it) ? <-- that how it works right now?
<micahg> MTecknology: lines 57 and 58 of your original paste
<MTecknology> oh..
<micahg> MTecknology: right
<MTecknology> thanks again :)
<micahg> MTecknology: actually 35 and 36 of the original paste
<MTecknology> micahg: heh.. now I'm confused.. the only change was adding a .preinst file; not .postinst
<MTecknology> and that exact same chunk is in each of package.{pre,post}{inst,rm}
<c2tarun> good morning :)
<Rcart> I'll apply this patch on bug 725217
<ubottu> Launchpad bug 725217 in ubiquity-slideshow-ubuntu (Ubuntu) "Typos in Edubuntu 11.04 slideshow" [Undecided,New] https://launchpad.net/bugs/725217
<Rcart> Bug the bug is present in the translation files (dir po), that the patch does not cover
<Rcart> I would like to know if I *must* fix the typos in the .po files too.
<Rcart> *But
<RoAkSoAx> SpamapS i upgraded to nvidia drivers today and they are working well not perfect but good enough
<SpamapS> RoAkSoAx: yeah when I get back home I'll upgrade. Good to hear though!
<SpamapS> RoAkSoAx: did you solve your multi monitor issues?
 * SpamapS really should be trying to get a bit more sleep
<RoAkSoAx> SpamapS yeah kinda getting a dualhead2go to try it out and see what happens otherwise ill get a x200 ultrabase
<Rcart> T_T
 * Rcart is going to bed.
<c2tarun> Can anyone give me a patch with DEP-3 tags. I want to look at one of those as an example.
<paultag> c2tarun: http://dep.debian.net/deps/dep3/
<paultag> c2tarun: there's a sample patch down a ways
<c2tarun> this question may be silly, but why we refer FTBFS fixes as binutils-gold?
<paultag> c2tarun: well binutils-gold issues are FTBFS issues, but not all FTBFS issues are binutils-gold issues
<paultag> c2tarun: aptitude show binutils-gold, it's a change in the linker
<paultag> c2tarun: and as a result, the linker behaves in a different way -- so some libraries which used to be linked are no longer linked
<paultag> and as a result, it fails to build (from source)
<c2tarun> paultag: got it :) thanks
<paultag> c2tarun: cheers :)
<c2tarun> can we use LIBS variable in rules file?
<RAOF> c2tarun: No; you're not running in the same make context.
<c2tarun> how to fix errors like [LD_ERROR] libkio.so.4: could not read symbols: Invalid operation
<RAOF> c2tarun: http://wiki.debian.org/ToolChain/DSOLinking
<RAOF> c2tarun: Essentially - fix the build order.
<c2tarun> there is a package named kbarcode, when I am trying to install build-dependencies I am getting this error http://paste.ubuntu.com/573311/
<c2tarun> when I am pinging to IP 91.189.88.45 I am getting response.
<RAOF> I'd just try again; that's a network problem.
<c2tarun> RAOF: I think that package is removed from that page.
<c2tarun> RAOF: What should I do?
<RAOF> Refresh your package lists if that error persists.
<RAOF> Aaah.
<RAOF> Sorry, I misread the error the first time.
<RAOF> That error is frequently caused by your apt cache being out of date - so apt tries to download 4:4.6.0-0ubuntu2 when 4:4.6.0-0ubuntu3 (or whatever) has been released and hence 4:4.6.0-0ubuntu2 has been removed from the mirror.
<RAOF> So, a simple âsudo apt-get updateâ should resolve things.
<c2tarun> RAOF: so updating the chroot will do it?
<RAOF> Right.
<c2tarun> RAOF: thanks :)
<lesliev> is there any list of packages that need packaging? searching for needs-packaging in launchpad doesn't seem to help much
<lesliev> for example, it lists "symon", which looks like it last had activity in 2006
<arand> lesliev: You might want to have a peek at harvest?
<lesliev> which makes me think its not really even needed by anyone
<lesliev> aha
<arand> lesliev: It doesn't seems to be very exhaustive... hmm, http://harvest.ubuntu.com, looking at it, it doesn't have a good needs-packaging fileter it seems
<arand> lesliev: I guess you could always check out debians lists, which should be somewhat representative I guess...
<arand> lesliev: http://www.debian.org/devel/wnpp/requested
<lesliev> so is most packaging done for debian and just pulled into ubuntu?
<arand> Well that's the ideal case I guess, if possible.
<lesliev> symon's changelog shows activity last year, so it may be worth trying to package. I am putting together a packaging presentation, so I want some test cases
<lesliev> oh, checking that url...
<arand> In particular now, when feature freeze is in action, it would likely be a good idea to get a new app into debian in order for it to get in natty+1.
<lesliev> wow, a lot of requests are >1 year old
<lesliev> does harvest rank requests based on how many people ask for the same thing?
<arand> It may rank by bug heat or so, and uses plent of lp tags, I think..
<c2tarun> can anyone please help me with this error http://paste.ubuntu.com/573321/ I know how to fix this error, but I dont know where to link the libraries to fix the error.
<c2tarun> can anyone please help me with this error http://paste.ubuntu.com/573321/ I know how to fix this error, but I dont know where to link the libraries to fix the error.
<Bachstelze> c2tarun: looking at it
<dholbach> good morning
<Rhonda> Hmm, I guess I need a FFE for gitolite. Or actually not, it's just a oneline security-related fix?
<Rhonda> I guess I should also prepare updates for maverick
<Rhonda> Ouch! natty still has 1.5.4, for the update to 1.5.7 I _definitely_ would need a FFE, I'm taking the question back. :)
<Rhonda> Now I wonder: Should I rather go for FFE for 1.5.7-2, or rather try to prepare an 1.5.4-2ubuntu1 with the security fix only, for natty?
<Bachstelze> c2tarun: have you tried ld's suggestion of adding /usr/lib/libkio.so.4 to the command line?
<siretart> Rhonda: at this point, your chances for a FFe seem high :-)
<Rhonda> siretart: So you'd suggest 1.5.7-2 to natty with FFe and 1.5.4-1ubuntu1 to maverick-updates for a SRU?
<siretart> Rhonda: I didn't look into that case at all. I just pointed out that FFe used to be approved more lightly right after FF than right before release
<Rhonda> Rught
<Rhonda> Shall I pass the maverick update for gitolite through the security team? Anyone I could query about that?
<Rhonda> micahg, sbeattie?
<Rhonda> Or is even kees around for a quick question?
<ari-tczew> bdrung_: https://lists.ubuntu.com/archives/technical-board/2011-February/000707.html
<ari-tczew> if you have another solutions, please reply on list
<c2tarun> I was working on bug 726405. The problem can be fixed by making a change in Makefile.am by a patch, but the problem is when I am building the source package the debdiff is getting extremenly large because a file Makefile.in is being generated automatically which is causing this problem. After building first time when I am trying to build the package again I am getting the error patch failed. What can I do?
<ubottu> Launchpad bug 726405 in kbarcode (Ubuntu) "package kbarcode_2.0.7-3 failed to build from source" [Undecided,Confirmed] https://launchpad.net/bugs/726405
<ari-tczew> c2tarun: attach this large debdiff to bug for example
<Laney> that package seems to have it's reautotoolisation split up into patches in d/patches
<c2tarun> ari-tczew: I am trying but not able to upload that file on LP, may be my connectio problem. Can I upload it to someother place?
<c2tarun> ari-tczew: phew... its done :) please take a look at bug 726405
<ubottu> Launchpad bug 726405 in kbarcode (Ubuntu) "package kbarcode_2.0.7-3 failed to build from source" [Undecided,In progress] https://launchpad.net/bugs/726405
<ari-tczew> c2tarun: quilt delete debian-changes-2.0.7-3ubuntu1
<ari-tczew> and rerun build source
<c2tarun> ari-tczew: but why is it there ? I didn't create it.
<ari-tczew> c2tarun: sometimes it just works like that. domain of 3.0 source format.
<micahg> ari-tczew: you should be able to push to any branch you can upload to
<ari-tczew> micahg: the case is changing status of merges
<micahg> ari-tczew: you can do that for branches you can control, as should be appropriate
<ari-tczew> micahg: bdrung can't do this as well and he is core-dev
<ari-tczew> so it's NOT appropriate ;]
<micahg> which branch specifically
<ari-tczew> c2tarun: * Modified patch according to dep3 format. <- remove it, not necessary info for d/changelog
<ari-tczew> micahg: https://code.launchpad.net/~legolas/ubuntu/natty/php5/5.3.5/+merge/48128
<micahg> Rhonda: re gitolite, https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation
<c2tarun> ari-tczew: I uploaded a new debdiff, can you please take a look, and tell me if still there is some problem
<Rhonda> micahg: Thanks. No CVE id though. But I'll follow through that checklist, expect a bugreport later tonight (european time)
<micahg> Rhonda: well, you might want to ask in #ubuntu-hardened to be sure if it should go through security, I remember the mentions in the Debian channel about it
<Rhonda> micahg: Does http://git.deb.at/w/pkg/gitolite.git/commitdiff/d471220 look proper to you? ae402da is the cherry-picked one-line change.
<Rhonda> I'm fine with dropping the Maintainer email address change if it really must, but I'd like to adjust these things when I'm in there already.
<micahg> Rhonda: version and target are correct, maintainer address changes probably shouldn't happen in a security update, but I don't see the actual one line change in tehre
<Rhonda> It's ae402da, replace the end of the URL (or click the [parent] link)
<ari-tczew> c2tarun: * Modified patch according to dep3 format. <- remove it, no point to keep this change
<micahg> Rhonda: yeah, you should probably run that by sbeattie in #ubuntu-hardened in a few hours
<ari-tczew> c2tarun: Bug: https://bugs.launchpad.net/ubuntu/+source/kbarcode/+bug/726405 <- it's wrong, please use another tag and short URL
<ubottu> Ubuntu bug 726405 in kbarcode (Ubuntu) "package kbarcode_2.0.7-3 failed to build from source" [Undecided,In progress]
<micahg> Rhonda: he's on community this week
<Rhonda> micahg: Alright, will drop by there later then.
<ari-tczew> c2tarun: Bug-Ubuntu: https://launchpad.net/bugs/bug-number
<c2tarun> ari-tczew: sure i'll do it
<ari-tczew> c2tarun: generally d/changelog entry should be rewrited
<ari-tczew> c2tarun: use something like this http://pastebin.ubuntu.com/573493/
<ari-tczew> c2tarun: I guess your fix in Makefile is wrong
<ari-tczew> c2tarun: try just add -lbkio
<ari-tczew> sorry, -lkio
<c2tarun> ari-tczew: I tried, after adding -lkio and after that it will ask for another and another, that's how I got all of them
<ari-tczew> c2tarun: let me try to build
<c2tarun> ari-tczew: sure
<mike__b> Hi, I have a package that does not have any patches yet. I've added a patch to it, to debian/patches, and added that patch to debian/rules. If I build a package from that, the patch is not applied. How can I check what is missing?
<mike__b> I meant debian/patches/series
<Ampelbein> mike__b: what sourceformat is the package using?
<ari-tczew> c2tarun: in future please use tag Description instead Subject if you add one sentence.
<mike__b> Ampelbein: I'm sorry, I'm a real newbie wrt Deb packages. How would I check?
<ari-tczew> mike__b: what-patch
<mike__b> unknown patch system :D
<ari-tczew> mike__b: do you creating new package?
<c2tarun> ari-tczew: sure, I'll fix that too and upload a final debdiff
<mike__b> No, I'm trying to patch an already existing package.
<mike__b> But the package did not have patches before.
<ari-tczew> c2tarun: in bug 725933 DEP3 tags should be below /bin/sh (initial script)
<ubottu> Launchpad bug 725933 in ivtv-utils (Ubuntu) "Package ivtv-utils-1.4.1 failed to build from source" [Medium,Incomplete] https://launchpad.net/bugs/725933
<ari-tczew> mike__b: does this package exist in Debian?
<mike__b> Yes it does.
<ari-tczew> mike__b: check https://wiki.ubuntu.com/PackagingGuide/PatchSystems
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in #ubuntu-classroom in 20 minutes!
<c2tarun> ari-tczew: please take a look on my new upload on bug 726405 meanwhile I'll fix bug 725933
<ubottu> Launchpad bug 726405 in kbarcode (Ubuntu) "package kbarcode_2.0.7-3 failed to build from source" [Undecided,In progress] https://launchpad.net/bugs/726405
<ubottu> Launchpad bug 725933 in ivtv-utils (Ubuntu) "Package ivtv-utils-1.4.1 failed to build from source" [Medium,Incomplete] https://launchpad.net/bugs/725933
<mike__b> ari-tczew: I read that article already, but to me it's confusing because it discusses so many different use cases. What am I missing? Should I add the stuff to debian/rules about the patches?
<ari-tczew> mike__b: which package?
<c2tarun> can anyone please help me with this error, http://paste.ubuntu.com/573510/ I got this error when I changed the sequence of few comments in .dpatch file
<mike__b> ari-tczew: libsoap-lite-perl
<ari-tczew> mike__b: switch to 3.0 source format will be easiest way
<MTecknology> I have nginx-common.preinst 'http://dpaste.com/456611/' That exact same chunk is sitting in {pre,post}{inst,rm}. The package would install just fine prior to adding .preinst. Now it blows up when I try to install it.. http://dpaste.com/456739/      Any thoughts to what I might be doing wrong? Packaging is at http://bazaar.launchpad.net/~nginx/nginx/debian/files
<tap-out> what is ubuntu motu
<Rhonda> Ubuntu is a Linux Distribution, and MOTU stands for Master Of The Universe, a petname for developers responsible for the packages in the "universe" part of the distribution.
<jpds> Rhonda: Shame he left. :<
<Rhonda> uhm
 * Rhonda is a fair bit annoyed about quick-leavers
<MTecknology> Rhonda: indeed.. at least he past the 2min barrier for most
<ari-tczew> Rhonda: if you don't want write to wall, please use TAB for check whether nick is still online
<ari-tczew> it will be also helpful for person who asked because he will be notified (highlight)
<joaopinto> hum, doesn't the MOTU definition overlaps with "Ubuntu Contributing Developers" ?
<Laney> !motu
<ubottu> motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See  http://wiki.ubuntu.com/MOTU
<Laney> !ucd
<Laney> I don't know why it says 'collectively responsible' â that's not my understanding (https://launchpad.net/~universe-contributors)
<joaopinto> from https://wiki.ubuntu.com/UbuntuDevelopers#ContribDev, UCDs are collectively responsible for the maintenance of most of the packages in Ubuntu  = universe ?
<joaopinto> unless we read as MOTUs being a subset of UCDs, meaning you can be an UCD maintaining packages without being a MOTU
<Laney> UCD means you have met the requirements for membership, and you contributions are from development
<Rhonda> ari-tczew, very much thanks for your input, actually I did that, but thanks anyway.
<Rhonda> joaopinto: UCDs need sponsorship for uploads, MOTUs don't.
<joaopinto> ah ok, tks
<ari-tczew> UCD = Ubuntu Member + Bug control
<Laney> I don't think it gives bug control.
<udienz> UCD = Ubuntu Member + Revu uploader + Planet Ubuntu
<ari-tczew> Laney: Right, MOTU gives bug control.
<Laney> yes
<fta> siretart, ping
 * siretart throws a contentless pong back
<fta> siretart, i was wondering about debian bug 595452, it's been a while and the bug is still there in natty. could we land that at least as a distro patch, if not directly upstream
<ubottu> Debian bug 595452 in mplayer "1.0rc3 native mkv demuxer fails to decode some files" [Important,Open] http://bugs.debian.org/595452
<siretart> fta: what would be the patch?
<siretart> AFAIR. the lavf demuxer is already enabled by default in rc4
<fta> siretart, referring to the "there is a patch pending for it in the MPlayer dev list" comment in the bts
<siretart> that referred to the native mkv demuxer
<siretart> from a distro POV, you want to improve libavformat, not the mplayer internal mkv demuxer
<fta> i still have mkv files that are unplayable in mplayer but fine in totem (yet too slow)
<siretart> do they play with ffplay?
<fta> super slowly but yes. mplayer is able to play the video smoothly (vdpau) but doesn't recognize the sound track
<siretart> that indicates a deficiency in libavformat. get that fixed :-)
<fta> well, no, as -demuxer lavf is fine
<siretart> no, you just told me that ffplay was broken
<fta> no, it's slow (no vdpau)
<siretart> aaah, so whats the problem then?
<fta> no audio with mplayer default demuxer
<fta> siretart, http://paste.ubuntu.com/573540/
<siretart> that paste indicates the (broken) internal mkv demuxer. so?
<fta> isn't what the debian bug is about?
<fta> well, n-m, -demuxer lavf will do.
<siretart> rc4 (which we have in natty) uses the libavformat demuxer by default, or not?
<siretart> oh, it says that rc4 used the internal mkv muxer? that would be a bug then, indeed
<geser> tumbleweed: I've commented on your u-d-t merge proposal.
<geser> Have you tried to use your branch over ssh? as this would be a general launchpadlib problem which will affect other non-u-d-t scripts too
<tumbleweed> geser: yeah working on it with leonardr in #launchpad
<tumbleweed> well, working on notes for NEWS
<tumbleweed> it seems like it'll work on headless boxes over ssh, but once you have python-gnomekeyring installed, things get messy
<ari-tczew> geser, tumbleweed: is requestsync broken at this moment?
<geser> sort of, python-launchpadlib 1.9 requires some changes, tumbleweed is working on it
<tumbleweed> ari-tczew: use e-mail for now
<ari-tczew> tumbleweed: or LP :)
<tumbleweed> or request the sync from a non-natty machine :)
<ari-tczew> tumbleweed: no infrastructure :>
<kklimonda> use VM
<micahg> tumbleweed: newest requestsync is broke on any version
<kklimonda> I keep older releases in VM so I can test on them, or fallback if my current development install is getting too unstable ;)
<tumbleweed> micahg: you mean the not-quite-newest requestsync?
<micahg> I guess, the one from 0.117 ubuntu-dev-tools
<manish> what is the possible problem with this changelog file?
<manish> http://paste.ubuntu.com/573624/
<manish> I get
<manish> parsechangelog/debian: warning: zeitgeist-datahub-0.7.0/debian/changelog(l7): badly formatted trailer line
<manish> LINE:  -- Manish Sinha <manishsinha@ubuntu.com> Tue, 01 Mar 2011 01:00:00 +0530
<tumbleweed> micahg: yeah, sorry about that, python scoping is a bit weird sometimes. 0.118 fixed it
<ari-tczew> manish: please use dch -e
<manish> ari-tczew: same
<manish> parsechangelog/debian: warning:     debian/changelog(l7): badly formatted trailer line
<manish> LINE:  -- Manish Sinha <manishsinha@ubuntu.com> Tue, 01 Mar 2011 01:00:00 +0530
<manish> both the lines starting from * should end with a . ?
<manish> right?
<seidos> period = unity
<seidos> i'm working on a flag
<ajmitch> manish: two spaces between the email address & the date, not one
<manish> ajmitch: yes. that was the issue. Thanks
<MTecknology> http://dpaste.com/459264/ <-- Any chance you guys could help me figure out this? /etc/logrotate.d/nginx-full should get removed. Packaging.. http://bazaar.launchpad.net/~nginx/nginx/debian/files
<MTecknology> err. that's not the 'exact' packaging, this has two fixes to keep it from breaking, but those are obvious in the paste
<pulb> hi guys, I created this package -> http://revu.ubuntuwire.com/p/basenji.  ari-tczew mentioned it is possibly too late to get it into natty and suggested to get it into debian. any opinions?
<Quintasan> pulb: Yup, too late for Natty as Feature Freez is in effect
<Quintasan> I think you can get it in Debian and then request a sync in natty+1
<pulb> hmmpf, I spend a lot time to get comfortable with this revu stuff. is debian uploading any different?
<Quintasan> pulb: dput mentors <changes>
<pulb> I don't have the time to install debian for testing, is it just a matter of dependency renaming?
<Quintasan> pulb: be sure to change the package to meet Debian requirements (like version in changelog etc)
<Quintasan> pulb: I do not think there should be any dependency renames
<Quintasan> pulb: Be sure to check you package using sid pbuilder
<pulb> if i dput it to mentos, where do i get feetback?
<pulb> err mentors
<Quintasan> pulb: http://mentors.debian.net/cgi-bin/welcome
<Quintasan> pulb: You will need to find a sponsor for your package, your best shot is #debian-mentors @ irc.oftc.net
<pulb> ok, thanks!
<micahg> ari-tczew: your advise on kklimonda's application is wrong, UNRELEASED should be used when proposing merges in a VCS unless you are the uploader
<micahg> err, scratch that last part, proposed merges should target UNRELEASED in case changes need to be made
<ari-tczew> micahg: yea, in VCS, not in lp:ubuntu/foo
<micahg> ari-tczew: UDD is a VCS
<ari-tczew> o_O
<micahg> if something in a UDD branch is not in the archive, the target should be UNRELEASED
<ari-tczew> micahg: I like sponsoring bzr merges by sponsor-patch but if branch is UNRELEASED there is a problem because it won't upload it into archive
<micahg> ari-tczew: then the tool should be fixed
<ari-tczew> bdrung: ^^
<bdrung> ari-tczew, micahg: that's how sponsor-patch works. it will ask if you want to set the series. then you can set it to whatever you want (natty, maverick-proposed, ...)
<ari-tczew> bdrung: by script? don't I need to open directory in /tmp and do it manually?
<bdrung> ari-tczew: if you say "yes", it will give you a shell in the correct directory
<bdrung> ari-tczew: do you have an example bug?
<ari-tczew> bdrung: no at this moment
<ari-tczew> bdrung: ehh, can't script do it automatically?
<ari-tczew> e.g. "there is UNRELEASED target, would you like to update it?"
<ari-tczew> and options to choice
<bdrung> ari-tczew: do we always know where it should be uploaded?
<ari-tczew> 1. natty
<ari-tczew> 2. maverick-rpoposed
<ari-tczew> bdrung: if you take it as sponsor, you should know where do you want upload it
<bdrung> yes, but does the script can know it?
<ari-tczew> bdrung: as I wrote 2 minutes ago, choice
<micahg> ari-tczew: that's a maintenance burden for the script to always keep those updated
<bdrung> micahg: no, we have distro-info!
<micahg> bdrung: ah, you actually did it?
<bdrung> yes
<cody-somerville> couldn't it just ask and let the user input the suite name? That would be better than dropping to a shell and having to do it manually + would make the tool work in non-ubuntu context.
<bdrung> cody-somerville: it is very ubuntu specific currently
<bdrung> cody-somerville: it work on LP bugs
<bdrung> s/work/works/
<micahg> kklimonda: congrats on MOTU
<highvoltage> kklimonda: welcomee to MOTU!
<kklimonda> thanks highvoltage, micahg :)
<chrisccoulson> kklimonda, oh, congrats!
<Quintasan> kklimonda: \o/ cookies
 * ari-tczew gives beer for kklimonda
<porthose> kklimonda, congrats welcome to MOTU :)
<kklimonda> chrisccoulson: thanks, it did take me some time, but I've done it at last :)
<kklimonda> porthose: thanks :)
<kklimonda> Ampelbein: you should branch ubuntu:transmission (or lp:ubuntu/transmission)
<Ampelbein> kklimonda: I did that. And then made a local branch for my bugfix. But then I'm getting a bit stuck. Do I have to use quilt to make my patch? Do I just edit the source? But how does the patch come in then? This is all a bit confusing
<kklimonda> Ampelbein: it is, isn't it? :)
<kklimonda> Ampelbein: you use quilt, add patch and changelog entry and then push your branch.
<Ampelbein> kklimonda: but then I end up with the changes 2 times in the bzr-diff - once in the original file and once in the patch. I know that it doesn't matter much but that doesn't sound right, if you know what I mean.
<kklimonda> .pc folder doesn't exist in transmission branch so I assume you don't have to commit it. But this part is a bit fuzzy
<kklimonda> Ampelbein: I just do quilt pop -a before commiting when .pc is not in vcs
<Ampelbein> kklimonda:  I branched with 'bzr branch ubuntu:transmission natty'
<Ampelbein> kklimonda: which has the patches applied (and thus the .pc directory)
<kklimonda> ah, then you should commit along with .pc
<kklimonda> sorry, I've cloned the wrong branch - I don't use bzr for transmission myself
<kklimonda> (but it's time to start doing it)
<Ampelbein> kklimonda: it is easier with just apt-get source, quilt new, quilt add, quilt refresh, debuild -S, debdiff, attach. at least till I understand this bzr thing fully.
<Ampelbein> kklimonda: but thanks, I will have another go.
<kklimonda> Ampelbein: I think you should add both debian/patches/patch and .pc/patch
<kklimonda> lets see if it works
<kklimonda> nope.. hmm..
<kklimonda> Ampelbein: it looks like you should clone the branch, create patch with quilt, add changelog entry, unapply the newly created patch, commit changelog, d/patches/series and d/patches/patch and that's it..
<Ampelbein> kklimonda: is there a website somewhere documenting that?
<kklimonda> but other patches are applied and .pc directory is commited.. ugh..
<kklimonda> Ampelbein: there is an entire wiki page about it: https://wiki.ubuntu.com/DistributedDevelopment but I don't know how up to date it is. I just tinker with it until it works :)
<MTecknology> http://dpaste.com/459264/ <-- Any chance you guys could help me figure out this? /etc/logrotate.d/nginx-full should get removed. Packaging.. http://bazaar.launchpad.net/~nginx/nginx/debian/files (only difference is the chmod that was breaking it and the use of set -x)
<kklimonda> Ampelbein: there is also https://wiki.ubuntu.com/DistributedDevelopment/Documentation
<MTecknology> Ampelbein: maybe you could take a look?.. :D
<Ampelbein> kklimonda: some pages there seem like "we need to document this", but https://wiki.ubuntu.com/DistributedDevelopment/Documentation/PatchSystem looks good
<kklimonda> Ampelbein: hmm, interesting - I've heard of looms before but it was months ago and they were being mentioned in context "it would be nice to have looms to do it" ;)
<Ampelbein> MTecknology: maybe later, I'm currently trying to figure out using bzr ;-)
<MTecknology> Ampelbein: alrighty; if you help me get this actually working I might need to go find you and hug you
<Ampelbein> kklimonda: http://bazaar.launchpad.net/~amoog/transmission/bug-726756/revision/63 this is the result of my current try without the looms stuff
<kklimonda> Ampelbein: it will create a debian-changes file when you try building a source package out of it
<Ampelbein> kklimonda: yes, that's fine I guess? transmission is source format 3.0 already.
<Ampelbein> kklimonda: and the debdiff looks fine, too http://paste.ubuntu.com/573667/
<kklimonda> Ampelbein: indeed, looks fine
<Ampelbein> kklimonda: I will propose a merge request and see what seb has to say ;-)
<kklimonda> Ampelbein: I can upload transmission, so I'll see if it works and upload ;)
<Ampelbein> kklimonda: oh, even better. thanks ;-)
<kklimonda> no problem
<kklimonda> Ampelbein: it doesn't work for me, any idea how to debug it?
<Ampelbein> kklimonda: you could try 'strace -o magnet.txt xdg-open "magnet-url"' to see what gets called?
<Ampelbein> MTecknology: where is your package failing now? the packaging looks good (apart from the 2 things you mentioned)
<kklimonda> Ampelbein: hmm
<kklimonda> Ampelbein: does it work for you with Exec=transmission-gtk %F ?
<kklimonda> I've had to change it to Exec=transmission-gtk %U
<kklimonda> and, by reading fd.o specification, I've come to conclusion that %F is wrong code for Exec in transmission's case..
<kklimonda> but it's been there for as long as I can remember, and it worked just fine.
<Ampelbein> kklimonda: actually it doesn't work for me with %F. I manually edited the .desktop in /usr/share/applications and must have forgot about that change. silly me.
<Ampelbein> kklimonda: I edited back to original state now and transmuussion just starts, but no add-file dialog
<Ampelbein> kklimonda: with %U it works
<kklimonda> it looks like fd.o tools got more strict in natty
<Ampelbein> kklimonda: I will update the upstream bug once it gets through moderation queue.
<kklimonda> upstream bug? you have a number?
<Ampelbein> kklimonda: not yet, it is still in moderation queue
<kklimonda> moderation queue on transmission trac? huh.. I'll poke developer to get it through :)
<Ampelbein> kklimonda: yes, I needed to register myself there and when i made new ticket, it said it was in queue for moderation.
<Ampelbein> kklimonda: I pushed an updated branch with the fix
<kklimonda> thanks
<acarpine> I need help
<acarpine> I worked on the bug 719379
<ubottu> Launchpad bug 719379 in python-fstab (Ubuntu) "Typos in Exception and docstring" [Undecided,Confirmed] https://launchpad.net/bugs/719379
<RAOF> acarpine: Ah!  That was you?
<acarpine> wow raof you are here!
<acarpine> tks 4 your reply
<acarpine> but this is my first bug fix
<acarpine> just a couple of questions...
<RAOF> Shoot!
<acarpine> I believe my error is that I used bzr push lp:~acarpine/ubuntu/natty/python-fstab/fix-719379
<acarpine> instead of bzr push lp:~juliank/python-fstab/debian
<acarpine> correct?
<acarpine> I'm talking about your first email advice
<RAOF> acarpine: No.  You pushed to the right place, but when you made the merge request you asked for it to be merged into the wrong tree.
<RAOF> You wouldn't have been able to push to lp:~juliank/python-fstab/debian, but you should be able to request a merge of your existing branch into it.
<acarpine> ok, clear now (I hope :-)
<RAOF> Feel free to ask more questions if I've been unclear anywhere else - I'll be here for the next 8 hours or so :)
<acarpine> the last advice said smthing about
<acarpine> You could drop the debian/changelog hunk and propose a merge into lp:python-fstab, which is where the upstream code lives.
<RAOF> (and then tomorrow, and the next day, and â¦ âº)
<acarpine> :) tks
<kklimonda> Ampelbein: I'll upload it after the soft freeze is over
<acarpine> I believe my problem is caused by my bad English...
<acarpine> raof: what do you mean with drop the debian/changelog hunk ?
<kklimonda> Ampelbein: It'll give me some time to get a response from T dev about this issue, as I'd like to get his input on it - the %F did come from somewhere :)
<Ampelbein> kklimonda: sure, no problem. thanks again for the help with bzr, I think I understood that a bit better now.
<RAOF> acarpine: No, it's probably the specialised language that I'm using. :)
<RAOF> acarpine: So, a âhunkâ is the name for one piece of the patch; your patch has 3 hunks - one for the changelog, and one each for the 2 message typos.
<Ampelbein> kklimonda: probably from the time when transmission didn't know magnet? as for torrent files I think %f is ok.
<kklimonda> Ampelbein: no, %F has broken opening torrents directly from Firefox
<kklimonda> both worked fine in maverick, and broke in natty
<Ampelbein> kklimonda: oh, I used to save torrent files and open from download folder so I didn't run into that problem.
<RAOF> acarpine: And as for what I was saying there: In Ubuntu, we generally take the code that various different projects write - banshee, gnome-do, firefox, python-fstab, â¦, ensure that it integrates with the rest of Ubuntu, and add the bits of metadata that become a Debian package.
<RAOF> acarpine: Other distros do the same thing.  So to make your fix as useful as possible, it would be good to submit it to the python-fstab project - that way it'll be fixed in Ubuntu, and Debian, and Fedora, andâ¦
<RAOF> acarpine: And to do that, you'd want to make the same changes, but submit a merge to lp:python-fstab :)
<acarpine> raof: but why I should "drop my changelog hunk" I mean...when I submit a merge directly to lp:python-stab I don't need to edit the changelog?
<acarpine> ...I'm feeling like a babe at his first lesson...
<RAOF> acarpine: Ah!  Because lp:python-fstab won't *have* debian/changelog.  Because debian/changelog is a part of the metadata that goes into a Debian package, not a part of the upstream project.
<acarpine> raof: wow incredible...my question have some logic so :D
<RAOF> acarpine: Yeah, there's a whole specialised language to distro development.  It can be difficult to understand if you're unfamiliar wih it :)
<acarpine> raof: Ok, perfect so I can change my previous branch or I have to delete it to fix....
<RAOF> acarpine: To merge into lp:python-fstab you'll need to redo your branch, this time starting by âbzr branch lp:python-fstabâ and then making your changes.
<RAOF> acarpine: To re-target your existing branch at lp:~juliank/python-fstab/debian you won't need to do anything to your branch.
<acarpine> raof: ok I try, really tks raof
<RAOF> No problem!  Thanks for your work!
<kklimonda> Ampelbein: ticket got accepted, can you add a comment about %U?
<Ampelbein> kklimonda: done
<acarpine> raof: done
<acarpine> raof: I hope I did well...but i'm still not very self-confident (I have good reasons :)
<RAOF> acarpine: I'll take a look.
<acarpine> raof: using bzr branch lp:python-fstab instead my previous bzr branch lp:ubuntu/python-fstab downloaded a different sources.
<acarpine> Sources without the debian directory (I believe this explain your comment about the changelog...)
#ubuntu-motu 2011-03-01
<RAOF> Yeah.  lp:python-fstab will be just the code, not the debian packaging.
<acarpine> raof: In this way I cannot test the package with bzr bd -- -S ... and I cannot use debcommit
<acarpine> if i'm right debcommit makes some changes at changelog...so I imagine is for this that I cannot use it
<RAOF> That would be correct, yes.  You'll need to use plain âbzr commitâ.
<acarpine> i didn't use it...and when I push the code to my lp I get a warning message
<acarpine> *used
<RAOF> What's the warning message?
<acarpine> ...Uncommitted changes will not be pushed.
<acarpine> all the msg was "Working tree "/home/andrea/Ubuntu/bugsFixing/python-round2/python-fstab/" has uncommitted changes (See bzr status). Uncommitted changes will not be pushed."
<RAOF> Ah, right.
<acarpine> but bzr status show me that the script was modified
<RAOF> Yes, you'll need to use âbzr commitâ to commit those changes.  That's one of the things that debcommit does.
<RAOF> bzr status is showing you what's changed since the last commit, and bzr push only pushes commits.
<acarpine> Should add a link to my branch in the bug report?
<RAOF> If you want to.  It's not particularly important one way or the other.
<RAOF> If you âbzr commit --fixes=lp:$THE_BUG_NUMBERâ then launchpad will automatically link the branch.
<RAOF> Again, not particularly important one way or the other.
<ari-tczew> tumbleweed: I think tht
<ari-tczew> that at this moment easier is use syncpackage instead manually making request sync.
<Laney> why?
<ari-tczew> Laney: because that my opinion/.
* ari-tczew changed the topic of #ubuntu-motu to: Archive: feature freeze | Want to get involved with the MOTU? https://wiki.ubuntu.com/MOTU/Contributing | Sponsor queue: http://bit.ly/fz6AyQ | http://qa.ubuntuwire.com/ftbfs | http://people.canonical.com/~ubuntu-archive/NBS | http://qa.ubuntuwire.com/bugs/rcbugs/ | Congrats to new DMB members: Laney, maco | New MOTU: kklimonda
<wejaeger> Hey, anyone up for reviewing l2tp-ipsec-vpn? It's a little applet to configure and manage L2TP IPsec VPN connections. I've just uploaded a new candidate to fix all problems about which micahg and mok0 complained. http://revu.ubuntuwire.com/p/l2tp-ipsec-vpn
<nigelbabu> Rhonda: poke?
<dholbach> good morning
<Rhonda> nigelbabu: peek?
<nigelbabu> Rhonda: PM? :)
<Rhonda> Peter Moosleitners interessantes Magazin?
<nigelbabu> Rhonda: haha, Can I PM you?
<Rhonda> Sure
<tumbleweed> bdrung, geser: poke (re u-d-t launchpadlib 1.9 branch)
<c2tarun> Can anyone please tell me how to forward a patch to debian?
<tumbleweed> c2tarun: you could go to Rhonda's talk on the subject, tonight :)
<tumbleweed> c2tarun: submittodebian is a good start. Have you used Debian's BTS before?
<c2tarun> tumbleweed: nope, its my first time, I was about to upload a patch on bug 726405, artur wrote in comment to forward it to debian.
<ubottu> Launchpad bug 726405 in kbarcode (Ubuntu) "package kbarcode_2.0.7-3 failed to build from source" [Undecided,In progress] https://launchpad.net/bugs/726405
<tumbleweed> c2tarun: https://wiki.ubuntu.com/Debian/Bugs
<Rhonda> \o/
<c2tarun> tumbleweed: and what about the bug number I should include in closes (please look at the last comment)
<tumbleweed> c2tarun: I sometimes do that, but as long as the Debian bug is linked from the Ubuntu one, that should be enough
<Rhonda> c2tarun: You'll receive a notification of your submitted bugreport which gives you the number of the bug
<tumbleweed> c2tarun: whoah, that patch. Should you not be using -lkio instead of /usr/lib/libkio.so.4 (for example)
<c2tarun> tumbleweed: yup, i'll upload a new copy within few minutes, that includes -lkio
<tumbleweed> c2tarun: same for the others
<c2tarun> tumbleweed: but I dont know what to write in Bug-Debian tag in patch header.
<tumbleweed> oh, artur told you that
<Rhonda> Wasn't -lkio part of what ari suggested?
<tumbleweed> c2tarun: as Rhonda said, you'll get a- enmail
<c2tarun> tumbleweed: so it means that first I have to submit it to debian, than I'll get a bug number then I'll enclose that number and submit debdiff to LP?
<tumbleweed> c2tarun: sounds good
<wejaeger> Hey, anyone up for reviewing l2tp-ipsec-vpn? It's a little applet to configure and manage L2TP IPsec VPN connections. I've just uploaded a new candidate to fix all problems about which micahg and mok0 complained. http://revu.ubuntuwire.com/p/l2tp-ipsec-vpn
<c2tarun> tumbleweed: thanks :)
<Rhonda> c2tarun: also submit debdiff to the Debian bug, and tag it patch
<c2tarun> Rhonda: sure
<Rhonda> c2tarun: Please check wether there is a Debian bug about it already, so you don't open a duplicate.
<c2tarun> Rhonda: how to do that? googling?
<Rhonda> http://bugs.debian.org/packagename
<Rhonda> So http://bugs.debian.org/kbarcode in this case.
<Rhonda> Gladly there seem to be only 6 open bugs there currently, so it should be easy to check :)
<c2tarun> Rhonda: yup :) there is no FTBFS bug in there
<tumbleweed> c2tarun: for bonus points, usertag it no-add-needed http://wiki.debian.org/ToolChain/DSOLinking#Notresolvingsymbolsinindirectdependentsharedlibraries
<Rhonda> Don't overflow him with information which makes him explode. :)
<tumbleweed> heh
<c2tarun> tumbleweed: I read that page, BTWwhat do you mean by usertag?
<tumbleweed> c2tarun: The debian bug tracker has two types of tags, official tags, and usertags https://wiki.ubuntu.com/Debian/Usertagging
<Rhonda> sbeattie: Btw., this is totally strange. I have the patch file sitting properly in debian/patches, but dpkg-source -b doesn't like to pick it up. Do you know if there is some filename specific exclude or such anywhere?
<tumbleweed> submittodebian will usertag the bug, to say that the bug came from an Ubuntu developer
<tumbleweed> there's also a usertag for the kind of issue that you are fixing. Unfortunatly you can't easily set both while you are filing the bug
<tumbleweed> s/easily/at all/
<tumbleweed> c2tarun: so maybe ignore that bit for now :)
<Rhonda> I don't buy that "at all" :)
<tumbleweed> Rhonda: how do you set usertags for two different users during submission?
<Rhonda> Ah, different users? That wasn't clear to me, why are different users used?
<c2tarun> well what should I choose the severity?
<Rhonda> Leave it as normal, it doesn't FTBFS in Debian (yet)
<tumbleweed> Rhonda: submittodebian will usertag bugs to say they came from Ubuntu
<Laney> I thought that change did happen in Debian already
<tumbleweed> it's certainly been announced a couple of days ago
<c2tarun> What should I write in report? I never wrote one.
<tumbleweed> c2tarun: but yes, you shouldn't filea bug in debian saying a package FTBFSs, unless you've tried to build that package on Debian
<Rhonda> gnangnanga. sbeattie, I know why dpkg-source didn't pick up the patch. You named it gitolite-<comittish>.patch, and my -i.git does exclude that (otherwise it would pull in the .git directory itself too, which obviously fails)
<c2tarun> tumbleweed: then what should I write there "FTBFS in ubuntu or on natty machine"?
 * c2tarun I cannot try on debian, I dont have debian chroot
<tumbleweed> c2tarun: FTBFS with ld --no-copy-dt-needed-entries
<tumbleweed> and yes, say on Ubuntu natty
<c2tarun> tumbleweed: what should I write in report section and in the section that tell "In ubuntu, the attached patch was applied to achive the following:"
<c2tarun> I get this error while submitting to debian :( http://paste.ubuntu.com/573861/
<tumbleweed> c2tarun: I've checked. it does FTBFS in Debian, you can make the bug grave, if you want :) http://people.ubuntu.com/~stefanor/kbarcode_amd64_sid.log
<tumbleweed> c2tarun: you have an unconfigured postfix on your system
<c2tarun> tumbleweed: what do you mean by make the bug grave? :/
<tumbleweed> http://www.debian.org/Bugs/Developer#severities
<c2tarun> tumbleweed: well I am getting only four here, I'll choose important than
<tumbleweed> c2tarun: there should be a special category for FTBFS
<tumbleweed> the reason you are only seeing 4 is that reportbug has multiple modes. It defaults to "novice"
<c2tarun> tumbleweed: dont know :( I am getting only four and a message of saying something about novice mode
<c2tarun> tumbleweed: yup exactly
<tumbleweed> that protects you from doing things that would make people shout at you :)
<c2tarun> tumbleweed: ok, I am getting this error on my system as well as on chroot, how to configure postfix?
<tumbleweed> c2tarun: as to the sending issue, you could try putting "smtphost bugs-master.debian.org" in your .reportbug.conf, to totally bypass your local postfix
<c2tarun> where is this file .reportbug.conf? in home folder?
<tumbleweed> Rhonda: what do we normally recommend for people running into this?
<kklimonda> morning
<tumbleweed> c2tarun: yes
<tumbleweed> the reportbug.conf manpage says "smtphost localhost" will use an internal MTA. That might be a good option
<Rhonda> tumbleweed: Why to bypass the local postfix instead to configuring it?
<c2tarun> tumbleweed: I am installing sendmail right now. should I add "smtphost bugs-master.debian.org" in my .repor* file?
<Rhonda> please don't choose sendmail, for your own good!
<c2tarun> Rhonda: then what?
<Rhonda> What's wrong with your postfix?
<Rhonda> ssmtp is also a quite cheap option.
<Rhonda> ah, unconfigured.
<c2tarun> Rhonda: actually I am not familiar with any of it :(
<tumbleweed> Rhonda: the reason I didn't go into configuring it is that it may not be trivial
<Rhonda> It's a *lot* easier and a *lot* less painful to configure your postfix instead of sendmail, trust me. :)
<tumbleweed> many ISPs block outgoing SMTP, and many people block mail from DSL IP-ranges
<Rhonda> Anyway, using smtphost in ~/.reportbugrc is a very good choice.
<tumbleweed> c2tarun: if you know your ISPs SMTP relay, you should configure your postfix to mail out through that. You could also use gmail's SMTP service, etc.
<Rhonda> Personally I have configured my local postfix to use a smarthost with smtp authentication.
<Rhonda> That way it doesn't matter where I am, my mail always goes out properly. :)
<c2tarun> what just happened :( http://paste.ubuntu.com/573865/ I thought to give sendmail a try. What is Tarun <tarun@localhost6.localdomain6>
<tumbleweed> c2tarun: sendmail is horrible. Seriously, avoid it.
<Rhonda> c2tarun: check /etc/mailname and output of "hostname -f"
<tumbleweed> /usr/sbin/sendmail is not necessarily sendmail, though
<geser> tumbleweed: pong
<tumbleweed> geser: I followed your suggestions
<Rhonda> tumbleweed: Ah, for that part, set DEBEMAIL environment variable. :)
<c2tarun> Rhonda: output of hostname -f is tarun-kubuntu and there is no file with mailname in /etc
<c2tarun> I have DEBEMAIL env variable set. :/
<c2tarun> Rhonda: ^^
<c2tarun> Guys my laptop is about to discharge :( I'll come back when electricity will come , Sorry
<c2tarun> Rhonda: ping
<bdrung> c2tarun: where do you live?
<c2tarun> bdrung: India. Why?
<c2tarun> Can anyone help me in configuring postfix?
<bdrung> because i can imaging how it would be to have no stable electricity supply
<coolbhavi> bdrung: I am also from India :)
<c2tarun> bdrung: it feels awful :(
<bdrung> and solar energy is too expensive, right?
<c2tarun> need help with this error http://paste.ubuntu.com/573874/
<c2tarun> bdrung: yup.
<coolbhavi> bdrung: even battery backups come at quite a cost here
<bdrung> do you have laptops for this reason or a desktop with battery backup?
<coolbhavi> bdrung: I do have both but with only a 2 hr backup
<c2tarun> bdrung: laptops are portable :) and for students they are best
<acarpine> raof: I'm sorry...was sufficient look into the branch to see that nothing was committed
<tumbleweed> bdrung: something I changed in u-d-t is breaking pylint on natty
<acarpine> raof: Anyway the Julian's message says "This branch is abandoned. Debian does not have this package anymore, and I don't know what it's needed for in Ubuntu anymore."
<bdrung> tumbleweed: do you refer to http://launchpadlibrarian.net/65093854/buildlog_ubuntu-natty-i386.ubuntu-dev-tools_0.118~daily%2Bbzr1031~natty1_FAILEDTOBUILD.txt.gz ?
<tumbleweed> aah, I didn't see that
<tumbleweed> I only saw it locally
<tumbleweed> ok, good to know it wasn't a local change
<tumbleweed> anyway, I've let pylint skip if it fails, in the launchpadlib-1.9 branch
<c2tarun> tumbleweed: can you please help me in configuring postfix?
<acarpine> raof: I imagine you are in vacation now :)
<tumbleweed> I'm going to land the thing and upload if there are no nobjections. It's not tested as thoroughly as it could be, butit's better than the status quo
<tumbleweed> c2tarun: dpkg-reconfigure postfix
<bdrung> tumbleweed: let me have a look at it.
<tumbleweed> bdrung: thanks
<bdrung> tumbleweed: can you check if we need to bump the version of launchpadlib?
<tumbleweed> bdrung: it still works on my wheezy box
<tumbleweed> I've avoidid making changes that'll actually cause trouble with older launchpadlibs (such as passing the program's name to launchpadlib instead of "ubuntu-dev-tools" everywhere)
<c2tarun> tumbleweed: how can i check whether it is configured and configured correctly?
<tumbleweed> c2tarun: use the mail command to send yourself an e-mail
<tumbleweed> see if you get it
<acarpine> raof: Anyway I re-committed the changes and re-pushed the branch and now should be correct...
<acarpine> I am curious how this report should be handle now. I hope to see you tomorrow (in your next 8 hours :) )
<acarpine> tks for your help
<bdrung> tumbleweed: maybe we should adjust the name later, e.g. "ubuntu-dev-tools <program name>"
<tumbleweed> yeah, that's what I'm thinking
<c2tarun> tumbleweed: what network block should I give while configuring postfix?
<tumbleweed> c2tarun: you don't want other machines using your postfix, I suggest just 127.0.0.0/8
<c2tarun> tumbleweed: this is the default text in there 127.0.0.0/8 192.168.0.0/24 [::1]/128 [fe80::%eth1]/64___, should I change it to what you said?
<tumbleweed> leave it as is
<tumbleweed> oh, maybe remove the last one
<c2tarun> tumbleweed: by last one you mean from [::
<tumbleweed> [fe80::%eth1]/64___
<tumbleweed> oh, and 192.168.0.0/24
<tumbleweed> you only want 127.0.0.0/8 and [::1]/128
<tumbleweed> sorry, not paying enough attention :)
<c2tarun> tumbleweed: np :)
<wejaeger> Hey, anyone up for reviewing l2tp-ipsec-vpn? It's a little applet to configure and manage L2TP IPsec VPN connections. I've just uploaded a new candidate to fix all problems about which micahg and mok0 complained. http://revu.ubuntuwire.com/p/l2tp-ipsec-vpn
<c2tarun> don't know how but my terminal is using nano by default as text editor while submittodebian. How can I change it to vi?
<debfx> c2tarun: export EDITOR=vi
<c2tarun> I was trying to submit a patch to debian, when I was doing it few hours back there was no FTBFS bug listed there but now I am able to see this bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554936 its very old bug with FTBFS. What should I do now?
<Rhonda> c2tarun: Is it related, the same cause?
<c2tarun> Rhonda: don't think so, the error log is different than mine.
<Rhonda> Then that's fine. If it's different issues, seperate bugreports are absolutely fine.
<c2tarun> what is bin/dash?
<tumbleweed> c2tarun: a shell
<c2tarun> tumbleweed: I configured postfix properly and checked. still I am getting this at the end   "Tarun <tarun@localhost6.localdomain6>" why so?
<tumbleweed> c2tarun: you exported DEBEMAIL?
<tumbleweed> oh, postfix won't let you provide your own domain part, via /sbin/sendmail
<tumbleweed> smtphost 127.0.0.1 should get around that
<c2tarun> tumbleweed: shit, I exported that in chroot and I was on my system. :(
<tumbleweed> c2tarun: I recomennd putting DEBEMAIL in yoru .bashrc
<c2tarun> tumbleweed: done :) and submitted again,  waiting for email now.
<bdrung> tumbleweed: I: ubuntu-dev-tools: debian-news-entry-uses-asterisk
<bdrung> tumbleweed: bug 727127
<ubottu> Launchpad bug 727127 in pylint (Ubuntu) "pylint crashed with AttributeError in visit(): 'TreeRebuilder' object has no attribute 'visit_set'" [Undecided,New] https://launchpad.net/bugs/727127
<bdrung> tumbleweed: would it be useful to split the pylint call into separate calls for each script?
<tumbleweed> bdrung: aah, thanks
<tumbleweed> bdrung: splitting it would probably be very expensive. It's already very slow. It still works on sid, so I'm happy for now
<bdrung> k
<Rhonda> hah, bdrung. do you feel attached to audacious?
<bdrung> Rhonda: a little bit
<bdrung> why?
<Rhonda> If you join my session tonight you might pick up a todo list. ;)
<bdrung> Rhonda: why?
<bdrung> audacious is in sync with debian
<Rhonda> Just wait, I don't want you to destroy my examples. :P
<tumbleweed> bdrung: ok, I'll fix NEWS and upload
<bdrung> yes
<bdrung> tumbleweed: you forgot to tag the release
<tumbleweed> bdrung: just hadn't got there yet :)
<psusi> what is the difference between motu and "contributing developers"?
<Laney> MOTU can upload, UCD can not
<Rhonda> contributing developers need sponsors for uploads
<Laney> (at least, not from their UCD status)
<Rhonda> Laney: Are you around tonight? ;)
<psusi> hrm... so what's the difference between ucd and my current status ( just bugcontrol )?
<Laney> Rhonda: No sorry, I've got a meal for a friend's leaving
<Laney> Rhonda: is it your session? :-)
<Laney> psusi: UCD gives you Ubuntu membership
<psusi> because I get sponsorship for plenty of fixes now ;)
<psusi> ohh... so basically it means I get an @ubuntu.com email?
<Rhonda> And voting right, yes.
<Laney> !membership
<ubottu> Want to become an Ubuntu member? Look at https://wiki.ubuntu.com/Membership
<Rhonda> And possibility to add your blog to planet ubuntu
<Laney> that stuff
<psusi> I've been reading it, which is why I was a bit confused on what ucd is... last time I read this I don't think that was there, just motu... think I finally need to become a motu so reviewing the process
<maco> Laney: PPU get membership automatically, right?
<Rhonda> Yep
<Laney> PPUs get added to ubuntu-dev, which I think gives membership
<maco> ok
<psusi> PPU?  does that mean you can now get upload rights for a specific package in main without being a core developer?
<Rhonda> I think UCD is meant as intermediate state to give contributors sooner membership option and through that motivae them to contribute more. Something like that. :)
<Laney> It's about recognising that someone has made a âsignificant and sustainedâ contribution, and that their contributions are through development work.
<soren> psusi: That's been that case since PPU's came into existence.
<psusi> oh neat
<psusi> when did that get added?
<Rhonda> Actually I still need to apply for PPU for logcheck  %-)
 * Rhonda . o O ( and irssi )
<soren> psusi: As I said: That's been the case since PPU's were invented.
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek day 2 starting in 25 minutes in #ubuntu-classroom
<effie_jayx> tnanks dholbach
<dholbach> :-D
<psusi> ok, I think I did this right.. can I get a review? https://wiki.ubuntu.com/PhillipSusi/DeveloperApplication
<ari-tczew> psusi: are you a Debian Developer?
<sbeattie> Rhonda: doh, sorry about that.
<psusi> ari-tczew: nope
<ari-tczew> psusi: why are you going to join MOTU right now? what are your plans as MOTU?
<psusi> ari-tczew: well, like I mentioned in the app, I'd like to get the defrag package back into the archive, and of course, continue fixing bugs in other areas I usually work on
<ari-tczew> psusi: maybe PPU for particular packages is better way?
<Rhonda> sbeattie: Not your fault, but it took me a lot of thoughts and time to figure it out  %-)
<psusi> ari-tczew: well I was thinking of asking for a few PPUs on top of motu
<psusi> but figured I'd start with motu and see where we go from there
<ari-tczew> psusi: so please start work on MOTU stuff
<ari-tczew> psusi: are you familiar with merging with Debian?
<psusi> ari-tczew: I think so... these days it seems to be mostly down to a bzr merge from the debian branch right?
<ari-tczew> psusi: merging with Debian is usually by debdiffs, check merge-o-matic
<ari-tczew> !mom
<ubottu> MoM is the Ubuntu Merge-O-Matic, a website helping the MOTUs keep Ubuntu in sync with Debian. See  https://merges.ubuntu.com/
<Laney> you can merge using the UDD bzr branches as well
<psusi> I thoguht that was the old way, and the new UDD way was with bzr merge?
<ari-tczew> psusi: it can be
<ari-tczew> as I wrote: usually
<psusi> ok... I like the new ways better ;)
<ari-tczew> psusi: don't you think that 8 uploads is too small to get full universe upload access?
<psusi> I didn't... I mean, I've been working on things for years now and am starting to feel confidant that I've got it down now after a number of successful sponsored uploads, so... figured the next step was motu
<chrisccoulson> well, it's not just about quantity. quality of work matters too, and you can't just assume quality if there is quantity
<Rhonda> ari-tczew: Don't you think that's something for the membership board to judge?
<ari-tczew> chrisccoulson: IMO quantity means the level of expierence.
<chrisccoulson> ari-tczew, not really
<Rhonda> Sheer quantity is a very back ruler
<Rhonda> ari-tczew: IMO it doesn't.
<ari-tczew> Rhonda: this is MOTU channel, psusi is asking here so I'm answering my opinion. can't I?
<chrisccoulson> if somebody does 100 very simple trivial merges, it does't demonstrate much experience
<cody-somerville> ari-tczew, They're just sharing their opinion too :)
<Rhonda> ari-tczew: Sure you can, but like said, the amount of uploads is just a number and doesn't say much.
<ari-tczew> ok last question.
<ari-tczew> psusi: are you Canonical employee?
<Rhonda> And if you like to book that rule of expressing opinions, so can others.
<psusi> ari-tczew: nope
<c2tarun> chrisccoulson: what kind of merges or fixes necessary for good experience?
<ari-tczew> oh! I'm suprised
<psusi> you are?
<ari-tczew> yes
<psusi> if I were, I'd be a core-devl wouldn't I? ;)
<chrisccoulson> not necessarily, i'm not a core-dev ;)
<psusi> though Keybuck did tell me I should apply once...
<ari-tczew> psusi: yes, Canonical staff like to join directly core-dev
<psusi> I'll get there eventually most likely
<chrisccoulson> ari-tczew, that's just not true i'm afraid
<ari-tczew> psusi: well, I've been disagreed here. Let's complete endorsements from your sponsors.
<chrisccoulson> canonical employees go through the same process as everybody else
<ari-tczew> (on wiki page)
<Rhonda> Sure, but just because they go through the same process doesn't mean that they can't apply directly to core-dev :)
<psusi> so the page is complete and correct so far?
<chrisccoulson> indeed :) but the same also applies to people who aren't employed by canonical ;)
<Rhonda> It's all a matter of the quality and visibility of the contributions, not the quantity.
<ari-tczew> psusi: Things I could do better and Plans for the future are empty
<Rhonda> I have no number at hands of how few sync requests I did send before I applied for MOTU, but I doubt that they were very many.
<ari-tczew> psusi: and of course there is not any endorse, you have to ask your sponsors
<psusi> right... that's next step
<Laney> It's not surprising that people who work on main all day every day end up asking for upload rights to it...
<ari-tczew> Rhonda, chrisccoulson: well, I mean that if someone works often on bugs, there is no point to give full upload access
<ari-tczew> sorry, no often
<ari-tczew> rarely, I mean
<Rhonda> Actually, bugs have to get applied eventually. Having to look for sponsors all the time, when one fixes the bugs, can be quite tedious and depressing.#
<Rhonda> of course, the bug *fixes* have to get applied, not the bugs. %-)
<chrisccoulson> ari-tczew, i spend a lot of time on bugs, shouldn't i have upload access? :/
<ari-tczew> chrisccoulson: typo, I mean rarely working bugs, no often
<chrisccoulson> ah, ok. thanks for clarifying
<ari-tczew> np
<ari-tczew> Rhonda, chrisccoulson: don't you agree with my opinion?
<c2tarun> What kind of bugs are good to work on for good experience?
<psusi> I've been pretty happy lately with the new udd branch linking and merging, and patch pilot program... been getting sponsorship quickly and easily.
<psusi> been such a smooth process I figure I must be doing it right ;)
<ari-tczew> c2tarun: it's not straightforward to tell what you should do to get expierence. every person is another.
<Rhonda> ari-tczew, usually not. Where did you pick up that "rarely" from?
<psusi> used to be a pita though...
<Rhonda> ari-tczew: And if your opinion is the one of quantity over quality, I couldn't disagree any stronger with.
<ari-tczew> Rhonda: https://launchpad.net/~psusi/+uploaded-packages
<ari-tczew> Rhonda: uploads twice a year
<ari-tczew> does it need to get upload access?
<Rhonda> Depends, and again (for the last time) not judgable only by that quantity marks.
<Rhonda> Please try to be less demotivating.
<psusi> hrm... I don't think that list is complete...
<ari-tczew> Rhonda: I'm not going to demotivate.
<ari-tczew> Rhonda: psusi asked for feedback, he got it.
<Rhonda> That might very well be, but you come across like that.
<cody-somerville> ari-tczew, add smiley faces to your messages. :)
<MTecknology> Ampelbein: I'm trying ot have the packaging remove /etc/logrotate.d/nginx-{full,light,extras}. Things install fine; but the file doesn't go away. Packaging that I'm testing with.. http://tinyurl.com/ngx-pkg-testing
<ari-tczew> Rhonda: sorry, I won't lie.
<cody-somerville> ari-tczew, I don't think Rhonda was asking you to. :)
<Rhonda> Noone ask that.
<ari-tczew> Rhonda: go send message to community council that I say my opinion, because it's demotivating!
<mr_pouit> sigh
<ari-tczew> sorry, simple joke
<cody-somerville> ari-tczew, Not funny.
<cody-somerville> ari-tczew, :(
<psusi> yea, there's definitely a few kernel patches missing from that list
<Rhonda> I wonder how you come down that road, and if you like to wave that flag around all the time, it isn't helping you in any way.
<ari-tczew> Rhonda: I don't care.
<ari-tczew>  I won't lie to keep CoC.
<c2tarun> can anyone please help me with this error. http://paste.ubuntu.com/574005/
<Rhonda> Again, noone asks you to lie. All that is asked to be less demotivating and more encouraging to others.
<ari-tczew> Rhonda: OK I'll do it just for YOU!
<ari-tczew> psusi: It's very very great that you are involved with making Ubuntu better!
<Ampelbein> MTecknology: I'll have a look now.
<ari-tczew> psusi: However, I guess it's too early to get full upload access for universe.
<ari-tczew> psusi: I encourage you to do something else for universe.
<psusi> such as?
<cody-somerville> ari-tczew, I'm not sure if you're being sarcastic but that approach is much better! +1 :)
<Rhonda> ari-tczew: You shouldn't do it for me, you should do it for yourself and for the community.
<debfx> c2tarun: the lib order is wrong, -latom4 and -lxatom4 have to be the first libraries
<ari-tczew> psusi: https://wiki.ubuntu.com/MOTU#MOTU%20Processes
<debfx> c2tarun: like that: ... -L/usr/X11R6/lib -latom4 -lxatom4 -lt++ -lpanel -lncurses -lX11 -lXpm
<MTecknology> Ampelbein: thanks; I'm really fumbling around
<c2tarun> debfx: ok, it worked. Can you please help me in finding the file in which I should make change in order to fix this bug? I tried but failed, there are no Makefiles here
<debfx> c2tarun: if you tell me which package it is :)
<c2tarun> debfx: sure :) its atom4
<psusi> I had done a merge of lvm2 but before it got reviewed and sponsored, someone else did the same... that was a hairy one...
<ari-tczew> debfx: how do you check which library is missing if got error undefined reference?
<debfx> ari-tczew: usually either ld tells you which library is missing or the order is wrong
<c2tarun> debfx: in one package it told that to add /usr/lib/libkio.so.4 , it worked but on adding lkio also it worked? what's the diff
<MTecknology> Ampelbein: to test.. I do this... debchroot sid sid; chroot sid; aptitude install nginx-full; echo "deb http://ppa.launchpad.net/nginx/package-testing/ubuntu lucid main" >> /etc/apt/sources.list; aptitude update; aptitude full-upgrade    That file 'should' be gone.
<debfx> c2tarun: in the file Construct you need to change this line: $LIBS     = "$PROGLIB $NCURSESLIB $X11LIB -latom4 -lxatom4";
<c2tarun> debfx: two questions, one I asked few seconds ago and other is how  you find this Construct file?
<debfx> c2tarun: you should use -lkio, it's more generic
<debfx> c2tarun: I've just searched for "x11" in the package files
<Ampelbein> MTecknology: yeah, I have a similar setup for testing.
<MTecknology> Ampelbein: the 0.8.54-3 in the last version is what's in sid right now
<MTecknology> Ampelbein: you see anything?
<Ampelbein> MTecknology: ok.. I don't know why, but putting 0.8.54-4 as version argument to dpkg-maint-helper works
<Ampelbein> MTecknology: but from the wording of the man page, it shouldn't
<Ampelbein> MTecknology: because -3 was the last version to ship that configfile
<Ampelbein> MTecknology: http://paste.ubuntu.com/574034/
<MTecknology> Ampelbein: it's that simple?...
<MTecknology> wow
<Ampelbein> MTecknology: apparently yes.
<MTecknology> I'll build and try it..
<MTecknology> Ampelbein: hm... it still exists for me..
<MTecknology> Ampelbein: http://dpaste.com/462477/
<MTecknology> Line 51 is where it should be moved..
<MTecknology> Ampelbein: what did you use as a base install?
<MTecknology> sid, 11.04, ?
<Ampelbein> MTecknology: I used a sid-pbuilder environment (pbuilder-dist sid login)
<MTecknology> Ampelbein: did you first install nginx; then do the upgrade to my packaged version?
<ari-tczew> Daviey: good point on kbarcode sponsorship
<Daviey> ari-tczew, But it's exploded in my face... :)
<MTecknology> Ampelbein: here's a pastebin of the whole process I took with the undesired result.. http://paste.ubuntu.com/574062/
<Daviey> ari-tczew, Someone beat me to uploading it by 10 mins... after i successfully dput'd, i pushed to lp:ubuntu/kbarcode... :/
<ari-tczew> Daviey: can't you just use dput?
<ari-tczew> branch should be imported automatically
<Daviey> ari-tczew, yes - but trying to maintain bzr history and get UDD ready :)
<Daviey> <-- food
<MTecknology> I wish I could just toss a simple 'rm /etc/logrotate.d/nginx-*' in nginx-common.postinst...
<MTecknology> I'm  starting to get very tempted to do that
<Ampelbein> MTecknology: I don't know why that worked for me and not for you. I'm out of ideas tbh
<MTecknology> Ampelbein: could you try doing the exact same thing that I did?
<Ampelbein> MTecknology: k
<Ampelbein> MTecknology: you could post do ubuntu-motu mailing list and ask for help or debian developer, if that doesn't work
<MTecknology> Ampelbein: I'll do that; my fiancee just got here so we're probably going to do some wedding stuff and then eat; I'll be back later
<MTecknology> Ampelbein: If you figure it out; I'll kiss you (or something equivalent); otherwise that shoulds like a really good idea that I didn't think of. :)
<MTecknology> the DD I've been talking to doesn't seem to know, but also doesn't seem to have the time to really look
<MTecknology> Thanks for all the help you're giving me too. :)
<ari-tczew> Daviey: heh, ogra was faster
<ogra> yeah
<ogra> we're just discussing the impact :)
<Daviey> :S
<ari-tczew> ogra: it's fantastic how Canonical staff fight for sponsorships!
<ogra> haha
<ogra> you didnt know we get a bonus of $1 for each upload ??
<ogra> *g*
<ari-tczew> ogra: I hear only about euro :D
<ogra> heh
<c2tarun> I am working on fixing ftbfs of a package, I need to make change in a file. but that package is not following any patching system. Can I just add 3.0 quilt or should I make change directly?
<ari-tczew> c2tarun: directly
<dajhorn> In an Ubuntu package, what is the right way for a script to test for a 32-bit environment at runtime?
<ogra> ari-tczew, bug 725933 looks fine to me (you were waiting for more info on it it seems, does it look sufficientto you ?)
<ubottu> Launchpad bug 725933 in ivtv-utils (Ubuntu) "Package ivtv-utils-1.4.1 failed to build from source" [Medium,Incomplete] https://launchpad.net/bugs/725933
<micahg> dajhorn: why are you doing that?
<dajhorn> micahg:  I'm working on the zfs-dkms package.  I need to create a /etc/grub.d/ stub that sets a kernel parameter if the host is 32-bit.
<dajhorn> micahg: I looked lsb_release and uname, but figured that there is an Ubuntu Way to check.
<micahg> dajhorn: well, there's dpkg --print-architecture
<dajhorn> micahg: Thanks.  That seems like a good way.
<micahg> dajhorn: there's dpkg-architecture -qDEB_HOST_ARCH_BITS, but I don't know how fragile it is
<dajhorn> micahg: That's even better.  (The problem is that vmem= must be increased on a 32 machine, even on a non-i386 arch.)
<ari-tczew> ogra: d/changelog has bug - should add LP: as well, and he didn't add DEP3 headers
<ogra> +  * debian/patches/04_fix_ftbfs_binutils-gold.dpatch
<ogra> +    - Fix FTBFS with binutils-gold. (Closes: #615989)
<ogra> thats not enough for you ?
<ogra> oh, heh
<ogra> closes a different bug, fun
<ari-tczew> ogra: bug is correct
<ari-tczew> debian bug 615989
<ubottu> Debian bug 615989 in ivtv-utils "ivtv-utils: Package failed to build from source on Ubuntu natty" [Normal,Open] http://bugs.debian.org/615989
<ari-tczew> ogra: online?
<ogra> yes
<ari-tczew> ogra: seems you have been disconnected.
<ari-tczew> ogra: about iv-tv, if you want, you can complete his debdiff and upload
<ari-tczew> ogra: just add (LP: #xxxx) as well and add Bug-Debian into patch
<ogra> well, i see he added headers to the diff
<ogra> is there a debian bug ? i dont see one linked
<ari-tczew> Fix FTBFS with binutils-gold. (LP: #725933, Closes: #615989)
<ari-tczew> use it
<ogra> oh, thats the debian one
<ogra> i was looking at the bug tasks
<ogra> right
<ari-tczew> yes he should add task on Debian as well
<ari-tczew> you can do it if you have time
<wejaeger> Hey, anyone up for reviewing l2tp-ipsec-vpn? It's a little applet to configure and manage L2TP IPsec VPN connections. I've just uploaded a new candidate to fix all problems about which micahg and mok0 complained. http://revu.ubuntuwire.com/p/l2tp-ipsec-vpn
<MTecknology> Ampelbein: What happened?
<Ampelbein> MTecknology: I can't reproduce my success on a totally clean environment
<mok0_> wejaeger: I'll take another look tomorrow
<wejaeger> mok0: great, thank you so much!
<xelister> hello
<xelister> is it easy to take say Ubuntu, and make a custom installation CD that executes as root some script at end of installation ?
<micahg> !support | xelister
<ubottu> xelister: The official ubuntu support channel is #ubuntu. Please be aware that this channel is for development only.
<xelister> micahg: this is development, not using
<xelister> is it not
<ari-tczew> micahg: not this time ;)
<micahg> ari-tczew: huh?  I stand by my comment
<micahg> either that or #ubuntu-installer
<xelister> hmm.. how to DEVELOP addition to the ubuntu installer, in a form of a script run at end
<xelister> sorry to interrupt all conversations here with my development question ;) if it was ot on this channel
<micahg> xelister: sorry, lots of things going on, #ubuntu-installer would probably be a better place to get an answer to your question, we mainly deal with universe packages here
<em> Do any of you know why Ubuntu would put untrusted packages in the Repo?
<ari-tczew> em: what do you mean by untrusted packages?
<cody-somerville> em, What do you mean?
<em> I just did: sudo aptitude install inkscape
<em> and I got the following warning:
<arand> em: Have you added a PPA?
<em> WARNING: untrusted versions of the following packages will be installed!
<cody-somerville> em, Can you pastebin the output of apt-cache policy inkscape?
<em> No I have not.
<em> okay
<em> cody-somerville: http://pastebin.com/FuQY2aZL
<em> These are the warnings it gave - http://pastebin.com/743emHBG
<cody-somerville> em, Can you pastebin the output of the following?: apt-cache policy python-renderpm
<em> http://pastebin.com/ckKnbqSZ <-- cody-somerville
<cody-somerville> em, Can you pastebin the output of sudo apt-key list?
<em> is any of this sensitive info?
<em> cody-somerville: ^
<kklimonda> no
<kklimonda> unless you have added some secret keys
<em> http://pastebin.com/EUDxuTif
<em> I have not
<em> cody-somerville: the apt-key list ^
<em> has anything been learned here?
<cody-somerville> em, try running sudo apt-get update and then try installing inkscape again.
<em> okay ive not installed it a first time because i chose "no"
<em> well that time it did not throw the warning.
<em> cody-somerville: what was the issue?
<cody-somerville> em, Not sure. Maybe the last time you did 'apt-get update' your mirror was in the process of updating or something?
<em> yeah im not sure
<seidos> are only canonical employees allowed to add packages to the distro release?
<maco> no
<maco> the ubuntu desktop team, kubuntu team, edubuntu team, etc decide what each of them will ship as default, usually at an Ubuntu Developer Summit
<maco> these occur May-ish and November-ish
<maco> and include community members as well
<lifeless> and many canonical staff that work on Ubuntu cannot add packages
<lifeless> they have to go through the same process everyone else does to earn that ability
<porthose> lifeless I beg to differ, not to pick on kate stewart, she is our new release manager, she is not a motu, she is not a core-dev but yet she is an archive admin or should I say thats what her launchpad page states https://launchpad.net/~kate.stewart.
<maco> archive admins don't change seeds though, do they?
<maco> just click the green button after a motu or core-dev uploads a new package
<lifeless> right
<lifeless> she can't sign an upload
<udienz> micahg, about gkamus, rpath has been fixed and re-uploaded again in revu
<micahg> udienz: I won't be able to look at it for a few days
<udienz> micahg, oh okay
#ubuntu-motu 2011-03-02
<micahg> hi espen77
<espen77> hi :)
<espen77> is there a command to make a diff between .orig.tar.gz and unpacked directory?
<micahg> so, you can create a new source build and debdiff the two, to create a new source build, you add a changelog entry (dch -i), and then create a source build (debuild -S)
<micahg> espen77: the sponsorship page I linked you to should I have a guide to debdiffing
<micahg> *have a link to a guide
<espen77> micahg: atleast google have
<micahg> espen77: https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff#Creating%20A%20Debdiff
<espen77> yeah, reading
<freakabcd> hi all.. i'm not really sure if this is the right place to ask, but i'll attempt anyway: is there a package for the openCV library ?
<freakabcd> https://launchpad.net/ubuntu/maverick/+source/opencv/2.1.0-2    <-- I found this. but its for a source package? and searching maverick repos there is a python-opencv and opencv-doc package.
<paultag> freakabcd: yeah :)
<paultag> freakabcd: I was using it the other day
<paultag> freakabcd: I can't reacall what it's called. I filed a bug with it up in debian. Let me look it up
<freakabcd> i'm trying hard to understand how the python-opencv package that provides py bindings to the lib) is supposed to without being able to install the library itself!
<paultag> oh you found it
<freakabcd> why does the package python-opencv exist? it seems to happily install itself without any dependencies, etc!
<paultag> freakabcd: the big ones: http://pastebin.com/u80TYmXM
<paultag> freakabcd: it sure does
<paultag> freakabcd: test it :)
<freakabcd> ewww.. why is it libcv instead of libopencv ?
<paultag> freakabcd: I have some example python-cv code on my blog: http://blog.pault.ag/post/1980116944/python-opencv
<paultag> beware that haarcascades issue I ran into
<freakabcd> paultag: err.. on that page you linked, there is no src code!
<freakabcd> or is it because noscript blocked it for me?
<paultag> freakabcd: yeah, let me get you the gist :)
<paultag> freakabcd: https://gist.github.com/603819
<freakabcd> lol indeed.. those should not be in the doc package
<freakabcd> so what exactly is lookatme.py doing? simply tracking the head?
<freakabcd> or heads
<paultag> freakabcd: right. I was just goofing around. Eventually I might use that for a display in my wall or something, turn on when you face it.
<paultag> freakabcd: Who knows, mirite?
<freakabcd> heh, but it immediately terminates on trying to run here :(         terminate called after throwing an instance of 'int' \n Aborted
<freakabcd> i will ask in #opencv
<paultag> freakabcd: sounds like you're missing the haarcascade stuff
<freakabcd> but i have installed opencv-doc
<paultag> freakabcd: check to make sure it exists. I had to take the files out of the sourceball and place it in the tree
<freakabcd> oh, you mean its gone to the wrong dir
<paultag> freakabcd: yeah, there was something dumb as hell about that package
<freakabcd> paultag: whats in /usr/share/opencv ?
<freakabcd> the haarcascades dir?
<freakabcd> for me thereis nothing in that dir except for a cmake file lol
<paultag> freakabcd: yeah, I think I had that issue too
<paultag> freakabcd: just copy in files where they should be from the source
<freakabcd> paultag: also do i need to gunzip the xml.gz files or can is work with the zipped ones?
<paultag> freakabcd: I think they need to be "real" xml
<freakabcd> paultag: did you happen to remove your installation or are you on a different machine now? easiest is to check /usr/share/opencv on your system
<paultag> freakabcd: I'm on a different machine -- I'm ssh'd in from work
<paultag> freakabcd: sorry :) -- I put a link in that bug report as to where that stuff should be
<freakabcd> so i can know the right path: i.e. /usr/share/opencv/haarcascades/*.xml or /usr/share/opencv/haarcascades/haarcascades/*.xml
<paultag> freakabcd: ah, sec
<freakabcd> yeah, but the non-unified diff hurts my eyes :D
<paultag> /usr/share/opencv/haarcascades/*.xml <-- freakabcd
<freakabcd> thanks
<paultag> freakabcd: righto
<freakabcd> right i wanted to do eye tracking and even lookatme.py seems not stable enough
<freakabcd> i wanted to finally have pointer follow eye on my laptop
<paultag> freakabcd: ah, haha. Good luck :)
<freakabcd> did you manage to do something like this? i see there are some software that allegedly do this
<paultag> freakabcd: you need a high framerate camera mounted close to the eye, so it can see your eye move, not where you eye is in relation to the screen
<paultag> or a high framerate, high quality camera that extracts where your eye is and uses that, but that seems hugely complex
<freakabcd> grrr.. and i thought one could do this sort of tracking with cheapass webcams
<paultag> :P
<paultag> anywho, I think we're a bit off topic :) -- freakabcd if you need any more help, the kind folks in #opencv, or I might be able to help (but I've not touched it in a while)
<psusi> slangasek, ping.  Remember the powernowd package you said I should get removed from the archive before invalidating its bugs?  well.. it's been removed ;)
<freakabcd> yeah, thanks. but someone needs to rename that package to be libopencv instead of libcv
<slangasek> psusi: ok, great :)
<paultag> freakabcd: why?
<psusi> slangasek, so now good to clear out the bugs?  I've been looking for a better way to do it this time... just tried using bughugger, but it apparently can't find the package now that it's been dropped
<paultag> freakabcd: we don't have un-open software in Debian main ;)
<slangasek> psusi: sure, by all means close them out now
<freakabcd> because everywhere it says opencv all websites were saying opencv
<psusi> slangasek, got any advice for how to do that batch style?
<paultag> freakabcd: file a bug :)
<freakabcd> and now if i had installed python-opencv, it installed without any deps
<psusi> last time I just did each one on the lp web site by hand....
<paultag> psusi: lplib not working for ya? ;)
<psusi> paultag, wassat?
<paultag> psusi: launchpadlib -- you know the python bindings to launchpad so you can batch operations (like, say, closing out a list of bugs)
<psusi> I was thinking of just using the email interface but that would still require me typing in each of the bug numbers ;)
<psusi> paultag, you mean roll my own python using the lib?  I have been learning python.... hrm...
<paultag> psusi: go for it, dude. Are you trying to close out all the bugs against a package or something?
<psusi> paultag, yea
<paultag> psusi: yeah, just use lplib to get a list of bugs, then change status to fix-released or invalid or whatever. Just be sure not to close valid bugs
<psusi> hrm....
<paultag> (tags might have done you some good)
<psusi> well, they are all getting closed since the package has been dropped
<paultag> psusi: lp should take care of that, yes?
<psusi> hrm.. I can't find lplib...
<psusi> paultag, doesn't look like it
<paultag> psusi: python-launchpadlib
<psusi> I can not figure this api out... lp.bugs[id] seems to get me a bug by id number, but I can't manage to search for distribution/package bugs
<paultag> psusi: feel free to jack code from: http://launchpad.net/locolint
<paultag> psusi: there's code in there that does some of what you need to do
<paultag> psusi: http://bazaar.launchpad.net/~ubuntu-lococouncil/locolint/trunk/view/head:/locolint/functions/pending-apps.py <-- that has the bug listing against a project
<MTecknology> Ampelbein: alrighty; thanks, I'll ask one more place and go to the mailing lists.
<psusi> why does launchpad.projects['powernowd'] not get me the powernowd project?
<paultag> psusi: https://launchpad.net/powernowd <-- because there's nothing with that name
<paultag> psusi: you'll be using ubuntu, then loading bugs against that package
<paultag> last I checked, anywho. I'm not handy with lplib
<paultag> psusi: if you need more help, #launchpad might be the right place
<paultag> psusi: ubuntu dev tools might help too
<psusi> slangasek, should they be invalid, or wontfix do you think?
<Ampelbein> psusi: if you want all bugs from a package, try something like lp.distributions['ubuntu'].getSourcePackage['name'].getBugTasks
<slangasek> psusi: I'd say 'invalid'
<c2tarun> Can anyone please help me with this error http://paste.ubuntu.com/574265/
<Ampelbein> c2tarun: looks like you are missing a build-dep
<c2tarun> Ampelbein: Can you please tell what is missing and how you figured it out? something related to Qt4 is missing but I am not able to get what to add in build-Depends
<Ampelbein> c2tarun: it complains about 'Qt qmake not found!' and the module is called (see line 5) findQt4
<Ampelbein> c2tarun: so you make 'apt-cache search qt4 qmake'
<Ampelbein> c2tarun: that would be my guess at least
<c2tarun> Ampelbein: on searching I got qt4-make is it this one?
<Ampelbein> c2tarun: I guess it is.
<c2tarun> Ampelbein: thanks :)
<c2tarun> Ampelbein: problem is still there. :( I installed qt4-qmake and added it to build-depends as well, again I am getting the same error. I checked manually file FindQt4.cmake is in the location required. its the message thrown by that file. its looking for something which is no found :(
<Ampelbein> c2tarun: then I don't know :-(
<MTecknology> Ampelbein: I'm still hoping to get a reply from the mailing list; because I'm utterly lost
<Ampelbein> MTecknology: I can understand that. I don't see a reason why it doesn't work, dpkg-maintscript-helper is there for exactly that case :-(
<MTecknology> Ampelbein: yup; and in your first try it actually worked; somehow
<MTecknology> I'm baffled
<Ampelbein> MTecknology: I think that was because I did multiple tries without going back to a "clear" state before each try
<MTecknology> oh
<MTecknology> so then the answer should probably be very very simple
<artfwo> is there any reason to use 3.0 source format for a new package, that has no patches yet?
<paultag> artfwo: no sense in using something old, since if you don't have source/format, lintian will whine
<paultag> artfwo: so why put anything besides it in there ;)
<artfwo> hmm, lintian had not warned me about it (on a maverick machine)
<paultag> artfwo: -IE --pedantic ?
<ScottK> paultag: missing source/format is a fairly pointless whine.
<paultag> I don't think it's E or W
<paultag> ScottK: aye
<paultag> ScottK: but it's also fixed without much work, so I hate seeing it :)
<ScottK> I hate wasting time on pointless things.
<ScottK> To each his own.
<artfwo> well, there might be a reason, besides the lintian whine (paultag, it showed up with -IE)
<paultag> artfwo: not really, narp.
<micahg> in this case, it can save oneself from accidental modifications to the build as debuild will say if there were changes to the orig files
<paultag> artfwo: unless you need multi .tar.gz, then you need 3.0 :)
<artfwo> oh, okay
<artfwo> thanks for the explanation
<artfwo> paultag: since you mentioned multi tar.gz I have another question :)
<paultag> artfwo: yis. forewarning, I'm not MOTU. Just a casual hacker up in debian.
<artfwo> I'm going to package a soundscape tool, called boodler (straight to debian, likely), and it has lots of tiny soundscape packages
<paultag> artfwo: sure
<artfwo> they're all distributed in separate files
<paultag> artfwo: it might be a pita to upload all those .tar.gz files, esp if one updates independent of the main package, you won't be able to upload it if it's part of the "master" source package
<artfwo> does it make sense to use multi tar.gz here, or is it better to pack them all in a handcreated .orig.tar.gz?
<paultag> artfwo: might be worth packaging each on their own
<paultag> but I don't know
<paultag> I'd ask a DD
<artfwo> there will be 54 packages then :)
<paultag> oh jesus
<paultag> might just need a -plugins package or something
<artfwo> I was thinking about -plugins package, but what approach to choose?
<paultag> artfwo: I don't know. I'd ask your friendly DD
<artfwo> okay :)
<paultag> :)
<Ampelbein> question: what is the general opinion about bugs like bug 572091? How should a debian package handle errors that are out of it's direct control?
<ubottu> Launchpad bug 572091 in festival (Ubuntu) "package festival (not installed) failed to install/upgrade: exit status 1 - useradd: cannot lock /etc/passwd; try again later." [Medium,Confirmed] https://launchpad.net/bugs/572091
<micahg> Ampelbein: I would think fail gracefully and don't leave the system in an unusable state
<Ampelbein> micahg: so you think, catch the error and give the user a "please run dpkg-reconfigure $package later"?
<ScottK> I think better to figure out why useradd failed.
<micahg> Ampelbein: idk, seems like dpkg already does that
 * micahg thinks ScottK's suggestion is good
<Ampelbein> ScottK: yes, in the case of useradd it's mostly a result of a stale *.lock file
<Ampelbein> at least that's what I found on the matter
<ScottK> Then running dpkg-reconfigure wouldn't help, would it?
<Ampelbein> ScottK: in that case not until the root cause is removed.
<ScottK> So I don't think that type of warning helps much.
<Ampelbein> what I'm trying to figure out is: should these report be treated as a bug in the package or a user configuration error?
<ScottK> I usually treat these things as configuration errors and convert them to questions.
<ScottK> But that's just me.
<ScottK> I think convert to question is way under utilized.
<micahg> ScottK: it's currently partially broken
<ScottK> micahg: What part of LP is not at least partially broken?
<Ampelbein> ScottK: good idea. I would have set to invalid and just put a information about how to fix in. But convert to question is good! thank you.
<micahg> ScottK: heh, I meant broke such that it's unusable for packages with large numbers of subscribers
<ScottK> micahg: It's not unique in that regard.
<c2tarun> can anyone please help me with this error http://paste.ubuntu.com/574265/
<lifeless> ScottK: :(
<lifeless> convert to question specifically is a disaster
<lifeless> its on our hit list to fix in the short term
<StevenK> ScottK: Could you go a few days without sticking the knife in and twisting?
<ScottK> lifeless: I think you've been doing great work to make things better over there.
<StevenK> lifeless: I want "Convert to forum post"
<ScottK> StevenK: It's been quite some time since I said anything bad a LP.  IIRC I even managed to refrain from comment when it was announced that U/I was going to be "imporoved" once again.
<lifeless> ScottK: thanks
<lifeless> we should have some new capacity in the next week-or-mumble
<lifeless> which will help
<lifeless> one of lps failings is success
<lifeless> StevenK: that could be nice
<artfwo> c2tarun: did you install qt4-qmake or specify it as build dependency?
<c2tarun> artfwo: yup, both
<artfwo> c2tarun: you need to make sure qmake is in your PATH
<artfwo> since it's install to /usr/share/qt4/bin/qmake
<c2tarun> artfwo: how can I check qmakes path?
<artfwo> perhaps you need to refresh your environment? (logout and login again)
<c2tarun> artfwo: how can i check qmake is in my PATH?
<artfwo> if it doesn't run, it isn't
<c2tarun> ok, than how can i include it in my path?
<artfwo> I think it's included by default
<artfwo> you just need to refresh your environment, like logging out and logging in again (read above)
<artfwo> I cannot guarantee it will work though, but it's worth a try
<c2tarun> artfwo: already did that
 * c2tarun I did it when you said. :( its not working
<artfwo> hmm
<artfwo> how did you remain online here then? :)
<artfwo> (just curiuous)
<c2tarun> artfwo: I am building it on chroot ;)
<c2tarun> artfwo: I exited from chroot and entered again
<artfwo> entering chroot does not reset your PATH, I recall
<artfwo> you have to run something like source /etc/profile
<c2tarun> artfwo: actually my home is not mounted on chroot's home. chroot have a separate home, so it will reset the path
<artfwo> I'd still run "source /etc/profile" after entering chroot to be sure
<c2tarun> artfwo: done :( same error.
<artfwo> do you have a QTDIR environment variable?
<c2tarun> artfwo: nope, what is it?
<artfwo> it's where Qt is installed. cmake normally looks for qmake under PATH and QTDIR
<artfwo> and I thought, these variables are updated automatically after installing appropriate dev-packages
<c2tarun> let me check
<c2tarun> artfwo: I dont have QTDIR set.
<c2tarun> artfwo: I looked into FindQt4.cmake file and found these lines throwing error http://paste.ubuntu.com/574298/ can it be of any help?
<artfwo> wow, that's an erroneous error message
<artfwo> it's thrown if QT4_INSTALLED_VERSION_TOO_NEW is true
<c2tarun> are you sure, I mean i think Qt4_FIND_VERSION_EXACT and QT4_INSTALLED_VERSION_TOO_NEW both should be true.
<artfwo> it evaluates the entire "Qt4_FIND_VERSION_EXACT and QT4_INSTALLED_VERSION_TOO_NEW" expression
<artfwo> anyway, the qmake-related error message is out of sense here
<c2tarun> artfwo: ya and with the AND in b/w both should be true then only we'll get the message
<artfwo> if it's not an arithmetical AND :)
<c2tarun> artfwo: oh.. :) sorry then
<artfwo> what package are you trying to fix?
<c2tarun> attica
<artfwo> the macports project had the same error I think, found by googling http://lists.macosforge.org/pipermail/macports-dev/2010-October/013025.html
 * c2tarun looking
<artfwo> but their fix looks non-revelant to us, I haven't investigated
<c2tarun> artfwo: yup, they fixed something in any Portfile
<c2tarun> do you know what a portgroup, that might be handy here.
<artfwo> that's their specific build system I think
<artfwo> but strangely, they fix it by switching some kind of build profile
<c2tarun> yup, somehow some kde 1.0 doesn't support qt4 :/
<artfwo> perhaps an environment check will do the trick?
<artfwo> something like setting your PATH to include /usr/lib/qt4/bin perhaps?
<artfwo> does the command qmake or qmake-qt4 run in your chroot?
<c2tarun> yup
<c2tarun> artfwo: http://paste.ubuntu.com/574306/
<artfwo> right
<artfwo> I cannot help you any further then, let's hope someone does :)
<c2tarun> ok, one last help please. /usr/lib* is not declared in my PATH var, can you please tell me how to set that
<micahg> this all doesn't sound right
<micahg> which package is this?
<c2tarun> attica
<micahg> c2tarun: you might want to ask in #kubuntu-devel if there are any tricks
<c2tarun> micahg: I asked there :) geeks might be sleeping right now ;)
 * micahg would hope there would be a cleaner way than setting LD_LIBRARY_PATH
<c2tarun> micahg: I tried on two different packages and got the same, may I'll wake for kubuntu-ninjas to wake up :) anyway, thanks for looking
<micahg> c2tarun: did you check the Debian svn repo to see if any fixes have been committed?
 * c2tarun checking
<c2tarun> well I looked into rmadison and debian is a version behind the version I am working on
<c2tarun> micahg: and there are not bug reports for this package :(
<micahg> c2tarun: yes, but a new version can be in the repo unreleased
<c2tarun> micahg: how to look into repo?
<micahg> there should be a link on packages.qa,debian.org/attica
<c2tarun> micahg: hey I think there is a patch, let me try
<micahg> c2tarun: make sure to give proper attribution to the patch author and source (DEP-3)
<c2tarun> micahg: umm.... I am familiar with DEP-3 but what do you mean by proper attribution?
<micahg> c2tarun: author and other headers
<micahg> !dep3 > c2tarun
<micahg> ah, you're familiar, sorry
<c2tarun> micahg: ok, I'll take care of dep3 headers :) and I'll show it here before any further steps, thank you
<c2tarun> micahg: that patch is already applied :(
<dholbach> good morning
<artfwo> I'd like to split a cdbs package in two by putting, say, hello-first.install and hello-dev.install in debian
<artfwo> hello-first.install contains a wildcard, like usr/bin/*
<artfwo> hello-dev.install contains usr/bin/devscript
<artfwo> devscript actually installs to both packages
<artfwo> is there an elegant solution to this problem?
<HPV> if i had a job paying more than $10/hr i would spend the money to hire another person to work on ubuntu
<HPV> k0p: if i had a job paying more than $10/hr i would spend 1/2 the money to hire another person to work on ubuntu
<tdelv> How come?
<HPV> what do you know?
<HPV> master-debator
<HPV> ?
<seidos> compassion -> buddha
<seidos> 1 xor 0?
<seidos> 1
<ari-tczew> tumbleweed: on branch https://code.launchpad.net/~stefanor/ubuntu/lucid/samba/ntlm-auth-623342/+merge/51560 in d/p/series is blank line before your patch, is it correct?
<tumbleweed> wow the sponsering queue is short! patch pilots ftw
<tumbleweed> ari-tczew: aah. I don't think blank lines matter, but I don't know why that blank line is there (I didn't add it)
<ari-tczew> yes, regards to pitti
<ari-tczew> tumbleweed: would be nice to keep short url, so Bug-Ubuntu: https://launchpad.net/bugs/623342
<ubottu> Ubuntu bug 623342 in samba (Ubuntu Maverick) "ntlm_auth returns invalid NT_KEY" [Low,In progress]
<ari-tczew> tumbleweed: does it really needed to have a link to bug in d/changelog entry if patch has got DEP3 headers?
<tumbleweed> ari-tczew: yeah I normally shorten URLs, doesn't matter, though
<tumbleweed> ari-tczew: that's how previous samba uploads had their changlog entries written. I didn't want to chagne the style
<ari-tczew> tumbleweed: ok gotcha. nice work!
<ari-tczew> bdrung: could you take tumbleweed's patches to sponsorship? then we could get less sponsors overview today
<bdrung> ari-tczew: which patches?
<ari-tczew> bdrung: samba SRUs
<tumbleweed> bdrung: I didn't spend any time actually understanding those patches (although they are quite small). Just grabbed from the samba bugtracker, and got our sysadmin to test my lucid proposed backage.
<Quintasan> dholbach: Is it okay to throw in daily builds of KDE as part of Project Lightning Talks?
<dholbach> Quintasan, sure - that'd be great
<Quintasan> awesome
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 3 starting in 25 minutes in #ubuntu-classroom
<acarpine> ready to go!
<acarpine> I'm working on the bug 639955 which describes two different error in two different packages (both are related to nvidia pkg)
<ubottu> Launchpad bug 639955 in Package Descriptions for Ubuntu "Typo in package description: Geforce should be GeForce" [Low,Triaged] https://launchpad.net/bugs/639955
<acarpine> Fixing the first error (in one of the pkg) editing the debian/changelog should I use the bug number (LP ...)
<acarpine> ?
<ari-tczew> acarpine: what's the question?
<adamhorden> Hi all, I am having a few issues with dependencies in my PPA, I am building packages for a cross compiler and binutils built successfully when I try to build gcc that depends on binutils I get Missing build dependencies: msp430-binutils (>= 2.21) but that exists in my ppa? any ideas? the binutils packages is called msp430-binutils - 2.21~git20110302r20110213-0ubuntu1~msp231~maverick
<acarpine> ari-tczew: ops I saw only now because i'm in #..classroom
<acarpine> the question: is it correct put the LP XXX voice in the changelog file also if my patch fix only one of the two errors?
<ari-tczew> acarpine: it depends, in general every error = another bug
<ari-tczew> if you mean two typos, please fix it in one place
<acarpine> ari-tczew: also if they are in two diff pkgs?
<ari-tczew> acarpine: then open task on two pkgs
<ari-tczew> acarpine: however, I think it should be fixed debian/upstream
<ari-tczew> upstream*
<ari-tczew> typos are not important, if it doesn't cause FTBFS or something
<acarpine> arii-tczew: So what do you think I should do?
<acarpine> arii-tczew: I know the typos are not important, but is useful for me to understand the process of packaging...
<acarpine> arii-tczew: that's why i'm choosing only easy bugs...
<psusi> should quilt patches be applied, or not in the bzr branch?
<psusi> seems to me like they should not be...
<tumbleweed> psusi: UDD branch?
<psusi> tumbleweed: yea
<tumbleweed> if the package uses sourec format 3.0 (quilt), the importer will import with patches applied
<psusi> hrm... why?
<tumbleweed> if the package uses quilt in rules, the importer will import with patches unapplied
<psusi> wait... what?
<tumbleweed> because dpkg-source -x applies patches
<psusi> right... so they will be applied when you build a package from the branch, so why should they already be applied in the branch?
<psusi> seems like that just complicates merging and reviewing changes
<tumbleweed> the importer takes uploads that aren't present in a branch, and adds them as new commits
<tumbleweed> that's how the UDD branches stay up to date
<psusi> right... and when it does so, it applies the packages in the process?
<psusi> s/packages/patches
<tumbleweed> yeah I'd personally prefer unapplied patches, but people who work on big packages seem to like patches applied, as it helps them to see the patched history
<psusi> it makes it harder to see the history since you have changes to the patch file, and to the rest of the sources
<tumbleweed> psusi: dpkg-source -x will apply patches for source format 3.0 (quilt) packages. That's part of the specification
<tumbleweed> (although you can tell it not to)
<psusi> and now you have to sort out what source change corresponds to what patch
<psusi> tumbleweed: and the auto importer uses that, and so as a result, auto imports with the patches applied?
<tumbleweed> yeah, as I said, I don't like applied patches. but they are a fact of life for most UDD branches
<tumbleweed> psusi: yes, so you should stick to the same standard already in the branch
<psusi> hrm... yea, I find them annoying and so am trying to figure out why they seem to be there, and whether I should add new patches applied or not
<psusi> they also enlarge the branch by adding duplicate files under .pc/
<tumbleweed> yup. Although only .pc/applied-patches needs to be in the branch
<psusi> which you have to remember to bzr add when you add a new patch
<psusi> ohh.. hrm...
<tumbleweed> well, you have to do that, whenever you use any VCS
<psusi> no... you have to bzr add debian/patches/foo only if you don't apply it... if you want it applied in the branch, then you also have to add the stuff that gets shoved into .pc/ when it's applied
<tumbleweed> IIRC you only need .pc/applied-patches
<psusi> hrm...
<bdrung> tumbleweed: can you incorporate the security update in your samba SRU fix branches?
<tumbleweed> bdrung: oh, whoops, sure
<bdrung> tumbleweed: debdiffs would be a bonus (smaller downloads for me)
<tumbleweed> bdrung: debdiffs posted. That security update made the bzr merge proposals hard to read, anyway.
<tumbleweed> bdrung: thanks
<bdrung> tumbleweed: the multicolumn footer on http://reports.qa.ubuntu.com/reports/sponsoring/ has a bug: "More sponsoring stats" is in the "Package Sets" column
<bdrung> tumbleweed: yw
<tumbleweed> bdrung: aah, that should be easy
 * tumbleweed likse style changes that don't involve a 10 minute test-turnaround
<bdrung> tumbleweed: the sponsor-overview needs only 4m22.899s for the short list
<tumbleweed> heh
<bdrung> tumbleweed: i am interested how long it takes for an empty queue
<tumbleweed> there are almost certainly optimisation-possibilities in it
<ari-tczew> what do you think about remove package from universe which has been removed from Debian as well?
<bdrung> tumbleweed: thanks for fixing sponsoring.css. can you poke dholbach to pull it?
<ari-tczew> !package  xsmbrowser
<tumbleweed> ari-tczew: that's almost always a good idea.
<tumbleweed> but the archive admins should do it themselves, most of the time
<ari-tczew> tumbleweed: ok, will file a bug.
<tumbleweed> (i.e. if there isn't a build-failure / urgent issue, don't worry)
<bdrung> ari-tczew: check the removal reason in debian.
<bdrung> in most cases it's a good idea, but in some cases not (e.g. package still works and has a few user)
<tumbleweed> bdrung: sure
<bdrung> barry: re bug #727988 - -dev packages shouldn't contain .la files any more.
<ubottu> Launchpad bug 727988 in gpgme1.0 (Ubuntu) "/usr/lib/libgpgme.la has broken dependency_libs entry" [Undecided,New] https://launchpad.net/bugs/727988
<ari-tczew> bdrung: RM: xsmbrowser -- RoQA; dead upstream, orphaned, better alternatives
<ScottK> ari-tczew: The package will have to be supported in Lucid longer than Natty, so there's no rush.  There is a semi-automatic process for Ubuntu following Debian removals.  My recommendation would be just to let that handle these kinds of things.
<ari-tczew> ScottK: so don't tuch?
<ari-tczew> touch *
 * micahg hadn't seen much of the semi-automatic removals happening lately
<ari-tczew> oh
<ScottK> It's not wrong to suggest removal in such cases, but there's not a lot of benefit to it.
<barry> bdrung: can you do a no-change upload to at least get the reference correct now, and i'll file a bug on the package to get the .la out of there?
<barry> bdrung: bug 727988 is a blocker for a claws-mail bug i'd dearly love to get fixed (and will be pushing a branch for momentarily)
<ubottu> Launchpad bug 727988 in gpgme1.0 (Ubuntu) "/usr/lib/libgpgme.la has broken dependency_libs entry" [Undecided,In progress] https://launchpad.net/bugs/727988
<ScottK> barry: A better goal would be to get rid of the .la file in gpgme entirely.
<barry> ScottK: sure, but they don't have to be mutually exclusive ;).  i'm happy to file that bug next, work on a fix and even submittodebian
<barry> otherwise i guess i'll just run the fixed claws out of my ppa
<ScottK> No we should get the fix in the archive.
<bdrung> barry: i will do the no-change rebuild. what should be changed by it?
<bdrung> barry: done
<broder> bdrung: since you're looking, can i harass you to twiddle the ubiquity mp at the top of the queue?
<broder> (we're *so close* to emptying the queue that it just seems like a shame to not push through)
<acarpine> raof: are you here for your 8 hours :-) ?
<RAOF> acarpine: Ah, yes.
<acarpine> Good for me :-) Just a couple a questions
<barry> bdrung: thanks!  i will file that bug and work on a real fix -- after i push the claws fix
<acarpine> raof: I'm curious about how should be treated the bug 719379 after the comment in  https://code.launchpad.net/~acarpine/ubuntu/natty/python-fstab/fix-719379-round2/+merge/51661 which say that "Debian doesn't have the package anymore..."
<ubottu> Launchpad bug 719379 in python-fstab (Ubuntu) "Typos in Exception and docstring" [Undecided,Confirmed] https://launchpad.net/bugs/719379
<broder> ari-tczew: i'm a bit confused by your request to wrap-and-sort samba4 (lp:~jelmer/ubuntu/natty/samba4/various-fixes). does that really make sense for a package that we're merging from debian?
<ari-tczew> broder: I only suggested. I didn't demand.
<RAOF> acarpine: Yeah.  It turns out that nothing actually *uses* python-fstab (you can use âapt-cache rdepends python-fstabâ to check the list of things depending on python-fstab).  What we should probably do is check that it's removed in Debian, and why it hasn't been removed from Ubuntu yet, and then ask for it to be removed.
<broder> ari-tczew: but why suggest at all? from my perspective, it seems like it just introduces unnecessary skew
<bdrung> broder: i looked at it and it isn't ready yet
<ari-tczew> broder: so blame it
<acarpine> ok. My second question is about the fix (that I imagine now is no longer useful).
<acarpine> I saw that after I executed the bzr commit and I re-pushed the the changes to the same branch, the changes are now visible in my uploaded branch (the typos are fixed) but the comment about the number of different lines still says "0 lines".
<broder> bdrung: err, sorry - mark it as "work in progress" so it fall off the queue :)
<acarpine> raof: Is it only a missing update?
<ari-tczew> ScottK: around?
<ScottK> ari-tczew: Just barely.
<RAOF> acarpine: It sometimes takes a while for the merge proposals to update, yes.
<acarpine> raof: I pushed the branch yestarday...
<acarpine> raof: anyway thank you very much for all your advices! They were all very precious!
#ubuntu-motu 2011-03-03
<artfwo> is it allowed to package data files with CC-BY-NC-SA license or "free for non-commercial use" license?
<artfwo> I mean, is it accepted in Debian/Ubuntu archives?
<james_w> artfwo, only in non-free/multiverse
<artfwo> james_w: if I have a mix of public domain and non-free files, can I produce 2 packages - for universe and multiverse respectively from one source package?
<james_w> artfwo, should be possible, provided the source package is in multiverse
<broder> james_w: i know that packages split across main and universe have their source package in main. can you split "up" like that?
<micahg> broder: that's more of a closure issue than anything else
<micahg> I think
 * micahg retracts his comment
<MTecknology> So.. if I have a man page provided by package A and there is package A, B, and C provided by the packaging; what's the right way to tell dh_link to link the man page for those?
<MTecknology> they all need to provide the same man page; but the man page is exactly the same
<MTecknology> also; B and C depend on A
<RAOF> You mean - A ships a binary + a manpage for said binary.  That manpage also describes a binary found in B and C.  Yes?
<MTecknology> RAOF: exactly
<RAOF> So, I think you just want to add them to debian/packagename.links
<RAOF> As normal, a one-line per link, whitespace delimited $SRC $DEST file.
<MTecknology> but would would my source be?
<MTecknology> they'd be the same file; right?
<RAOF> No, because you've got different binaries in B and C?
<MTecknology> nope..
<RAOF> So their manpages need to be named different things?
<StevenK> If the binary has *exactly* the same name, you don't need a link
<RAOF> But if the binary has exactly the same name you have other problems, such as playing the Replaces game :)
<MTecknology> I'm guessing I can't just put the man page in each package and let them all install the same thing?
<RAOF> Does B conflict with A?
<RAOF> It sounds like it should, because it's got an identically-named binary?
<MTecknology> no
<MTecknology> B and C conflict; but i already dealt with that
<RAOF> So this is something like A=foo-common, B=foo-type-one C=foo-type-two?
<RAOF> Regardless of how this ends up, its likely that lintian will erroneously flag your binary as not having a manpage.  Feel free to override that warning.
<MTecknology> yup; that's what i have; only worded much nicer
 * RAOF heads out to exercise.
<broder> so if i take lp:~jelmer/ubuntu/natty/samba4/various-fixes, does anybody want to take lp:~w-shackleton/ubuntu/natty/x2vnc/x2vnc-fix-726783 ?
<MTecknology> lintian-override file... [<package>[ <type>]: ]<lintian-tag>[ [*]<lintian-info>[*]]. <package>  <-- does this mean that anything inside the brackets can be ignored?..
<MTecknology> I'm struggling with adding a lintian override... I can't figure out how to write the thing..
<MTecknology> nginx-full package does not have a binary; but binary is provided by nginx-common which is a required package
<broder> MTecknology: i...thought you could generally take the lintian output and paste it in directly
<MTecknology> I tried to add to debian/lintian-overrides      nginx-full binary: binary-without-manpage usr/sbin/nginx * Supplied by nginx-common package. * nginx-full
<MTecknology> broder: http://dpaste.com/467878/
<MTecknology> broder: should I paste in only "nginx-full: binary-without-manpage usr/sbin/nginx" ?
<broder> i think so. try it?
<MTecknology> alrighty
<MTecknology> now the long painful build time....
<MTecknology> the proc is good; but that's about it
<MTecknology> broder: that didn't work.. I put that exact line "nginx-full: binary-without-manpage usr/sbin/nginx" into debina/lintian-overrides
<broder> wouldn't you want debian/nginx-full.lintian-overrides?
<MTecknology> ther'es three of them; I thought I could do just one file to cover all three
<broder> i don't think it works like that
<MTecknology> I'll try with separate files tomorrow; it's getting really late here
<MTecknology> thanks for the help. :)
<broder> np
<dholbach> good morning
<tumbleweed> dholbach: morning. Care to bzr pull the sponsor queue?
<dholbach> tumbleweed, done - thanks for the fix
<tumbleweed> dholbach: just a minor tweak :)
<dholbach> :)
<om26er> Hi! how do I work on a package to gets its latest version in Ubuntu? I mean its simple to backport a patch what how do I work on a new upstream release?
<om26er> for example: telepathy-logger's launchpad maintanance branch is bzr branch lp:ubuntu/telepathy-logger now there is a new upstream release what do i do?
<om26er> should I make a diff between the above branch and the new release and apply it to the branch and commit?
<Laney> there is a command "bzr merge-upstream" that might do what you want
<Laney> I think that's the bzr-ish way of doing it...?
<Laney> om26er: you should probably coordinate in #ubuntu-desktop for that package (and look at merging in the packaging with Debian)
<Laney> alternatively (and preferably IMO) you can /do/ the upgrade in Debian and then merge/sync it back into Ubuntu
<om26er> thanks Laney i'll look into these options
<Laney> for debian you want #debian-gnome on irc.debian.org
<Laney> argh, he's gone (but I just noticed 0.2.4 is in NEW)
<james_w> broder, good point, maybe you can't do that
<c2tarun> can anyone please help me with this error http://paste.kde.org/6297/ error can be fixed by moving -lm and -lrt at the end. but when I am making this change to one of the Makefiles, on rebuild makefile is getting restored to its previous state.
<ari-tczew> c2tarun: maybe again debian-changes* is introduced? check debian/patches
<c2tarun> ari-tczew: there are no patches, infact package is not following any patching system
<c2tarun> ari-tczew: there was also a file Makefile.in in the same folder, I made change to that as well :) now buil successful ;)
<ari-tczew> c2tarun: congrats
<c2tarun> ari-tczew: I have a doubt, I thought that Makefile.in was created automatically during build by Makefile (or some other file) but here when I changed Makefile.in it worked. I was making same changes to Makefile.in of one other package ( dont remember may be chaplin) then it was not working, I had to make change to Makefile.am there.
<ari-tczew> c2tarun: sometimes it needs to get applied in these 2 both files.
<c2tarun> ari-tczew: ok
<bdmurray> hyperair: I'm a bit confused about how bug 725316 was hijacked.  Could you help me out?
<ubottu> Launchpad bug 725316 in banshee (Ubuntu) "banshee 1.9.4-1ubuntu1 crashes on now playing view with wikipedia plugin enabled (by default, main banshee package)" [High,Triaged] https://launchpad.net/bugs/725316
<hyperair> bdmurray: the description shows a BadMatch error returned by X.
<hyperair> bdmurray: christian was seeing a completely different bug involving missing dependencies
<bdmurray> hyperair: isn't christian the reporter of the bug?  when I think of hijacking I think of a person other than the reporter changing the bug
<hyperair> eh?
<kklimonda> ScottK: any idea why there is no libqwebkit.so provided by libqtwebkit4? Without it QtCreator doesn't display WebView widget
<kklimonda> (or rather qt designer)
<hyperair> bdmurray: ah hell
<hyperair> >_>
<hyperair> bdmurray: looks like i got it wrong
<ScottK> kklimonda: No.  I suspect debfx knows though.
<kklimonda> debfx: ^ ?
<kklimonda> oh well, you did ping him already :)
<bdmurray> hyperair: not a big deal.  In case you didn't know the firefox-lp-improvements extension identifies original reporter comments.
<hyperair> lp-improvements?
<hyperair> what's that?
<bdmurray> Its an extension of compiled greasemonkey scripts that add some functionality to launchpad
<bdmurray> https://edge.launchpad.net/~gm-dev-launchpad/+archive/ppa
<debfx> kklimonda: libqwebkit.so (without the "t")?
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 4 starting in 25 minutes in #ubuntu-classroom
<bdmurray> hyperair: and an example http://www.murraytwins.com/blog/?p=96
<hyperair> bdmurray: is there any reason we can't have this functionality added directly to launchpad?
<kklimonda> debfx: erm, libqwebview.so - it should go to /usr/share/qt4/plugins/designer according to some documentation I've found
<kklimonda> debfx: there is a bug about it on debian bts: http://bugs.debian.org/612974
<bdmurray> hyperair: because Launchpad development is hard?  More seriously though some things have been added to Launchpad and some are Ubuntu specific (showing team badges).
<hyperair> hm
<bdmurray> As an LP developer I'd think highlighting reporter comments makes sense.
<debfx> kklimonda: oh, that fell victim to the qtwebkit split which upstream doesn't really support
<ScottK> debfx: Can we fix it?
<kklimonda> debfx: is it fixable?
<ScottK> ;-)
<debfx> ScottK, kklimonda: we could copy the source code from qt4-x11 to qtwebkit-source and patch the build system
<ChogyDan> Is this normal?  Every time I use dch, it always applies maverick as the release when I'm working on a lucid package.  I thought it was supposed to match the release, ie apply lucid to a new entry when the previous is lucid
<ari-tczew> ChogyDan: it bases on system which you're running.
<ChogyDan> ari-tczew: :(  is there any way to get it to base on the previous instead?
<ari-tczew> ChogyDan: dch -i -D lucid ?
<ChogyDan> ari-tczew: yeah, fair enough, thanks!
<ari-tczew> ChogyDan: np
<kklimonda> debfx: bah, it does sound like quite a lot of work, on the other hand current situation is damn confusing.. I wonder if there are any other plugins that are missing because of that
<seidos> empathy is better than ex-chat right?
<ari-tczew> seidos: it depends on taste
<seidos> ari-tczew: motu?
<ari-tczew> seidos: me? yes. does it matter about your question whether motu or not?
<seidos> ari-tczew: yes
<seidos> until i get kicked, then no
<ari-tczew> seidos: are you going to ask everyone whether is he/she motu?
<seidos> if i got a job at ubuntu i'd give half my money to hire another
<Rhonda> ?
<seidos> question?
<Rhonda> I have a dejavu, someone said something similar just recently
<Rhonda> Are you HPV?
<Rhonda> ah :)  -!- HPV is now known as seidos
<Rhonda> Though, as generous as it sounds, at the same time I think it won't work. Either they are paying way too much to make that possible, or half the money won't be able to make a proper living
<seidos> i am not HPV, though i have it Rhonda
<seidos> do you have it?
<Rhonda> have what?
<seidos> Rhonda: who is "they"?
<seidos> HPV
<seidos> efficient speak, not double speak
<seidos> u got my back Rhonda ?
<seidos> go outside?
<seidos> walk around?
<Rhonda> Your nick was HPV before, that's what I meant.
<Rhonda> And they are canonical in that case.
<seidos> Rhonda: i just ran around the block, and in the driveway and lawn.  dog has no leash.
<ari-tczew> 11 entries in sponsors overview \o/
<seidos> right view, right intention, right speech, right action, right livelihood, right effort, right mindfulness, right concentration
<ari-tczew> seidos: right sentences on right channel ;)
<seidos> ari-tczew: trying to use empathy to join right channel
<seidos> ari-tczew: are you an op?
<seidos> an agent?
<ari-tczew> seidos: why empathy?
<ari-tczew> seidos: nope, ask persia
<ari-tczew> !op
<ubottu> Help! Hobbsee, Riddell, sladen, fbond, mneptok, gnomefreak, Seveas, dholbach, elkbuntu, PriceChild, or jpds!
<seidos> ari-tczew: part of the default packages
<seidos> ari-tczew: are you an agent?
<ari-tczew> seidos: agent? guess no
<seidos> ari-tczew: was that a command?
<maco> why do you need an op? whats the emergency?
<fbond> Odd, I should not be an op.
<ari-tczew> and persia should be IIRC
<seidos> maco: ask ari-tczew
<seidos> how's persia doing?
<micahg> maco: I think he did it by accident, but I think seidos is very close to needing to be kicked
<ari-tczew> :)
<seidos> ari-tczew: is persia doing alright?
<maco> havent seen persia in a bit
<ari-tczew> seidos: I don't understand.
<maco> still hasnt added me to the DMB mailing list
<seidos> ari-tczew: middle east revolution
<seidos> mah-co
<seidos> mama
<ari-tczew> seidos: are you drugged?
 * maco raises an eyebrow
<seidos> ari-tczew: negative
<ari-tczew> seidos: drunk?
<seidos> ari-tczew: define drug
<maco> are you here for constructive purposes?
<seidos> ari-tczew: define drunk
<ari-tczew> take less then
<seidos> maco: affirmative
<seidos> 1
<seidos> ari-tczew: less what?
<maco> please define
<seidos> brain chemicals?
<ari-tczew> seidos: alcohol
<seidos> ari-tczew: 0 alcohol
<ari-tczew> also brain chemicals
 * seidos dies
<seidos> 0 brain chemicals = death?
<seidos> yes
<ari-tczew> seidos: if you think you're OK, hit your head on the wall
<seidos> brain chemicals at nominal levels
<seidos> ari-tczew: once
<maco> seidos: what are the constructive purposes for your visit?
<seidos> ari-tczew: are you okay?
<ari-tczew> seidos: you can twice if you wish
<seidos> maco: metta
<seidos> ari-tczew: i do not
<ari-tczew> maco: he is looking for friends
 * micahg thinks its a bot
<maco> this channel is for development work
<maco> micahg: nah, too irregular
<seidos> cease suffering
<maco> seidos: take it elsewhere, please
<ari-tczew> micahg: nope, too inteligent
<seidos> what package are you working on maco ?
<seidos> upgrades
<seidos> what upgrades?
<seidos> to what packages?
<maco> at the moment, i'm not doing any packaging work. later this evening or tomorrow, qt/atspi
<seidos> it was more like a tap
<tsimpson> now back to the silence :)
<maco> tsimpson: too soon
<tsimpson> maco: see my 2nd +q
<maco> tsimpson: i thought the exact string had to match, so you would need more *s
<tsimpson> IPs look behind hosts and cloaks
<tsimpson> (except webchat cloaks, but that's because the IP would be for whatever server runs webchat)
<maco> oh ok
<maco> neat
<Rcart> I'm working in this bug 725217 (just some typos)
<ubottu> Launchpad bug 725217 in ubiquity-slideshow-ubuntu (Ubuntu) "Typos in Edubuntu 11.04 slideshow" [Undecided,New] https://launchpad.net/bugs/725217
<Rcart> but the patch in the bug report does not cover the typos in po/ files
<Rcart> So, I asked in -translators, with no response. I'd like to know if I need to patch the typos in po/ files too
<Rcart> ubiquity-slideshow-ubuntu is a native package and I'll apply a patch to it. Are there any recommendations or rules that differs from non-native packages while working on this kind of packages?
<Rcart> btw, I know that that d/source/format must be 3.0 (native)
#ubuntu-motu 2011-03-04
<Rcart> Ubuntu native packages are patchless? I get that from what-patch on ubiquity-slideshow-ubuntu, and no patch signs in debian/changelog
<psusi> Rcart, I would think so, since there is no upstream orig to patch
<Rcart> psusi: Maybe. I'll fix some typos in bug 725217
<ubottu> Launchpad bug 725217 in ubiquity-slideshow-ubuntu (Ubuntu) "Typos in Edubuntu 11.04 slideshow" [Undecided,New] https://launchpad.net/bugs/725217
<Rcart> psusi:  Would be enough to mention it in changelog, right?
<psusi> Rcart, enough what?
<Rcart> enough to mention that I fixed some typos
<lesliev> hi everyone! I just fixed a small crasher bug in a ruby program, part of the rbbr package.. is it best to try patch the ubuntu package or try to send the patch upstream?
<Rcart> lesliev: I would send it to Debian, I understand that is better to request a merge (:
<lesliev> Rcart, any hints on how to do that?
<lesliev> should I find a debian maintainers IRC channel? a forum? a website? I am not running Debian so I wouldn't be able to build a debdiff
<Rcart> lesliev:  file a bug in Launchpad, report it to Debian too (using submittodebian) and mention the LP bug, then you should add a bugwatch to the LP bug report
<lesliev> ok
<lesliev> kthxbai!
<highvoltage> hey Rcart
<Rcart> highvoltage: Hello.
<highvoltage> Rcart: I guess that's something we should handle as part of translations instead
<highvoltage> (referring to bug 725217)
<ubottu> Launchpad bug 725217 in ubiquity-slideshow-ubuntu (Ubuntu) "Typos in Edubuntu 11.04 slideshow" [Undecided,New] https://launchpad.net/bugs/725217
<Rcart> highvoltage: about ubiquity-slideshow-ubuntu ? If so, I asked (well, a contact did it for me) in -translators and there were no response
<Rcart> highvoltage: But I also think that it should be handled in tranlations team
<Rcart> highvoltage: I'll un-assign. Thanks for the comment.
<highvoltage> Rcart: you're welcome
<highvoltage> Rcart: there should be new slideshows soon though (at least for edubuntu)
<Rcart> highvoltage: Surely. There's something about it in the changelog
<c2tarun> How can I apply the debdiff uploaded on a bug and check whether its working or not?
<achiang> c2tarun: do you have more context around your question?
<achiang> c2tarun: without knowing more, i'd say: apt-get source <package> ; patch -p1 < debdiff.patch ; dpkg-buildpackage
<achiang> but that's very broad and handwavey
<c2tarun> achiang: suppose anyone worked on a bug and uploaded a debdiff b/w the source packages. And I want to check whether his debdiff is working or not?
<achiang> c2tarun: right, ok -- so get the current source package, and use patch(1) to apply the debdiff
<achiang> c2tarun: i mean, that's how i would do it. there are probably smarter ways
<c2tarun> achiang: well I dont know any way so any way is smart for me ;)
<achiang> c2tarun: a debdiff is just a normal patch, so you can use the patch command to apply it. 'man patch' for more details there
<c2tarun> achiang: what is num denotes here?
<c2tarun> I mean digit after p
<achiang> c2tarun: but again, in broad terms, you a) save the debdiff somewhere, say, foo.debdiff and then b) patch -p1 < foo.debdiff
<StevenK> c2tarun: The digit tells patch how many path elements to strip
<StevenK> -p0 means don't strip any, -p1 says drop the first
<achiang> c2tarun: there are several styles to generate a diff. some people generate from *within* the source tree, some generate from outside the source tree
<achiang> c2tarun: depending on *where* you generate the diff, you will have different paths to the filename you want to actually patch
<c2tarun> achiang: what do you mean by within or outside the source tree, normally .dsc are outside the source tree (I guess)
<achiang> c2tarun: so, as StevenK says, you use the -pN arg to strip out the paths you don't want, so that eventually, the paths match up
<achiang> c2tarun: here's a very short example: say my package is foo, and i am in: /home/achiang/Projects/foo/
<achiang> i want to modify bar.c
<achiang> so i say:
<achiang> cp bar.c bar.c.old
<achiang> # hack on bar.c
<achiang> diff -Nurp bar.c.old bar.c > my-lovely-patch
<achiang> that is what i mean by making a diff from *within* the source tree
<achiang> now contrast a different method:
<achiang> $ pwd
<achiang>  /home/achiang/Projects
<achiang> cp -a foo foo.old ; ls -F
<achiang> foo/ foo.old/
<achiang> same thing, hack on foo/bar.c
<achiang> now i can say:
<achiang> diff -Nurp foo.old/bar.c foo/bar.c > my-lovely-patch
<achiang> and that generates essentially the same diff, but the path on how you get to bar.c is slightly different
<achiang> so on the other end, when you want to apply the patch, you need to pass -pN appropriately, so that patch knows how to get to bar.c
<achiang> generally, debdiffs are more similar to the second method, so you typically just say -p1
<c2tarun> achiang: ok, got it :)
<c2tarun> achiang: thanks for the example :)
<achiang> anyway, hopefully that gives you enough of a conceptual understanding so you can figure out how to recover when a patch doesn't apply (when you think it should)
<achiang> the details are in the patch and diff man pages. :)
<c2tarun> achiang: sure thanks :)
<achiang> np
<c2tarun> can anyone please look at bug 728438 the patch seems to work fine for me but may not be working on sponsors system, What's wrong with the patch?
<ubottu> Launchpad bug 728438 in clips (Ubuntu) "Package clips 6.24-3 failed to build from source" [Undecided,Incomplete] https://launchpad.net/bugs/728438
<c2tarun> what does this mean in a Makefile LIBS=@LIBS@
<c2tarun> !makefile
<jmarsden> c2tarun: The make manual is online at http://www.gnu.org/software/make/manual/make.html
<c2tarun> jmarsden: I am reading that manual but stil didn't find anything about @ symbol. can you please help me a big
<c2tarun> big =bit
<jmarsden> Maybe... I'm bust doing something else here... and I am not a make expert at all.  I think the @something@ syntax is autotools more than Make... are you seeing that in a Makefile, or in Makefile.am or Makefile.in ?
<jmarsden> s/bust/busy/ :)
<c2tarun> jmarsden: Makefile.in
<jmarsden> Aha.  That is not a Makefile :)   You said: <c2tarun> what does this mean in a Makefile LIBS=@LIBS@
<c2tarun> jmarsden: but the changes I made in Makefile.in is getting reflected in Makefile, but when changing Makefile all the changes are reset on building
<jmarsden> Now you need to read the autotools docs... let me find a linke for that
<jmarsden> Yes, the Makefile.in is a template for a Makefile
<jmarsden> You need to understand autotools for the details...
<jmarsden> Autotolls Tutorial: http://markuskimius.wikidot.com/programming:tut:autotools/
<c2tarun> !autotools
<c2tarun> jmarsden: thanks :)
<jmarsden> The real autotools manual / book is elsewhere... one book is free online at http://sources.redhat.com/autobook/
<dholbach> good morning
<nonix4> Does it make sense to report usability bugs in undocumented parts of programs, or should the existence of undocumented features be reported as a bug instead?
<cgroza> Hello, I have a deb file of my program and I would like to submit it to Ubuntu. What do I have to do?
<cgroza> Anyone?
<Bachstelze> cgroza: for new packages, it's generally better to submit them to Debian
<Bachstelze> but you can always upload the source package somewhere and have someone look at it
<Bachstelze> I'd be surprised if your package was Debian Policy-compliant on the first try :)
<cgroza> I may need more info
<cgroza> how do i get it to debian?
<c2tarun> Can anyone please take a look at this debdiff. http://paste.kde.org/6451/ I just added one library to Makefile.in and I got this debdiff so long
<ari-tczew> c2tarun: is there any patch system?
<Bachstelze> c2tarun: Â²why did you not add -lX11 to LIBS?
<c2tarun> ari-tczew: no there is no patch system
<c2tarun> Bachstelze: because I found a line LIBS=@LIBS@ I dont understand it, I tried to read few manuals but still didn't got it. so I added directly.
<Bachstelze> cgroza: http://wiki.debian.org/Maintainers
<cgroza> ok
<cgroza> thank you
<ari-tczew> c2tarun: LIBS=@LIBS@ -lX11
<c2tarun> ari-tczew: oh.... I'll try that. but what is meaning of @ symbol in Makefiles?
<Bachstelze> as you were told already, it's not a Makefile thing
<Bachstelze> it's used by autotools
<c2tarun> Bachstelze: ok, its used by autotools, but autotools use Makefile.in as a template to generate Makefile. I guess Makefile.in is written by user. I found @ symbol in Makefile.in.
<c2tarun> ari-tczew: after adding -lX11 to LIBS I am getting the same length debdiff.
<ari-tczew> c2tarun: so clean up it manualy
<Bachstelze> c2tarun:
<Bachstelze> oops
<Bachstelze> mMakefile.in is generated by automake, not written by the user
<c2tarun> ari-tczew: there is one more prob, when I tried to apply this debdiff to a fresh new copy it is detecting some previously applied patch, but I dont see any patch in there, though in diff.gz file there are some changes.
<c2tarun> Bachstelze: still I failed to find the meaning of @ symbol :( can you please tell me.
<c2tarun> ari-tczew: I dont understand what do you mean by cleaning manually, do I delete the lines I dont understand why there are there?
<ari-tczew> c2tarun: probably changes during build
<ari-tczew> c2tarun: keep only that you did on package
<Bachstelze> c2tarun: it's really just variable subsitution, @var@ in Makefile.in means that @var@ is rerplaced by the value of var in the written Makefile
<c2tarun> Bachstelze: oh... just that :) and I find some more symbols in there like $^ and $@ what are they?
<Bachstelze> you mean $< ?
<Bachstelze> those are make special variables
<Bachstelze> $@ means the name of the target, $< means the name of the first dependency
<Bachstelze> there are more, they're all in the make manual
<c2tarun> Bachstelze: the one there on debian site :( that is 230 pages long manual
<Bachstelze> http://www.gnu.org/software/make/manual/make.html#Quick-Reference
<Bachstelze> I'm looking at the pÃ¢ckage, you might need to add dh_autoreconf to your rules files
<c2tarun> Bachstelze: how to add it, I am reading the man page, there is not any thing about how to use, should I simply write it down in rules file?
<Bachstelze> Ino, never mind, dh_autoreconf is if you modify configure.in
<Bachstelze> which is a bit cleaner than modifying Makefile.in, but I guess Makefile.in will do
<c2tarun> Bachstelze: on modification of makefile.in I am getting fairly huge debdiff and on applying also I am getting reverse patch detected. wait let me show you the debdiff
<Bachstelze> you did already ;)
<ari-tczew> tumbleweed: around?
<c2tarun> Bachstelze: check this out http://paste.ubuntu.com/575467/
<tumbleweed> ari-tczew: hi
<ari-tczew> tumbleweed: hi. could you manage to create a script pull-snapshot-source?
<Bachstelze> c2tarun: then yes, it is actually A LOT cleaner to modify configure.in and use dh_autoreconf
<Bachstelze> c2tarun: just a sec, I'll do a debdiff and pastebin it so you cna see how it's done
<c2tarun> Bachstelze: sure :) thanks
<ari-tczew> tumbleweed, geser: I got this error while requesting sync: http://pastebin.ubuntu.com/575469/
<ari-tczew> does it need bugtracking?
<ari-tczew> btw. bug filled successful
<c2tarun> Bachstelze: ping
<tumbleweed> ari-tczew: oh, that should be easy, pull-debian-source already supports snapshot, I just need to make it take version numbers as well as release names
<Bachstelze> I get all the crud too, I guess autotools regenerates config.guess and config.sub anyway, it should still work if you ditch those changes from your debdiff
<Bachstelze> c2tarun: ^
<c2tarun> crud?
<c2tarun> Bachstelze: oh you mean you are getting almost same debdiff
<Bachstelze> yeah
<Bachstelze> I mean all the unrelated stuff
<c2tarun> Bachstelze: but after dropping those changes also on applyin it to fresh source code, I am getting some reverse patch error.
<c2tarun> Bachstelze: check this http://paste.kde.org/6452/
<kklimonda> james_w: what is the address of the page I can check branch import failers on? ubuntu:ruby1.8 branch is ancient
<tumbleweed> kklimonda: http://package-import.ubuntu.com/status/
<kklimonda> thanks
<james_w> thanks tumbleweed
<Bachstelze> c2tarun: actually, config.sub and config.guess are not regenerated by autotools, they are copied by debian/rules
<c2tarun> Bachstelze: so what should I do?
<c2tarun> Bachstelze: and copied by debian/rules means? rules file is common config.guess and .sub should also b common b/w older and newer version
<tumbleweed> c2tarun: read autotools-dev's README.Debian for a background on that situation (although IIRC the recommendations in there are outdated)
<Bachstelze> it means that debian/rules copies config.guess and config.sub from /usr/share/misc to the source dir
<c2tarun> Bachstelze: and why is only newer version of rules file doing that? I mean rules are common so it should have been copied in previous version as well, so why the difference?
<tumbleweed> (without having followed this whole discussion) easy recommendation is to just strip config.* out of the debdiff. If a package from debian doesn't clean properly, that's not necessarily something we have to fix
<c2tarun> tumbleweed: I tried that, but on applying it to fresh copy of source code I am getting this error http://paste.kde.org/6452/
<tumbleweed> c2tarun: that means Makefile.in is already patched
<tumbleweed> are you sure it was fresh?
<tarun> tumbleweed: sorry I got disconnected,
<ari-tczew> tumbleweed: really? pull-debian-source supports snapshot.debian.org already? how?
<tumbleweed> ari-tczew: if it can't find the version you want from lp, or a mirror, or the master, it'll go to snapshot.debian.org
<tumbleweed> but you can only request releases, not versions
<tumbleweed> so I just have to add a way for the suer to request a version
<tumbleweed> ari-tczew: look at pull-debian-debdiff, that'll almost always use snapshot.debian.org
<ari-tczew> tumbleweed: I imagine that scripts as: $ pull-snapshot-source package version
<tumbleweed> ari-tczew: yeah, that's what I intend to do, if version doesn't match a known release name
<ari-tczew> aha
<Bachstelze> c2tarun: http://paste.ubuntu.com/575486/ this debdiff works fine here
<Bachstelze> the new config.guess and config.sub will still appear in the .diff.gz when you build the source package, but nothing you can do about it
<ari-tczew> tumbleweed: did you see my traceback from requestsync? I posted it here some minutes ago.
 * tumbleweed reads back
<tumbleweed> hmm, I've had similar issues, goes off to poke #launchpad peopel
<Bachstelze> woops typo, -lXII...
<c2tarun> Bachstelze: yup :) fixed that and it applied :)
<Bachstelze> also, the old debian/rules was doing that as well
<Bachstelze> what you're seeing is the difference betwwen config.guess and config.sub now, and as they were the last time the package was built
<Bachstelze> which was a long time ago, if you read debian/changelog
<kklimonda> hmm.. when I work on a package update using UDD, should I unapply all patches before merging new upstream version?
<kklimonda> if I don't do that I can't figure out how to deal with patches that don't unapply cleanly.
<plainas> heya
<plainas> so i have a debian folder in my python project with my control file, rules, etc.... is it possible to set the application to run at startup?
<tumbleweed> kklimonda: you are using merge-upstream, right?
<kklimonda> tumbleweed: yes
<tumbleweed> kklimonda: I can't remember how I've dealt with this before, but I can't see how unapplying all patches before merging would help
<tumbleweed> unless you commit the patch reversal
<kklimonda> tumbleweed: yeah, I'd probably try doing something like that and it wouldn't be nice.
<tumbleweed> aah, so, IIRC, after you've merge-upstream-ed, it leavs you with the debuntu-modifications, uncommitted
<tumbleweed> so you can bzr revert all the upstream stuff, get the quilt patches to apply, apply them, commit
<Laney> what's the point of the revert?
<tumbleweed> so you don't have to deal with the conflict,s and fix the patches twice
<tumbleweed> (once in the applied versions, once in the patches)
<Laney> I thought it would be; quilt pop; merge-upstream; quilt push (and fix conflicts); commit
<tumbleweed> Laney: merge-upstream operates on the branch (things that have been committed), not yoru workdir
<Laney> oh ok, that is uncool
<tumbleweed> but I'm talking from memory, I haven't had to do this in a while
<tumbleweed> of course quilt-as-loom will get around all this when that happens :)
<Laney> I just avoid 3.0 (quilt)
<Laney> or use unapply-patches
<Laney> http://raphaelhertzog.com/2010/11/18/4-tips-to-maintain-a-3-0-quilt-debian-source-package-in-a-vcs/
<tumbleweed> if you are working on random universe packages in UDD, yo udon't really get that choice.
<kklimonda> this list is great if you maintain package.. right
<kklimonda> and we keep .pc in bzr
<tumbleweed> yeah, I really hate that
<kklimonda> except when we don't
<tumbleweed> heh
<tumbleweed> we do with 3.0 (quilt), we don't with 1.0 + quilt
<kklimonda> I've worked with transmission packaging in git (that's how debian maintainer keeps it) and it makes much more sense
<kklimonda> it's not as magical
<kklimonda> but feels more solid
<tumbleweed> I think patches-applied makes sense when you are maintaining your package in git, and pulling from upstream's git, less so for most MOTU tasks
<psusi> if you are doing that though, why bother using quilt at all?
<kklimonda> I wonder about that myself
 * tumbleweed doesn't have any packages like that, I'm hypothesising :) But people in situation slike that seem to be proponents of patches-applied, and it vaguely makes sense
<psusi> seems like if you are going to track the packages with quilt then track them with quilt ( and leave them unapplied in the archive )... if you are going to track with git or bzr, then track changes with that and don't bother with quilt
<kklimonda> isn't it why 3.0 (git) format has been created?
<kklimonda> is it used by any package?
<tumbleweed> kklimonda: it was NACKed by the ftp-masters
<kklimonda> tumbleweed: no wonder I've heard no news about it - do you remember the reason? or link?
<psusi> all I know is that it makes the vcs change log look like a mess when you have changes both to the original source, and bundled as a diff in patches/ and has got to be a needless duplication of effort...
<kklimonda> I've had the dream where every distribution, and every project switches to git and we can just do it all in git.. ;)
<psusi> hehehe, amen ;)
<tumbleweed> kklimonda: lists.debian.org/87wrrxhlr7.fsf@windlord.stanford.edu
<kklimonda> thanks
<c2tarun> Is anything wrong with debian bugtracker? I submitted two bugs (one at least half an hour ago) and I didn't got any mail for the bug number.
<hakermania> micahg: Hello :) What's going on with Wallch, buddy :) ?
<micahg> hakermania: sorry, it's been a busy week, will try to take a look over the weekend
<tumbleweed> c2tarun: you sure you sent it from the right address? Did the bug get filed (can you see it on the web interface, under the package you filed it against?)
<c2tarun> tumbleweed: I filed few more by same method. let me check on debian page
<tumbleweed> also, I think the BTS does greylisting, so it may take a while before the message is accepted...
<c2tarun> tumbleweed: sure I'll wait :)
<dholbach> Last day of https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in 15 minutes in #ubuntu-classroom
<hakermania> micahg: OK, no problem :) Take your time!
<kklimonda> dholbach: any chance you could add me to ubuntu-sponsors?
<dholbach> kklimonda, sure, just a sec
<dholbach> kklimonda, done
<kklimonda> thanks
<debfx> kklimonda: the qwebview designer plugin is going to return soon :)
<kklimonda> debfx: awesome :)
<MTecknology> If something was originally GNU GPLv2 and a fork was made from it; can the fork be DEP-5 ?
<micahg> MTecknology: DEP-5 is a documentation standard, not a license
<MTecknology> or is DEP-5 not a license: I've never seen it before so I'm kind of confused
<MTecknology> oh..
<MTecknology> micahg: thanks :)
<geser> ari-tczew: re your requestsync crash: does it happen every time? (I didn't had any sync request to file in the recent past so didn't use requestsync recently)
<ari-tczew> geser: I got it once and dunno whether it happens every time - no point to use requestsync anymore ATM. Problem has been resolved. More questions, ask tumbleweed.
<tumbleweed> geser: yes, it would happen every time, it was due to a stale WADL cache
 * micahg is still using requestsync 
<geser> tumbleweed: is this a problem of requestsync and should it do something about it?
<tumbleweed> geser: it's a problem with launchpadlib, they are aware of the issue
<tumbleweed> (well there's an open bug)
<kklimonda> is ther use of syncpackage still discouraged by archive admins?
<micahg> also fails on maverick backport, so if there are minimum version requirements, they should be specified
<tumbleweed> micahg: what fails, and how?
<ari-tczew> micahg: I mean that I don't have a demand to use requestsync. It doesn't mean that I don't request syncs anymore.
 * micahg upgrades again so it can fail
<tumbleweed> kklimonda: yes
<tumbleweed> geser: for the record, bug 714621
<ubottu> Launchpad bug 714621 in Launchpad itself "Reevaluate our WADL caching strategy under continuous deployment" [High,Triaged] https://launchpad.net/bugs/714621
<micahg> tumbleweed: weird, it seems to want to work now, last night it was temperamental
<tumbleweed> micahg: any recollection what the issue was?
<micahg> python backtrace of some sort, I think when polling the packages
<tumbleweed> micahg: try requestsync firestarter, does it show you th eduplicate
<tumbleweed> (--lp of course)
<micahg> tumbleweed: I was having some trouble with authorization last night, that could've been it
<micahg> tumbleweed: ah, that did it, got a backtrace, do you want to see it?
<tumbleweed> micahg: was it something about a missing web_link attribute?
<micahg> tumbleweed: yes
<tumbleweed> micahg: rm -rf ~/.launchpadlib/*/cache
<tumbleweed> and it'll work again
<micahg> that's the WADL stuff?
<tumbleweed> yeah
 * tumbleweed must run
<micahg> tumbleweed: thanks and have a good weekend
<ari-tczew> if package in main Depends on package in universe, move it in d/control to Recommends is enough?
<ari-tczew> I'm merging sane-backends with Debian and in delta we have moved it from Depends to Suggests, but Debian moved it to Recommends.
<ari-tczew> If Recommends is fine, I'd like to stick with Debian.
<ari-tczew> Advices are welcome. ;-)
<geser> My guess is it should stay in Suggests for Ubuntu
<ari-tczew> geser: why?
<geser> I'm not fully sure about it but as Recommends are installed by default nowadays, Recommends for packages in main should be available in main
<ari-tczew> geser: Would be nice to look into technical documentation.
<geser> I'm trying to find something
<geser> which either supports or contradicts my statement
<mr_pouit> I think it should stay in suggests too
<geser> ari-tczew: http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-archive.html#s-main
<geser> * must not require a package outside of main for compilation or execution (thus, the package must not declare a "Depends", "Recommends", or "Build-Depends" relationship on a non-main package)
<ari-tczew> geser, mr_pouit: OK, I'll keep them in Suggests. Thanks geser.
<mr_pouit> grmpf, requestsync now asks me to authorize it on LP at every callâ¦
<geser> mr_pouit: with python-launchpadlib 1.9?
<mr_pouit> geser: no, 1.8.0-2
<geser> which Ubuntu version are you running?
<mr_pouit> sid ;-)
<geser> and u-d-t 0.119?
<mr_pouit> yep
<mr_pouit> I removed .launchpadlib and .cache/lp_credentials, but it doesn't change anything
<geser> requestsync got recently upgraded to work with python-launchpadlib 1.9 (ie. let python-launchpadlib handle the authorization completely)
<geser> you might ask leonardr (on #launchpad, probably after the weekend) if the code to work with python-launchpadlib 1.9 should also correctly work with 1.8 too (or if we should bump the dependency to >= 1.9)
<mr_pouit> geser: I just built python-launchpadlib 1.9 on sid, and it works as expected, so u-d-t 0.119 should  bump the dep
<ari-tczew> DktrKranz: around?
<DktrKranz> yeah
<ari-tczew> DktrKranz: oh, great. Do you remember what's the point of this change? http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/sane-backends-extras/natty/revision/12
<DktrKranz> ari-tczew: IIRC, it was to get rid of an old libtool NBS
<ari-tczew> DktrKranz: Can I drop it if package builds fine without it?
<DktrKranz> 99,9% could go away
<ari-tczew> DktrKranz: OK, I'll test build and get you back the information. ;-)
<DktrKranz> :)
<ari-tczew> DktrKranz: Built fine. Dropping.
<kamal> who can kill a PPA build for me?  (its a kernel targeted to the wrong distro -- hate to have it clog up the builder for hours).
<ari-tczew> kamal: ask on #launchpad
<kamal> ari-tczew: ty
<ari-tczew> kamal: np
<paultag> kamal: go to the source of the package detail and request delete
<paultag> kamal: I just did the same thing two hours ago
<kamal> paultag: I've done that, but the builds are already running, and don't appear to be stopping
<paultag> kamal: oh, then it's past the point of no return
<ari-tczew> !sru | ubottu
<ubottu> ari-tczew: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<ari-tczew> !ffe
<ubottu> Feature Freeze Exception. See https://wiki.ubuntu.com/FreezeExceptionProcess for the freeze exception process.
<ari-tczew> bdrung, tumbleweed, geser: when I entry wrong password while requestsync: http://paste.ubuntu.com/575727/
<bdrung> ari-tczew: file a bug
<ari-tczew> bdrung: why it now asks me twice for passwords?
<ari-tczew> previous requestsync didn't ask and I was happy.
<bdrung> ari-tczew: because of heavy changes in launchpadlib
<ari-tczew> bdrung: is it possible to workaround?
<bdrung> ari-tczew: dunno. you may ask in #launchpad
<tumbleweed> ari-tczew: is this from a gnome session?
<tumbleweed> see ubuntu-dev-tools' NEWS file
<ari-tczew> tumbleweed: nope
<tumbleweed> ari-tczew: that bug has been passed upstream to python-keyring, but there are known workarounds (sort-of)
<ari-tczew> bdrung: bug 729383
<ubottu> Launchpad bug 729383 in ubuntu-dev-tools (Ubuntu) "[requestsync] Traceback when password is wrong" [Undecided,New] https://launchpad.net/bugs/729383
<tumbleweed> ari-tczew: what password was wrong?
<ari-tczew> tumbleweed: do you want to get to know my password?
<tumbleweed> ari-tczew: no, I mean did you get a gnome-keyring password dialog?
<ari-tczew> tumbleweed: dunno whether gnome-keyring, but 1st was kwallet and 2nd was pinentry, I guess.
<ari-tczew> and I dunno which password it needs.
<tumbleweed> ari-tczew: ok, but it works when you get the password right?
<tumbleweed> ari-tczew: it'll need your login password (I assume) basically whatever password protects your kwallet
<ari-tczew> tumbleweed: I forgot password :/
<tumbleweed> ari-tczew: I guess you'll have to delete your kwallet password-store then
<ari-tczew> tumbleweed: how?
<tumbleweed> it's in ~/.kde/share/apps/kwallet/ according to google
<tumbleweed> ari-tczew: just committed the download-specified-version support to pull-{lp,debian}-source we discussed
<ari-tczew> tumbleweed: how it works now?
<ari-tczew> if I want to get source from snapshot
<tumbleweed> ari-tczew: I'll trigger a PPA build
<tumbleweed> oh, that's already in the queue
<lfaraone> A MOTU just uploaded version 0.3.7-2ubuntu1 of a package I  maintain in Debian. That's fine, except one problem: the latest version in unstable is 0.3.7-1. When I release the *right* 0.3.7-2, how can I ensure that gets moved over to Ubuntu?
<paultag> lfaraone: sounds like someone screwed up :(
<lfaraone> I'm actually at a loss how the uploader came across the changes I had in VCS which were previously unpublished, the UDD branch for my package only has the released version. (Ubuntu's changelog of pithos now has an "UNRELEASED" entry that its basing on)
<paultag> lfaraone: might have to either bump to 3 up or ask for that package to get removed :(
<paultag> lfaraone: +1
<lfaraone> merde. it was published 21 minutes ago.
<lfaraone> too late to get it removed now. <_<;
<paultag> lfaraone: at least now you get to yell at the MOTU who did it :)
<lfaraone> oooh, he's @canonical.com.
<paultag> lfaraone: :D
<Ampelbein> lfaraone: pithos?
<lfaraone> Ampelbein: yep.
<broder> lfaraone: there are other options than uploading a -3. you could upload a -2, and then we could merge it as -2ubuntu2
<Ampelbein> lfaraone: I asked in #ubuntu-desktop
<broder> (or the always excellent -2ubuntu1reallyjust2)
<Ampelbein> lfaraone: ken is in there
<lfaraone> Ampelbein: there were no changes in -2, other than including changelog entries that were lost in -1, but I was going to roll out a -2 with the patch Ken just uploaded.
 * lfaraone joins and waves.
#ubuntu-motu 2011-03-05
<artfwo> can anyone give reasons NOT to use cdbs?
<artfwo> more specifically, why some Debian sponsors dislike cdbs and recommend pure debhelper instead?
<tumbleweed> artfwo: I find it hard to understand what CDBS is doing, and why, and debug rules using it
<tumbleweed> artfwo: I can also never ues it without referring to its documentation. With dh, it's pretty obvious what you have to override to do something
<tumbleweed> oh, and have you read it? it's far worse than perl. Although I've submitted a few patches to it, and none to debhelper...
<artfwo> tumbleweed: that's what I thought, I've had to read the entire /usr/share/cdbs directory sometimes
<artfwo> tumbleweed: but it does have some good points, doesn't it? :)
<tumbleweed> artfwo: it has classes for doing some things, that dh can't do easily, so yeah there are times when I'd consider using it. But all my packages are dh.
<artfwo> tumbleweed: couldn't you point out an example dh-package using pysupport, so I could compare both approaches?
<tumbleweed> artfwo: for pysupport, all that's needed would be "%:\n\tdh"
<artfwo> tumbleweed: you mean "%:\n\tdh $@"?
<tumbleweed> er that
<artfwo> tumbleweed: many thanks, your advice just made my rules six times smaller :)
<tumbleweed> heh
<tumbleweed> I think it makes less difference when you are customising a lot of behavior
 * c2tarun don't miss me too much ;) â¥
 * c2tarun is back.
<c2tarun> I submitted 2 bugs yesterday and no mail from debian till now :( what should I do?
<DktrKranz> less than 24 hours is normally not a significant time
<c2tarun> DktrKranz: actually I filed a few bugs before this and I use to get a mail in 1 or 2 hours, that's why I asked.
<tumbleweed> c2tarun: are you using a local MTA (i.e. postfix) on your system? Or going through a smarthost / direct to bugs-master?
<c2tarun> tumbleweed: using postfix
<tumbleweed> c2tarun: run "mailq". Does it show anything?
<c2tarun> tumbleweed: its empty.
<tumbleweed> ok, so it's not stuck on your system. Although it could have also bounced back to you and be sitting in your local mailbox. (you can read your mail.log, if you want to be sure it was successfully delivered somewhere)
<DktrKranz> c2tarun: oh, you meant you didn't get an ACK saying your bug has been reported, didn't you?
<c2tarun> DktrKranz: yup
<webdevbyjoss> hey, guys. I have a problem with installing Qt application, because I can't install required qt-lib. is this a good channel to ask for help?
<stefanlsd> Is ubuntu-archive ok with motu using syncpackage to process sync's that have ffe to universe, or would they prefer to manage it?
<bdrung> stefanlsd: they prefer to manage it
<stefanlsd> bdrung: aah ok. noted. thanks
<MTecknology> !info nginx-full natty
<ubottu> Package nginx-full does not exist in natty
<MTecknology> !info nginx natty
<ubottu> nginx (source: nginx): small, but very powerful and efficient web server and mail proxy. In component universe, is optional. Version 0.8.53-2 (natty), package size 327 kB, installed size 900 kB
<hyperair> ooh i never knew about !info
<hyperair> that looks pretty nice
<MTecknology> heh... I thouch ubuntu at least had .54
<hyperair> well if .54 is a bugfix release it's not too late for a sync
<MTecknology> I'm doing that now
<MTecknology> hyperair: You think I could still get a new app in that conflicts with nothing and has nothing conflict with it once it passes through debian NEW either this week or next?
<hyperair> MTecknology: you'll have to ask ubuntu-release that.
<MTecknology> hyperair: I guess I'll have to find out when it's in unstable. No point in bugging people until it's there. :)
<hyperair> MTecknology: you could pre-request a FFe
<MTecknology> oh
<MTecknology> I guess I'll do that then. I didn't know that. :)
<MTecknology> I guess I'll get ready to leave for the funeral while this builds.
<MTecknology> hyperair: there we go; bug 729691 added :)
<ubottu> Launchpad bug 729691 in nginx (Ubuntu) "Freeze Exception Request: nginx-0.8.54-4" [Undecided,New] https://launchpad.net/bugs/729691
<hyperair> =)
<hyperair> is it a non-bugfix release?
<MTecknology> there's a little bit of non-bugfix; but that's mostly all it is
<psusi> if I pushed another change to my branch, I don't need to request a merge again if the one I requested yesterday has not been done yet right?
<ari-tczew> geser: bug 729524, I unsubscribed ubuntu-sponsors, looks like you forgot about it.
<ubottu> Launchpad bug 729524 in proftpd-dfsg (Ubuntu) "Sync Proftpd-dfsg 1.3.3d-4 (universe) from Debian Unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/729524
<geser> ari-tczew: thanks, I didn't forgot it, I simply can't (not a member of ~ubuntu-sponsors)
<ari-tczew> geser: oh, don't you want to be added?
<geser> as I'm not doing much sponsoring, I don't know if it's worth it
<c2tarun> I submitted 3 bugs to debian yesterday and didn't got any ACK mail till now. What should I do? Should I upload them to LP?
<Ampelbein> c2tarun: does /var/log/mail.log show the mails as delivered?
<c2tarun> Ampelbein: there is no mail.log file :(
<Ampelbein> c2tarun: did you send the bugs with reportbug/submittodebian? how is your mailsystem configured?
<c2tarun> Ampelbein: I used submittodebian for submitting bug, I posted few more bugs same way and that time I got the ACK mail but it was this time I am not getting anything, I use postfix
<Ampelbein> c2tarun: if you use postfix then there must be a mail.log file somewhere.
<c2tarun> Ampelbein: let me run a search
<Ampelbein> c2tarun: you could also try 'grep postfix /var/log/syslog'
<c2tarun> Ampelbein: I have only these files in /var/log http://paste.ubuntu.com/576041/
<Ampelbein> c2tarun: erm... what system are you using? that isn't standard ubuntu?
<c2tarun> Ampelbein: it is natty chroot :/
<Ampelbein> c2tarun: oh, in that case postfix probably connected to the system syslog-daemon.
<c2tarun> Ampelbein: oh wait sorry... I used my main sys for submittodebian wait
<Ampelbein> c2tarun: you can use something like 'grep postfix.*submit\@bugs\.debian /var/log/syslog' on your mainsystem to find only the mails to the debian tracker
<c2tarun> Ampelbein: here is my mail log for debian http://pastebin.com/4ELdNMDz
<c2tarun> Ampelbein: I guess it failed :(
<Ampelbein> c2tarun: yes, failed: 550 malware detected: MBL_144360.UNOFFICIAL: message rejected (in reply to end of DATA command))
<c2tarun> Ampelbein: what does it mean?
<Ampelbein> c2tarun: the remote mailserver detected malware in the mail you sent. that could be a virus or something thelike... what patches did you try to submit?
<c2tarun> Ampelbein: here is the debdiff http://pastebin.com/P6rWVcEm
<Ampelbein> c2tarun: hmm, that's strange. that shouldn't trigger any malware detection. maybe it was a temporary problem, just try sending again.
<c2tarun> Ampelbein: sure.
<Ampelbein> c2tarun: but I would remove the change to debian/control from the debdiff, it's not needed in debian
<c2tarun> Ampelbein: hmm.... ok, I'll remove that.
<c2tarun> Ampelbein: there is a problem, the debdiff generated by submittodebian is not showing changes of changelog.
<TeTeT> hi, I would like to build a newer version of glib2.0 on 10.04 for trying out the new NetworkManager. I got the latest debian directory of the package via svn from svn://svn.debian.org/svn/pkg-gnome/desktop/unstable/glib2.0. How do I get the source now? In a bazaar repo, I could do a 'bzr bd -S', is there any equivalent for svn?
<Ampelbein> TeTeT: are you looking for 'svn-buildpackage'?
<TeTeT> Ampelbein: thanks, that's it most likely :)
<Ampelbein> ;-)
<Ampelbein> TeTeT: you have to install it extra though.
<Ampelbein> !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
<TeTeT> Ampelbein: do you know if I can override the pristine check? I need to modify control and control.in to change some build dependencies
<Ampelbein> TeTeT: --svn-ignore should do that (I can't test right now)
<TeTeT> Ampelbein: starts to build now, thanks again
<highvoltage> f/win 27
<c2tarun_> If I fix any ftbfs bug for natty machine and submit it to debian. How can i connect LP page of that bug to its debian page?
<paultag> c2tarun_: just paste the debbug URL in the report
<paultag> c2tarun_: be sure to note it was forwarded
<iulian> There's a "Also affects distribution/package" button in Launchpad.
<iulian> If this is what you mean.
<c2tarun_> paultag: I included the debbug number in changelog. will it be enough?
<paultag> c2tarun_: not for the LP bug report :)
<paultag> c2tarun_: LP bug should be linked to debian's bts, and when you upload, the changelog should close the debbug and the lp bug
<c2tarun_> paultag: how can i link it to debian's bts?
<paultag> c2tarun_: just paste the debbug URL in the report
<paultag> c2tarun_: be sure to note it was forwarded
<c2tarun_> paultag: ok thanks :)
<paultag> c2tarun_: sure :)
<ari-tczew> lucas_: do you planning rebuild ubuntu archive to get ftbfs output? a lot of errors are deprecated, now are other failrues
<bdrung> tumbleweed: pull-debian-source foo unstable fails, but pull-debian-source foo sid works
<tumbleweed> bdrung: thanks, I'll have a look later
<bdrung> thx
<ari-tczew> tumbleweed: what's the command will be for snapshot?
<tumbleweed> ari-tczew: nothing special, if the version isn't available from anywhere else, it will come from snapshot
<ari-tczew> tumbleweed: so how can I specify package and version?
<tumbleweed> ari-tczew: pull-debian-source foo 0.1.2-3
<ari-tczew> tumbleweed: ok thnx
<ari-tczew> c2tarun_: ping
<bdrung> tumbleweed: maybe "Aborting at user request" -> "User abort."
<tumbleweed> sure
<tumbleweed> we still don't handle squeeze-updates, squeeze-p-u, -security, etc
<bdrung> tumbleweed: your comments to bug #728751?
<ubottu> Launchpad bug 728751 in ubuntu-dev-tools (Ubuntu) "[sponsor-patch] support cowbuilder and cowbuilder-dist" [Undecided,New] https://launchpad.net/bugs/728751
<tumbleweed> the comma is optional. It's probably more correct to omit it, although I also use them like that quite often.
<bdrung> tumbleweed: and the restructuring of the if clause?
<tumbleweed> works for me
<bdrung> and the error message format change?
<tumbleweed> it seems a more maintainable solution
<bdrung> tumbleweed: ok, then feel free to merge that branch. i am going to bed now.
#ubuntu-motu 2011-03-06
<micahg> should we remove sources for packages that don't build any binaries on arches we support?
<MTecknology> "What about the rdepends?"
<MTecknology> How can I answer this?
<micahg> MTecknology: what's the question?
<MTecknology> How do I know if a new package affects rdepends?
<micahg> MTecknology: apt-rdepends -r BINARYPKGNAME
<micahg> MTecknology: and reverse-build-depends BINARYPKGNAME
<MTecknology> apt-utils supplies those commands?
<micahg> MTecknology: no
<MTecknology> oh.. ubuntu-dev-tools
<MTecknology> rdepends are packages that depend on this package, right?
<micahg> MTecknology: yep
<MTecknology> thanks :)
<ScottK> micahg: No.  Just ignore sources that don't build for our archs.  Removing them bloats the sync blacklist to no purpose (they don't hurt anything).
<micahg> ScottK: right, thanks
<c2tarun> !git
<ubottu> git is a distributed revision control/software code management project created by Linus Torvalds. For more information, see http://en.wikipedia.org/wiki/Git_(software)
<c2tarun> !svn
<ubottu> svn is Subversion: an open-source revision control system, which aims to be a compelling replacement for CVS. See http://subversion.tigris.org/
<micahg> !msgthebot > c2tarun
<ubottu> c2tarun, please see my private message
<c2tarun> micahg: sorry, I was not knowing this is also a way :( sorry
<micahg> c2tarun: no problem, now you can query the bot all you want :)
<c2tarun> micahg: yup :)
<c2tarun> micahg: its still getting displayed here.
<jmarsden> c2tarun: Yes, but noone except you can see it now :)
<c2tarun> jmarsden: oh.... :) got it.
<jmarsden> :)
<artfwo> how can I tell quilt, that I want to rename a file in a patch?
<artfwo> I am not sure, that "quilt add oldname newname && mv oldname newname" is the right way to do it
<c2tarun> artfwo: add that new filename to patch and then rename old one. then refresh
<micahg> artfwo: there's a quilt rename command as well
<c2tarun> micahg: thats for reaming patch I guess not for renaming files.
<micahg> ah, right
<artfwo> yes, rename is for patches
<c2tarun> artfwo: try how I told, and tell me if it works.
<artfwo> c2tarun, it works, but I thought there may be a smarter solution :)
<c2tarun> artfwo: ya there may be :) please tell me if you find one.
<c2tarun> what is trunk?
<jmarsden> c2tarun: In the context of animals, it is the nose of an elephant :)  In the context of version control systems, it is the main stream of code from which other secondary streams of development can branch off.
<c2tarun> jmarsden: ok, so it means that git get branch of from trunk?
<jmarsden> I do not know what context you are seeing the word "trunk" in, so I can't answer that :)
<hyperair> a trunk is a suitcase.
 * hyperair hides
<jmarsden> c2tarun: You should probably read more about version control systems and bzr and git to get a good understanding of this stuff
 * micahg finds hyperair hiding behind a trunk
<jmarsden> c2tarun: You should probably ignore hyperair :)
<c2tarun> jmarsden: I was looking on project neon, there I am getting these words very frequently like svn/git trunk. :/
<jmarsden> c2tarun: OK, so read up on distributed version control systems a little and then come back to what you are doing.
<c2tarun> jmarsden: is there any wiki page for this?
<jmarsden> Probably... I'll see what I can find...
<jmarsden> Try http://learn.github.com/p/intro.html for a tutorial about git
<jmarsden> c2tarun: And maybe http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ for a more general into to distributed version control.
<c2tarun> jmarsden: these links are awesome :) thanks
<jmarsden> c2tarun: You're welcome.
<c2tarun> one more help please, earlier when I was using ubuntu lucid when buffering of any video ends then I can copy that video from /tmp folder, but since I switched to kubuntu maverick there are no such videos in that tmp folder. why?
<jmarsden> That's not a MOTU-ish packaging-related question... I don't generally watch videos on Ubuntu... sounds like the software you are using to watch videos has been fixed to tidy up after itself and delete the temp files it uses -- but that is just a guess.
<hyperair> c2tarun: are you talking about Flash videos?
<hyperair> the current version of Flash seems to create a /tmp/FlashXXXXXX file, keep the file descriptor open, and then delete it.
<hyperair> meaning that if you do lsof -n | grep Flash, you'll see which file descriptor points at this deleted file. then you can go to /proc/$pid/fd/$fd (specifically, cat /proc/$pid/fd/$fd > /path/to/newfile
<hyperair> i frequently also just run mplayer on the partially-buffered file the same way =p
<c2tarun> hyperair: ping
<hyperair> c2tarun: pong
<c2tarun> hyperair: this channel is not for discussing Flash problem :( can I PM you?
<hyperair> sure
<c2tarun> If a package has newer version in debian and no watch file, how can I get it from debian?
<micahg> c2tarun: pull-debian-source in ubuntu-dev-tools
<c2tarun> there is package tracked by ftbfs tracker, its newer version in debian claims in its changelog that it fixed the ftbfs problem, but package still fails to build on natty, what can I do? I know how to fix, but how can I close same debian bug in two changelog entries?
<Bachstelze> c2tarun: a lot of things can cause FTBFS, if it is fixed in debian doesn't mean it is in Ubuntu, you should probably file a new ftbfs bug
<Bachstelze> c2tarun: what's the package?
<c2tarun> Bachstelze: bfm
<c2tarun> Bachstelze: some errors mentioned in debian's bug error log are same
<c2tarun> i'll brb
<c2tarun> Bachstelze: yup I am back :) you looked at the package?
<Bachstelze> looking at it now
<Bachstelze> you can't do these things in 30 seconds ;)
<c2tarun> Bachstelze: sorry :)
<Bachstelze> c2tarun: what's the debian bug number?
<c2tarun> Bachstelze: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=553959
<Bachstelze> debian bug 553959
<ubottu> Debian bug 553959 in src:bfm "FTBFS with binutils-gold" [Important,Fixed] http://bugs.debian.org/553959
<Bachstelze> c2tarun: that's the prefered way ;)
<c2tarun> oh ... :) sorry
<c2tarun> Bachstelze: found something?
<Bachstelze> c2tarun: the new versions adds -lX11, but all the -l flags are still in the wrong place
<Bachstelze> they should be after the .c files, not before
<Bachstelze> on the command line
<c2tarun> Bachstelze: so what should I do, file a new bug into debian?
<Bachstelze> it's related, so report in the same bug
<Bachstelze> and see what the maintainer says
<Bachstelze> but wait a bit, I'll see if that's really the problem
<c2tarun> sure
<micahg> Debian might not have all the default flags that we do on
 * Bachstelze nods
<Bachstelze> --as-needed is probably the culprit here
<c2tarun> Bachstelze: what should I do
<c2tarun> I have problem with one more package, there is a package named btnx in that ftbfs bug tracker, its ubuntu1 version failed to build, should this error be reported to debian?
<Bachstelze> what's ubuntu1 for?
<c2tarun> I mean  btnx_0.4.11-3ubuntu1 version failed, as this incorporated the changes for ubuntu so I asked.
<Bachstelze> yes
<Bachstelze> I meant what changes does ubuntu1 bring opver the version in Debian?
 * c2tarun looking
<c2tarun> Bachstelze: something related to source code. must be necessary
<Bachstelze> yeah
<c2tarun> Bachstelze: so what should I do? report it to debian?
<Bachstelze> so report it to both, we need an Ubuntu-specific patch anyway since we have already diverted
<Bachstelze> there is no newer revision in Debian
<c2tarun> Bachstelze: no there is no newer revision in debian + there is no patch as well. package doesn't follow any patch system
<Bachstelze> c2tarun: http://paste.ubuntu.com/576463/
<Bachstelze> bfm builds fine with this
<Bachstelze> see how the LIBS must be after the SRCS
<Bachstelze> last part
<Bachstelze> or after the OBJS, depending on what you're doing
<Bachstelze> but always at the end of the command line
<c2tarun> I would have also done same thing but not in that proffesional way :( why you remove line 7 from comment?
<Bachstelze> I only did the last part
<Bachstelze> line 7 is already in 0.6.4-4
<c2tarun> Bachstelze: not getting what do you mean by last part? if its in last part how come its in debdiff?
<Bachstelze> it's not a debdiff
<c2tarun> i mean diff
<Bachstelze> it's part of the .diff.gz for my fixed package
<c2tarun> Bachstelze: ohh..... got it :)
<Bachstelze> you normally don't submit debdiffs to debian, only patches
<c2tarun> Bachstelze: so submittodebian submits patch like this?
<Bachstelze> no idea, I have never used it
<c2tarun> Bachstelze: so submittodebian submits creates patch like this?
<c2tarun> Bachstelze: then how do you submit to debian?
<Bachstelze> the old way, by email
<c2tarun> Bachstelze: oh... :)
<koenig> ive got question ive a deb package and i want to add this to the official ubuntu repostorys how can i do this
<koenig> can sombody helpme pls ????
<kklimonda> !revu | koenig
<ubottu> koenig: 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
<koenig> thanks for quick reply
<c2tarun> Bachstelze: ping
<Bachstelze> c2tarun: pong
<c2tarun> Bachstelze: you remember that bfm package we discussed?
<Bachstelze> yes
<c2tarun> Bachstelze: dont you think bfm package is in condition for merge ( debian has a newer version which needs some change for building on ubuntu)
<Bachstelze> c2tarun: we haven't diverted, so it would not be a merge, just a sync
<Bachstelze> and we can apply the fix for --as-needed to the new debian revision
<c2tarun> diverted means?
<Bachstelze> it means that the apckage is different in Ubuntu and in Debian, denoted by ubuntuX appended to the version number
<c2tarun> Bachstelze: so change for --as-needed can not be considered as a change enough for merge?
<Bachstelze> the change is not commited to ubuntu yet, right ?
<ScottK> If the package currently fails to build on Ubuntu due to --as-needed then we want that fixed in Ubuntu.
<Bachstelze> can't we sync the new debian revision at the same time ?
<Ampelbein> Bachstelze: that is called a merge.
<Bachstelze> only if we have diverted
<Bachstelze> we have not, or not yet at least
<ScottK> Bachstelze: We still call it a merge if the package is different when uploaded even if it wasn't before.
<Bachstelze> ok
<Ampelbein> Bachstelze: it's still a merge if we introduce a change only now.
<ScottK> The key point about a merge is we have to manually upload to Ubuntu.
<c2tarun> ok, so I will file a bug for merge than
<ari-tczew> c2tarun: FYI, output messages on lucas merges are outdated, you have to copy log from http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110125-natty.html
<c2tarun> ari-tczew: what log?
<ari-tczew> c2tarun: when you create a bug on launchpad, you copy FTBFS log to description, right?
<c2tarun> ari-tczew: that was not from lucas log, that was the actual error I got
<ari-tczew> c2tarun: odd, in some cases I got another error than you
<c2tarun> ari-tczew: what case?
<c2tarun> I mean which casse
<ari-tczew> wgrant: could you give me a link to latest rebuild of archive?
<ari-tczew> c2tarun: bug 729118
<ubottu> Launchpad bug 729118 in dma (Ubuntu) "Package dma_0.0.2010.06.17-6 failed to build from source" [Undecided,Fix released] https://launchpad.net/bugs/729118
<ari-tczew> c2tarun: I got undefined reference to HMAC or something
<ari-tczew> c2tarun: and please add
<ari-tczew> Debian bug to this one
<ari-tczew> on launchpad
<c2tarun> ari-tczew: how to add debian bug?
<ari-tczew> c2tarun: Also affects distribution
<c2tarun> ari-tczew:  can you please check, is it fine now?
<ari-tczew> c2tarun: yes, it's fine. when you receive message from bug tracker about fixed bug in Debian, it's sign to check whether we can drop changes in package.
<m4n1sh> is watch file mandatory while packaging?
<Bachstelze> m4n1sh: no
<m4n1sh> Bachstelze: thanks
<Bachstelze> http://www.debian.org/doc/debian-policy/ch-source.html#s-debianwatch
<Bachstelze> says it's recommended, though
<Ampelbein> m4n1sh: but it's considered good practice to include one and many reviewers will complain if its not there.
<m4n1sh> Ampelbein: the problem is that I am taking an upstream codebase
<m4n1sh> which does not have autotools support
<m4n1sh> so I took the codebase, added build support
<m4n1sh> and hosting it myself
<m4n1sh> and working side by side :(
<Bachstelze> how is upstream supposed to be built thenN
<Bachstelze> ?*
<m4n1sh> it is a Visual Studio solution
<m4n1sh> hosted at json.codeplex.com
<m4n1sh> it is a .NET library
<m4n1sh> works on mono also
<Bachstelze> hmm
<m4n1sh> but does not have any linux build system support
<m4n1sh> it is a great library, since mono as of now doesnt have good json support
<Bachstelze> not sure how to handle such cases, I think you should list yourself as upstream, since the source tarball is modified
<Ampelbein> m4n1sh: and you need a get-orig-source target if you modify the source tarball
<m4n1sh> Ampelbein: in which file
<Ampelbein> m4n1sh: debian/rules
<m4n1sh> Bachstelze: I just added the build system but no codebase changes
<Ampelbein> m4n1sh: are you repacking the orig.tar.gz?
<m4n1sh> Ampelbein: the upstream is a zip file with source and binaries and blobs
<m4n1sh> i mean upstream release
<m4n1sh> stripping out everything
<m4n1sh> and adding build support
<m4n1sh> is what I am doing in my case
<m4n1sh> and finally I am done
<m4n1sh> and now trying to package it
<Ampelbein> m4n1sh: the point is, 'wget <upstreamsource>, tar xfz <debian-diff>' must result in the source that can be built. if it is not, you need a get-orig-source target.
<Ampelbein> m4n1sh: so if you repack the .zip to .tar.gz, you need to make a rule for that.
<m4n1sh> Ampelbein: okay. I have hosted my packagign in gitorious
<m4n1sh> will release it
<m4n1sh> and add that in watch
<m4n1sh> still I need a rule?
<Ampelbein> m4n1sh: since debian only allows gz, bz2 and xz, yes, you need a rule to repack the tarball.
<m4n1sh> Ampelbein: the tarball I am releasing is tar.gz
<m4n1sh> which I work  upon after taking the source from upstream
<Bachstelze> m4n1sh: the point is that someone can take the package and use it with any new source release
<Bachstelze> so that people can take over if you can't maintain the package antmore
<Bachstelze> anymore*
<m4n1sh> yes, but right now I am acting in the middle between the package and the upstream newtonsoft-json author
<m4n1sh> since he does not support the build systems
<m4n1sh> the upstream release files are a zip file
<m4n1sh> with no LICENSE
<m4n1sh> or README
<m4n1sh> anything
<Bachstelze> that's what get-orig-source is for
<m4n1sh> hmm
<Bachstelze> http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
<m4n1sh>  get-orig-source should point to upstream one?
<Bachstelze> you should make it fetch thz zip, do the changes and repack it as .tar.Gz
<m4n1sh> says
<m4n1sh> 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.
<m4n1sh> actually writing a script to do this is tough
<m4n1sh> it has to be done manually
<m4n1sh> tested and then can be released
<Ampelbein> m4n1sh: if there is no LICENSE, you might have other problems to consider first.
<m4n1sh> Ampelbein: the LICENSE is not shipped with the tarball
<m4n1sh> but when downloading it shows properly
<Bachstelze> it should be
<m4n1sh> I am checking agai
<m4n1sh> when I click Download it says "Do you agree to this license"
<Bachstelze> doesn't matter
<Ampelbein> m4n1sh: the license must be included in the debian package
<Bachstelze> the license must accompany the code
<m4n1sh> I checked the upstream zip file
<m4n1sh> it contains a readme.txt file
<m4n1sh> upper part is readme
<m4n1sh> below part contains license
<m4n1sh> and the debian package has that license
<Ampelbein> m4n1sh: good. be sure to mention that in debian/copyright
<m4n1sh> checked again
<m4n1sh> I have updated it
<micahg> gilir: you know xulrunner-1.9.2 is going away in natty, right?
<gilir> micahg, there are still some packages depending on it, you plan to do the migration so late in the cycle ?
<micahg> gilir: whatever is left at teh end of the cycle, we're going to drop
<micahg> we can't support multiple xulrunners
<micahg> gilir: is gecko-mediaplayer an npapi plugin?
<gilir> so why not removing it right now ? it's still in the archive
<micahg> gilir: to give people a chance to port and still have the app useable :)
<micahg> but I'll bring up dropping it for beta
<gilir> micahg, I don't know, it installs a .so in the same place than flash and java
<micahg> gilir: is upstream not active?
<gilir> micahg, it is, only the ususal ubuntu/debian maintainer is not
<micahg> gilir: is it just a matter of packaging the new upstream?
<kklimonda1> micahg: why the hell are upstream devs depending on mozjs if it doesn't provide a stable API?
<kklimonda1> micahg: is it the same with v8?
<gilir> micahg, no, according to upstream, it's already compatible with 2.0
<micahg> kklimonda1: idk about v8, but mozjs should be stable soon
<micahg> gilir: ok, I'll try to have a look this week
<kklimonda1> micahg: stable as in they will provide stable API for years?
<RAOF> micahg: Oh, really?  Mozilla will commit to an ABI in the near future?  Sweet.
<micahg> kklimonda1: which upstream are you frustrated with now
<kklimonda1> micahg: mongodb ;)
<micahg> RAOF: they're thinking about trying at least :)
<kklimonda1> sweet
<micahg> kklimonda1: yep, are you trying to port to xul-2.0?
<kklimonda1> micahg: I know nothing of xul 2.0 API changes, nor about mongodb internals. I may take a look at it this week, but I wouldn't hold my breath :)
<gilir> micahg, thanks :)
#ubuntu-motu 2012-02-27
<arand> quidnunc: Aren''t they doing pretty much the same thing?
<jtaylor> strange, I synced espeakup via syncpackage today but still not accept mail
<jtaylor> its been a couple of hours already
<RAOF> jtaylor: Beta freeze is a hard freeze; it'll be sitting in unapproved.
<jbicha> jtaylor: https://launchpad.net/ubuntu/precise/+queue?queue_state=1
<jtaylor> :O O forgot about the freeze :/
<jtaylor> a its not seeded so no damage done?
<ajmitch> just have to be patient :)
<RAOF> It's in unapproved; it hasn't hit the archive, so no damage done, even if it were seeded.
<quidnunc> arand: I can only build dsc with pbuilder-dist
<quidnunc> I think
<stefanct> "[qastaging] Launchpad is processing new changes to this branch which will be available in a few minutes. Reload to see the changes." that was 10 hours ago...? :)
<tumbleweed> stefanct: -> #launchpad
<stefanct> thx
<pipedream> tumbleweed: I kinda crashed last night. more or less ready to resume my efforts now
<tumbleweed> pipedream: maybe we should move this to #ubuntu-packaging, as it's about a PPA package
 * ajmitch wishes he had an SSD in his desktop now, upgrading from natty to oneiric is taking awhile
<pipedream> tumbleweed: ok
<geser> dholbach: thanks for sponsoring my vim merge. So the changelog shortening I've done is in your opinion ok (dropping 800 lines of debian/changelog delta)? There was a short discussion yesterday if it should be kept
<dholbach> geser, personally I think it's alright
<dholbach> it has happened before :)
<Laney> call it "rebase" instead of "merge" and kill the changelog delta :-)
 * ajmitch should finish off this merge & upload it 
<geser> I tried to find a balance between preserving history (1000 lines) and the size of the real delta (30-40 lines) and dropped entries older than lucid
<dholbach> sounds reasonable to me
<dholbach> archaeologists should be able to find old changelogs still :)
<geser> it's not like LP forgets something (for the main repositories)
<ajmitch> though I'm merging a new upstream release of phpldapadmin due to some security issues in the current one :)
<micahg> ajmitch: might need an FFe still
<ajmitch> micahg: yeah it likely will
<ajmitch> http://phpldapadmin.sourceforge.net/wiki/index.php/Release shows a number of new features since 1.2.0
<micahg> ajmitch: and thanks, that saves me from doing it :)
<ajmitch> micahg: I don't want to deprive you of your fun ;)
<micahg> heh, I've got a large bucket of "fun" to choose from :)
<debfx> geser: my apt-cacher-ng sync has superseded your upload so you need to upload it again based on 0.7.1-1
<micahg> debfx: I'd venture to say, depending on who uploaded whoever uploaded the package second is responsible (don't know if there's a way to tell at this point)
<geser> will do, my change just quietens the logrotate warning from the unknown option
<geser> would soyuz allow to upload a version if a newer version is sitting already in the queue?
<micahg> yes, it was sitting in unapproved (since we're frozen)
<micahg> but whoever's approving the queue should be watching for these things :))
<debfx> still lp shouldn't allow accepting both
<micahg> sure, it's unapproved
<micahg> oh, accepting...
<micahg> well, it's accepted, but wouldn't build
<debfx> yeah it is accepted but it shouldn't allow it to be accepted
<micahg> well, that doesn't seem like a high priority at this point
<ajmitch> Laney: what do you need from me for this FFe fun? :)
<Laney> money
 * ajmitch has 10c around here somewherew
<ajmitch> I can post it to you, should arrive in a couple of months
<Laney> Â£ please
<ajmitch> closest I have is euros, sorry :(
<Laney> play money :(
<Laney> usual stuff
<Laney> how major is the update? any rdeps?
<ajmitch> closest to an rdep is a Suggests from samba4, the update looks to be about 85% bugfixes
<Laney> smoke testing would be nice, otherwise bug with rationale
<Laney> build/install logs probably wouldn't be that interesting ...
<ajmitch> it's a php app, so build logs should be boring
<nigelb> Laney: can we gift you the metric system instead? :D
<ajmitch> the main rationale is OMG security holes (it's php...)
<tumbleweed> so, it'll still have security holes :)
<ajmitch> yup
<tumbleweed> maybe even bigger ones, if php itself is anything to go by :P
<ajmitch> 2+2=4, except when running php? :)
<nigelb> haha
 * Laney measures nigelb in links, then runs several furlongs away
 * nigelb goes to find a converter.
<Laney> 1/25 of a rod
<nigelb> ...
<Laney> 1/100 of a chain?
<ajmitch> Laney: bug 941855, want u-release subscribed?
<ubottu> Launchpad bug 941855 in phpldapadmin (Ubuntu) "[FFe] phpldapadmin 1.2.2" [Undecided,New] https://launchpad.net/bugs/941855
<Laney> did it
<Laney> do you have any ability to test?
<ajmitch> limited, I don't have an ldap server up & running
<Laney> k
 * Laney sticks a cherry on top
 * ajmitch is just trying to look at some of the big bad bugs on the rc bugs page, though tumbleweed & micahg seem to have got most :)
<nigelb> phpldapadmin *shudder*
<ajmitch> nigelb: I know...
<nigelb> I spent 2 weeks playing with it :)
<ajmitch> it's like giving a teenager the keys to an expensive car & hoping that they don't crash it ;)
<tumbleweed> ajmitch: I'm sure there are lots of worthwile things there, still
<nigelb> ajmitch: wow, exactly!
<tumbleweed> the automated lucid->precise upgrade tests are main-only, right? It'd be nice to run some on universe packages. But I doubt we'd have the manpower to deal with them...
<micahg> tumbleweed: stgraber is running upgrade tests on the flavors
<tumbleweed> right, but nothing approaching debian's piuparts upgrade tests of the whole archive
<tumbleweed> (a few issues in rcbugs were squeeze->wheezy ugprades, which applied to lucid->precise)
 * ajmitch thinks having universe upgrades tested is probably almost as important
<tumbleweed> I agree, they are important bugs for our users
<tumbleweed> Ubuntu has a reputation of not upgrading cleanly, and only part of that comes from crazy PPAs :P
<micahg> I fixed a release upgrade bug in lucid at the last UDS :)
<tumbleweed> unfortunatly, they are a pain to test, becasue of the debconf upgrade problem (that's worked around in update-manager)
<ajmitch> Laney: ta for the ffe approval, uploading now
<Laney> ye beauty
<hakermania> Hello :) May I be told when is the last timeline (which 'freeze') in which ubuntu can accept backports(new version of program already in the repos). I have thhe realease schedule link but setill not sure. Thanks :)
<tumbleweed> hakermania: the last time for FFes to be processed is unseeded universe final freeze https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
<tumbleweed> and the -backports for new packages process doesn't appear to be usable yet
<hakermania> tumbleweed, so, what do you suggest for having a ready backport?
<tumbleweed> go with an FFe ifyo want a newer version in precise, and please try and do it before beta 2
<geser> jtaylor: do you plan to get your planner FTBFS fix directly into Ubuntu or wait some more on a new upload?
* Topic unset by dholbach on #ubuntu-motu
* dholbach changed the topic of #ubuntu-motu to: REVU is back up | Precise: Feature Freeze | Want to get involved with the MOTU? https://wiki.ubuntu.com/MOTU/Contributing | Sponsor queue: http://bit.ly/fz6AyQ | http://qa.ubuntuwire.com/ftbfs | http://people.canonical.com/~ubuntu-archive/NBS | http://qa.ubuntuwire.com/bugs/rcbugs/
<jtaylor> geser: probably makes sense to fix planenr directly, the new upload will likely include new features
<jtaylor> I'll do that later
<AnAnt> Hello, is universe/multiverse also freezed ?
<broder> AnAnt: universe and multiverse are subject to feature freeze
<broder> due to lp limitations, uploads also get held for beta freeze, but if the package isn't on any beta products (cds, etc.), then they basically get instantly approved
<broder> (so effectively not beta-frozen)
<AnAnt> broder: so, I can sync packages that aren't on CDs ?
<broder> AnAnt: yes
<AnAnt> ok
<broder> AnAnt: note that https://wiki.ubuntu.com/BetaFreeze only mentions main and restricted
<AnAnt> ok
<micahg> AnAnt: the archive is frozen, but sources that don't affect images are usually waved through
<micahg> that wiki page needs updating
<broder> micahg: i thought non-imaged packages were actually an automatic accept and not just "usually"
<micahg> it still requires a human
<broder> right, but as automatic as anything done by a human can be
<micahg> and if someone uploaded some crazy universe package that took 2 days to build, it might not go through
<AnAnt> ok
<broder> fyi, for people who are doing the stripe ctf, they're planning to shut it down on wednesday
<tumbleweed> so soon?
<tumbleweed> broder: have you finished yet?
<broder> no :-/
<broder> but i haven't put more than about 5 minutes of serious effort into it
<broder> i know conceptually what i want to try and do, but haven't figured out how to do it yet
<tumbleweed> :)
#ubuntu-motu 2012-02-28
<quidnunc> How do I verify which DIST pdebuild is using?
<quidnunc> god damn you pbuilder
<dholbach> good morning
<_nullthree> morning
<tumbleweed> jtaylor: from #debian-ubuntu:
<tumbleweed> 12:46 < sgnb> unison has been synchronized in precise, but not unison2.32.52
<tumbleweed> 12:47 < sgnb> unison2.32.52 should be imported to precise as well, to keep  compatibility with previous ubuntu releases
<jtaylor> wtf is that for a source package name oO
<tumbleweed> compatibility package :)
<jtaylor> do you know what exactly its needed for?
<jtaylor> because I'm guessing it will fail to build + needs patching for the log
<tumbleweed> the reason in the debian upload was "to maintain compatibility with squeeze"
<tumbleweed> I'm assuming the network protocol has changed
<tumbleweed> but I left finding that out to you :P
<jtaylor> I already inquired in #debubu
 * tumbleweed saw
<geser> jtaylor: why to you expect it to FTBFS?
<jtaylor> rsvg has disappeared in ubuntu
<geser> ah
<geser> jtaylor: see also bug #941836 and bug #937596 requesting that version too
<ubottu> Launchpad bug 941836 in unison (Ubuntu) "Please add unison2.32.52 packages to precise" [Undecided,New] https://launchpad.net/bugs/941836
<ubottu> Launchpad bug 937596 in unison (Ubuntu) "Ubuntu should deliver compat package: unison 2.32" [Undecided,New] https://launchpad.net/bugs/937596
<jtaylor> meh forgot to subscribe to the package
<jtaylor> is there a tool for that btw?
<jtaylor> only know of pts-subscribe
<geser> I don't know of any for LP
<lifeless> CLI tool? you could add one to lp-dev-tools
<lifeless> but the only events LP knows about for a per-package-subscription today are bug mail
<geser> you might also want to ask sgnb if we really need 3 version of unison in the archive (there is also unison2.27.57)
<jtaylor> hm and it does not look patched for the log dir change
<jtaylor> why was that done without debian in a package that forks so often :(
<jtaylor> tumbleweed: I'll merge the unison package, do I need an ffe for that?
<jtaylor> 2.32
<geser> as it's a new source package you'll need a FFe
<jtaylor> its not really new ;)
<ScottK> It takes an archive admin to review it, so you need an FFe.
<jtaylor> k I'll reuse the existing unison ffe
<ScottK> Please don't
<jtaylor> k new one then
<jtaylor> bug 937596
<ubottu> Launchpad bug 937596 in unison (Ubuntu) "feature freeze exception: Ubuntu should deliver compat package: unison 2.32" [Undecided,In progress] https://launchpad.net/bugs/937596
<jtaylor> whats the SRU version number when the same XYbuildZ version is in a later release and is not affected?
<ScottK> How about XY0.1
<jtaylor> buildX.11.04.1?
<ScottK> Oh, wait.
<ScottK> Same version in a later release is not affected?
<micahg> jtaylor: you're in trouble, you have to rebuild the later release in any event, for versioning: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<ScottK> How does that work out?
<micahg> and the same question as ScottK ^^ :)
<jtaylor> the cause is actually a library, but the broken packages declares its dependencies in a broken way, fixing that fixes the issue
<jtaylor> the broken package is a leaf package, the library not
<jtaylor> so its safer to just fix the leaf package
<jtaylor> the library is not actually broken, it just behaves in a way not expected by the broken leaf package
<jtaylor> it does in a later release so no fix necessary
<jtaylor> but I could fix the leaf package in the later release too, it does not even declare a dependency on libc
<ScottK> That would solve the versioning problem.
<jtaylor> can armel and armhf do unaligned memory access? if no how is that handled in qemu armel?
<jtaylor> hm no to the first according to http://wiki.debian.org/ArmEabiFixes but my qemu question still stands
#ubuntu-motu 2012-02-29
<Corey> Does anyone have a git tree that they're having Jenkins turn into a dpkg?  I've got a few questions if so relating to versioning. :-)
<ScottK> You can't use the hash of the git commit for the version.  You need something montonically increasing (people usually us date based).
<Kiall> Corey, have you looked at git-buildpackage?
<Corey> Kiall: I have.
<Corey> Kiall: Unfortunately it doesn't seem to play nicely with the script I dug out for making Jenkins build the package.
<Kiall> There actually isn't much to building the package in Jenkins, gpb handles most of it..
<Kiall> http://review.managedit.ie/graphite/carbon.git is a example git-buildpackage repo i build from jenkins
<Kiall> http://review.managedit.ie/managedit/ci.git are the most recent (read: still being worked on) scripts I use to build from jenkins..
<quidnunc> How do I verify the DIST pdebuild is using?
<Corey> Kiall: Ooh.  Thanks. :-)
<Corey> Wait, first one 404'd.
<Corey> As does the second.
<Corey> Hmm.  Kiall, I think you're taunting me. :-)
<Kiall> git clone.. not your web browser ;)
<Corey> Oh jeez.
<Corey> Kiall: Which script do you call from the Jenkins project for carbon?
<Kiall> The jenkins job is basically 1 build step - http://paste.ubuntu.com/861391/
<Kiall> whj
<Kiall> whoops - cut the end off that http://paste.ubuntu.com/861392/
<Corey> Kiall: Ooh.  Are build-deb.sh and publish-deb.sh publically available?
<Corey> I've spent some time digging, and can't find this type of thing anywhere.
<Kiall> yea - in that second git repo I linked to above
<Kiall> http://review.managedit.ie/managedit/ci.git are the most recent (read: still being worked on) scripts I use to build from jenkins..
<Corey> Oh, durh. :-)
<Corey> Kiall: You have plans to turn this into a blog post at some point?
<Corey> It's hugely useful.
<Kiall> I'm still working on them, but the bones of building packages has worked for a while.. just adding sbuild / schroot support for building in a clean environment...
<Kiall> If I had a blog ;)
<Corey> Kiall: My current (badly written) script successfully uses pbuilder.
<Kiall> I've used pbuilder before, but kept hearing good things about sbuild so figured I'd give it a go ;)
<Corey> Kiall: I'll have to keep track of your progress on that. :-)
<Kiall> Sure.. I'm usually here ;)
<jtaylor> grr pytables still fails on arm!
<jtaylor> at least now 2000 test passed instead of 500
<dholbach> good morning
<danboid> Bah! Looks like we missed feature freeze - when did that occur?
<dholbach> danboid, https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
<dholbach> I guess you might be also interested in https://wiki.ubuntu.com/FreezeExceptionProcess (if applicable)
<danboid> dholbach, Thanks!
<dholbach> anytime
<sladen> danboid: two weeks ago :)  But as dholbach notes, if it's important, then a FFe would be the way to go
<danboid> sladen, Its important for users of the app in question yes and updating it wouldn't cause probs for any other apps
<sladen> danboid: sounds like the advantages outweigh the disadvantages
<ESphynx> hey guys... is there a way to generate a .dsc file without building the package?
<Adri2000> ESphynx: you want to build the source package without building the binary package(s), don't you?
<savvas> debuild -S -sa (or debuild -S -sd if you don't want to include *orig.tar.gz)
<ESphynx> Adri2000: i want to build with pbuilder...
<ESphynx> but I want to drop to a shell so I modified the package to add a failure
<ESphynx> I really don't want to build anything, I just want to update the .dsc that I already have with the matching SHA stuff
<ESphynx> maybe --preserve-buildplace is what I want
<ESphynx> thanks
<PaoloRotolo> Hi all!
<jtaylor> when merging a new source into ubuntu is there something I need to take care of?
<jtaylor> e.g. -1ubuntu1 is ok as first version number?
<geser> if it's based on -1 from Debian then yes
<Ampelbein> jtaylor: No, -0ubuntu1 if it's a new upstream not yet in Debian.
<jtaylor> it is in debian
<jtaylor> just the version in debian cannot be synced directly as it will ftbs
<Ampelbein> Then -Xubuntu1, where X = the debian revision
<phiphi> Hello, I have three points where I'd like to help: 1. Getting my headphone-jacks working correctly 2. getting my multimedia-keys working 3. Getting the package spice-xpi in the ubuntu repository
<phiphi> Who can help me achieve those?
<jtaylor> phiphi: for the first two please ask in #ubuntu, this is no user support channel
<jtaylor> on 3. we can help
<Ampelbein> phiphi: 1+2 #ubuntu, #3, the packaging guide and you can ask here for help
<micahg> phiphi: what is spice-xpi, is that a Firefox extension?
<phiphi> 1. and 2. is not meant to be user-support but hardware-support improvement
<phiphi> spice-xpi is a firefox-extension needed for accessing vms in RHEV / oVirt (SPICE-Protocol)
<directhex> there's a channel for ubuntu mozilla stuff isn't there?
<phiphi> there is already a ppa with a package of it
<micahg> we're generally not taking new mozilla extensions in the archive without a good reason and it would have to be a binary extension
<phiphi> http://blog.jebpages.com/archives/spice-spice-baby/
<micahg> is it an NPAPI only extension?
<phiphi> i think it has binary components
<directhex> the problem with mozilla extension packages is they'll break horribly when firefox 11 ships. then again with 12, etc. firefox sucks at abi compatibility - which is a problem from a long-term distro support perspective
<micahg> right, so unless it's NPAPI only, we're not likely to take it
<jtaylor> arg, I forgot to update-maintainer in planner upload
<jtaylor> is that reason enough to ask for a rejection?
<micahg> jtaylor: do you not have your ubuntu E-Mail in DEBEMAIL?
<jtaylor> I do
<jtaylor> but I must have overlooked the warning
<micahg> it should error out then
<jtaylor> it didn't
<phiphi> spice-xpi is the glue to the spice-client which is packaged in the repos. In fedora / redhat it's a package in the repo
<jtaylor> hm probably because my debemail is still the debian mail, I changed it to ubuntu by hand in the changelog
<micahg> jtaylor: right :)
<jtaylor> who reviews the packages?
<micahg> phiphi: since we're updating to a new Firefox release every 6 weeks, we don't have the resources to keep updating extensions
<phiphi> micahg: Canonical is strategic supporter of oVirt. Is there noone that should care about it? http://www.ovirt.org/about/sponsors-and-supporters/
<micahg> phiphi: idk, that might be a good reason :)
<micahg> phiphi: can you file a needs packaging bug (if there isn't one already) and subscribe me?
<broder> ...is canonical actually supporting oVirt strategically in practice? i thought we still don't even have all the pieces to run FreeIPA
<tumbleweed> jtaylor: I forget update-maintainer fairly regularly, and don't lose sleep over it :)
<micahg> broder: no idea, but I can ask about it :)
<jtaylor> some DD here you wants to sign a request for a porterbox in debian?
<jtaylor> guest account on one I mean
<tumbleweed> jtaylor: I'll happily do that, what for?
<jtaylor> I want to look at pytables
<jtaylor> I'm guessing the thing is just plain broken on !x86
<jtaylor> (and always was, it previsouly did just not execute its testsuite)
<jtaylor> I want to check how many tests fail to decide if I remove it from arm or keep it reduced functionality
<jtaylor> though its maybe not worth the trouble
<phiphi> micahg: done https://bugs.launchpad.net/ubuntu/+bug/943510
<jtaylor> there are probably 0 arm users of that package ._.
<ubottu> Launchpad bug 943510 in Ubuntu "[needs-packaging] Package spice-xpi" [Undecided,New]
<tumbleweed> jtaylor: send me a mail with this data, and I'll sponsor it http://dsa.debian.org/doc/guest-account/
<micahg> phiphi: thanks
<jtaylor> tumbleweed: http://paste.debian.net/158092/
<micahg> AlanBell: all those hi-res icons bugs need to be forwarded upstream, we're not going to carry a permanent diff for these things
<jtaylor> same hould apply to most of the quicklist bugs :/
<micahg> jtaylor: those were already addressed separately
<jtaylor> ah good
<tumbleweed> it would be nice if people asked for feedback on the ubuntu-devel list before running "submit patch" programs
<AlanBell> micahg: yes, I think mhall119 is tracking upstreaming of them too
<AlanBell> it was relating to a message on the unity-design list https://lists.launchpad.net/unity-design/msg08430.html
<mhall119> yes, sorry that the quicklist and keyword submissions are not package-patches, I didn't know enough of that to walk people through, I'm learning it currently
<micahg> I personally don't think it's worth filing in launchpad unless it's linked to an upstream bug
<micahg> even then, it would only be worth it if we need to pull it in separately or we're worrying people will report it on their own and want to show them it's already been reported
<broder> mhall119: are you on the ubuntu-devel mailing list? there was discussion about the workload created by the quicklist patches, including mentioning how the patches weren't quilted and lacked changelog entries. i was a little disappointed that you didn't see that and address it before starting another patch project
<mhall119> micahg: they should all be filing with upstream too, I'm checking in to make sure they're doing it
<mhall119> broder: I am, and I've spoken to both didrocks and seb about it
<micahg> mhall119: thanks, I'd actually suggest having people file the upstream bugs first so they can be linked right away and same developers time thinking/worrying about them
<micahg> s/same/save/
<mhall119> micahg: is there a way to manually pull the upstream bug into launchpad?
<micahg> mhall119: you link it by clicking also affect upstream, some upstream bugzilla installations can have their comments imported into launchpad once linked
<micahg> sorry, also affects project
<mhall119> broder: as soon as I learn how to make package patches, I will be blogging a tutorial on it for the people who have been following my others
<mhall119> dholbach was kind enough to give me a walk-through set of steps
<MiS-SAT> hello, I have a little packaging issue with a custom software. building it requires a custom library which lives in my ppa so pbuilder fails with pbuilder-satisfydepends-dummy: Depends: libcppinstrospection-3.0-dev which is a virtual package.
<jtaylor> is the ppa added to the sources.list of the ppa?
<MiS-SAT> however, I added OTHERMIRROR="deb http://ppa.launchpad.net/sat-metalab/metalab/ubuntu lucid main" to my .pbuilder, run pbuilder update and I am still getting the dependency error
<jtaylor> have you checked if the othermirror setting succeeded?
<MiS-SAT> yes, I have the ppa added to my sources but pbuilder seems to ignore ppa listings...
<MiS-SAT> how do I check that?
<jtaylor> just look at the sources.list
<jtaylor> can you install libcppinstrospection-3.0-dev in the pbuilder?
<jtaylor> manually
<MiS-SAT> you mean in the global /etc/apt/sources.list ?
<jtaylor> the one inside the pbuilder chroot
<MiS-SAT> oh, perhaps I should RTFM on setting pbuilder manually...
<jtaylor> pbuilder --login
<EvilResistance> ^
<EvilResistance> and then within that chroot login, you go to /etc/apt/sources.list...
<EvilResistance> and add the source in that
<jtaylor> well to change it permanently you would have to use --login --save-after-login
<jtaylor> but for the test installation use only --login to keep the chroot clean
<MiS-SAT> ah ok, thanks. So that means that my OTHERMIRROR is not taking effect (I checked and the ppa is not in sources.list)
<jtaylor> use --login --save-after-login and add it by hand, getting OTHERMIRROR use right will take much longer :)
<MiS-SAT> :)
<MiS-SAT> hmm... but even now, after adding my ppa to the sources.list, and even installing it by hand in pbuilder, it fails with the same error...
<MiS-SAT> oh, nevermind. there are some other dependecy problems. Will investigate
#ubuntu-motu 2012-03-01
<micahg> iulian: you uploaded ghc without -v :(
<directhex> MiS-SAT, --override-config flag is needed for changes to pbuilderrc to persist
<directhex> MiS-SAT, i.e. pbuilder update --override-config
<directhex> (the pbuilder image has priority over pbuilderrc, by default)
<ajmitch> micahg: you don't mind if I sync moodle for a bunch of security fixes? wasn't sure if you'd spotted that one yet :)
<micahg> ajmitch: go for it
<ajmitch> micahg: great, was more of a heads up that it was being synced, in case it gets held up for a few hours in the queue
<micahg> http://people.canonical.com/~ubuntu-archive/transitions/ghc.html (and the fun is already showing up)
 * ajmitch should get in on the fun
<micahg> ajmitch: you have to wait for ghc to build on all archs first :)
<ajmitch> micahg: in other words, probably not before I go to bed tonight? :)
<micahg> right
<micahg> well, ~7-8 hours
<ajmitch> that's what I thought
<ajmitch> assuming that the builds succeed
<ajmitch> amd64 & armhf look to have failed already
<tumbleweed> broder: I see you made it into the LWN quotes this week https://lwn.net/Articles/484521/
<broder> haha, somebody pointed that out to me
<broder> if i had known they'd be looking i would have tried to write a better soundbyte
<tumbleweed> heh
<tumbleweed> ah, good, vorlon's "To be fair, it also omits one of SystemD's greatest strengths: Roman numeral-compliant project naming. System D is obviously way better than System V." made it too
<broder> i guess it's just a banner week for ubuntu
<micahg> where are all of these
<broder> slangasek is the "development" quote of the week: https://lwn.net/Articles/484166/
<broder> they're part of the lwn weekly edition
<micahg> ah
<tumbleweed> well, that one came from a Debian flamewar^Wthread that had lots of amusing bits
<dholbach> good morning
<Laney> heya
<ajmitch> hi Laney
<Laney> myunity fan?
<ajmitch> Laney: just excited to see things backported ;)
<Laney> yar
<Kiall> Heya - I have two related packages built from separate source packages, the upstream version numbers will always match up but the package version may not. I was hoping for something like "python-carbon (= ${binary:Version})" where I can just check the upstream version number? any suggestions?
<ScottK> Kiall: {source:Version}
<ScottK> Actually, that's not right.
<Kiall> ah.. nice! Is there a list of that kind of thing anywhere?
<Kiall> Actually, that does seem correct. Googling for that turned out the deb-substvars man page, with that listed
<ScottK> source:Upstream-Version
<ScottK> Yes.  That's the place to look.
<Kiall> It seems both are listed there.. the Upstream-Version seems to included the "Debian version epoch if any."
<ScottK> source:Version still includes the package revision.  You need Upstream-Version
<Kiall> Oh. Fair enough :) Thanks
<Kiall> Will give that a go now...
<Kiall> ScottK: That worked a charm, thanks again...
<ScottK> You're welcome.
<ashickur-noor> Hi
<ashickur-noor> Need some instant advice
<EvilResistance> with?
<ashickur-noor> UBJ
<ashickur-noor> For test 12.04 and Bug reporting
<ashickur-noor> I need to know what we have to do
<ashickur-noor> how to start
<ashickur-noor> etc
<valdur55> ubuntu-bug package
<PaoloRotolo> Hi all!
<jtaylor> :( my unison upload was rejected, no the search for the reason begins again ...
<jtaylor> why does the mail not just tell you
<jtaylor> https://code.launchpad.net/~jtaylor/ubuntu/precise/unison2.32.52/lp-937596 here is the branch in case someone want to help me in the search ._.
<ajmitch> does the mail tell you who rejected it?
<jtaylor> no
<ajmitch> a little trickier then, I guess you have to ask around :)
<ScottK> The archive admin that rejected it is supposed to mail you seperately.
<ScottK> (It wasn't me)
<ScottK> jtaylor: There were some accidental rejects that are being restored.
<jtaylor> k, because I can't find an issue with the package
<arand> For backports, how strict are the criteria? Can new-in-precise packages be added?
<broder> arand: yes. what part of the criteria makes you think you couldn't?
<arand> Hmm, re-reading it againk, I guess none...
<arand> Also, new versions of multiplayer-centric games (which needs to match server-client versions), are those strictly backport-material, and not SRU-able?
<RAOF> arand: That depends case to case.
<arand> ok, I guess I'll have to dig deeper once that time comes :)
<arand> Hmm, by default only the main repo is available right?
<arand> But software centre shows universe as well? Or does it only hint about enabling it?
<arand> And if something is in universe and depends on a -data package in mutliverse, it asks for confirmation but auto-enables multiverse then, right?
<broder> packages in universe can't depend on packages in multivers
<arand> Hmm, I wonder if my package is voilating policy then :/
<arand> Ah, no they're both in multiverse, good :)
<arand> But on that note, does Ubuntu hold the same rules as Debian as to what is considered "free" with respect to artwork, music, 3D models, etc.?
#ubuntu-motu 2012-03-02
<arand> The game redeclipse contains these items, but it's not available in "the preferred form for modification" (i.e. psd files, sequencer audio project files, etc.), which is why it was packaged in Debian "non-free".
<RAOF> Multiverse is similar to non-free.
<arand> Yes, I know, but I'm asking if Ubuntu has the same criteria for data that Debian has (lately)?
<RAOF> Pretty much, yes.
<arand> Ok
<micahg> arand: the Ubuntu DFSG is slightly more lenient than the Debian version
<arand> micahg: Hmm, does it affect what is considered "source" for an audio file for example?
<micahg> arand: I'm not sure on specifics unfortunately
<arand> Well, hmm, I guess the Ubuntu Font is in the same seat really, (source files in some unaccesible-ish proprietary format), and that's in main, right? :D
<arand> Hence I figured Debian and Ubuntu's view on what 'source' entails differs slighly, and hence the requirements for Debian-Main and Universe...
<arand> But I guess it's a wasps nest, at that... :)
<micahg> arand: it's also license dependent which form is required
<arand> Yeah, in this case it's CC-BY[-SA], so that doesn't give any hint.
<arand> (or more permissive)
<crimsun> these 180-min buildd timeouts are frustrating, particularly when I can't reproduce the build failures in schroots
<John_____> This will take 10 minutes out of your life. I hope you have them:)) . We will be extremely grateful. We love Ubuntu. We hope Ubuntu developers are nice. I have never ever asked any Ubuntu dev. for any 'favour' since my adventure with Ubuntu started 5 years ago.  It looks like nobody has cared for 1.5 years (will be at the release time of 12.04). Over a year ago Ralink open sourced their drivers (links below), Fedora applied t
<John_____> I've searched the issue on the net. Many (believe me) people are outraged and any solution is really bad. I tried to install manually, but failed due to failed initramfs update (perhaps it doesn't update on an USB flash drive...). Everyone hoped Ubuntu to pick it up- its on 11.10 bug report under 810111)
<John_____> The solution to apply the patches from OpenSuse  (more likely they are NOT needed at all for the newer driver version below) and installing the drivers manually every time there's a kernel update is not nice. Talk about long FIVE YEARS. Dreadful. Hope you are a nice person and will help me (or more precise: us).
<John_____> The solution to apply the patches from OpenSuse  (more likely they are NOT needed at all for the newer driver version below) and installing the drivers manually every time there's a kernel update is not nice. Talk about long FIVE YEARS. Dreadful. Hope you are a nice person and will help me (or more precise: us).
<John_____> Please update patches for Ralink RT5390 to the (X)Ubuntu 12.04 LTS. Its critical not just for me (...). I hope you are nice person and will fix the bug as soon as possible and get back to me when its available in Xubuntu nightly build. Its getting close to LTS release and I have nobody to rely upon. I hope you folks in Ubuntu are nice. Otherwise I will be stuck with sloooooow yum (despite the fastestmirror-plugin), and other 
<John_____> Please update patches for Ralink RT5390 to the (X)Ubuntu 12.04 LTS. Its critical not just for me (...). I hope you are nice person and will fix the bug as soon as possible and get back to me when its available in Xubuntu nightly build. Its getting close to LTS release and I have nobody to rely upon. I hope you folks in Ubuntu are nice. Otherwise I will be stuck with sloooooow yum (despite the fastestmirror-plugin), and other 
<John_____> This driver is required for many, many, many HP laptops.   Thanks in advance, (X)Ubuntu Lover, John  Open Source RT539x: http://www.ralinktech.com/en/04_support/license.php?sn=5001  All Ralink Linux drivers: http://www.ralinktech.com/en/04_support/support.php?sn=501
<John_____>  PS. I hope this time the AMD Northern Islands drivers will be ready and jockey in 12.04 will install them. No compiz tearing and no video tearing (sync to vblank).
<crimsun> John_____: you're better off filing a bug against 'linux' and providing links to the Fedora and openSUSE bug reports.
<crimsun> John_____: please be aware that we're past feature freeze, so it's highly unlikely those drivers will land in 12.04.
<John_____> kernel freeze is in 5 weeks, its not a feature, its driver long overdue
<John_____> bug is inder: 810111 in 11.10 its still stands
<crimsun> John_____: it is a feature addition, since the current kernel does not ship a driver.
<crimsun> John_____: regardless, this irc channel is not the best venue; please file a bug report against 'linux' as recommended earlier. You may also contact kernel-team at lists.ubuntu.com, and there is an irc channel: #ubuntu-kernel.
<John_____> feature is a button, it will take less time than your denial, sorry you are rude I'm out
<ajmitch> classic example of how not to motivate developers to jump to demands
<dholbach> good morning
<dholbach> happy fix it friday! :)
<dholbach> is anyone here for Fix It Friday? :)
<vibhav> I actually know a bit of packaging
<vibhav> But cant fix bugs :(
<vibhav> IS it important to be a developer to apply for MOTU ?
<dholbach> welcome vibhav, no, you don't need to be member of a team to be able to fix bugs
<vibhav> dholbach: What I meant was that *I dont know how to fix bugs* but wanted to apply for MOTU
<dholbach> as long as you just attach patches to bug reports and subscribe 'ubuntu-sponsors', or bzr branch from ubuntu:<package>, push your changes to Launchpad and propose a merge, your suggested changes should turn up in review queue where somebody will take care of them
<dholbach> ah ok
<dholbach> you might want to have a look at http://developer.ubuntu.com/packaging/html/fixing-a-bug.html then
<dholbach> (if you know some bits of packaging already)
<vibhav> I know packgaing, but I dont know a programming language :(
<dholbach> otherwise http://developer.ubuntu.com/packaging/html/introduction-to-ubuntu-development.html and http://developer.ubuntu.com/packaging/html/getting-set-up.html might be interesting too
<dholbach> why don't you start with an easier bug then - today we wanted to have a look at bugs which have been fixed elsewhere
<dholbach> https://bugs.launchpad.net/ubuntu/+bugs?field.status_upstream=resolved_upstream&orderby=-id is the bug list
<dholbach> in an ideal case it would "just" be a matter of finding the fix either upstream or in Debian (or another distro) and applying it to the Ubuntu package
<vibhav> thats interesting
<dholbach> cool :)
<vibhav> dholbach: thanks
<dholbach> if there's anything else which is unclear, just ask :)
* dholbach changed the topic of #ubuntu-motu to: REVU is back up | Precise: Feature Freeze | Want to get involved with the MOTU? https://wiki.ubuntu.com/MOTU/Contributing | Sponsor queue: http://bit.ly/fz6AyQ | http://qa.ubuntuwire.com/ftbfs | http://people.canonical.com/~ubuntu-archive/NBS | http://qa.ubuntuwire.com/bugs/rcbugs/ | Fix-It Friday: http://pad.ubuntu.com/OsSL8mOs2o
<dholbach> I added links to docs, TODO lists and so on to http://pad.ubuntu.com/OsSL8mOs2o - it'd be great if everybody listed what they worked on on the pad as well - that'll make writing a summary of the event later on much much easier :)
<vibhav> dholbach: I package through debuild, is that fine?
<dholbach> yes
<vibhav> dholbach: For example , I want to package Unity Fixing this bug: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/943223
<vibhav> I downloaded the source, what do I need to do now?
<dholbach> vibhav, unfortunately this might be a bad example - as far as I know this has been packaged in a PPA already and will soon be released to Ubuntu, but didrocks would know more about this
<didrocks> there are still regressions in the release candidate
<didrocks> so we are fixing them before releasing in ubuntu
<vibhav> I see
<didrocks> and this fix is even not confirmed
<didrocks> so just need to be patient :)
<dholbach> didrocks, so it might be better for vibhav to pick another "fixed elsewhere" bug?
<didrocks> dholbach: I would mean, don't package unity right now ;)
<dholbach> ok :)
<didrocks> as we are in a release mode, everything will go in the current release
<vibhav> Let me start again
<vibhav> What I have to do is, find a random package with a bug fixed upstream
<vibhav> Download the patch, apply the patch and package it, right?
<dholbach> yes, that should be it
<dholbach> ciao xdatap1
<vibhav> From where do I find programs whose bugs are fixed upstream?
<dholbach> https://bugs.launchpad.net/ubuntu/+bugs?field.status_upstream=resolved_upstream&orderby=-id
<xdatap1> dholbach, guten morgen!
<dholbach> xdatap1, come stai? cosa fai?
<xdatap1> dholbach, I'm taking care of my new baby: https://wiki.ubuntu.com/ItalianCD
<xdatap1> dholbach, tonight I released the first image, based on beta1, for testing
<dholbach> wow
<dholbach> good work
<xdatap1> dholbach, *last night, I meant
<xdatap1> dholbach, thanks, we're all very excited about it
<xdatap1> dholbach, If you're interested in the work in progress I created an english BP: https://blueprints.launchpad.net/ubuntu-defaults-it/+spec/precise-default-it
<vibhav> dholbach: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/261595 IS fixed upstream, from where do I find its patch?
<dholbach> vibhav, if you have a look at the top of that page, you see two lines one saying   "Mozilla Thunderbird"   and one saying  "thunderbird (Ubuntu)"
<dholbach> both show the status of the same bug both Upstream and in Ubuntu
<vibhav> dholbach: yes
<dholbach> Upstream the bug was marked as "Invalid"
<dholbach> so it's not necessarily fixed upstream
<vibhav> ok
<vibhav> dholbach: I found this bug https://bugs.launchpad.net/ubuntu/+source/elfutils/+bug/934433
<vibhav> From where do I get its patch?
<dholbach> in the line where it says "elfutils (Debian)", do you see the "debbugs #657139"?
<dholbach> that's a reference to the upstream bug report
<vibhav> yes
<vibhav> I just went to that URL
<dholbach> oh and in the bug report itself there's a patch too
<dholbach> and the 'ubuntu-sponsors' team is subscribed to the bug already
<dholbach> so that one is likely handled already
<dholbach> you seem to be really good at picking the false positives :-/
<vibhav> :(
<dholbach> let me see if I can find one for you
<vibhav> thanks
<dholbach> but it is like that, sometimes you need to put a bit detective work into it
<dholbach> don't give up yet :)
<vibhav> This  is interesting though
<dholbach> https://bugs.launchpad.net/ubuntu/+source/cssutils/+bug/931624 might work for example
<ubottu> Launchpad bug 931624 in cssutils (Ubuntu) "Test suite fails" [Undecided,New]
<dholbach> or https://bugs.launchpad.net/ubuntu/+source/amavisd-new/+bug/930916
<ubottu> Launchpad bug 930916 in amavisd-new (Ubuntu) "amavis start-stop script fails to stop amavisd" [High,Confirmed]
<vibhav> dholbach: The second bug, from Where do I get the patch now?
<dholbach> vibhav, one option would be to download the source package from Ubuntu and Debian and diff the initscripts in there
<tumbleweed> dholbach: the cssutils issue is fixed in Debian (where it's maintained by an ubuntu developer), and the tests are disabled in Ubuntu
<dholbach> tumbleweed, ah, so we can close that one?
<tumbleweed> I think porthose_spider wanted to sync it
<tumbleweed> but yes, the temporary disabling of tests means it can be closed, I think
<dholbach> great :)
<broder> tumbleweed: ran into some friends of yours at the stripe ctf event today, though i don't remember their names at all
<tumbleweed> broder: ah, so it was you, they remembered an "aron" :P
<broder> heh
<dholbach> broder, hey Aron - how are you doing? :)
<dholbach> thanks for helping out with the d-a-t :)
<broder> dholbach: hey :) np - things are good. looking forward to spending some time this weekend jamming. how're you?
<dholbach> good good - reviewing a couple of things from the sponsoring list and trying to help out with Fix-It Friday
<broder> yeah, i think i'm likely to spend most of my jam time working on the queue
<dholbach> it's great - today is not only the start of Global Jam and Fix It Friday, but also an ARM Porting Jam from the ARM/Linaro folks
<tumbleweed> dholbach: thanks for kicking of the doc-testing, sorry I'm tied up in moving house atm
<tumbleweed> (which also means I'm not doing a global jam, but maybe I can get some people together next week...)
<dholbach> tumbleweed, don't worry - sometimes it takes a bit to realise that it's better to bundle initiatives :)
<vibhav> dholbach: I downloaded the packages, is the init script amavisd_init.sh ?
<dholbach> vibhav, I would download both packages (from Ubuntu and Debian) and check the changes between the two for the files ./amavisd_init.sh and ./debian/amavisd-new.init
<vibhav> dholbach: I found out the changes
<dholbach> cool
<vibhav> now?
<dholbach> check out the fixing a bug in ubuntu article I mentioned earlier
<dholbach> I need to step out for a bit now, so if you have any more questions or if anything's unclear, just ask in here and somebody else might be able to help
<debfx> Rhonda: wesnoth-1.8 and wesnoth-1.10 have some overlapping binary packages. should I just drop them from wesnoth-1.8?
<dholbach> who do we have here for Fix-It Friday? Are there any open questions? How are you all doing?
<jokerdino> oh yeah, it is Fix-it Friday today. *must fix something*
<dholbach> jokerdino, woohoo :)
<dholbach> I added the Fix-It Friday page to the topic
<dholbach> there's a TODO list if you can't think of anything :)
<jokerdino> I have a bookmark of bugs that I can try to fix. :D
<broder> dholbach: battery is dying and i should probably go to bed, but http://qa.ubuntuwire.com/bugs/rcbugs/ can be a good source of things to fix
<dholbach> ah yes
<dholbach> of course
<dholbach> adding
<jokerdino> i have been looking at the delta-with-unity tagged bugs. like this https://bugs.launchpad.net/unity-2d/+bug/910167
<ubottu> Launchpad bug 910167 in unity-2d (Ubuntu) "In Unity-2D, the desktop does not have a global menu" [Low,Confirmed]
<broder> dholbach: and there are still bugs marked bitesize
<dholbach> jokerdino, wow - good luck with that one
<broder> though that tends to be hit or miss
<dholbach> maybe a number of us could get together to put a "real TODO list" together
<dholbach> like a pre-filtered TODO list
<dholbach> next Thursday :)
<broder> it'd definitely be good to have
<broder> i never feel like i have a good answer whne somebody asks me what they should work on
<jokerdino> i think the bitesize tag on the bug report is not fair.
<dholbach> and if it's 3-4 people working together, I'm sure you can easily get together 50 bugs/items in around 15 minutes
<broder> (i personally don't like giving ftbfs or sync/merges to new people)
<dholbach> I agree - some of them are quite hard - the best thing I can say about it is "it's a learning experience" :/
<dholbach> you get to know how the bug tracker works, where to look for patches, etc
<broder> heh
<ajmitch> hi
<dholbach> but it's by no means a "go through commands 1) to 5) and you're done"
<jokerdino> dholbach: i think i can work with you to identify the easy bugs, i found quite a few when i was scourging the harvest.
 * broder actually goes to bed now. 'night, folks
<dholbach> broder, good night
<dholbach> hey ajmitch
<geser> Hi ajmitch and dholbach
<dholbach> jokerdino, let's try to put something together for next Fix-It Friday then - maybe on Thursday
<dholbach> hi geser
<jokerdino> dholbach: sure
<dholbach> awesome, thanks jokerdino
<Laney> ããã«ã¡ã¯
<ajmitch> Laney: and hello to you too
 * micahg wonders if anyone is working on ghc rebuilds/syncs
<Laney> ajmitch in japanese speaker shocker
<ajmitch> Laney: sadly not
<ajmitch> micahg: are there still some to be done? :)
<micahg> also, the tracker doesn't seem to show the uninstallablility on armhf
<Laney> because it failed to build
<micahg> hmmm, archive page shows it passed
<micahg> oh, wait, I"m looking at the wrong one
<micahg> that would explain why no one's started the rebuilds :-
<Laney> yeah
<ajmitch> amd64 & armel built in the end?
<Laney> i wonder if you can give -mfloat-abi=hard to the build system
<ajmitch> last I saw they'd both failed
 * micahg kicks off a test build
<Laney> i think armel was always fine, amd64 is ok too
<Laney> you have hardware?
<micahg> ajmitch: armel seems to have worked
<micahg> Laney: porter box ;)
<Laney> nice
<Laney> bung an -optc in an armhf conditional then
 * ajmitch was just watching the builds after it was uploaded & approved
 * micahg has hardware, but the porter box is faster
<ajmitch> maybe my memory is shot & I'm going senile
<jokerdino> devs, is this one really a bitesize? https://bugs.launchpad.net/unity-2d/+bug/910167
<ubottu> Launchpad bug 910167 in unity-2d (Ubuntu) "In Unity-2D, the desktop does not have a global menu" [Low,Confirmed]
<jokerdino> ;(
<Laney> no
<Laney> you can just remove the tag from inappropriately tagged stuff
<jokerdino> lol, i have been trying to find how to start fixing it.
<dholbach> jokerdino, maybe one of the resolved_upstream bugs or the debian rcbugs might be better? (unless you want to get into unity hacking :-))
<jokerdino> may be those are better
<jokerdino> as long as i don't need to propose a branch, i will work with anything,
<dholbach> you can also attach a patch to a bug report and subscribe ubuntu-sponsors if you like
<jokerdino> i prefer the last one, attaching the patch works well.
<dholbach> cool
<jokerdino> how do i go about fixing rcbugs?
<jokerdino> i am looking at hamster-applet
<dholbach> jokerdino, you would have a look at the differences between the debian and ubuntu package and figure which change needs to be applied in Ubuntu
<dholbach> it seems the Ubuntu package has changes not yet in Debian (2.91.3+git20110714.9aefd7-2ubuntu3 indicates there were 3 uploads to Ubuntu)
<dholbach> so either we can identify how exactly this serious bug (http://bugs.debian.org/654474) was fixed, or we perform a merge between the debian and ubuntu package
<ubottu> Debian bug 654474 in hamster-applet "Doesn't contain source for waf binary code" [Serious,Fixed]
<dholbach> if we should find that the Ubuntu changes can be overwritten, we could sync the package
<jokerdino> would bzr branch lp:hamster-applet get me the ubuntu package?
<ajmitch> lp:ubuntu/hamster-applet
<jokerdino> thanks ajmitch
<jokerdino> Packaging branch version: 2.91.3+git20110714.9aefd7-2ubuntu1
<jokerdino> Packaging branch status: OUT-OF-DATE
<jokerdino> ?
<ajmitch> that's a bit of a pain when that happens
<micahg> jokerdino: grab-merge should work as it's in testing
<jokerdino> i see
<jokerdino> give me a while, it takes a while to get the branch
<jokerdino> and how do i get the debian package?
<micahg> jokerdino: grab-merge will get you the current Ubuntu and Debian packages (in non-bzr form)
<rsajdok> dholbach: I am working on bug in loco-team-portal. Should I prepare css or only code of python and html?
<rsajdok> https://bugs.launchpad.net/loco-team-portal/+bug/720824
<ubottu> Launchpad bug 720824 in LoCo Team Portal "break up past events and meetings by year/month" [Medium,In progress]
<Rhonda> debfx: Uhm, is there an update for wesnoth-1.8 needed in precise?  I thought uploading wesnoth-1.10 did already drop them from 1.8?
<dholbach> rsajdok, I would suggest asking in #ubuntu-locoteams - people like daker, mhall119, cjohnston should be able to help you out (some of them might not be up yet)
<dholbach> rsajdok, but feel free to change whatever is necessary
<Rhonda> debfx: What update is needed for 1.8?  I am curious about that.
<debfx> Rhonda: just a no-change rebuild
<debfx> which failed to upload: https://launchpadlibrarian.net/94848743/upload_3454613_log.txt
<micahg> Laney: well, passing that flag failed for me, but I probably did it wrong (janimo says it's the default for gcc anyways), he's having a look in a bit
<Rhonda> This issue doesn't exist in Debian because binNMUs won't replace arch:all packages.
<jokerdino> micahg: "It looks like this package is maintained in revision control:"
<jokerdino> it says don't continue
<Rhonda> debfx: Sure, because the versions are older indeed. :)  Yes, drop those four from debian/control{,.in}
<Rhonda> Those are the meta packages that help people with the upgrade and noticing the new release.
<jokerdino> now that i got both the packages, i should untar them right?
<micahg> jokerdino: you can use the debdiff command along with filterdiff (I usually create a source package with the Ubuntu changes applied and then debdiff against the Debian upload to see if they're still relavent)
<micahg> jokerdino: the script should create the new source dir for you with the previous patches applied (unless they failed, that'll show in the REPORT file)
<debfx> Rhonda: ok, will do
<jokerdino> micahg: it says conflicting changes have been made
<micahg> jokerdino: so you have to resolve those manually, they should be visible in the filed
<micahg> *files
<Laney> micahg: oh ok, I really have no clue about this but it looks to me like some option is being passed incorrectly
<Laney> i'm sure janimo can sort it
<ajmitch> boo, syncpackage died on me
<toabctl> what's the best way to show bugs for a source-package? ie i want to see all bugs from networkmanager i go to https://bugs.launchpad.net/ubuntu/+source/network-manager/ but the bug order is imho useless. the most important bug is from 2008..
<jokerdino> micahg: no idea how i am supposed to do that. is it possible if you can go through them one by one? :S
<dholbach> toabctl, you can sort by "number" - would that be helpful? what are you looking for?
<toabctl> dholbach, i want to see only precise bugs ordered by date.
<micahg> jokerdino: well, ask your questions, and I'm sure someone here can help (I might not be available)
<toabctl> dholbach, i just don't understand why the default order seems to be useless
<dholbach> toabctl, the default order is based on bug importance
<jokerdino> well, after grab-merge, what should i be doing?
<toabctl> dholbach, then imho bug importance is useless. why is a bug from 2008 most important?
<dholbach> toabctl, I don't know - maybe the bug importance should be changed then :)
<dholbach> jokerdino, you seem to have a knack for picking the hard ones :)
<jokerdino> i am so lucky \o/
<dholbach> jokerdino, the 'motion' package on the same list might be easier for example
<dholbach> let me see if I can find anything else
<toabctl> dholbach, is there a better interface to get the bugs? maybe command line tools?
<jokerdino> ah, cool. dholbach i am now looking at motion.
 * jokerdino is away for dinner now.
<dholbach> toabctl, it depends on what you are after - do you want to triage new bugs that came in? does the 'heat' order help?
<dholbach> there might be command line tools, but I don't know
<toabctl> dholbach, i want to see the newest bugs but only for NM.
<dholbach> sort by 'number'?
<dholbach> on the page you mentioned above
<toabctl> dholbach, ahh. the number is what i missed. thanks!
<dholbach> :)
<dholbach> jokerdino, pornview might also be easier
<dholbach> and then generally: all the unmodified packages in Ubuntu - in their case it will be interesting to find out how much else was changed, so we don't end up bringing up huge changes just to fix a small bug
<ajmitch> quite a few of those will have comments, too
 * dholbach nods
 * ajmitch is doing a few on the list at the moment
 * ajmitch thought all kernel-patch-* packages were blacklisted from syncs
<ajmitch> yet there's a https://launchpad.net/ubuntu/+source/kernel-patch-viewos which is horribly out of date :)
<dholbach> might be a good idea to get rid of it :)
<ajmitch> yeah, was just checking up on it before I asked for removal
<ajmitch> ok, filed bug
<dholbach> awesome
<dholbach> I wonder who else came here for Fix-It Friday - maybe you could do a round of introductions? :)
 * ajmitch should probably leave soon, it's no longer friday here
<micahg> ajmitch: bug  944672 :P
<ubottu> Launchpad bug 944672 in clisp (Ubuntu) "FFe: Sync clisp 1:2.49-8.1 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/944672
<ajmitch> micahg: sigh, sorry
<ajmitch> I did ask you about this one a few days ago, too :)
<micahg> ajmitch: more concerned that you didn't notice it needs an FFe ;)
<ajmitch> I didn't think that it was needing an FFe for that change?
<micahg> well, libdb5.1 dropped a feature and this required a specific source patch, I figured it was worth asking for one
 * ajmitch will just stop now then
<micahg> ajmitch: don't stop on my account ;)
<ajmitch> no, I'll stop because I'm screwing up the archive :P
<geser> ajmitch: a) it's Friday, so a good time to screw up the archive :) and b) you give dholbach tasks for his Fix-It-Friday :)
<dholbach> geser, it's not *MY* Fix-It Friday :)
<dholbach> seriously - we all want more contributors to development, no? :)
<geser> yes, and hopefully they stay longer than one Friday
<dholbach> :)
<geser> and also contribute on the other days of the week
<dholbach> so what are you all working on?
<jokerdino> so dholbach now that i have the packages for motion, how do i proceed? i have no idea what i should be doing.
<dholbach> jokerdino, so the line on the page says that between motion 3.2.12-3ubuntu2 in ubuntu and 3.2.12-3.1 in debian, debian bug 640562 was fixed
<ubottu> Debian bug 640562 in motion "FTBFS against libav/0.7.1" [Serious,Fixed] http://bugs.debian.org/640562
<dholbach> now it's interesting to do some archaeology and figure out what the changes between the two packages are
<dholbach> you might find one of the following things:
<dholbach>  - there's an interesting change we should have, but there's too many other things in the change as well, so we "cherry-pick" the interesting change
<dholbach>  - there's an interesting change we should have, and our changes were integrated in debian too, so we can sync from debian (basically overwrite our package)
<dholbach>  - there's an interesting change we should have, but we can't overwrite all our changes, so we need to do a merge
<dholbach>  - there's nothing interesting
<dholbach> I think that's all :)
<dholbach> so running a     debdiff motion_*.dsc | less     should give you a basis for archaeologic studies :)
<jokerdino> Need exactly two deb files or changes files to compare
<jokerdino> Weird thing is weird
<dholbach> how many motion*.dsc  files do you have there? :)
<jokerdino> three :/
<dholbach> ok
<dholbach> debdiff motion_3.2.12-3ubuntu2.dsc motion_3.2.12-3.1.dsc | less
<dholbach> basically: diff the source packgae from ubuntu against the one from debian
<jokerdino> so i ignore the base package i see
<dholbach> what do you mean by "base package"?
<jokerdino> the common ancestor from which the ubuntu and debian package came from?
<jokerdino> that's what the report file says
<dholbach> ah, yes
<dholbach> sure, if a reviewing a diff gets too complicated, you can do that
<dholbach> the good thing is: both the recent Ubuntu and Debian versions are based on the same version just one upload (in the case of Debian) and two uploads (in case of Ubuntu) before
<dholbach> so it shouldn't be too crazy
<jokerdino> so i found the part that fixes the relevant bug.
<dholbach> as the Ubuntu changes fixed the build with a recent libav, it might worth doing a test-build of the current debian package, without any ubuntu modifications
<jokerdino> how do i build a package locally?
<dholbach> http://developer.ubuntu.com/packaging/html/getting-set-up.html#set-up-pbuilder
<jokerdino> wow, this is so intense :S
<dholbach> I'm glad you like it :)
<jokerdino> i choose not to give up.
<dholbach> good :)
<dholbach> at the beginning it's important to understand a few concepts and workflow bits
<dholbach> at some stage (I'd say quite soon), you'll know which tool to pick and a bunch of commands will go into muscle memory quickly :)
<jokerdino> ah yeah. initially i found basic debian packaging quite hard, but now i can do a bit more stuff easily
<dholbach> and you're doing much better than many others - lots of others gave up earlier :)
<jokerdino> i will get back to you when the pbuilder finishes downloading the relevant parts :)
<dholbach> it caches them, so you just have to go through this once :)
<jokerdino> heh nice.
<jokerdino> but i need to do this for the ubuntu version as well?
<jokerdino> is this command right? pbuilder-dist sid create build motion_3.2.12-3.1.dsc
<jokerdino> or is it wheezy instead of sid?
<dholbach> no, unfortunately not
<dholbach> try: pbuilder-dist precise build
<dholbach> err, sorry
<dholbach> try: pbuilder-dist precise create
<dholbach>     pbuilder-dist precise build motion_3.2.12-3.1.dsc
<dholbach> you don't want to test if it builds fine in Debian sid, but if it also builds in precise (without the Ubuntu modifications)
<jokerdino> i should be building the unmodified debian package in precise, hmm
<dholbach> yes
<babai> afaik pbuilder caches the minimum deps for building packages, i have a slow internet connection, anyone knows the size of the 'minimum'?
<sagaci> around 50-100mb
<babai> k, thnx
<dholbach> jokerdino, we want to check if the debian package would also build in ubuntu (without ubuntu modifications)
<dholbach> babai, if you just want to do a quick build test, you can also build the package by running "debuild" in the source package tree
<jokerdino> yes, i understand that :)
<dholbach> ok :)
<jokerdino> it makes no sense to test for debian
<babai> dholbach: hmm, i want to build for stable releases also, so  i need pbuilder
<dholbach> babai, the reason we recommend pbuilder ist that you can make sure that the package builds in a reproducible way (without relying on local changes you made to your system)
<dholbach> babai, ok - that's fine :)
<l3on> Hi all ... I need a sponsor for nmu ... somebody around? (debian bug 660044)
<ubottu> Debian bug 660044 in src:flowscan "flowscan: FTFBS since netbase 4.47" [Serious,Open] http://bugs.debian.org/660044
<l3on> it also causes ftbfs in Precise
<dholbach> ciao l3on, you could try to ask in #debian-ubuntu on irc.oftc.net
<l3on> ok, thanks dholbach :)
<geser> Laney: is http://people.canonical.com/~ubuntu-archive/transitions/ghc.html for the current ghc transition? (or an old one?)
<Laney> current
<Laney> i'm not sure if stuff will build against old ghc on armhf though
<geser> should haskell-platform be also included in that list? see bug #944742
<ubottu> Launchpad bug 944742 in haskell-platform (Ubuntu) "missing ghc-7.0.4 in precise i386 " [Undecided,New] https://launchpad.net/bugs/944742
<Laney> yeah probably
<Laney> not fixed in debian though either
<jokerdino> dholbach: the debian package builds well
<dholbach> jokerdino, excellent - so it looks like we can completely replace the Ubuntu source with the one from Debian
<dholbach> and as its only bug fixes, we can get it in without filing any freeze exceptions
<dholbach> jokerdino, what's your launchpad id?
<jokerdino> ~jokerdino
<dholbach> great, I'll sync the package in your name
<jokerdino> launchpad.net/~jokerdino
<dholbach> well done
 * jokerdino hugs dholbach.
 * dholbach hugs jokerdino back :)
<dholbach> done
<jokerdino> heh awesome.
<jokerdino> where do i verify if i actually haven't made a mistake and the package did build properly?
<dholbach> jokerdino, if the build passed without any errors and you see the resulting .deb files in ~/pbuilder/*_result/ you should be fine
<geser> jokerdino: you can also watch the build of the upload on https://launchpad.net/ubuntu/+source/motion/3.2.12-3.1 , the "Builds" section
<jokerdino> awesome, motion is sitting right inside
<jokerdino> thanks geser
 * dholbach takes the dog for a walk - brb
<Kiall> Heya - What is the recommended way to restart/reload a service from a postinst script - without caring if its a traditional or upstart script?
<Kiall> something like if [ -e /etc/init/bla.conf] .. else ... or?
<dupondje> https://launchpad.net/ubuntu/+source/cryptsetup -> is there a change a merge of this would still be accepted now ?
<dupondje> chance*
<Kapil> HI guys, so what are your expectations from 12.04?
<valdur55> Hey! Good Fixit Friday!
<dholbach> hey Kapil, hey valdur55 :)
<dholbach> dupondje, are the changes mostly bug fixes?
<vibhav> dholbach: I am a bit confused now, how do I apply the diff to to theamavisd-new.init
<vibhav> the amavisd-new.init
<dholbach> vibhav, if you want to merge all changes, you could just copy the file over
<dholbach> if you just wish to merge select changes, you can do it manually by just editing the file
<vibhav> dholbach: Copied the file, what do I need to put in the changelog?
<dholbach> vibhav, http://developer.ubuntu.com/packaging/html/fixing-a-bug.html#documenting-the-fix
<jokerdino> dholbach: pornview is a pain.
<jokerdino> https://bugs.launchpad.net/ubuntu/+source/pornview/+bug/935370 ;(
<ubottu> Launchpad bug 935370 in pornview (Ubuntu Precise) "pornview version 0.2pre1-11ubuntu2 FTBFS on i386 in precise" [High,New]
<dholbach> ok
<dholbach> then pick another :)
<jokerdino> snowballz?
<dholbach> snowballz has a comment - on the very right of the page
<dholbach> I don't know how much additional problems that's going to be
<vibhav> dholbach: I am a bit confused now, how do I apply the diff to to theamavisd-new.init (LP: #930916)
<vibhav> oops
<jokerdino> ok then, i will look at something else. haha
<vibhav> Sorry dholbach
<dholbach> vibhav, no worries
<jokerdino> i feel proud of myself. haha
<vibhav> dholbach: I meant , shall I write "Update amavisd-new.init from upstream (Fixes LP: 930916)
<vibhav> updated*
<dholbach> "(LP: #930916)" is the syntax to get the bug automatically closed
<dholbach> and I'd probably try to explain what exactly the fix from Debian fixed
<dholbach> jokerdino, you could take a look at ldb - it is unmodified in Ubuntu, has received fixes in Debian - if you should find that it builds and works fine in Ubuntu and that there are only good bug fixes and not huge other modifications in the package, that might be a good fix for Ubuntu
<dupondje> dholbach: nothing really special.
<dholbach> dupondje, if it's bug-fixes, then yes - https://wiki.ubuntu.com/FreezeExceptionProcess explains how things work after Feature Freeze
<vibhav> dholbach: Edited the changelog, what do I do now?
<Rhonda> debfx: hmm, the changelog now only contains the dropping of the metapackages and no information why the rebuild was needed? :)
<l3on> Ampelbein, hey... Are you sure about bug #931720 ? I can't reproduce it :/
<ubottu> Launchpad bug 931720 in librsvg (Ubuntu) "FTBFS on amd64 in precise: /Â«PKGBUILDDIRÂ»/gtk-engine/svg-main.c:63: undefined reference to `g_module_make_resident'" [High,Incomplete] https://launchpad.net/bugs/931720
<debfx> Rhonda: I didn't change the changelog entry of the rebuild upload
<dholbach> vibhav, you can ask the others in here as well - not just me :)
<dholbach> vibhav, but yeah, try running   debuild -S
<dholbach> so you generate a new source package from your changes
<dholbach> and then try to build it with pbuilder
<vibhav> Is pbuilder a must?
<Ampelbein> l3on: I'll retry the the build when I get a chance. Could have been a temporary issue.
<Ampelbein> vibhav: No, but it's highly recommended. With pbuilder/sbuild you build in a clean environment, making the build behave more like on the launchpad builders.
<vibhav> Ampelbein: Cant I get it to build it somewhere else?
<jokerdino> there is no ldb that i can grab :(
<Ampelbein> vibhav: What is the first "it" referring to?
<vibhav> Ampelbein: The fixed package
<jokerdino> oh wait grab-merge won't work if there is no diff?
<dholbach> vibhav, you could also upload it to PPA or build it locally by just running 'debuild' in the source tree
<dholbach> jokerdino, you can run "apt-get source <...>" and "pull-debian-source <...>"
<Ampelbein> vibhav: Like dholbach said, in a ppa or with debuild or dpkg-buildpackage.
<vibhav> dhAfter running debuild, where do I need to submit the package?
<dholbach> vibhav, do   debdiff <old>.dsc <new>.dsc > ~/<package>.debdiff
<dholbach> and attach it to the bug report you're working on
<dholbach> and subscribe the 'ubuntu-sponsors' team, so it ends up in the review queue :)
<Rhonda> debfx: oh, right, it's partly visible in what mom did mail me, just not with a + at the start of the line. Sorry :)
<jokerdino> ldb has no ubuntu source package, but i did download the debian package
<debfx> mom sends mails?
<dholbach> jokerdino, it does have a source package in ubuntu
<dholbach> can you check in software-properties you have "Source code" enabled?
<jokerdino> oh that one?
<jokerdino> i don't have it on
<dholbach> enable it and try again :)
<vibhav> Ampelbein, dholbach : thanks
<dholbach> if apt-get doesn't know where to get source packages from, it won't download anything :)
<dholbach> vibhav, anytime :)
<Rhonda> debfx: yes, To: wesnoth-1.8@packages.qa.debian.org  :)
<vibhav> Also, how do I know which file do I need to edit while fixing bugs?
<Rhonda> i.e., PTS keyword "derivatives".
<dholbach> vibhav, sometimes you need to do some detective work to find out, but "grep -r ........" is often very helpful
<vibhav> dholbach: I did not understand , what do I need to type after "grep -r "?
<dholbach> type "man grep" - it will show you some information about the grep command
<dholbach> but    grep -r <search> <path>    usually is a huge help to search for something in a source package
<vibhav> i see
<dholbach> there's a bunch of new people here - I hope you're all here for Fix-It Friday :)
<dholbach> I'm wondering if some of you would be interested in chatting a bit in a Google+ Hangout
<dholbach> and maybe be more comfortable asking questions there
<dholbach> I still have 50 minutes until I have another call - I'll just set one up and we see how it goes :)
<jokerdino> dholbach: the debian version of ldb builds well
<dholbach> jokerdino, great - now you just need to make sure that it doesn't add huge amount of new features and just fixes bugs we're interested in seeing fixed
<dholbach> in that case we should be able to sync it and get those bugs fixed
<jokerdino>  * New upstream snapshot.
<jokerdino>    + Extracts waf source code. Closes: #654482
<jokerdino>    + Disable tdb2 support.
<jokerdino> that's all you got
<dholbach> it might be good to inspect the diff
<dholbach> and see if there's another more detailed changelog in there
<dholbach> https://plus.google.com/hangouts/d3e6d86b708ed0838b233de40dad8aab9ed4f246 for everyone's who interested in chatting a bit and asking all their questions about ubuntu development :)
<randy_> hello i have a question
<dholbach> hello randy_
<dholbach> what's your question?
<randy_> i use a tablet and when i use onboard (the default on screen keyboard) i often have to unselect then reselect the window i am using in order for ubuntu to not unfocus the window
<randy_> is there a known bug concerning this and if so is this being worked on
<dholbach> randy_, try asking the folks in #ubuntu-desktop
<dholbach> they should have an overview over what's being worked on
<randy_> ??
<dholbach> just type this into the chat window: /join #ubuntu-desktop
<jokerdino> the debdiff gives me a 26k line file :S
<randy_> oic sorry i didnt realize this was not the correct IRC channel
<dholbach> randy_, don't worry - that's fine
<randy_> thank you
<dholbach> it's just that you have the whole desktop team in the other channel and are more likely to get a quick answer there :)
<randy_> O thanks i will direct my question there then.
<Ampelbein> l3on: librsvg still fails with the same error for me. Are you on amd64, too?
<l3on> Ampelbein, damn, no i386
<l3on> let me check it on amd64
<Ampelbein> I'll have more time to debug it later today
<dholbach> toabctl, did you get anywhere with the network-manager bugs?
<dholbach> jokerdino, I just briefly had a look over it - maybe it's not worth having - maybe some other package has more interesting bugs which were fixed - I don't know
<jokerdino> yeah, i was thinking the same.
<jokerdino> the diff is just too huge
<jokerdino> perhaps the trivial logjam?
<dholbach> yeah, check it out
<tumbleweed> Laney, ScottK: busy moving flat, if one of you could stand in for me at the release meeting, that'd be awesome
<ScottK> tumbleweed: OK.  Anything worth mentioning?
<tumbleweed> I haven't been paying much attention, I'm afraid
<ScottK> OK.
<tumbleweed> you probably know more about approved FFes than me
<ScottK> ghc6 I guess.
<tumbleweed> yeah
<dupondje> https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/776264 could somebody review please ? :)
<ubottu> Launchpad bug 776264 in cryptsetup (Ubuntu) "Please merge cryptsetup 2:1.4.1-2 (main) from debian unstable (main)" [Wishlist,New]
<l3on> tumbleweed, can you sponsor me another nmu please? :)
<dholbach> libsfml might be good too
<dholbach> brb
<jokerdino> logjam (4.6.2-1ubuntu1) UNRELEASED; urgency=low
<jokerdino> heh it is done, i think
<jokerdino> dholbach: logjam (4.6.2-1ubuntu1) UNRELEASED; urgency=low
<jokerdino> it seems mom did the work
<dholbach> jokerdino, in that case: can you make sure that the merge doesn't miss anything either having been done in Debian or Ubuntu and that it builds, etc?
<jokerdino> i am not sure if you like people pinging you all the time
<dholbach> jokerdino, just ask whatever your question is in here - there's lots of people who should be able to help you out
<dholbach> most of them know much more about this stuff than I do ;-)
<l3on> ok, someone can take a quick look at this â https://code.launchpad.net/~l3on/ubuntu/precise/lusca/fix-ftbfs/+merge/95594 ? :)
<jokerdino> just clarifying. the dsc is still the older version
<jokerdino> but the bzr inside the grab-merge has the latest version, without the dsc.
<l3on> Amaranth, librsvg builds fine also in amd64 â http://debomatic64.debian.net/precise/pool/librsvg_2.35.1-0ubuntu2/
<geser> l3on: we usually don't switch any packaging formats in Ubuntu delta
<l3on> geser, dpatch is obsolete and bzr builddeb returns me error, I needed it to build the dsc
<dholbach> jokerdino, if it's a patch file, you could get the old source package, then apply the diff in there, then rebuild the source package (debuild -S, etc.)
<geser> hmm
<l3on> Amaranth, sorry, was a ping for Ampelbein
<geser> did the package had any dpatch patches?
<l3on> Ampelbein, librsvg builds fine also in amd64 â http://debomatic64.debian.net/precise/pool/librsvg_2.35.1-0ubuntu2/
<l3on> geser, no
<jokerdino> well the control file of the modified logjam is in a mess
<dholbach> jokerdino, do your best to fix the merge, generate a debdiff (first build the new source package, then do a debdiff <old>.dsc <new>.dsc > logjam.debdiff) and maybe put it up on paste.ubuntu.com if you need help from anyone in here
<Ampelbein> l3on: Interesting. I'll investigate this. Feel free to close the bug.
<l3on> Ampelbein, status Fix released ?
<Ampelbein> l3on: Or Invalid, as you like.
<l3on> Ampelbein, done, thanks :).
<valdur55> lol :) i found funny bug on indicator-sound-gtk2 :P
<valdur55> how can i record screen?
<dholbach> if you work on something, can you add it to http://pad.ubuntu.com/OsSL8mOs2o please? :)
<dholbach> I'll blog about the event later on then
<dupondje> well dholbach  :)
<dupondje> https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/776264 uploaded a merge
<ubottu> Launchpad bug 776264 in cryptsetup (Ubuntu) "Please merge cryptsetup 2:1.4.1-2 (main) from debian unstable (main)" [Wishlist,New]
<dupondje> but gone now :)
<dholbach> dupondje, in a call right now
<dholbach> but maybe somebody else has a bit of time
<l3on> dholbach, that pad is also for contributors like me (or only for motu?)?
<dholbach> no, for everyone
<dholbach> everyone who participates in Fix-It Friday :)
<l3on> ah ok :)
<ScottK> tumbleweed: No meeting today.
<dholbach> coolbhavi, happy birthday! :)
<coolbhavi> thanks a lot dholbach! :)
<dholbach> :)
<dholbach> how's Fix It Friday coming along? anyone stuck anywhere?
<dholbach> hey crimsun
<dholbach> happy fix-it friday :)
<crimsun> hi dholbach :)
<crimsun> I've been fighting with armhf, qemu, and sbuild
<dholbach> crimsun, have you chatted with the guys currently doing the ARM Porting Jam?
<crimsun> dholbach: no, but it isn't the armhf qemu that's causing problems. It's the i386 and amd64 buildds that time out after 180 minutes :/
<dholbach> ugh :-(
<dholbach> what's taking so long? is it some test suite which could be turned off?
<crimsun> yeah, it's a test suite, though I'm loathe to just kludge a "FTBFS fix" just by turning off the single test suite
<dholbach> yeah :-/
<jokerdino> i can build logjam_4.6.2-1 here. needs someone to verify if sync is viable
<crimsun> jokerdino: what arches does "here" cover in your statement?
<jokerdino> here as in, in my system
<crimsun> jokerdino: what arch is your system? i386? amd64?
<jokerdino> amd64
<crimsun> (`uname -m')
<jokerdino> x86_64
<dholbach> alright my friends - I'm going to call it a day as I'm supposed to be somewhere for dinner in a few minutes
<crimsun> dholbach: see ya!
<dholbach> but I'll make sure to check the review queue some times over the weekend :)
<dholbach> and I'm looking forward to seeing your names there :)
<jokerdino> good day dholbach !
<crimsun> jokerdino: I'm test-building on armhf, sec.
<jokerdino> I will give you a minute or more. no hurry
<tumbleweed> ScottK: aah, right, beta week
<jokerdino> crimsun: i am not doing a ftbfs, rather it is a rcbug thingie
<dholbach> bye crimsun, jokerdino :)
<crimsun> jokerdino: yep. I'm just avoiding a run if I know beforehand that the source will FTBFS :)
<jokerdino> surely, it won't ;)
<crimsun> at least we hope not. There are source packages that build fine locally but fall over on buildds.
<jokerdino> hmm, yeah, it is safer to test
<crimsun> hmph. 4.6.2-1 FTBFS on armhf.
<jokerdino> heh, which package did you use?
<jokerdino> the one i used was the debian package.
<jokerdino> unmodified
<crimsun> yep, I attempted using the source package from `pull-debian-source logjam'
<jokerdino> i used from grab-merge logjam
<crimsun> the error doesn't make any sense, though: failed to load "./logjam_ljuser.png": Couldn't recognize the image file format for file './logjam_ljuser.png'
<jokerdino> o.O
<crimsun> (invoked from gdk-pixbuf-csource)
<jokerdino> have no idea what those things are supposed to mean
<crimsun> jokerdino: synced, thanks
<jokerdino> great.
<crimsun> lfaraone: any plans for the Ubuntu Sugar Team to update the seeds for 12.04?
<micahg> crimsun: in cases of FTBFS on arm*, I usually check if the previous Debian build built on the arch in question if it's not a failure specific to our libraries (Qt + GLES) and such
<lfaraone> crimsun: "probably no"
<lfaraone> crimsun: ISTR we have no users, and I was working on that as part of a contract two+ years ago.
<lfaraone> crimsun: upstream's answer to "I want to use Sugar" is  "so then you also want to use Fedora, don't you."
<crimsun> lfaraone: that's unfortunate, because it FTBFS
<crimsun> it->ubuntu-sugar-remix-meta
<lfaraone> crimsun: I noticed. I'm curious if we should have them dropped; nobody is looking at it and the company that was funding it has moved to fedora.
<crimsun> sounds reasonable if there aren't any loud complaints
<jokerdino> http://paste.ubuntu.com/865497/ any ideas? :S
<crimsun> jokerdino: your debian/patches/series file wasn't properly merged
<crimsun> jokerdino: i.e., it still has the diff(3) markers
<jokerdino> not sure how i should handle it.
<jokerdino> i did a grab-merge pornview and was packaging the unreleased version in it
<Rhonda> debfx: speaking of, I really should finally upload wesnoth 1.10.1 and sync it  ;)
<crimsun> jokerdino: compare change-libs-param-order-with-ld.patch and 615765-gold-no-add-needed
<crimsun> jokerdino: chances are that we should drop our delta and take the 11.1 NMU
<crimsun> jokerdino: actually for that source package, you should just drop the Ubuntu patch (change-libs-param-order-with-ld.patch) and take Debian's (615765-gold-no-add-needed), then finish the merge.
<fabrice_sp> Rhonda, speaking of which: wesnoth-1.8 should be dropped from the archive, right? Because with the 1.10 upload, some packages are not installable anymore
<Rhonda> fabrice_sp: debfx fixed that before :)
<fabrice_sp> oh, ok :-)
 * fabrice_sp should have checked before writting
<Rhonda> I think it would be nice to keep 1.8 around for a release - on the other hand, this is a LTS release, so I'm uncertain â¦
<Rhonda> I will get 1.8 removed eventually, but I haven't made up my mind when the best time is.  It definitely will be dropped before Q (is the name already decided?), but for now â¦
<Rhonda> I was (and still am) on parental leave for almost 4 months now, and haven't followed stuff too closely.
<fabrice_sp> tbh, I've been quite absent last 6 months because of real life (Work), so I can understand that perfectly :-)
<Rhonda> Hope it's a nice job?
<fabrice_sp> and about 1.8, it's up to you. I just noticed it when I was reviewing uninstallable packages
<fabrice_sp> a lot of travels :-)
<jokerdino> crimsun: i tried hard but i still don't know what i should be doing, can you guide me through?
<Rhonda> sabdfl would still blog about the Q name, right?
<debfx> I haven't fixed any installability issues in wesnoth, just an uploadability issue :)
<Rhonda> I think that's what fabrice_sp meant.  installable to the archive :P
<debfx> dupondje: have you tested that the new cryptsetup doesn't break root encryption?
<crimsun> jokerdino: you need to carry forward only the necessary Ubuntu delta. Notice how the Debian patch that's in the 11.1 NMU is preferred to Ubuntu's. So take Debian's, remove Ubuntu's, and update the merge.
<jokerdino> i mean, how is this process done? i have no experience of handling merges and packages.
<crimsun> jokerdino: I may have glossed over it as obvious (sorry), but we want to reduce the Ubuntu delta to zero if possible so that syncs are possible.
<crimsun> jokerdino: ah, there are some wiki pages on working through merging
<crimsun> jokerdino: have you read https://wiki.ubuntu.com/UbuntuDevelopment/Merging ?
<jokerdino> Just reading it
<PaoloRotolo> Hi all!
<valdur55> Hi
<jokerdino> http://paste.ubuntu.com/865632/ anyone has any ideas / suggestions?
<Ampelbein> jokerdino: You can use the -iI switch to get more information about tags
<tumbleweed> or just look them up with lintian-info
<jokerdino> well, they don't seem to help. :/
<tumbleweed> jokerdino: pornview is in debian
<tumbleweed> we don't try and make debian packages lintian clean
<tumbleweed> we try and stay as close to debian as possible, preferably in sync with debian
<jokerdino> they don't build.
 * tumbleweed looks
<jokerdino> https://bugs.launchpad.net/ubuntu/+source/pornview/+bug/935370
<ubottu> Launchpad bug 935370 in pornview (Ubuntu Precise) "pornview version 0.2pre1-11ubuntu2 FTBFS on i386 in precise" [High,New]
<tumbleweed> is that the same issue as debian bug 527714
<ubottu> Debian bug 527714 in pornview "pornview: FTBFS: gtkcellrendererpixmap.h:69: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gtk_cell_renderer_pixmap_get_type'" [Serious,Fixed] http://bugs.debian.org/527714
<dupondje> pornview ... :D
<dupondje> what could that be :P
<dupondje> debfx: didn't test that no ...
<tumbleweed> no
<tumbleweed> anyway, I can't help with that right now
 * tumbleweed tears himself from IRC
<jokerdino> ;(
<tumbleweed> but don't worry, the lintian errors don't look related to the build failure
<jokerdino> i see.
<JanC> dupondje: it's an image viewer with a somewhat controversial name  ;)
<jokerdino> may be someone else can offer help later on.
<jokerdino> i need some sleep.
<jokerdino> zzzz
<dupondje> JanC: boring, only images .. :)
<JanC> dupondje: image/movie viewer apparently
<JanC> in any case, many people seem to expect something else...
<jokerdino> o.O
<JanC> (there are several bug reports about removing porn from the repositories)
<jokerdino> what porn?
<dupondje> apt-get install porn
<dupondje> some additional features ^^
<asomething> jokerdino, people think pornview has something to do with porn, understandably
<ajmitch> jokerdino: by the way, when working on things like the rc bugs page, please leave comments against packages you've looked at so that someone else doesn't end up looking at the same one
<jokerdino> where should i be commenting?
<Ampelbein> jokerdino: When I work on a bug, I set status "In Progress" and assign myself to prevent others from duplicating work.
<ajmitch> in the right-hand column where there are comments already - there's a text input field on each line
<ajmitch> jokerdino: also, the table at the bottom are for bugs that don't really need to be fixed in ubuntu :)
<jokerdino> ajmitch: they are not necessary, but i was doing to learn the process
<jokerdino> so far, i have synced motion and logjam.
<jokerdino> i will look at others later tmrwo
<mfisch> hey motu, a bug-fix day question.  I see the issue with aweather, but in the development branch it's been fixed and superseded, so I assume it's not worth fixing at this point?
<micahg> mfisch: well, if it's easily fixable (by cherry-picking patches) in the stable releases, you could do that
<mfisch> micahg: so what happened is that it was patched "fixes ftbfs" but they forgot to add quilt to the rules file.  In the dev branch the patch (and need for it) is gone
<mfisch> micahg: so it would be immediately nuked once a new version comes out
<micahg> mfisch: we don't add a patch system in general if Debian doesn't have one
<mfisch> micahg: the attempted fix (patch) was done with quilt, but if you don't add it to the rules file, the patch is not very useful, at least thats my understanding
<micahg> ah, ok, and this only affected the dev release?  yeah, nothing to do
<mfisch> micahg: sorry, I'm not explaining myself well
<mfisch> micahg: current ubuntu release ftbfs, despite an attempt last year to fix that (a patch was added, but quilt's not in the rules or control file)
<mfisch> micahg: the development branch has changed to the point where this patch, working or not, is no longer needed
<mfisch> micahg: so I assume it's a waste of time to fix the patch thats already superseded in the dev branch
<jtaylor> dev branch of upstream?
<mfisch> sorry again for not specifing, no the dev branch in launchpad
<micahg> mfisch: FTBFS fixes are generally ok for SRUs
<jtaylor> why was the patch dropped in the sync oO
<mfisch> jtaylor: I think the rev 7 of the dev branch is new from upstream which precludes the need for said non-functional patch.
<mfisch> I think doing nothing is the right thing here
<jtaylor> no we definetly need to do something
<mfisch> dputting the top of the dev branch would fix this
<jtaylor> we don't want to put in dev releases without good reason
<jtaylor> the old patch looks fine, can't we just use that?
<mfisch> jtaylor: where would it get merged to?
<jtaylor> the ubuntu package?
<mfisch> the branches are precise/development and oneiric: https://code.launchpad.net/ubuntu/+source/aweather
<micahg> mfisch: so, the patch needs to be carried fwd as the new upstream version still fails to build for the same reason, it might need to be rebased
<mfisch> let me pull the rev from bzr and see if it builds
<jtaylor> mfisch: don't bother about the branches, this case is quicker fixed by just doing it on the package directly
<mfisch> jtaylor: just dputting a fix without checking in to bzr?
<mfisch> I can certainly do that
<jtaylor> yes, the importer will erge it into the branch after the dput
<mfisch> got it
<micahg> mfisch: well, you can propose a debdiff for someone else to dput :)
<micahg> or a branch
<mfisch> micahg: ah yes, I can't just dput this ;)
<mfisch> while I do this, I'd also like to ask about the ftbfs for live-manual.  It failed to build in december, but from what I can see builds fine today.  if it's a transient error can it just be retried somehow?
<jtaylor> yes
<jtaylor> let me do one
<mfisch> jtaylor: thanks
<mfisch> jtaylor: worked for me on amd64 and i386
<Amoz> pbuilder?
<jtaylor> hm it also failed in oneiric
<mfisch> Amoz: I used a vm, let me try a pbuilder
<asomething> re: aweather 0.5.2-1ubuntu1 did build. The package is source version 3.0 (quilt) so you shouldn't need to touch debian/rules to make it apply. Someone synced it instead of merging.
<Amoz> mfisch, I was just curious =)
<asomething> Running "bzr merge . -r5..6" at the tip of lp:ubuntu/aweather will bring back those changes.
<mfisch> asomething: so you don't need to add "dh --with quilt $@" to the rules file?
<jtaylor> is bzr smart enough to refresh the patch?
<jtaylor> I don't think so
<micahg> mfisch: no, source format 3 has some built in source quilting
<mfisch> micahg: awesome, I didn't know that
<asomething> mfisch, not if it is source version "3.0 (quilt)" http://wiki.debian.org/Projects/DebSrc3.0
<asomething> jtaylor, nope.
<mfisch> asomething: that wiki wording could be misinterpreted: "Does a 3.0 (quilt) source package need to build-depend on quilt?    No because you're supposed to drop the quilt usage in debian/rules (patch/unpatch logic)."
<mfisch> asomething: where drop could = "remove" or "drop .. in" = "add"
<jtaylor> true
<mfisch> English is fun
<jtaylor> I'll fix it
<asomething> mfisch, I could see that, but it definitely means "remove"
<Amoz> I'd say "put" in that context
<Amoz> not "drop"
<Amoz> and I'm not even native english speaking
<jtaylor> yes but drop is used that way, wy keep it ambigous
<mfisch> Amoz: "drop the meat in the pan"
<jtaylor> remove is clear
<asomething> a drop in replacement
<Amoz> jtaylor, yup, "remove" is more clear
<Amoz> so, I've got this testcase in bzr-gtk failing, ftbfs
<Amoz> it works if I run xvfb-run -a ./debian/testsuite.sh manually
<Amoz> but in pbuilder it fails
<asomething> Amoz, jelmer in #bzr would be the one to talk to. He's the debian maintainer and an upstream dev.
<Amoz> asomething, thanks :(
<Amoz> :)*
<mfisch> well, live-manual will NOT build inside my chroot, so I'll go figure out what dep is missing
<jtaylor> mfisch: libe-manual failed again
<mfisch> jtaylor: jinx
<jtaylor> I wonder why no bug was filed during the test rebuild
<jtaylor> oh because it already had one
 * jtaylor should not only look for "new" bugs
<Amoz> hmm
<mfisch> jtaylor: so it looks like we just need to pull a newer copy of live-manual from debian
<jtaylor> quite a lot of changes :/
<jtaylor> if you can identify the changes that would be great, but maybe its even worth requesting a freee exception
#ubuntu-motu 2012-03-03
<jokerdino> i am trying hard to make pornview build from source but i keep failing :(
<vibhav> jokerdino: Maybe I could help you
<vibhav> Suppose I want a package that is of an old version in Ubuntu be updated from upstream,what doo I do?
<jokerdino> i dropped pornview and i am now messing with uisp
<crimsun> hmm? still at it? :-)
<jokerdino> lol :/
 * crimsun is waiting for digikam to finish test-building on armhf
<nigelb> heh, pornview.
 * nigelb gets reminded of a particularly long discussion on a m/l related to it.
<jokerdino> when i dropped the patch, i get this http://paste.ubuntu.com/865632/
<jokerdino> for pornview
<jokerdino> nigelb: why on earth is it named pornview? misleading name.
<crimsun> jokerdino: that shouldn't cause the build to fail, though
<vibhav> jokerdino: pornview caused a huge flame war at the unity-design mailing list
<jokerdino> i know. ;)
<crimsun> flamewar? why is that not surprising?
<nigelb> and there was a total of 1 email about the name.
<nigelb> jokerdino: It's like the old libp0rn.
<jokerdino> o.O
<jokerdino> weird FOSS people
<jokerdino> i was expecting a backlash for that X lens.
<crimsun> heh, the merged pornview FTBFS with a missing -lpng anyway
<nigelb> also, hi crimsun! I just realized why the nick sounded familiar :)
<crimsun> nigelb: hiya!
<jokerdino> crimsun: what is that supposed to mean? :S
<crimsun> ah, pornview is a multiarch casualty
<vibhav> nigelb: Can I PM you ?
<crimsun> jokerdino: it's looking for libpng in the wrong place
<jokerdino> wah.
<crimsun> it'll take another 4 hours to compile digikam anyway ;-)
<jokerdino> dropping the ubuntu patch makes it build
<nigelb> vibhav: sure
<jokerdino> crimsun: i can build pornview after dropping the ubuntu patch. should i upload the modified dsc to my PPA for verification?
<crimsun> jokerdino: sure, or use sbuild or pbuilder
<jokerdino> pbuilder gives positive results.
<jokerdino> dpkg-deb: building package `pornview' in `../pornview_0.2pre1-11ubuntu2_amd64.deb'.
<crimsun> jokerdino: that isn't the merged one ;-)
<crimsun> Source-Version: 0.2pre1-11.1ubuntu1
<crimsun> Space: 12428
<crimsun> Status: attempted
<jokerdino> i thought mom did the merging?
<crimsun> jokerdino: it attempts to
 * jokerdino is confused.
<crimsun> jokerdino: note that your version string is 11ubuntu2, which is "older" (less) than 11.1ubuntu1
<jokerdino> wah, i used the wrong dsc
<jokerdino> i will get back to you
<jokerdino> well, it failed.
<jokerdino> no more p0rn for 12.04 then
<nigelb> lol
<jokerdino> regarding uisp, i can't find this patch
<jokerdino>  Build with -Wno-error as some warn_unused_result warnings are
<jokerdino> +    generated. Fixes FTBFS.
<jokerdino> may be it was a bad idea to try uisp
<vibhav> jokerdino: heh
<jokerdino> i will pick the relatively easier looking radare
<jokerdino> no success with radare either
<crimsun> uploaded pornview
<jokerdino> oh wow
<vibhav> crimsun: Congrats
<crimsun> jokerdino: don't worry, that one was kinda hairy. It was easier to keep the Ubuntu delta.
<jokerdino> http://paste.ubuntu.com/866336/ what about radare :?
<crimsun> jokerdino: hmm, what are you attempting?
<jokerdino> trying to build the debian src without modifications
<jokerdino> (crimsun https://bugs.launchpad.net/ubuntu/+source/pornview/+bug/935370)
<ubottu> Launchpad bug 935370 in pornview (Ubuntu Precise) "pornview version 0.2pre1-11ubuntu2 FTBFS on i386 in precise" [High,New]
<crimsun> hmm, I fail.
<crimsun> I utterly forgot to update the changed-by :/
<crimsun> oh well, guess Ubuntu Merge-o-Matic gets more karma ;-)
<jokerdino> LOL :p
<jokerdino> i am going to do something other than rc bugs
<crimsun> good luck :)
<jokerdino> is this bug still open? https://bugs.launchpad.net/ubuntu/+source/gnome-user-docs/+bug/804855
<ubottu> Launchpad bug 804855 in gnome-user-docs (Ubuntu) "Typo string 913" [Low,Fix committed]
<vibhav> How Do I update packages in Ubuntu?
<jokerdino> which package?
<jokerdino> you mean locally or in the repo?
<vibhav> repo
<jokerdino> you need to sync it from debian.
<jokerdino> but i am not very sure about the process. i will withdraw from your question
<vibhav> thanks
<vibhav> I dont know any programming launguage, can I w\still contribute to MOTU??
<vibhav> Never Mind, I have started working on "Needs Packaging Bugs"
<valdur55> Cups default filters doesn't include Samsung-ML1670 fiters...
<valdur55> filters. How can i fix it?
<vibhav> IS there any way I can know the dependencies of a specific program using the 'configure' script?
<jokerdino> you can use apt-cache show rdepends packagename
<arand> vibhav: I think you'll need to do some detective work there, normally.
<arand> I'm assuming that this is a new package
<vibhav> arand: The package is not in the repos
<arand> vibhav: And if it is a new package, aim to package it for Debian first.
<vibhav> arand: I was working on a "Needs PAckaging" bug
<valdur55> vibhav, https://help.ubuntu.com/community/AptGet/Howto#auto-apt
<jokerdino> vibhav:  there is no readme file?
<vibhav> jokerdino: There is, but it doesnt list the dependencies
<arand> valdur55: Oh, that's a convenient one :)
<vibhav> ( https://launchpad.net/unity-lens-bliss )
<arand> Oh, though packaging Unity bits for Debian might be tricky... :)
<vibhav> I was going to say that
<vibhav> Cant I directly package it for Ubuntu and upload to my PPA
<arand> Of course.
<vibhav> But I dont know the dependencies :(
<jokerdino> take a wild guess haha
<vibhav> No way
<jokerdino> i am guessing it has the same depen as the unity-lens-app
<vibhav> What are the dependencies of                     ^
<vibhav> found out
<vibhav> syntax error in unity-lens-bliss-0.1.3/debian/control at line 16: line with unknown format (not field-colon-value)
<vibhav> Can anybody tell me the reason of the problem?
<arand> Could you pastebin the control file?
<jtaylor> hurray pytables built :)
<vibhav> My builds are failing giving the message "Missing build dependencies: libunity-dev (>= 5.2)"
<jokerdino> add it to the control
<jokerdino> the debian/control file
<jtaylor> tumbleweed: your build status history is not updating anymore :(
<dross> hey guys :3 Can sexually explicit packages be in MOTU? i.e. XXX slash screens of the GIMP mascot
<ScottK> dross: Go read the code of conduct and then think about it.
<dross> ScottK: I don't see anything against it in there
<ScottK> Not a specific 'rule', but think about the intent of it.
<dross> to cater those who use gimp for rather xxx nature of commissions :-)
<dross> ScottK: I dont' think it's inconsiderate since people won't use it unless they are looking for it
<dross> i.e. Bible tools, not everyone believes in "God" or are religious at all
<jtaylor> well, but its very optional, why offend the easily offended
<jtaylor> more people will complain that its there than that its not
<ScottK> dross: Where's the line?  If there was a package that contained images of people being tortured to death, would that be OK?
<dross> you all are offending athiests and those who don't believe in God by including bible tools
<dross> how is that any different
<ScottK> dross: It's not a black and white thing.
<dross> ScottK: so are you saying the ubuntu project is controlled by christian morals?
<dross> that's what I'm getting from this conversation
<ScottK> dross: No.
<ScottK> I'm saying it takes some balancing.
<dross> it would be optional and even the package name would be very apparent
<ScottK> FWIW, I think offending Muslim morals is more of a concern.  There is a very popular derivative oriented towards them, so from my POV Christian morals aren't even the worst case.
<PaoloRotolo> Hi all!
<ScottK> dross: I don't actually know the answer to your question and I'd have to see exactly what we're talking about to have a firm opinion.  My answer to your question is "maybe".
<dross> ScottK: let me get you a thread. i was just messing around and even told the gimp developers. Now it's turning in to an interest.
<dross> http://lulz.net/furi/res/1993335.html
<ScottK> dross: I'm just about to have to leave, so I really can't look into it further right now.
<dross> splash mockup http://img.lulz.net/src/Untitled.png  (NSFW)
<vibhav> My builds are failing giving the message "Missing build dependencies: libunity-dev (>= 5.2)"
<Ampelbein> vibhav: For what release are you trying to build?
<vibhav> Ampelbein: oneiric
<vibhav> Ampelbein: https://launchpad.net/~vibhavp/+archive/needspackaging/+build/3256388
<vibhav> Its stuck on "Dependency wait"
<Ampelbein> vibhav: See the rmadison output at http://paste.ubuntu.com/866899/, oneiric doesn't have that version of libunity-dev
<jtaylor> oneiric only has 4.0
<vibhav> Ampelbein: How Do I build it for oneiric then ?
<Ampelbein> vibhav: You could try to backport the precise version to oneiric
<Ampelbein> (of libunity-dev)
<vibhav> Ill package it for precise then
<vibhav> will backport it later
<vibhav> thanks Ampelbein
<Ampelbein> yw
<vibhav> Also, Is fixing "Need Packaging" Bugs also called contributing to MOTU ?
<Ampelbein> Of course.
<vibhav> Ampelbein: I uploaded a package for a certain "Needs Packaging" Bug , what do I do next ?
<vibhav> in my PPA *
<Ampelbein> vibhav: The preferred way to get new applications in Ubuntu is via Debian first, but there's also REVU so that people can review
<Ampelbein> !revu | vibhav
<ubottu> vibhav: REVU is a web-based tool to give people who have worked on Ubuntu-specific 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  Please consider maintaining new packages in Debian rather than Ubuntu, they can be easily synced across.
<vibhav> Ampelbein: The Application is for unity, so I upload it to Ubuntu.
<Ampelbein> vibhav: Then REVU is the way to go.
<vibhav> "REVU is no longer the primary path for submitting new packages for Ubuntu"
<vibhav> But I can still use it, right?
<ScottK> Yes, but you'll have to look for reviewers.
<ScottK> Also we're past feature freeze, so you'd have to have release team approval to get any new packages in.
<vibhav> Where will I get reviewers from ?
<ScottK> Here is probably the best place.
<vibhav> I just uploaded a new package, Its telling me that I have 0 uploads
<vibhav> http://revu.ubuntuwire.com/u/vibhavp
<m4n1sh> vibhav: how did you upload to REVU?
<vibhav> m4n1sh: dput
<m4n1sh> vibhav: full command? maybe you used the wrong URI or something
<vibhav> dput revu unity-lens-bliss_0.1.3-1_source.change
<m4n1sh> vibhav: " Processing of uploads is done every 5 min" from https://wiki.ubuntu.com/MOTU/Packages/REVU
<tumbleweed> jtaylor: I moved it to ubuntuwire http://people.ubuntuwire.org/~stefanor/lp-ftbfs-report/historical/primary-precise.html
<Rcart> Hello, while working on a bitsize bug, created a patch and commited the changes, quilt creates a .pc dir
<Rcart> I wanna know if is recommends to delete that dir before commiting the changes, or let it in there
<jtaylor> opinions diverge here, I prefere branches without quilt stuff
<Rcart> does it matters?
<jtaylor> not really, it just keeps the diff smaller
<Rcart> Ok, I'll remove it. Thanks jtaylor (:
<broder> a udd branch should always have the patches applied, including the .pc dir
<broder> there are things that are unfortunate about it, but that's the udd format for 3.0 (quilt) patches. trying to not submit branches like that causes problems during review
<Rcart> broder: what kind of problems?
<broder> Rcart: it increases the probability that a sponsor will run into problems merging
<broder> i don't think i've ever been able to merge a branch with patches unapplied directly - i always have to go and apply the patches and then merge it
<Rcart> Understood
<Rcart> broder: do you have some time to review this fix-typo branch? https://code.launchpad.net/~rcart/ubuntu/precise/hyperestraier/fix-914180
<broder> Rcart: sure, i'll take a look
<broder> Rcart: did you commit with the patches unapplied? there's a lot of diff for just a debian/control typo fix
<Rcart> I'm using edit-patch, and I guess that it unapplies the patches
<Rcart> yes, the diff is scary
<broder> ah, you used edit-patch to change the debian/control file?
<Rcart> yep
<broder> we don't use patch systems like quilt to modify stuff in the debian/ directory
<broder> just stuff outside of it
<broder> for stuff in the debian directory, you can just modify it directly
<broder> in this particular case, this is a package that ubuntu is getting from debian, right?
<Rcart> without any patch? just the changelog entry?
<Rcart> yes
<broder> Rcart: yes, just the changelog entry. no edit-patch needed
<Rcart> awesome, I'll fix it right away
<broder> Rcart: it might be easiest to just start over so we  can get rid of the rest of that diff
<broder> once you've made the change, you can push --force lp:~rcart/ubuntu/precise/blah/blah/blah
<broder> to overwrite the branch that's already there
<Rcart> in fact I do --overwrite for the push
<broder> err, right that one
<broder> sorry, i'm mostly a git person
<Rcart> should I report this to upstream?
<broder> Rcart: not upstream, but you should report it to debian
<broder> we actually have a script that makes that really easy - submittodebian
<broder> you can run it once you've made your change
<Rcart> yeah, I mean debian
<broder> for any package that we're importing from debian, we almost always prefer getting the change from debian to maintaining it ourselves, at least in the long term
<broder> so i would have asked you to submit it to debian anyway :)
<Rcart> updated (:
<broder> Rcart: much better :). i'll go ahead and sponsor it now
<Rcart> thank you broder, I'm gonna submit it to debian (:
<broder> awesome. do you know how to associate the debian bug with the ubuntu one on lp?
<Rcart> yep, adding a bug watcher, no?
<broder> right
<broder> that's important because it means that down the line people can easily confirm that you sent the bug to debian
<Rcart> Ok
<Rcart> btw, I'll work on this bug too #902485
<Rcart> bug 902485
<ubottu> Launchpad bug 902485 in mpd (Ubuntu) "mpd unable to create database" [Undecided,New] https://launchpad.net/bugs/902485
<Rcart> It's a typo, and this time I need to work on a  patch, right?
<Rcart> sorry, needs to update a string*
<broder> Rcart: is the only change that the "start-create-db" needs to be removed from the usage string of the initscript?
<Rcart> yes
<broder> it's not trying to create the database from the package's postinst script or something?
<Rcart> the database creation is now inside mpd, not needed to be called directly
<broder> ok
<broder> the initscript usually lives at debian/packagename.init or debian/init
<broder> since it's inside the debian/ directory, you just modify it directly
<Rcart> Ok, and then report it to debian as well?
<broder> sure. have you checked that debian hasn't fixed this already?
<Rcart> yes, I did. There's no bug report about it.
<broder> cool. then yeah, fix it and report it to debian
<Rcart> awesome
<broder> Rcart: still working on a test build of hyperestraier, btw - my network connection's a bit slow today
<Rcart> broder: No worries (:
<broder> damnit, i need to do more ppa uploads. "dput ubuntu" comes out without thinking if i'm not careful
<jtaylor> ^^
<Rcart> https://code.launchpad.net/~rcart/ubuntu/precise/mpd/fix-902485/+merge/95761
<Rcart> broder: would you review it please?
<broder> Rcart: sure, looking now
<broder> Rcart: the patch looks good, but it seems like there are a bunch of bugs open against mpd about install-time failures
<broder> e.g. bug #778571
<ubottu> Launchpad bug 778571 in mpd (Ubuntu) "package mpd 0.16.1-1ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/778571
<broder> if that still happens, it would be nice to fix those now
<broder> if you don't want to, though, i can just upload the patch and we can move on
<broder> hmm, actually, it's not clear that all of the postinst faliure bugs are the same
<Rcart> broder: I've never try to fix FTBFS bugs S:
<broder> Rcart: these aren't FTBFS; they're failure to install
<broder> but they alos seem to be a pretty mixed bag - this may not matter as much as i had thought
<Rcart> I would like to try to fix them, but no have experience on that kind of bugs S:
<Rcart> Do you have any link on debian/ubuntu about it? I'd really like to work on that kind of bugs
<Rcart> (kind of bored of typos)
<broder> i do'nt know of any references, but i can try to help you understand what's going on
<Rcart> awesome, let's do it then =P
<broder> anyway, i don't see anything obvious with any of the install failures, so i'll just upload your typo fix
<Rcart> broder: take a look: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489353
<ubottu> Debian bug 489353 in mpd "failure to start causes failure to install/upgrade" [Normal,Open]
#ubuntu-motu 2012-03-04
<broder> Rcart: hmm, i think i actually disagree with that bug report. if i was maintaining that package, i would tell the user to configure the package to not start automatically (using policy-rc.d - see http://manpages.ubuntu.com/manpages/precise/en/man8/invoke-rc.d.8.html#contenttoc6), which would keep the postinst from trying to start the daemon
<broder> but i can't actually find anything in the debian policy manual to back me up on that
<broder> Rcart: ok, just uploaded mpd
<Rcart> broder: I think that the second comment is right, it would be easier for the user to just receive a warning and not a critical error that stops the update/install procedure
<broder> Rcart: that would be different behavior than almost every other postinst script i've seen
<broder> the standard postinst snippet for starting an initscript exits with an error if the start fails
<Rcart> I see. He said that will fix it (on 5 Jul 2008) and seems like he didn't X:
<Rcart> should I add a bug watcher linking that (debian) bug report?
<broder> to what?
<Rcart> the LP bug report
<broder> which bug report?
<Rcart> (that you mentioned)
<Rcart> #778571}
<broder> ah. no - the one i mentioned is a different bug from the one described
<Rcart> Ah, ok
<Rcart> I'll add a bug watcher to the bug you reviewed
<broder> huh?
<Rcart> xD
<broder> no, i don't think there's any bug in lp right now that matches the debian bug you linked to
<broder> you should only link bugs if it's the same bug being reported in two places
<Rcart> the bug I was working on you uploaded it, I'll report it to debian and link it to LP
<broder> ah, yes. that would be excellent :)
<broder> sorry for the confusion
<Rcart> :D
<Rcart> Think I need to read carefully the scripts post-pre-etc and try to work on bugs like that
<Rcart> Thanks for your help broder, I'm leaving. o/
<broder> Rcart: no problem! thanks for stopping by and contributing!
<Rcart> (:
<akrogames> Thanks jtaylor for your help
<akrogames> hi broder
<broder> akrogames: hey, what's up?
<akrogames> I live in France and I'm tired and you ?
<akrogames> I learned to fix bugs
<akrogames> good night, so later
<mfisch> jtaylor: I found out the fix for live-manual, it's not pulling a new version.  I'm still trying to figure out the right way to actually make the change.  Ping me when you're around and I'll explain
<mfisch> jtaylor: strike that, I have the debdiff ready to go, just need to know where to put it so that a MOTU can take it from there
<tumbleweed> !sponsorship| mfisch
<ubottu> mfisch: You can find out about the package sponsorship process here http://wiki.ubuntu.com/SponsorshipProcess - For !UDS sponsorship see http://uds.ubuntu.com/participate/sponsorship/
<mfisch> tumbleweed: thanks, I'll take a look in the morning
<tumbleweed> Changed-By: Ubuntu Merge-o-Matic <mom@ubuntu.com>
<tumbleweed> ^ we should have a noisy lintian check for that
<micahg> heh
<vibhav> It is possible to sync a Ubuntu package to Debian?
<tumbleweed> vibhav: there's no automated proces for it
<tumbleweed> it generally works better to maintain the packgae in Debian and sync to Ubuntu
<vibhav> I prefer to upload it to Ubuntu first, since I am not experienced in the Debian process
<tumbleweed> all the tools (and people) assume that Debian is the upstream
<tumbleweed> and I think Debian is a better place to maintain packages (the stronger maintainership makes sense for packages you care about)
<vibhav> I still can upload it to Ubuntu first?
<tumbleweed> nothing stops you from doing that
<bkerensa> tumbleweed: Assuming he has upload privileges or gets a package sponsored
<tumbleweed> did something change in apport? There's hardly any information in bug 940800
<ubottu> Launchpad bug 940800 in python-wadllib (Ubuntu) "pyclean crashed with Exception in from_package(): cannot get content of python-wadllib" [Undecided,New] https://launchpad.net/bugs/940800
<Ampelbein> tumbleweed: bug 944078
<ubottu> Launchpad bug 944078 in apport (Ubuntu) "bugs reported by apport missing essential information" [Undecided,Incomplete] https://launchpad.net/bugs/944078
<tumbleweed> hrm, probably it
<pkt> what is the process of fixing these http://qa.ubuntuwire.com/bugs/rcbugs/
<pkt> Is there a document about this?
<pkt> I mean I can download the debian source, get the relevant patch etc, then where and how do I submit the result?
<micahg> pkt: either request a sync if appropriate or submit a patch for sponsorship either through a bug or bzr branch
<pkt> how do I request a sync?
<pkt> ok I found, sorry for that question
<micahg> pkt: use requestsync from ubuntu-dev-tools (use the -e flag if the new version has new features since we're past feature freeze)
<pkt> http://qa.ubuntuwire.com/bugs/rcbugs/
<pkt> ok, thanks :)
<pkt> I tried requestsync -e radare but it doesn't work since it says the versions are the same (in reality they aren't)
<micahg> pkt: if it's only in unstable you'll need -d unstable
<tumbleweed> pkt: -d unstable
<pkt> thanks :)
<pkt> (and sorry for the newbie questions)
<tumbleweed> np, that's an issue that only comes up with LTS releases where we sync from testing by default
<Pikkachu> this is confusing http://developer.ubuntu.com/packaging/html/packaging-new-software.html
<tumbleweed> Pikkachu: what are you finding confusing? let's fix it
<Pikkachu> it's entirely confusing, but gtg now
<pkt> I think I succeeded (https://bugs.launchpad.net/ubuntu/+source/radare/+bug/946269)
<ubottu> Launchpad bug 946269 in radare (Ubuntu) "FFe: Sync radare 1:1.5.2-4.1 (universe) from Debian unstable (main)" [Undecided,New]
<pkt> Is this correct?
<tumbleweed> pkt: that doesn't need an FFe, it's only a bug fix
<pkt> uff, I understood wrong then
<pkt> should I close the bug?
<tumbleweed> if the upstream part (before the dash) of the version hasn't changed, it is unlikely to need the FFe
<pkt> It shouldn't need
<pkt> it is a trivial bug fix
<tumbleweed> no, lets leave it as a sync request, it just doesn't need an FFe
<pkt> so, what did I do wrong?
<tumbleweed> there, done
<tumbleweed> it didn't need -e
<pkt> ah, ok :)
<pkt> Thanks :)
<pkt> So the correct command would have been requestsync -s radare -d unstable
<pkt> I will learn slowly slowly :)
<tumbleweed> yes
<tumbleweed> if you have a recent requestsync (using LP API) you don't need -s either, it'll wor that out itself
<pkt> I 'm using latest precise so I guess it is recent enough
<tumbleweed> yes
<pkt> great, continuing to the next package :)
<Pikkachu> I have source code for which compilation is like $apt-get install build-dep other; $apt-get source other; cp here/patched other/foo/bar; cd other; ./configure; cd foo/bar; make patched.so
<Pikkachu> how would I make a bin deb and how to put this on a recipe?
<pkt> first of all instead of cp here/patched other/foo/bar you should have a proper patch
<pkt> in the form of a unified diff
<pkt> if the package you are patching has source format 3.0 (quilt) then it is very easy to add a patch
<pkt> https://wiki.ubuntu.com/PackagingGuide/Complete
<Pikkachu> "first of all instead of... " -- you don't really understand what's that
<Pikkachu> I will explain what it is
<pkt> please do :)
<Pikkachu> sorry for calling it patch, it's a new plugin for pidgin called ircaway
<pkt> From the process you described it looks as if you want to patch pidgin to include it
<Pikkachu> it's a single ircaway.c for which I need to create the .so, instructions in pidgin website suggested me to put the source under pidgin-source/pidgin/plugins and run $make ircaway.so
<pkt> Does pidgin provide a way to build plugins out of tree?
<pkt> If it doesn't you need to convince them to add it, or add the source file as a patch
<Pikkachu> so I use pidgin's build infrastructure which is able to build arbitrary plugins if they're under that folder, I did this because it just works and I don't want to waste time trying to figure out how to build it alone
<pkt> sure
<pkt> but this can't work for packaging I think
<pkt> either it needs a way to be built standalone
<Pikkachu> please this has nothing to do with patches unless they decided to add the plugin to upstream
<Pikkachu> from the pidgin docs, the plugin author would provide the way the plugin needs to be built
<pkt> fair enough
<Pikkachu> but I'm reading the docs themselves for that
<pkt> but pidgin should provide a way to build plugins against it
<Pikkachu> which don't explain how to build them alone
<pkt> i.e., libraries etc
<pkt> are there any pidgin plugins distributed as standalone packages?
<Pikkachu> I suppose because it's a plugin it somehow would require most or much of the original infrastructure to build pidgin itself
<Pikkachu>  https://wiki.ubuntu.com/PackagingGuide/Complete -- is totally confusing
<Pikkachu> sorry I mean the new guide
<Pikkachu> I just know of purple plugin pack, a set of plugins, distributed as a separate package
<pkt> apt-cache search pidgin shows a few extra packages
<pkt> you can check if any of them are small enough to be used as examples
<tumbleweed> Pikkachu: does libpurple-dev or pidgin
<tumbleweed> -dev have wha tyou need?
<pkt> I would propose pidgin-extprefs
<pkt> it is also a single .c file from what it seems
<pkt> so maybe you can reuse its build infrastructure
<Pikkachu> tumbleweed: does what?
<pkt> He asks if it provides the needed libraries etc
<pkt> but I think the problem is to figure out the build system
<Pikkachu> pkt: sorry I'm not in Ubuntu right now, but does extprefs stand itself as a pidgin plugin?
<pkt> yes it seems so
<Pikkachu> pkt: yeah it's a problem -dev x build-dep
<Pikkachu> first of all I don't get why can't one put the build deps as deps of the -dev packages
<Pikkachu> anyway, libpurple-dev and pidgin-dev contain just headers iirc
<Pikkachu> and build-dep for pidgin is really big
<pkt> Pikkachu: again, I think you can try extprefs plugin as a template to build from
<Pikkachu> pkt: ok will try to take a look at extprefs
<pkt> if you are not on ubuntu you can get the source package from the web
<pkt> It has some extra stuff for installing on win32 and such, you can just ditch those
<pkt> and just copy the linux-related infrastructure
<Pikkachu> ok
<pkt> great :)
<tumbleweed> Pikkachu: if it's a single c file, it can't be that hard to build, right?
<pkt> not true
<pkt> a kernel module is also a single file
<pkt> s/is/can be/
<tumbleweed> and they are fairly straight forward to build
<pkt> not without the kernel's build infrastructure
<Pikkachu> yeah
<pkt> you can't just call gcc on it by hand and expect a working module
<pkt> Pikkachu's issue is that he is trying to figure out the corresponding build system for pidgin plugins
<Pikkachu> I just don't get why build-dep is not reversible like normal deps with autoremove
<tumbleweed> I'm saying that that may be more effort than it's worth
<tumbleweed> Pikkachu: use mk-build-deps, then they are easy to remove
<Pikkachu> I think you don't really understand the problem, tumbleweed
<Pikkachu> I have no idea how would I "use mk-build-deps"
<tumbleweed> Pikkachu: of course I don't, I haven't seen the source[6~
<tumbleweed> it has a manpage
<tumbleweed> but basically, mk-build-deps -ir inside an extracted source package
<Pikkachu> are you trying to sound cool? it's not working
<tumbleweed> Pikkachu: I'm trying to be helpful
<pkt> Pikkachu: yes
<tumbleweed> and you don't appear to want help, so I'm not entirely sure why I'm bothering
<pkt> I think there is a misunderstanding
<pkt> tumbleweed's advice is useful
<Pikkachu> of course, those standard responses, please I disregard your help, right now, ignore me PLEASE
<pkt> Pikkachu: mk-build-deps solves the problem of being able to unistall the stuff apt-get build-dep brought in
<tumbleweed> Pikkachu: sorry, I tend to not give complete hand-holding instructions, but rather point you in useful directions, and expect you to do some research yourself
<Pikkachu> tumbleweed: sorry I stopped at 'sorry'. I'm not really interested in your help, sorry
<tumbleweed> np
<Pikkachu> pkt: well but it will just output the package names, which is mostly the same as saving build-dep's output :(
<pkt> Pikkachu: not just that
<pkt> it will also make a binary package that depends on them
<pkt> so you can install this package to install the build-deps
<pkt> and then remove it and they will become removable through autoremove
<pkt> of course I don't know how useful this is now (if you have already installed them by build-dep)
<pkt> but for future reference
<Pikkachu> I'd have to do it for every package I want the build deps, I'm just saying there should be something like 'autoremove --build-deps'
<pkt> It is the same number of commands
<pkt> I.e., instead of "apt-get build-dep <foo>" you do "mk-build-deps -ir"
<pkt> and this way the build deps are instantly autoremovable
<pkt> I didn't know about this script myself to be honest, I had hacked my own solution for this problem :P
<akrogames> hi all
<mfisch> I'm making a change on a package that has no branches in launchpad, can I just attach a debdiff to the bug and leave it at that?  Or, should I make an initial branch and then commit on top of that to show the diffs?
<tumbleweed> debdiffs are fine. Nobody requires you to use bzr
<tumbleweed> however, why does i tnot have any branches in LP?
<mfisch> tumbleweed: because, I think, until now it was just, uh, pure debian, no ubuntu changes
<tumbleweed> mfisch: no, it should still have branches
<tumbleweed> what package is it?
<mfisch> let me confirm that assumption
<mfisch> okay nevermind :(
<tumbleweed> :)
<mfisch> I just wasn't looking in the right place
<pkt> still the information that bazaar is not really needed is useful
<tumbleweed> I still find it easier to not use bzr, but bzr is certainly becoming more appealing
<mfisch> I prefer bzr myself
<ral> As someone who has only done a small amount of packaging I found modifying a package with bzr very straightforward.
<mfisch> when I do the merge proposal don't i need to add ubuntu-sponsors as a reviewed?
<mfisch> reviewer i mean
<tumbleweed> orrect
<tumbleweed> err, you don't need to
<mfisch> mind if i add that to the wiki?
<mfisch> hmm ok
<mfisch> tumbleweed: how will it end up in sponsor queue?
<tumbleweed> the sponsorship queue includes all merge proposals against ubuntu pcakages
<mfisch> alright, I'll see if this shows in the queue in a bit
<ESphynx> hey guys... Would anyone be able to assist me? I'm having really bad troubles with Precise. It fails to build our software in the most silly way...
<tumbleweed> ESphynx: this isn't really a support channel, but those kind of thinsg we can probably help with. Also, don't ask to ask, just ask :)
<mfisch> tumbleweed: thanks for the ifno, I attached a debdiff and did a merge-prop
<ESphynx> It builds fine on Oneiric, which is GCC 4.6.1 .  I was trying to install the 'standard' GCC 4.6.2 on Precise to see if it would build fine (Seeing that GCC/MinGW 4.6.2 on Windows works fine), but then my Precise VM died on me =(
<tumbleweed> mfisch: so it'll show up twice :)
<ESphynx> tumbleweed: you the man.
<tumbleweed> ESphynx: can you pastebin the error?
<ESphynx> I don't know what happened to my VM.. last night I went to sleep after the GCC build was going on... this morning the Vbox interface is just jammed, even cloning the machine jams taking 0% CPU
<ESphynx> tumbleweed: the errors won't really help you, it's my compiler doing really silly stuff that it normally doesn't
<pkt> ESphynx: do you have a hardware problem or something?
<ESphynx> The only thing I can't think up is a messed up GCC
<tumbleweed> ESphynx: you sure your hard drive isn't going? check dmesg...
<pkt> or zero free disk space?
<mfisch> tumbleweed: eh, should I nuke my merge proposal then?
<ESphynx> pkt: no hardware problem, this is on Launchpad PPA building machines as well
<mfisch> tumbleweed: not sure if I can remove the attachment from the bug
<ESphynx> pkt: no, dynamic vdi drives with plenty of space
<tumbleweed> mfisch: I can unsubscribe sponsors from the bug
<mfisch> tumbleweed: bug #831392
<ubottu> Launchpad bug 831392 in live-manual (Ubuntu Oneiric) "live-manual version 1:3.0~a6-1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/831392
<ESphynx> tumbleweed: https://launchpadlibrarian.net/95143170/buildlog_ubuntu-precise-i386.ecere_201203031148-0~446~precise1_FAILEDTOBUILD.txt.gz  -- the build log, but like I said it won't help much
<mfisch> my bug-day contrib, 48 hours late ;)
<tumbleweed> mfisch: thanks
<ESphynx> tumbleweed: It is virtual machines, and PPA building machines! no HW issue.
<ESphynx> I was suspecting a bug in the Ubuntu GCC 4.6.2 patches.
<pkt> mfisch: is it 48-hours late? hehe I thought the Jam was during the weekend as well
<mfisch> pkt: oh well I'm good then!
<pkt> I still haven't finished my contribution :S
<mfisch> pkt: you're running out of time there in Greece!
<tumbleweed> ESphynx: the ppa build failed for a very clear reason
<ESphynx> tumbleweed: Which reason is that?
<pkt> mfisch: true, just a few hours more :P
<tumbleweed> error: unresolved identifier publicAccess; expected ecere::com::Module
<pkt> but can't I say that my personal clock is in pacific timezone :P
<ESphynx> tumbleweed: that is not supposed to happen.
<ESphynx> tumbleweed: also consider "warning: incompatible expression "ecere::sys::FileAttribs FileExists(char * fileName)" (byte *); expected pe"
<ESphynx> there's no such thing as "pe" anywhere in our software...
<ESphynx> the compiler (the bootstrap eC compiler) is all messed up
<ESphynx> none of this happen on any other Ubuntu versions...
<mfisch> tumbleweed: how often is the sponsor queue updated?  hourly or so?
<ESphynx> My Precise VM is dead :| will have to reinstall everything... So much for trying to build my own GCC 4.6.2 :|
<tumbleweed> mfisch: I think every 10 mins or so. Maybe 30. depends how big it is (the script that produces it takes forever to run)
<tumbleweed> ESphynx: sorry, I thought you were saying tha tthe build had killed your VM
<ESphynx> tumbleweed: building GCC killed my VM.
<pkt> ESphynx: how much RAM did you give to your VM?
<ESphynx> ah the hw errors, is what you were talkign about :) hehe, on a Windows host though
<ESphynx> pkt: 2gb
<ESphynx> sorry I thought you guys were blaming the failed build on hw hehe
<pkt> And still it died
<pkt> hehe
<ESphynx> yes :(
<pkt> Interesting
<ESphynx> you guys have other flavors of Gcc installed on Precise?
<ESphynx> we could give that a try?
<pkt> I have a VM here with precise (kvm)
<pkt> if you want I can install a version of gcc
<ESphynx> pkt: I would greatly appreciate taht.
<pkt> But know that I can't build gcc on this VM
<pkt> it has just 256MB ram
<ESphynx> pkt: I gave up on building GCC :P
<ESphynx> pkt: but I couldn't figure out out to try 4.6.1, for example, without building it
<ESphynx> if you do know how ;)
<pkt> I can try to find out
<pkt> just a sec
<tumbleweed> ESphynx: w still have a gcc-3.5 package in precise
<tumbleweed> err 4.5
<ESphynx> i decided to try building 4.6.2 , since it built our software fine on Windows
<ESphynx> tumbleweed: ah yes... I guess we could try that. but that's quite far from 4.6.2 :|
<ESphynx> but it would help narrow down the problem
<pkt> I see 4.6.3 as default here
<tumbleweed> yeah
<ESphynx> See, our first open source release on Ecere was 0.44 draft 1, on Dec 25, 2008.... and this coming Wednesday is finally the official 0.44 ;)
<ESphynx> And I would like to build on Precise, at least when it comes out :)
<pkt> 4.4, 4.5, 4.6 are all available
<ESphynx> pkt: 4.6.3 now ? is it a newer VM?
<pkt> which one do you want?
<pkt> It has latest precise on it
<ESphynx> pkt: maybe i'm out of date hehe...
<ESphynx> pkt: care to try 4.6.3 first ?
<pkt> sure why not
<ESphynx> guess i'll link you to the source package?
<pkt> but if lp failed probably it was with  4.6.3
<pkt> sure
<pkt> do you have it on a ppa?
<ESphynx> yes
<ESphynx> https://code.launchpad.net/~jerstlouis/+recipe/ecere-daily-multiarch
<ESphynx> gcc-4.6 i386 4.6.3-1ubuntu2 [7576 kB]
<ESphynx> right, lp failed on 4.6.3 as well :(
<ESphynx> so the easy thing would be to try 4.4 ? to establish whether GCC is to blame or not?
<ESphynx> since 4.5 is dev right, so latest dev might have the bug as well?
<pkt> I think 4.5 should be release as well, not dev
<ESphynx> ah right osrry
<ESphynx> it's the middle number
<ESphynx> hmm.
<ESphynx> my only worry... when installing side by side... our build system just invokes 'gcc'
<pkt> I think gcc is selected using alternatives
<ESphynx> so you can try 4.5
<ESphynx> please =)
<pkt> sure but you will need to wait a few mins
<ESphynx> np
<ESphynx> I gues another thing to try would be to disable -O2 ...
<pkt> that you can also try yourself
<ESphynx> guess I could try that on a new Precise machine
<ESphynx> yes. i'll brb, logging out to kill stalled VBox
<Pikkachu> hi pkt, not much help http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/pidgin-extprefs/oneiric/view/head:/debian/control
 * Pikkachu rebooting to ubuntu
<pkt> Pikkachu: fwiw I didn't understand what you meant
<Ampelbein> Pikkachu: There are lots of pidgin plugins in ubuntu, have you had a look at how they accomplish the build?
<pkt> what was the problem with pidgin-extprefs?
<Pikkachu> Ampelbein: and this is what you call "a lot"? http://i.imgur.com/Q5hAT.png
<PaoloRotolo> Hi all!
<pkt> Pikkachu: try from the command-line
<pkt> there are several
<pkt> apt-cache search pidgin
<ESphynx> That .vdi was so locked down, even "Restart" wouldn't work... i had to press the Reset button :|
<pkt> Pikkachu: but still what was the problem with extprefs, I chose it for you because it is also a single .c file
<Pikkachu> pkt: I have no idea whether its Build-Depepndencies field matches?
<Pikkachu> pkt: can we start from the beginning?
<pkt> sure
<pkt> for starters, where is ircaway.c ?
<Ampelbein> Pikkachu: I count 24 plugins, that is a lot.
<ESphynx> well the good news is I miraculously kept that .vdi (because it was locked! i had done "delete all files"), and it works
<pkt> nice :)
<ESphynx> so now I can try taking out -O2 :P
<Pikkachu> Ampelbein: ignore me from now on, and I'm serious
<Pikkachu> hi ESphynx, how's eC going :)
<Pikkachu> pkt: well, I will stand it in a simple way then
<pkt> sure, simple always helps
<Pikkachu> I have a Bazaar branch for a new plugin for pidgin, I want Launchpad building the deb and putting it available, that simple. I tried and read docs about recipes, ppa, packaging, and they're just confusing, so I wanted to start from this simple point with human help
<pkt> can you give the link to that branch?
<Pikkachu> fwiw I can generate the .so by ./configuring the pidgin host and $making plugin.so from within pidgin-source/pidgin/plugins (that is, this build thing I used is from pidgin)
<pkt> Pikkachu: sure, but this won't help you produce a package
<Pikkachu> pkt: https://code.launchpad.net/~renatosilva/pidgin/ircaway
<pkt> Pikkachu: great
<Pikkachu> pkt: yeah I just mentioned that because I'm not sure how to build the plugin at all except by reusing pidgin infrastructure, which is sort of overkill for a small plugin I think
<pkt> it is not just overkill
<pkt> it is also not going to be accepted
<pkt> so, you need to figure out how to build it standalone
<pkt> this doesn't just mean the debian/ part
<pkt> it also means the makefile etc
<pkt> In fact, the first thing you need to figure out is what to put to the makefile
<pkt> you can start simple, assuming that you don't ever want to build for other platforms, so you don't need the autoconf stuff
<Pikkachu> do I really need a makefile? because I think that even that is overkill, no?
<pkt> no
<Pikkachu> why not, just to understand
<pkt> Because you need to ensure you are building against the proper headers / libraries
<pkt> you could also write a bash script but a Makefile is the standard way to do it (TM)
<pkt> so at the very minimum you need the .c file and a Makefile
<pkt> and most likely a README
<pkt> once you have those, you can also make the debian/ folder with the right contents
<tumbleweed> +1 to Ampelbein's suggestino of looking at other plugins, and yes, writing a simple Makefile is probably the easiest way to get a working package
<Pikkachu> pkt: ok so let's leave the deb thing for a separate stage. I'm new to make, I've just used it, how would I figure out the dependency tree for the source file compiling?
<Pikkachu> tumbleweed: I'm looking right now, will take a look at their makefile
<pkt> Pikkachu: typically you use pkg-config
<pkt> Pikkachu: here is my suggestion
<pkt> go to the extprefs plugin
<pkt> do the mk-build-deps -ir thing
<pkt> and now do a debuild -uc -us 2>&1 | tee -a ../build.log
<pkt> this will show you which commands the makefile of this plugin called
<pkt> it is much easier than trying to analyse its source
<pkt> because the source is obfuscated a lot by the automake infrastructure that you don't need
<Pikkachu> I'm trying to process what you said
<pkt> btw, I hope this advice is ok and not considered as spamming the channel
<tumbleweed> sure, nothing else going on right now. (weekends are quiet)
<tumbleweed> Pikkachu: no tee reqd, debuild writes a log to ../$pkg.build
<pkt> even better
<tumbleweed> err pkt
<Pikkachu> I'm really annoyed by all this word salad I've been through in the docs, I'm really lost
<jtaylor> :O why have I been using tee all the time?!
<Pikkachu> I'm looking in pidgin-facebookchat now
<pkt> This is why trying to help on IRC is helpful
<pkt> most time you learn new stuff yourself
<pkt> Pikkachu: sure, pick the simplest you can find
<tumbleweed> Pikkachu: the solution to that is to improve the docs, so it helps if you can tell us where you are getting stuck / confused
<pkt> facebookchat looks much more complicated
<Pikkachu> pkt: I'm having to install devscripts for mk-build-deps, I hope I don't need any more word-salad packages since it has already a salad of dependencies itself :(
<tumbleweed> devscripts is certainly something you want. Any sane packaging documentation should have told you that pretty early on
<tumbleweed> I'd also recommend ubuntu-dev-tools
<Pikkachu> tumbleweed: the docs are confusing to the point you don't know where it's confusing, but I'd say write something to someone like "I have source code to give people, I want Launchpad to build and publish the .debs for me". Something straighforward to follow for that kind of developer like me
<pkt> Pikkachu: the thing is that you need to know the basics of open source development before you start caring about packaging
<tumbleweed> Pikkachu: I'm afraid there's a bit of stuff you need to learn along the way, debian packaging has quite a lot going on in it
<Pikkachu> pkt: I don't like these standard unclear responses, please
<Pikkachu> pkt: any sane developer would hate the whole toolset, to begin with
<pkt> I 'm trying to make it specific (searching for a link to a howto)
<tumbleweed> Pikkachu: please don't insult our build systems, that doesn't motivate people to help you
<Pikkachu> I've read the docs pkt, they're confusing
<Pikkachu> tumbleweed: please ignore me, right now, and I'm serious
<Pikkachu> pkt: I think the core problem is
<tumbleweed> Pikkachu: if you can't have a civil conversation in this channel, could you please move it elsewhere
<Pikkachu> pkt: how to know what packages are needed to build the source code
<pkt> Pikkachu: what tumbleweed says is true (it is not nice to insult people that try to help you)
<pkt> about the build dependencies
<pkt> just pick a random plugin (facebookchat)
<pkt> and do mk-build-deps -ir in its directory
<Pikkachu> tumbleweed: I said kindly to ignore me, and I was serious, I'm not offending you so if you're willing to do something without any reason, I don't really care at all except you're in my way to publish software to people
<Pikkachu> pkt: yeah I will concentrate in that point now
<pkt> or apt-get build-dep pidgin-facebookchat
 * tumbleweed wanders off
<Pikkachu> pkt: if I get anything relevant and I'm still here I'll let you know
<pkt> ok
<Pikkachu> pkt: oh that's even better I can see the packages before confirming, a second...
<ESphynx> sorry guys, I was cooking my breakfast ;)
<ESphynx> Pikkachu: quite good! if we can only get it working on Precise :) we're releasing the official 0.44 this wednesday
<pkt> Hehe, you are lucky it is already night here ...
<Pikkachu> pkt: debhelper gir1.2-json-1.0 html2text libdbus-1-dev libdbus-glib-1-dev libglib2.0-dev libjson-glib-dev libpurple-dev po-debconf zlib1g-dev
<Pikkachu> pkt: so your idea is eliminating from above what seems unnecessary?
<pkt> I would also install pidgin-dev just to be on the safe side
<pkt> my idea is to manage to build your plugin out of tree first
<pkt> then you can care about removing stuff
<pkt> your first objective should be to build the .so successfully from outside pidgin's directory
<pkt> by installing the build-deps from another plugin at least you know that the headers/libs you need are available to begin with
<pkt> now you need to write your Makefile correctly
<Pikkachu> ESphynx: glad to know you got your way on PPas
<ESphynx> Pikkachu: almost there, hehehe
<ESphynx> Pikkachu: just Precise failing to build :(
<ESphynx> pkt: well, taking out -O2 doesn't seem to help!!
<Pikkachu> pkt: the makefile from that plugin is 137 lines long, should I read it and amke mine based on that?
<ESphynx> Would anyone know how different the Ubuntu patches for GCC are, and how likely they are to cause memory corruption issues? :|
<pkt> The short answer is that nothing is impossible with gcc ...
<ESphynx> hehehe
<jtaylor> what is the problem?
<ESphynx> now that i've ruled out the -O2... i'm pretty sure it's a bug in either 4.6.2 on linux, or the ubuntu patches...
<ESphynx> jtaylor: My compiled bootstrap eC compiler is going nuts.
<ESphynx> jtaylor: it works fine on oneiric and all previous Ubuntus.
<pkt> ESphynx: https://code.launchpad.net/~ecere-team/+archive/ppa/+files/ecere_201203031148-0~446~precise1.dsc
<pkt> should I try this with gcc-4.5?
<jtaylor> does valgrind help?
<ESphynx> pkt: yes, please :)
<pkt> Ah, btw, I just remembered one of the nuances of gcc 4.6
<ESphynx> jtaylor: it could. I usually use my own memory protection tool called 'memoryguard', but since the thing doesn't build yet :P
<pkt> (the ubuntu version)
<ESphynx> pkt: Ah? (Note it works fine in Oneiric, 4.6.1 ...)
<pkt> the $CFLAGS should be in the end of gcc command
<pkt> e.g., gcc $FLAGS -c foo.c -o bar.o won't link
<pkt> gcc -c foo.c -o bar.o $CFLAGS will work
<ESphynx> it won't ? :S
<pkt> the reason is a bit esoteric
<pkt> and it will work in previous versions AFAIK
<ESphynx> love how this word keeps popping up lately.
<Ampelbein> pkt: Nothing to do with CFLAGS.
<jtaylor> -c does not linking
<pkt> yes sorry
<pkt> it is actually the linker flags
<ESphynx> ok, i'm all confused here... but here it's not something that won't link
<ESphynx> every gcc command compiles and links
<ESphynx> it just produes horrible results.
<Ampelbein> The problem in many packages was that libraries were added in LDFLAGS, which is the wrong place to put them. They belong in either LDADD or LIBADD.
<pkt> exactly
<pkt> and because ubuntu has a patch to make the linker stricter
<Ampelbein> pkt: Ubuntu uses --as-needed by default.
<pkt> yep
<pkt> gcc-as-needed.diff
<ESphynx> I put them in $(LIBS): $(TARGET): $(SOURCES) $(RESOURCES) $(SYMBOLS) $(OBJECTS) | objdir
<ESphynx> 	$(CC) $(OFLAGS) $(OBJECTS) $(LIBS) -o $(TARGET) $(INSTALLNAME)
<pkt> A friend of mine got burned by this but his source was technically broken anyway
<pkt> http://lists.debian.org/debian-devel-announce/2011/02/msg00011.html
<ESphynx> Ampelbein: Could this particular difference have any impact on memory corruption?
<Ampelbein> ESphynx: Unlikely.
<ESphynx> downloading Valgrind.
<ESphynx> it's just a matter of linking with -lvalgrind , is it?
<jtaylor> no
<jtaylor> running your application under valgrind
<ESphynx> No linking necessary?
<jtaylor> no
<ESphynx> Guess I can try that.
<ESphynx> it used to be just linking with it right? :)
<pkt> no
<ESphynx> In the early days?
<pkt> it was always running it under valgrind
<pkt> there were other projects that required linking
<pkt> e.g. electricfence etc
<ESphynx> ah. electric fence is the one I was thinking of.
<pkt> valgrind works in a different way
<ESphynx> k.
<jalcine> viva la valgrind.
<pkt> your program sees valgrind "as the cpu" sort of
<ESphynx> eC's memoryguard works by using another version of libecere.so :)
<ESphynx> k
<ESphynx> it's surely nowhere as good as valgrind, but usually works great :P Can you run Valgrind on MinGW/Windows?
<ESphynx> ok guys. What is wrong with bash's tab completion???
<pkt> works here
<ESphynx> It's trying to be too intelligent, and won't let me complete files!
<ESphynx> e.g. doing make obj/ doesn't autocompelte... it will only give me 'rules', but what if I want to specify an object target?
<pkt> you can use shopt -u progcomp I think
<pkt> this will disable programmable completion
<ESphynx> prog-and-args -- how does that work? I did  'valgrind obj/ecc myargs here' but my app doesn't seem to be getting any args?
<pkt> then you can enable it again
<ESphynx> hehe k, thanks!
<ESphynx> sorry, I had a space where I shouldn't have. works now
<ESphynx> ok, under Valgrind, it seems to compile fine!
<ESphynx> I get a bunch of 'Source and destination overlap in strcpy(0xbea45aeb, 0xbea45aeb)'
<pkt> Hehe great, how I always manage to get more than I sign up for :P
<pkt> I started with the simplest RC bug, it seemed to be "just a resync request"
<pkt> now it seems that the package actually needs surgery
<ESphynx> pkt: Which package is that? :P
<pkt> radare
<pkt> I picked it from the list of rc bugs
<ESphynx> hehe
<pkt> since it was among the few that I knew about :P
<ESphynx> So these strcpy things... I'm not really worried about :|
<pkt> ESphynx: the friend that had the problem with linking because of as-needed
<pkt> he also had a memory corruption
<pkt> because he had a double free bug in his code
<pkt> i.e., he free'd a var without making it NULL and then he free'd again
<ESphynx> but his double free bug was unrelated to the as-needed, right?
<pkt> yes
<ESphynx> yeah, no such thing as double free in my code ;P
<ESphynx> and it works fine in Valgrind!
<pkt> I only mention because this problem also only showed in gcc 4.6
<ESphynx> maybe I should replace calls to ecc in the package by 'valgrind ecc' for Precise :P
<pkt> *with
<pkt> It seems you are dealing with a "heisenbug"
<ESphynx> hehhe
<ESphynx> is than an uncertainty principle?
<pkt> It is a term used for a bug that doesn't want to reproduce under debugging infrastructure
<pkt> like gdb or valgrind
<ESphynx> hehe. let me try simple gdb.
<pkt> So, about radare. I got the package from debian, but it wouldn't build
<pkt> then I discovered that the version in precise shouldn't build either
<pkt> (it has the same bug)
<ESphynx> great, under gdb, it goes nuts.
<pkt> and now that this is fixed as well, lintian decides to reject it
<pkt> because of the decision in debian to reject waf binaries :P
<tumbleweed> well, at least yo uare half way there
<pkt> I hope more than half hehe
<pkt> But this could probably be characterised a "hydra bug"
<pkt> every subbug I fix 2 others are revealed :P
<ScottK> The new minc in Unstable looks like we might want it, if someone has time to investigate...
<ESphynx> jtaylor: Any idea why something would work on Valgrind (without seeing any error), but behaves nuts on GDB?
<jtaylor> valgrind runs under a very different environment
<jtaylor> which is often more resistant to issues
<jtaylor> did it output any errors?
<ESphynx> jtaylor: only those strcpy overlap errors (strcpy(string, string))
<jtaylor> thats your issue
<jtaylor> libc has changed
<jtaylor> this will now crash
<ESphynx> jtaylor: you sure?
<jtaylor> yes
<jtaylor> memcpy's are now done backwards
<jtaylor> that breaks overlaps
<ESphynx> i.e. you're positive something changed between oneiric and precise ?
<jtaylor> but is faster
<ESphynx> ugg. on x86?
<jtaylor> its something that changed recently
<ESphynx> I can understand on some exotic platform
<ESphynx> but on x86?
<jtaylor> use memmove for overlaps
<jtaylor> on x86
<ESphynx> it's not even 'overlap' is the same string :|
<akrogames> hi jtaylor
<ESphynx> well. if you say so!! I'll go and hunt those down.
<ESphynx> thanks for clarifying this
<jtaylor> not sure how that will work
<jtaylor> but its 100% an issue that must be fixed
<ESphynx> jtaylor: you mean the same string?
<jtaylor> there should be a flag for libc hhat disables the feature
<jtaylor> read the README
<ESphynx> jtaylor: i'd love to try out that flag...
<ESphynx> to be sure before I invest the time to fix this
<jtaylor> let me check
<ESphynx> thanks
<ESphynx> (So it would be libc rather than gcc?)
<jtaylor> yes
<jtaylor> LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libc/memcpy-preload.so /path/to/binary
<jtaylor> though that change should already be in oneiric
<broder> ESphynx: regardless of whether it fixes *the* problem you're trying to track down, strcpy(string, string) is definitely *a* problem and you should not be doing it
<ESphynx> I understand and respected that for memcpy...
<ESphynx> But to me strcpy(string, string) should just work :P
<jtaylor> no it should not
<jtaylor> and never should have
<ESphynx> Why not :)
<jtaylor> the manpage clearly says the memory regions *must* not overlap
<jtaylor> ok it only says may not :O
<ESphynx> too bad Dennis isn't among us anymore to discuss it :P
<jtaylor> that should be fixed
<jtaylor> why do you do that copy in the first place?
<ESphynx> jtaylor: i use it e.g. for left trimming purposes
<ESphynx> strcpy(string, string + x) , where x sometimes is 0
<ESphynx> From Valgrind's output, it seems to happen in 3 spots: LoadTranslatedStrings, ChangeExtension, and TrimLSpaces
<broder> ESphynx: it would be better to strcpy(string + x) and then free(string)
<broder> assuming you're using a heap buffer
<broder> err, sorry, strdup
<ESphynx> right.
<ESphynx> I have my own memory manager though... so I have CopyString()
<ESphynx> but I generally try to avoid heap allocs...
<ESphynx> thanks guys. since I only have 3 spots should be easy to try it out
<jtaylor> did the wrapper work?
<ESphynx> jtaylor:  LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libc/memcpy-preload.so /path/to/binary  --> this is to revert to the previous way?
<jtaylor> yes
<ESphynx> let me try that
<jtaylor> there is also a version that dumps to syslog
<jtaylor> LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libc/memcpy-syslog-preload.so /path/to/binary
<ESphynx> hmm x86 here, not 64 bit
<jtaylor> hm the change is only in amd64
<ESphynx> yeah I don't seem to have this memcpy-preload.so
<ESphynx> nor a /i386-linux-gnu/libc directory :|
<pkt> Hmm, ok now the package builds, so the problem becomes how to push the fixes
<pkt> It isn't just a sync request anymore since there is an extra patch
<pkt> And I think maybe it would be good to push to debian as well
<micahg> pkt: is this for radare?
<pkt> yes micahg
<jtaylor> can I see the diff?
<jtaylor> the package looks in bad shape
<jtaylor> lots of uncaught errors in the logs
<jtaylor> as needed issues
<jtaylor> requires py2.5
<micahg> and we have radare2 already
<jtaylor> can we just remove radare then?
<micahg> no reverse dependencies, we could remove it
<pkt> I 'm fine with removing it as well
<pkt> my fix is just for the FTBFS
<jtaylor> I looked at it too, fixing one issue just uncvered another issue later ...
<jtaylor> etc etc
<pkt> hehe exactly
<jtaylor> I'm for nuking it
<micahg> well, the explicit python2.5 dep isn't expressed in the packaging
<pkt> this is what I fixed
<pkt> and for lua as well
<pkt> the build deps are implicit in the Makefile
<jtaylor> ruby is needed too
<pkt> it seems to build without it here
<jtaylor> can you pastebin your diff
<pkt> sure
<ESphynx> jtaylor: I'll be damned.
<ESphynx> jtaylor: The build is working now. Thank you!!!
<pkt> http://pastebin.ubuntu.com/868973/
<jtaylor> you didn't fix the as needed issue?
<pkt> no
<pkt> I didn't see that one
<jtaylor> my not working "fix": http://paste.ubuntu.com/868975/
<jtaylor> src/rsc/gtk/Makefile needs fixing
<jtaylor> that worked pre oneiric
<pkt> when you say not working what do you mean?
<pkt> FTBFS?
<pkt> or not working result?
<ESphynx> Now I have a question guys regarding the multiarch stuff... Adding ia32-libs-multiarch fixed the build on oneiric, but on Precise it doesn't.
<ESphynx> I realize that people can just install the i386 build on their Precise amd64 install... But what about people wanting to build from source on amd64?
<jtaylor> it does not link, but the error is noon fatal
<jtaylor> but its an regression
<pkt> I see
<pkt> I can look at it
<pkt> unless the package is to be dropped of course
<jtaylor> I don't really now the difference between the two
<ESphynx> Alt-F "Search" shortcut ? how can I disable that? :|
<ESphynx> ah no, it's just 'alt / released' :| how annoying!!
<ESphynx> the hud :| disabled that...
<ESphynx> E: Package 'ia32-libs-multiarch' has no installation candidate --> where should I ask about this?
 * Pikkachu tired
<ESphynx> when tired, sleep :)
<ESphynx> "This may mean that the package is missing, has been obsoleted, or is only available from another source"
<pkt> micahg fwiw I think I fixed the as-needed issue as well
<pkt> Sorry for taking so long but compiles take long time here
<ESphynx> tumbleweed: you remember this amd64 issue I had? =)
<pkt> http://pastebin.ubuntu.com/869020/
<pkt> these are my changes
<ESphynx> pkt: Any idea about multiarch? :| where should I ask about this? :\
<pkt> sorry, not much experience with this
<ESphynx> I basically want to know how one is meant to build a 32 bit app on a 64 bit machine :|
<pkt> ah ia32-libs-multiarch
<pkt> it reminds me of something
<JanC> multiarch allows you to install i386 packages on an amd64 system
<pkt> wine was broken a little time ago because of this I think
<ESphynx> adding this fixed the build on Oneiric (i.e. just ia32-libs, which works on Natty, wasn't enough)
<pkt> there was a change for precise IIRC
<JanC> so no more need for ia32-lib*
<ESphynx> JanC: I understand that. but what about 'building' on a 64 bit machine
<JanC> (in theory)
<ESphynx> a 32 bit app?
<JanC> well, I guess you would need the right 32-bit compiler & -dev packages
<ESphynx> JanC: which are all specified in my package dependencies... So I would wish my package builds on a 64 bit machine as well
<ESphynx> But I get this error: Package ia32-libs-multiarch is not available, but is referred to by another package.  This may mean that the package is missing, has been obsoleted, or is only available from another source. E: Package 'ia32-libs-multiarch' has no installation candidate
<JanC> ESphynx: one option is to use a chroot or similar
<JanC> pbuilder can do that...
<ESphynx> JanC: On Oneiric, which also uses multiarch, it 'just works'
<ESphynx> (My makefiles all have -m32 to build in 32 bit)
<JanC> BTW: you probablmy don't need/want any ia32-lib* packages anymore
<JanC> as a dependency
<ESphynx> JanC: but I do need the 32 bit dev packages to be installed! how can I let the package manager know about that?
<ESphynx> for the build to work...
<pkt> btw I think the package is now ia32-libs-multiarch:386
<ESphynx> pkt: that might work :)
<JanC> maybe specify dependencies as libfoo-dev:i386 ?
<ESphynx> JanC: I got all those coverd (well not with :i386... I just learned about that :P)
<ESphynx> i'm downloading Precise 64 so I will give that a try
<JanC> what I mean is: don't use the ia32-* stuff anymore  ;)
<ESphynx> JanC: right. use :i386 instead ?
<JanC> I think so
<ESphynx> that's basically my question :P hehe, what should I do :P
<JanC> I think you should build them on a 32-bit system/chroot and then install using :i386 on the amd64 system  ;)
<ESphynx> JanC: that's not easy for people downloading my software as source :P
<JanC> at least, I think that's how it's done officially
<ESphynx> I want them to just do 'make' and it works
<JanC> PPA?
<pkt> JanC's way seems the right way to go
<ESphynx> ESphynx: i mean, right from a git clone... I want them to just do 'make' even if they are on amd64
<ESphynx> pkt: :i386 ?
<pkt> I mean to build in 386 chroot
<ESphynx> pkt: that's a pain for users.
<JanC> ESphynx: why would you need to build 32-bit only anyway?
<pkt> :i386 seems to be for depending on i386 libraries
<ESphynx> JanC: 'cuz my software doesn't support 64 bit yet :P (i hope it will later this year...)
<pkt> not for dev tools, at least if I understand correctly
<ESphynx> pkt: those ia32-libs / ia32-libs-multiarch did get things building on oneiric though :P
<JanC> ESphynx: make a daily build PPA on Launchpad for those who want the latest version, but really, you should fix your software first instead of trying to set up weird build systems  :P
<Pikkachu> amazing, I installed libglib2.0 and it succeeded to install, but now thinks removing it is too dangerous???
<ESphynx> JanC: yes, but I still think it should be possible to build in 32 bit on a 64 bit system.
<pkt> Unfortunately I have to leave now
<ESphynx> I mean, it was easy before
<ESphynx> thanks for all your help pkt. good night and take care :)
<pkt> I will put radare in my ppa and look into how to merge it tomorrow
<RAOF> It *is* possible to build 32bit binaries on a 64bit system, but it's non-trivial.
<pkt> thanks ESphynx: I hope you will solve the build problems
<ESphynx> JanC: and it's not weird :P
<JanC> ESphynx: it is possible, but the recommended way is to use a chroot or a VM  ;)
<ESphynx> RAOF: Any advice?
<ESphynx> pkt: I solved the i386 one!
<pkt> cheers, goodnight everyone :)
<ESphynx> pkt: it was the stricter libc regarding strcpy overlap...
<pkt> ah, that makes sense yes :)
<RAOF> ESphynx: Multiarch gets you *most* of the way there, but -dev packages aren't multiarched yet.
<ESphynx> as jtaylor pointed out ;P
<JanC> building binaries is one thing, building packages complicates it somewhat more
<Pikkachu> if I didn't recover the additional files the system would be compromised: libglib2.0-0-dbg libglib2.0-0-refdbg libglib2.0-cil-dev libglib2.0-doc
<ESphynx> RAOF: it was working on oneiric ... with ia32-libs and ia32-libs-multiarch
<ESphynx> RAOF: but on precise now I get this weird E: Package 'ia32-libs-multiarch' has no installation candidate
<ESphynx> RAOF: https://launchpadlibrarian.net/95113396/buildlog_ubuntu-precise-amd64.ecere_201203031148-0~446~precise1_MANUALDEPWAIT.txt.gz
<Pikkachu> anyone using pidgin help me testing a thing?
<ESphynx> Pikkachu: What's your pidgin plugin do?
<RAOF> ESphynx: Oh!  That's very simple - don't build an amd64 package :)
<RAOF> ESphynx: Your i386 package will show up on amd64 packages, and the multiarch support will pull in the relevant dependencies.
<ESphynx> RAOF: I understand that. but I'm worrying about people ON a 64 bit machine, wanting to build my source.
<ESphynx> I want 'make' to work for them.
<Pikkachu> ESphynx: changes nick when you are away (can't be tested within this channel :(, but you could use some other network )
<ESphynx> Pikkachu: hehe sorry I don't use pidgin, I use Ecere Communicator and mIRC :P was just curious
<RAOF> ESphynx: Ah.  That's no longer possible without some manual work on their side (creating dev symlinks).  It only accidentally worked with ia32-libs, too :)
 * Pikkachu brb
<ESphynx> RAOF: I wish it would accidentally work again.
<EvilResistance> is CDBS still supported/used?
<EvilResistance> for packaging
<EvilResistance> oh nevermind
<ESphynx> RAOF: it worked till Oneiric ...
<EvilResistance> but perhaps a MOTU could discuss with me how this could be improved: https://wiki.ubuntu.com/PackagingGuide/Basic#rules
<EvilResistance> erm
<RAOF> ESphynx: Well, it can *kinda* work now; you'd need to instruct the user to install libfoo-dev:i386.  That'll work, as long as they don't have libfoo-dev:amd64 installed.
<EvilResistance> ermhttps://wiki.ubuntu.com/PackagingGuide/Basic
<EvilResistance> BLEH
<EvilResistance> https://wiki.ubuntu.com/PackagingGuide/Basic <-- this even
<ESphynx> RAOF: ugg!!!
<jtaylor> RAOF: aren't many -dev packages coinstallable?
<ESphynx> RAOF: but it does 'skipping incompatible' , doesn't it?
<ESphynx> RAOF: the linker ignores wrong architecture...
<EvilResistance> MOTUs: https://wiki.ubuntu.com/PackagingGuide/Basic <-- doesnt this ignore the 'install' file, which defines "Where to put built files"?
<ESphynx> RAOF: really it's only an apt-get being stubborn here that's the problem
<jtaylor> ESphynx: you have to pass -m32 of course
<RAOF> ESphynx: Right.  But the *correct* architecture is available.  As long as you pass -m32.
<ESphynx> i.e. it works in oneiric, with both pacakges installed
<ESphynx> jtaylor: I do (always)
<ESphynx> RAOF, jtaylor: So should I just try chanigng the ia32-libs dependencies for libbla-dev:i386 ? might that work ?
<jtaylor> I don't think that works yet
<RAOF> ESphynx: Yes, that will probably work.
<micahg> no, that won't work on the buildds
<RAOF> Oh, that's right.
<jtaylor> or it will ^^
<ESphynx> love it ;)
<RAOF> You can't have a package dependency on :i386.
<RAOF> You can *tell* people to install :i386, but there's no syntax for doing that in debian/control.
<ESphynx> But will it work for the user
<ESphynx> to do apt-get install with :i386 ?
<ESphynx> and I'll just disable the PPA build for amd64 on Precise.
<EvilResistance> micahg:  jtaylor:  can i get your input on the packaging guide?
<EvilResistance> it appears to be missing things
<EvilResistance> (the basic guide)
<RAOF> Yes.  It should work for the user (assuming they don't have :amd64 installed)
<ESphynx> RAOF: Even if they do, I think? (hope)
<Pikkachu> hi, I'm willing to have launchpad compiling and building a plugin I wrote to pidgin onto a PPA, I have created the Makefile based on another plugin, does it look good? http://pastie.org/3521901. I wanted to remove the unnecessary flags tough.
<jtaylor> RAOF: most -dev packages should be coinstallable?
<jtaylor> I tried it once with one of mine
<jtaylor> worked flawlessly
<ESphynx> jtaylor yes I would think so.
<RAOF> jtaylor: I'm pretty sure it's a policy violation to have -dev coinstallable.
<micahg> EvilResistance: install file not needed for basic packaging (i.e. one binary)
<jtaylor> really?
<jtaylor> I have seen a couple of -dev pacakge declaring MA: same
 * ESphynx beats the policy
<jtaylor> why would it violate policy?
<micahg> well, coinstallable dev packages isn't required by multiarch policy yet
<ESphynx> yes, why? :O
<ESphynx> I vote it should be _o/
<jtaylor> when the checksums match it works fine
<ESphynx> thanks for all the help guys. appreciate it.
<jtaylor> but I recall the huge discussion on that on d-d
<ESphynx> got to run for now ;) cheers.
<jtaylor> is there a result of that yet? I haven'T read everything
<RAOF> jtaylor: http://wiki.debian.org/Multiarch/Implementation#What_does_the_end_result_look_like.3F
<RAOF> Hm, actually, on closer inspection... no.
<jtaylor> RAOF: multich same -dev package conform to that
<RAOF> That doesn't prohibit multiarch -dev packages.
<ESphynx> successful i386 PPA build on Precise =) https://code.launchpad.net/~jerstlouis/+recipe/ecere-daily-multiarch
 * Pikkachu brb
<tumbleweed> ESphynx: my recommendation was to not bother building on amd64, in the multi-arch world
<ESphynx> tumbleweed: right, I think i'll go that way, I was just worried about people 'building' on an amd64 system...
<ESphynx> but as RAOF and jtaylor pointed out, they can probably install the :i386 packages
<ESphynx> (which unfortunately we cannot do from the package system)
#ubuntu-motu 2013-02-25
<ESphynx> I get the weirdest build error now on Lucid related to PTHREAD_MUTEX_RECURSIVE :S It built fine a week and a half ago...
<dholbach> good morning
<geser> good morning
<tumbleweed> Laney: mitya57 thinks ubuntu_upload_history is out of date. Can you poke it? where do I find logs?
<tumbleweed> oh, hrm, found the stuff in your homedir
<tumbleweed> it looks up to date
<Laney> might not be running
<Laney> the import side
<tumbleweed> yeah, guessing so
<tumbleweed> no idea where the logs for that live
<Laney> cron email
<Laney> upload-history: lockfile found, exiting.
<tumbleweed> :P
<Laney> just revved it manually
<Laney> seems ok now
<tumbleweed> ta
 * Laney wonders whether to break the lock
<Laney> lucas: ^?
<jtaylor> is there a way to install raring without booting the iso?
<jtaylor> like some clever dd of a chroot to the partition?
<jtaylor> (I'm asking because the isos don't work for me for some undebuggable reason and I slowly need a proper installation for testing :/ )
<tumbleweed> um, debootstrap into a blank partition, and do the rest by hand?
<tumbleweed> it's not much - install a kernel, grub, set up an fstab, and hosts
<ogra_> using ubuntu-core tarballs heps to skip debootstrap :)
<ogra_> *helps
<jtaylor> I'll try that thanks
 * tumbleweed almost always installs with debootstrap, but maybe that's weird or I use odd hardware
<jtaylor> seems to be much easier than I though, why did I waste my time with these isos all thes years :)
<ogra_> haha
<ajmitch> wendar: congratulations on MOTU, sorry I missed the meeting :)
<wendar> ajmitch: thanks :)
<jtaylor> hm ok not so easy
<jtaylor> can't get grub to work
<jtaylor> not helped by that it doesn'T detect my keyboard properly on startup
<micahg> wendar: Logan_: have at it :)
<wendar> micahg: thanks!
<tumbleweed> Logan_: if you're looking for lists of thnigs that need work... http://people.canonical.com/~ubuntu-archive/proposed-migration/
<tumbleweed> bdrung: the thing I just committed to mk-sbuild depends on a recent schroot, do you think that's a problem?
<bdrung> tumbleweed: define recent
<tumbleweed> since august - 1.6.4-1
<bdrung> tumbleweed: btw, mk-sbuild should move into sbuild
<tumbleweed> they already have their own tool
<tumbleweed> but yes, it should
<ESphynx> hey guys :)
<bdrung> tumbleweed: so debian testing and raring ship a recent enough schroot package. i am fine with that. ubuntu backporters have to take care of it (in case someone wants to backport it)
<tumbleweed> bdrung: it's also easily worked around by providing a custom template
<bdrung> tumbleweed: if sbuild has it's own tool, how about combining these tools?
<tumbleweed> bdrung: yes
#ubuntu-motu 2013-02-26
<micahg> Logan_: don't forget to pass -v to debuild or dpkg-buildpackage when generating sources.changes for merges
<ESphynx> so I'm really hoping to hop in to that whole Ubuntu Mobile thing with Ecere :P
<ESphynx> think anyone could help with that? :)
<ESphynx> 'Quickly' would be a place to start? :)
<vibhav> ESphynx: You might want to ask #ubuntu-touch
<ESphynx> ah nice, thanks vibhav
<vibhav> No problems
<Logan_> micahg: Oh, was that upload not done correctly?
<tumbleweed> LoganCloud: nope
<dholbach> good morning
<Rhonda> More recently in the packages.ubuntu.com were a "maverick" and "k9copy".
 * Rhonda boggles at that time concept.
<Rhonda> There is no archive for old releases, like in Debian, is there?
<Laney> Rhonda: http://old-releases.ubuntu.com/ubuntu/dists/
<Rhonda> Hmm, thanks.
<Rhonda> Won't follow up to my response though, I was already liberal.  It started off with "Dear Sirs !" - they can't mean myself.
<Rhonda> Out of curiosity, why haven't the responsible people set the Description for the directories anymore? :)
<Rhonda> Oha.
<Rhonda> And now that I look, the "old-releases" link is on the main page of pkg.u.c.
<tumbleweed> wat (re UDS)
<tumbleweed> there could have been slighty more advance notice there
<cjohnston> jtaylor: ping
<jtaylor> cjohnston: ?
<cjohnston> jtaylor: how did it go with shiboken? were you ever able to sort it out?
#ubuntu-motu 2013-02-27
<jtaylor> well it builds and pyside builds (with a couple new failures which might not necessarily be related)
<jtaylor> when I finally get a raring install going I wanted to test some basic functionality
<jtaylor> and hope upstream replies at some point ...
<jtaylor> if not I guess upload and hope for the memleak is not too bad
<jtaylor> and if it is replace it with the crash again ^^
<jtaylor> I'd say we should decide before feature freeze
 * jtaylor offline
<cjohnston> jtaylor: I'm able to test with raring if you want some assistance
<dholbach> good morning
<ESphynx> 'morning dholbach :)
<dholbach> hey ESphynx
<dholbach> To everyone who speaks a language apart from English: please help out with translating: https://translations.launchpad.net/ubuntu-packaging-guide/ :-)
<dholbach> thanks
 * dholbach will do a page of German translations now
<dholbach> wow... the Brazilians are getting close to the magic 70% mark: pt_BR.po (64%) :-)
<jtaylor> wtf
<jtaylor> su: System error in my chroot
<jtaylor> what does that mean? it worked yesterday ._.
<jtaylor> I need to test something, can someone build http://incoming.debian.org/sundials_2.5.0-3.dsc in raring and check the dpkg-shlibdeps output?
<tumbleweed> is week-old raring ok? (my local mirror is on the blink)
<jtaylor> yes
<jtaylor> weird unstable chroot works
<tumbleweed> talknig of which, mirror-maintainer-poking-time...
<jtaylor> hm quantal works too, should be sufficient for the test
<jtaylor> tumbleweed: you may abort if you like, thanks
<tumbleweed> jtaylor: it finished. all I saw was
<tumbleweed> dpkg-shlibdeps: warning: symbol N_VNewEmpty_Serial used by debian/libsundials-nvecserial0/usr/lib/libsundials_fnvecserial.so.0.0.2 found in none of the libraries
<tumbleweed> dpkg-shlibdeps: warning: symbol N_VCloneVectorArrayEmpty_Serial used by debian/libsundials-nvecserial0/usr/lib/libsundials_fnvecserial.so.0.0.2 found in none of the libraries
<jtaylor> only those two? good
<tumbleweed> yeah
<Rhonda> Subject: problem
<Rhonda> blad 502 getaway
<Rhonda> â¦ and that's all of the mail.  I can just *assume* that it's meant to be related to packages.ubuntu.com, but who knows.  Mails get weird these days.
<Logan_> This may be a silly question, but, as a MOTU, do I also have to be part of ubuntu-sponsors to sponsor stuff for people?
<jtaylor> no
<jtaylor> grats on motu btw
<Logan_> Cool, thanks. :)
<tumbleweed> Logan_: being a membor of ubuntu-sponsors allows you to unsubscribe the team from bugs
<tumbleweed> that's about it
<Logan_> Oh, I see. So it's more of an administrative thing.
<tumbleweed> yeah
<Logan_> Still waiting on my cloak (*cough* Pici *cough*) ;)
<Logan_> Is sync package not working for anyone else?
<Logan_> *syncpackage
<jtaylor> what happens?
<Logan_> jtaylor: http://paste.ubuntu.com/5571510/
<Logan_> It's weird because it was definitely working yesterday.
<tumbleweed> Timestamp appears to come from bad system clock
<Logan_> I checked my system time, and it is correct.
<Logan_> I even did a dpkg-reconfigure of tzdata.
<Logan_> â¦wait, no it's not.
<Logan_> I set it to EST, and it says "Local time is now: Wed Feb 27 11:43:13 EST 2013."
<Logan_> And it's 3:03 PM...
<jbicha> Logan_: by the way, when the sponsoree doesn't have a public email address in LP, you probably don't want to use the -s option
<Logan_> kk
<tumbleweed> and that bug wasn't a sync request
<Logan_> But, since it, by the nature of the new version of the software being in experimental, fixes the bug, shouldn't I mark that bug as fixed by the sync?
<Logan_> (Or are you just saying that I shouldn't include a sponsor?)
<Logan_> *sponsoree
<tumbleweed> yeah, the sponsoring
<Logan_> Ah, okay.
<Logan_> Another question (sorry) - when it says to wait for the sync to be successful before closing the bug, does that mean I should wait until the package has been built/accepted into the archive?
<Logan_> Or should I just wait until I get the e-mail saying the sync was acknowledged?
<tumbleweed> so, syncpackage sends a sync request to LP
<tumbleweed> LP doesn't actually do that immediately, but queues it
<tumbleweed> when it does get around to looking at it, it may reject the sync
<tumbleweed> so, either leave it open until you get an email saync it synced, or remember to go back and re-open syncs, if it gets rejected
<Logan_> Okay, awesome.
<tumbleweed> *sayng, *re-open bugs
<tumbleweed> I'm typing sync too much :P
 * ScottK can't remember the last time he had one rejected, so has a strong opinion on which option is less work.
<tumbleweed> yeah, I put that prompt in before we really had a feel for how it would work
<ajmitch> probably best to wait until you know the package has built successfully & been published
<tumbleweed> we should really just add bug-closing support to syncs in LP
<tumbleweed> although, that's probably hard
<tumbleweed> for normal uploads, the bugs get closed on copy into -release, right?
<Laney> yeah
<Laney> or -updates
<tumbleweed> so, if we wanted to attach bug closing to a sync, it'd have to be attached to the SPPH
<jtaylor> got a step closer to installing raring
<jtaylor> if I pull out the usb before starting the step that hangs it continues
<jtaylor> but of course the test fails with io errors then
<jtaylor> I probably have to try a cd ._.
<Laney> tumbleweed for DPL!
<Laney> (re -vote)
 * tumbleweed hides
 * ajmitch seconds
#ubuntu-motu 2013-02-28
<ScottK> bdrung: "* Bump Standards-Version to 3.8.4 (no changes needed)." <-- udt.  I hope you bumped it to 3.9.4.
<micahg> cody-somerville: are you DM/DD or just maintainer for catfish?
<cody-somerville> just maintainer I believe
<micahg> hrm, ok
<ESphynx> 'evening gentlemen
<ESphynx> so hmm guys... what would the deadline be for my Ecere release to make it into Raring?
<ESphynx> I was thinking I could make a pre-release first to integarate it and then the official release a week later?
<micahg> ESphynx: Mar 7 for new features, bug fixes until a couple days before release
<ESphynx> micahg: yes... so, could I release say, 0.44.09 before March 7, and then 0.44.1 a week or so later?
<micahg> sure, as long as the new version has no features (and I'd shoot for a bit before the 7th as you need sponsorship to Debian and Ubuntu)
<ESphynx> I'm going to have the 64 bit support ready, but not all the testing/bug/fixes tweaks that I want in 0.44.1
<ESphynx> still not clean on what constitutes a 'feature' :P is this as strict as for SRUs? ;)
<ESphynx> clear*
<micahg> new functionality
<micahg> new library SONAME
<micahg> https://wiki.ubuntu.com/FeatureFreeze
<ESphynx> ah well there won't be no new library for sure
<ESphynx> a lot of the things might have to do with the Windows installer in fact
<ESphynx> but for example... [   ] Switch to OpenGL if opening 3DS from commandline
<ESphynx> would that be OK? ;)
<ESphynx> or say... [   ] Edit/Copy/Paste buttons in toolbar
<ESphynx> (I have this list of things I'd like to get done before 0.44.1 ... they're all minor tweaks and enhancements or bug fixes)
<micahg> if there was already opengl available and you're switching a default, that might have passed before, idk about now; if the buttons were there before, it's UI freeze, if they weren't feature freeze
<ESphynx> tthe buttons were not there
<micahg> so, I'd say new buttons are functionality unless the functionality was previously there
<ESphynx> there;s already opengl mode in the IDE, but it's not enabled unless you switched to it... i want to auto switch to it if you launch the ide with .3ds model filename to open
<ESphynx> micahg: well the editor's cut/copy/paste functionality was already there :P just no buttons for it
<ESphynx> but these are just examples ( I got a long to do list we won't go one by one :P )
<ESphynx> it's just that 1. I want to make sure this release makes it into Raring  2. I want to fix as many things as possible for this release (to me adding missing cut/copy/paste or not seeing your model when you open it 'cuz you're not in OpenGL mode these are bugs )
<micahg> IANA release team member
<ESphynx> ah =)
<micahg> so I have to err on the side of caution
<ESphynx> anyways, I'll try to squeeze as much done as possible
<ESphynx> and then we'll just have to see if the official 0.44 is included or not
<ESphynx> micahg: did you or xnox ever got the chance to look at the SRU ? :)
<micahg> nope, I'm a bit behind on Ubuntu work
<ESphynx> ah :(
<ESphynx> actual 64 bit support is working now :P except for the boostrapping (working on that this weekend)
<ESphynx> I also greatly improved the Android support last night =)
<Unit193> micahg: So if something gets in unstable by say the 5th, could it get synced over to Raring?
<micahg> sure
<ESphynx> micahg: 5th is a good date? 11.59pm EST / 5th? ;)
<ESphynx> hmm but I'd need to have the package uploaded before right ?
<ESphynx> damn time :P
<ESphynx> been rushing on this :|
<ESphynx> say, Monday night EST? :)
<micahg> should be fine, you only need 6-12 hours to be able to sync from Debian usually
<ESphynx> if I dput it to mentors? :)
<micahg> well, I can only help on the Ubuntu side
<ESphynx> hopefully xnox is around :P
<ESphynx> that's why I wanted to plan ahead with you guys ;) don't wanna miss the boat
<Unit193> micahg: Thank you!
<ScottK> ESphynx: Personally (and I am a member of the release team) I'd prefer to see you land something a day after feature freeze and ask for an exception and land crap right at the deadline.  FFe's are generally approved somewhat liberally right after FF.
<ESphynx> ScottK: k, thanks. even a week later?
<ScottK> Time is not your friend.
<ScottK> It's not a step function, but we do get more strict over time.
<ESphynx> hehe :) mind you i wasn't going to be crap, just more time for testing and fixing :)
<ScottK> Don't take this as "Oh, I have more time, so I can add X, Y, and Z".
<dholbach> good morning
<geser> good morning
<bdrung> ScottK: yes, to 3.9.4
 * tumbleweed doesn't know why I'm rambling about UDS on ubuntu-devl. I just feel I have to say something...
<ogra> tumbleweed, what surpises me is that nobody seems to have read the last paragraph of jonos mail ... its not set in stone
<tumbleweed> ogra: of course - maybe that just reminds us that nothing is?
<tumbleweed> I don't get this UDS. I don't feel the urge to submit any blueprints (and it doesn't look like anyone else has either)
<tumbleweed> I assume it's happening because we want to discuss specific things, but nobody has said what tehy are
<ogra> we'll see how it turns out, for now the most important bit is that we need to do planning on a shorter schedule and need the community to participate
<ogra> i personally expect physical UDSes again in the future (probably one per LTS or so) but the need for quicker planning cycles is there and we need the community for it
<ogra> and thats only possible to something like a virtual one
<tumbleweed> it'd easier to engage the community if we felt like we had a clue what was going on
<tumbleweed> I don't
<ScottK> ogra_: I read it.  It's set in stone for the next two UDS (what would have been one).  It would be better if it were at least explained why the sudden need for more planning cycles.
<tumbleweed> slangasek has done that to some degree
<ogra_> ScottK, tabler and phone ecosystem velocity
<ogra_> *tablet
<ScottK> That's a category, not a reason.
<ScottK> I mean it's suddenly so urgent we have to have a UDS in a week?
<ScottK> What happened we couldn't have had this discussion in a timely manner?
<tumbleweed> and there's still nothing scheduled
<mitya57> having schedule available only the day before the UDS is a shame
<tumbleweed> err, did anyone say that the schedule will only be available the day before it?
<tumbleweed> I mean, of course UDS schedules change all the time, but surely topics should be appearing?
<tumbleweed> where are the gearing up for UDS threads on ubuntu-devel?
<mitya57> "Since we're short on time we'll probably select the talks on Monday" â Jorge Castro
<ScottK> mitya57: That's plenaries, not the actual sessions.
<tumbleweed> sessions aren't "talks" anyway
<mitya57> ok, taking my words back then
<ogra_> ScottK, i can only speculate myself here but i think the distance between the two would have become to small
<ogra_> (i totally agree that a one week notice is crap btw, but we also werent notified internally earlier than you)
<mitya57> Do we at least know the time range â i.e. will it be whole day, or European day, or American?
<tumbleweed> http://fridge.ubuntu.com/2013/02/26/ubuntu-developer-summits-now-online-and-every-three-months/
<ScottK> ogra_: But it's at least the case for you that it's your job to show up, so there's one set of conflicts you don't have.  I think most people who work for !canonical can't just do that.
<ogra_> ScottK, yeah, agreed, i'm not thrilled at all, but i see that we need shorter cycvcles and cant do 4 UDSes per year
<ScottK> Personally, I already have work commitments that preclude participation.
<tumbleweed> o_O I see the timeslots changed from starting @ 4pm UTC to 2pm
<mitya57> great, evening-night here in Russia
<tumbleweed> ogra_: I thought the cycles were already too short to get things done in (re scott's rolling proposal a while ago)
<ScottK> ogra_: If we need shorter development cycles, let's have that discussion first.  It seems to me that the changes to UDS might follow a discussion on release velocity, not preceed it.
<ogra_> we dont need shorter developemnt cycles but shorter planning cycles
<tumbleweed> anyway, I suspect that if we need 4 UDSs a year, there should be a mix of physical and virtual (and possibly the UDSs should be more specific, but that risks dividing the project)
<ScottK> If we execute on a six month periodic, why would be need to replan the release?
<ogra_> tumbleweed, right, and nobody said there would never be a ohysical UDS again, jono explicitly said it will be reviewed afterwards
<tumbleweed> I think many of the effects it'll have on the project won't be visible in the short-term
<ogra_> right
<stgraber> Laney, ScottK, micahg: hey, I just filed bug 1135860 to update the lxc backport in precise following an sru that just landed in quantal. I wasn't sure whether this was done automatically or not, so figured it wouldn't hurt to file a new backport request.
<ubottu> bug 1135860 in Precise Backports "Please backport lxc 0.8.0~rc1-4ubuntu39.12.10.2 (universe) from quantal-updates" [Undecided,New] https://launchpad.net/bugs/1135860
<ScottK> it's not done automatically.
<ScottK> stgraber: Done.
<stgraber> ScottK: thanks!
<foxx> @all - having a little bit of confusion with makefiles and pdebuild (20 hours of banging my head against a wall).. the issue seems to be that the DESTDIR is not being passed to the makefile.. so when i attempt to do cp $(DESTDIR) etc, it gives a permission denied error.. but i cant understand why it wouldnt be passed. Any help at all on this would be greatly appreciated
<slangasek> ScottK: "What happened we couldn't have had this discussion in a timely manner?" - well, some of the designs have been embargoed internally up until this month
<slangasek> so yeah, hard to have a public discussion about those before now
<slangasek> (designs+architectures)
<ScottK> slangasek: Right, but they were known, so that fact that we should have the discussion was certainly known and discussable.
<ScottK> I understand it may not have been possible to have the actual "UDS" sooner, but it could have been planned out and announced sooner.
<slangasek> ah, well, as to that, I can only say that businesses don't always make their decisions on a 6-month cadence
<micahg> ScottK: Laney: I think we should try to leverage some of the autopkgtest stuff for backports to make backporting newer versions easier
<micahg> if we can backport newer stuff to LTSs with less difficulty, LTS only becomes less bad
<ScottK> Not really.
<ScottK> AFAICT, Kubuntu is totally screwed.
<micahg> well, that's why I didn't say good as we still have the problem of having a new stack that will receive updates
<Laney> "a new stack"?
<micahg> Xubuntu isn't as screwed as it doesn't have an upstream with a proper 6 month cadence, but yeah, Kubuntu will be screwed
<micahg> Laney: KDE, Xfce, GNOME new series
<micahg> *major series
<Laney> oh, not a backports thing
<micahg> Laney: right, I meant as a release
<Laney> mmm
<Laney> not sure what the flavour story is with all this
<micahg> Laney: well, without security support from Canonical, intermediate releases are almost useless
<Laney> right
<Laney> but it's not really going to be viable to tell people to use the rolling release if they want (say) the latest KDE
<micahg> worse than useless in fact, dangerous
<micahg> right, the only hope would be to backport the entire KDE stack to the LTS
<micahg> or Xfce or GNOME
<Laney> transitions in -backports? :)
<ScottK> No.
<ScottK> There's no way I'm testing all the kd4libs rdepends.
 * Laney sniggers
<micahg> ScottK: right, that's why I think we should try to leverage autopkgtest
<ScottK> No, my best thought is LTS + per KDE release PPA.
<Laney> I suspect the argument is going to go along the lines of the rolling release has good enough quality so you shouldn't be too scared of telling people to use it if they want new stuff
<ScottK> Of course by the current rules, that can't be a release.
<Laney> you could block all of KDE in -proposed and then release it when it's ready
<ScottK> Or we could remove everything that doesn't have external rdepends from the archive and make KDE PPA only.
<micahg> that would be a shame IMHO
<ScottK> I agree, but then this isn't my idea.
<micahg> the proposal basically turns Ubuntu into Debian + corporate backing
 * micahg wonders if maybe we should look into moving upstream....
<Laney> time based releases :-)
<micahg> but we'd be stuck with the same problem, security support
<micahg> Laney: right, that too :)
<Laney> I'd like to think that something can be worked out with flavours
<Laney> even if releasing stops being an option
<Laney> probably a good v(shudder)UDS topic
<Laney> if people can make it, of course
<micahg> flavours can make intermediate releases, sure, but without security support, there's no value the releases as you can't tell regular users to run them
<tumbleweed> Laney: however, we don't know if that's what's on the table until teh vUDS, because nobody is saying what sessions are scheduled
<Laney> I don't know either, but we'll surely be able to schedule stuff
<Laney> if it comes to it, well, it's just a hangout -- JFDI
<Laney> micahg: It's why I'm thinking about how to make the rolling release work better (migration blocks etc)
<Laney> if the focus is on daily (continuing) quality then in theory it might be more ok for people to run that
<tumbleweed> foxx: sorry, we all seem to be too tied up in wondering what Canonical is up to, to answer you. Can you pastebin a build log?
<ScottK> Laney: I JFhave_other_plans_already.
<Laney> yeah I get that
<foxx> tumbleweed: sure 1 sec
<Laney> not being a flavour lead I'd find it hard to know what would work for you and your users
<Laney> (with JFDI I was just referring to the fact that it's not required to stick to any official schedule if it's not working out, not trying to dismiss any difficulties caused by the short notice)
<micahg> the other problem with rolling release is the tremendous amount of bandwidth needed for constant updates
<micahg> at least that problem is solvable with debdelta
 * tumbleweed has locals who are dying for Ubuntu debdelta
<Laney> yeah and pdiffs too
<Laney> the indices aren't small either
<tumbleweed> I think someone even wrangled a server, but he's not quite clued up enough to generate debdeltas
<micahg> and even if the software isn't broken by an update, there could be tremendous UI changes which could disorient users
<tumbleweed> yeah, users like to get change on their own terms (well, when tehy admit to liking chaneg at all)
 * tumbleweed -> pub
<micahg> that's what a release upgrade or opt-in backport is for :)
<foxx> tumbleweed: done - http://pastebin.com/En7k3Mrt
<foxx> (makefile and debian/rules included at the bottom)
<foxx> you'll also see an 'env' dump being executed in the Makefile.. of which you'll prob notice DESTDIR is not in that list lol
<slangasek> Laney: "you could block all of KDE in -proposed and then release it when it's ready" - contrary to the stated purpose of, and works at cross-purposes to the goals of, -proposed as we've deployed it
<slangasek> fwiw
<Laney> I was thinking it's somewhat like what was done for the alpha which was just releases
<Laney> s/s$/d/
<ScottK> Yes, but that was just two days.
 * slangasek nods
<Laney> Right.
<micahg> the other problem is how do you get testing if it's stuck in -proposed...part of the value of the development release is being able to catch important bugs before end users are exposed
<micahg> well, that's moreso a problem with the proposal in general
<Laney> right
<Laney> It was merely the first thing I thought of ...
<tumbleweed> foxx: you're doing stuff in all that should happen install (you only get DESTDIR in install)
<foxx> tumbleweed: sorry for the slow reply, was afk. could you point out where im doing stuff in 'all'? from what i could tell, it was in 'install'
<foxx> oh wait, is this because i didnt include an 'all:' at the top? (retrying with that in now)
<foxx> IT WORKS
<foxx> just because i didnt put 'all:' at the top before install
<foxx> tumbleweed: thank you so much, i was pulling my damn hair out with this.. debian packaging/makefile is not very noob friendly :(
<Laney> Hmm, so if raring-updates is used to roll then there's another potential place to block migrations for flavours
<Laney> I'm sure there's potential to use phased updates here somehow too
<ajmitch> too much mail to catch up on today, with these UDS changes & now suggestions of rolling releases
 * ajmitch really lives in the wrong timezone to discuss stuff on irc
<slangasek> do you?
<slangasek> IRC is eternal
<foxx> wtf irc has concept of time? :X
<foxx> ajmitch: turn off your timestamps
<ajmitch> it does when you want to talk to people as a discussion is happening
 * Laney wibbles ajmitch 
<Laney> what do you think?
<ajmitch> that it could maybe work for main, but universe quality will possibly suffer, since we're still using those terms :)
<ajmitch> and by main, I should say the ubuntu desktop & not kubuntu, etc
<ajmitch> Laney: I guess I won't be able to buy you a beer at UDS now :(
<Laney> I hope we'll still have LTSUDS
<Laney> @ Dunedin?
<micahg> ajmitch: Kubuntu hasn't been in main since 12.10
<ajmitch> micahg: right, but the release changes would affect it still as ScottK has pointed out
<ajmitch> Laney: nowhere big enough here for that
<micahg> it'll affect anyone producing images
<Laney> ajmitch's living room?
<ajmitch> yep, I was just using it as an example
<Laney> break out sessions in the bathroom
 * ajmitch doubts he'll be making it to the 3AM UDS sessions next week
<lifeless> perhaps UDS should run for 48 hours straight with no interrupts
<ajmitch> that'd be fun
 * Laney sends a rambly mail in which he disproves his own proposed scheme
<Laney> rambly
<Laney> err
<ajmitch> the community team did a 24 hour thing a few months ago, I don't think they got an awful lot done
<micahg> lifeless: when is beer-o-clock in a 48-hour straight UDS?
<lifeless> micahg: every 6th hour
<micahg> Laney: I commented in the blueprint about a second britney migration setup
<Laney> yeah, just saw
 * ajmitch looks
<Laney> when I started writing that email I thought it was a cool idea
<Laney> then I started thinking it was less cool
<Laney> and now I'm just confused
<ajmitch> so this is where we start to get more like debian testing
<Laney> it â my "use blocks" idea
<ajmitch> where packages can be removed from testing but stay in unstable, unlike our current system
<Laney> I suppose they do manage to do that with testing
<Laney> but you don't get e.g. the whole of a KDE alpha uploaded to unstable then blocked
<Laney> that's what experimental is for (now there's an idea!)
 * micahg sees laney asking for -proposed-proposed....
<ajmitch> time to rename the ubuntu suites to match debian
<micahg> ajmitch: why can't we pick our own movie?
<Laney> hah, maybe
<ajmitch> micahg: I mean stable/testing/unstable, don't need to use sid :)
<Laney> proposed-proposed which is *blocked* by default
<Laney> and you explicitly unblock stuff when you want it to go p-p â p â u â r
<micahg> actually, it would probably need to be -updates-proposed
 * Laney overengineers
<Laney> no, wouldn't work because you want users to use these alphas
<Laney> which is an antigoal for proposd
<micahg> hrm, was thinking akin to experimental
<Laney> yeah, so not proposed-proposed and no automatic migration then
 * micahg ponders -experimental
<ajmitch> NotAutomatic?
<micahg> yeah
<Laney> yeah that works really well with our buildds
<ajmitch> just upgrade sbuild, it won't take long
 * micahg eyes rolling backports as possible crack den
<ajmitch> micahg: next you'll be wanting crack-of-the-day grumpy groundhog
<Laney> heh
 * micahg wants winter to be over already
<ajmitch> who needs releases when you can build from upstream trunk each day
<lifeless> ajmitch: +1
<lifeless> ajmitch: daily is a little slow
 * micahg waits for ajmitch to make quantum computing affordable allowing everyone to use gentoo style build on the fly for everything
<ajmitch> micahg: but this wasn't my suggestion :)
<ajmitch> https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/GrumpyGroundhog
<Laney> heh
<Laney> if our tests are good enough!
<Laney> we already started doing it with the autolanding business
<ajmitch> yep, and that's because the upstream there has a trunk which is meant to be usable at all times
<micahg> interesting
<jtaylor> hurray got raring running, finally
<foxx> so, im a long time user of debian/ubuntu, but first time ive ever done any package maintenance.. is it just me, or does a shitton of work go into package maintenance? ive been working on a single package for three whole days now
<micahg> it can keep one busy, it can get easier as time goes on
<foxx> hmm - now that ive started playing with it, it feels like all the magic has gone
<foxx> and instead has been replaced by spahghetti makefile code :(
<jtaylor> the beginning always takes time
<Laney> it's like lots of things - pieces will fall into place with experience
<jtaylor> but depending on the package it can stay a lot of work even when the beginning is done, others are simpler
<foxx> got it.. would it have helped if i had prior makefile experience? as in this was the first time id ever made/modified a makefile too
<tumbleweed> most likely, yes
<foxx> well, my first attempt is now finished.. its basically a build wrapper for Atlassian Bamboo.. theres a script that detects and downloads their latest release, then does all the necessary prep/build work, and spits out a deb file.. if i was to put this on github, would someone here mind taking a quick look and give feedback on things i could improve on? ideally id like to contribute more
<foxx> packages and improve my skills on this
<foxx> (it works as well, amazingly lol)
<jtaylor> isn'T bamboo commercial?
<foxx> sadly yes.. as far as i know, this means it wont make it into the official package tree right?
<jtaylor> yes
<jtaylor> I didn't even know you could download it without an evaluation license
<foxx> yeah they changed their system around.. downloads are now public, and u input your license key after install
<foxx> my idea for this script was so their devs could just run it, and then provide a 'deb' download option for their customers
<foxx> although, it does some nasty hacks.. like placing everything into /opt
<foxx> purely because splitting the package out into /usr /var /etc components would have heavily broken it, and fixing would have been... difficult
<jtaylor> opt is a ok place for non free stuff, I think all the stuff you can buy in software center is put there too
<foxx> i assume this is heavily frowned upon?
<foxx> ahh
<foxx> excellent
<ScottK> foxx: I can do in minutes what once took me hours, so it gets better.
<foxx> lol ok - guess its like anything, with practise etc
 * micahg has to try to find some time before feature freeze to help with haskell
<micahg> s/haskell/ghc/
 * Laney too
<Laney> I suppose there's a good chance that feature freeze soon might not mean what it currently does though
<micahg> ScottK: Can I assume we can get a little more time with the ghc migration since it's not seeded?
<micahg> (with proper paperwork filed of course)
<ScottK> I'm assuming feature freeze will be cancelled.
 * ajmitch looks forward to having everyone try & cram stuff in for an LTS feature freeze
<micahg> ah, right
<foxx> hmm, question.. in the event that a package install fails for some reason (say it fails to add a user).. and then you try and remove but the postrm fails because it cant remove the user (as it didnt get added to begin with).. at the moment i have to manually useradd to then perform the --purge.. is there a better way to force things like this? i.e. so even if it encounters errors it will
<foxx> still remove?
<foxx> or does that really fall under the category of user choice, rather than trickery in postrm?
<ScottK> Don't remove the user on purge.
<tumbleweed> ajmitch: nobody has even mentioned what will happen to the rolling release closer to LTS release...
<foxx> ScottK: oh, i thought purge was meant to remove everything, including /var/lib data?
<ScottK> It's almost impossible to be certain a particular user doesn't own any files on the file system, so if you remove it, weirdness ensues.
<ajmitch> tumbleweed: you mean whether the LTS will be branched off & frozen while uplaods still happen for the rolling release?
<ScottK> Remove all the data, sure, but not the user.
<ScottK> This is a matter on which there is some debate, but that seems safest.
<foxx> okay got it.. what about if i reinstall the package and the user exists... should i just force adduser to ignore user exist errors?
<ajmitch> tumbleweed: maybe I think of things in debian terms too much
<tumbleweed> ajmitch: no, I'm thinking in Debian terms here too
<tumbleweed> "rolling people" don't like Debian freezes
<ajmitch> stopping automatic migrations from -proposed for an LTS freeze would probably annoy people who want their rolling updates
<Laney> I wouldn't be surprised if it was a slowing rather than a block (FeatureFreeze style)
<micahg> you just stop the "monthly migration" in the current proposal, but the question would be where can you find the equivalent of t-p-u
<ScottK> foxx: Yes.
<ScottK> micahg: Maybe we start uploading to proposed-proposed in that timeframe.
<ScottK> Actually they could branch off the release into a new derived release at FF if they wanted.
<foxx> thanks @all for the advice :)
<tumbleweed> ScottK: and then your developers go off and don't work on stabalisation
<ajmitch> tumbleweed: like debian? :)
<tumbleweed> and Ubuntu too I suspect
<ScottK> tumbleweed: It's already perfect according to Rick so no problem.
<ajmitch> yeah it's easy enough for people to just work on stuff & upload while the archive is frozen
<ajmitch> ScottK: it's ok, we've got UDS to discuss it
<tumbleweed> if people are not recommending our regular releases to people doesn't that mean even our polished releases aren't stable enough?
<ScottK> I've always recommended regular releases.
<tumbleweed> ajmitch: discuss, but not significantly influence, I suspect
<ScottK> I don't find the LTS releases significantly different regarding stability.
<tumbleweed> neither
<tumbleweed> I only prefer them because they have a longer shelf life
<ajmitch> perhaps they're more stable over time as they've had more resources put in for SRUs
<ScottK> My wife has precise and i have one old desktop running lucid as it won't run newer.
<ScottK> Other than that, all the desktops/laptops are precise.
 * micahg wonders why ScottK has a SPARC desktop... :P
<ScottK> err quantal.
<ScottK> No, sparc last worked on hardy.
 * ajmitch has a lucid desktop at work, and an old laptop still running hardy :)
<micahg> I thought sparc last installed on hardy
<ScottK> It's an old, old intel video chip.
<ajmitch> i740?
<ScottK> Sparc last installed on gutsy and last worked on hardy.
<ScottK> i845, I think.
<micahg> ajmitch: you know you have about 2 months to upgrade your hardy machine before it's forgotten, right? :)
<ScottK> It's one of the ones that they dropped support for on 10.10.
<ajmitch> micahg: considering that the laptop needs some pressure applied to the case to power it on if you're lucky, I'm not overly worried about it
<tumbleweed> micahg: I have a worrying number of hardy boxes in production - migrating off them won't happen in the next 2 months, either (can't afford DB downtime)
<ajmitch> 540 days uptime, not bad for a laptop with a dead battery
<foxx> does anyone know of any reason "/usr/share/debconf/frontend /var/lib/dpkg/info/atlassian-bamboo.postinst configure" would hang in the event of the init.d script calling a nohup command which backgrounds itself?
<foxx> is this because i should be using start-stop-daemon and re-writing the init.d for the project, rather than just 1 line wrapping?
<ScottK> You should be using start-stop-daemon
<micahg> tumbleweed: well, the response to that is, why wasn't a migration planned over the last year? :)
<micahg> but no need to answer
<micahg> it's a common problem
 * micahg heard rumors of etch boxes lying around somewhere in production
<ajmitch> thankfully I migrated off my old debian boxes late last year :)
 * tumbleweed has one of those, too :P
<ScottK> I have one hardy box.  I need to buy new hardware to replace it.
<foxx> ScottK: is it normal to have to re-implement an entire init.d, despite the upstream package already containing a semi working one?
<ajmitch> micahg: only rumours?
<ScottK> Yes.
<foxx> lol ffs
<foxx> im assuming this is what you guys meant by "some are easy, some arent"
<ScottK> Well there's a ~standard template you can use.
<jtaylor> daemons certainly belong to the not easy category
<foxx> oh, do you have the url? i looked around for "init.d lsb template" but had no luck
<micahg> ajmitch: I haven't confirmed anything :)
<foxx> oh, is this it? http://www.thegeekstuff.com/2012/03/lsbinit-script/
<ScottK> http://paste.debian.net/238955/ is an example
<foxx> perfect, thank you
<tumbleweed> foxx: /etc/init.d/skeleton
<foxx> ahh there we go.. how the hell did i not spot that, thanks
<Laney> huh, I've never seen that before either :)
<ajmitch> because you write upstart jobs instead? :)
<Laney> actually I will be for the user session stuff
<micahg> because you don't work with daemon spawn? :D
<Laney> to both of you :P
<tumbleweed> micahg: the real answer is, OS releases end up being tied into entire software stack renewal
<ajmitch> Laney: fair enough, but less useful right now if you want a package for debian
<Laney> yeah I'd just copy something similar and modify it
<Laney> same as for most of the rest of the packaging bits really
<micahg> tumbleweed: right, also most companies don't have proper test suites for their applications, so it's not just a 2-4 week qualification for a HW migration but 6-12 months
<ajmitch> does anything use upstart user sessions right now?
<micahg> tumbleweed: oh, hrm, you said software, not HW
<Laney> i think stgraber only uploaded the first (test) package today
<Laney> so no
<foxx> okay, here's a question.. ive recently taken inspiration from http://synack.me/blog/deploying-code-with-packages which is basically deploying internal releases (such as python webapps) as .deb files on bare machines.. is this an exceptionally bad idea? the releases will sometimes contain an entire debian chroot, a bunch of compiled binaries etc
<tumbleweed> micahg: yes, sw. that said, the only reason we run anything on precise is that some new hardware didn't support lucid :P
<foxx> personally i really liked the idea, but not sure if its considered abuse
<stgraber> Laney: the PPA has been there for the past two weeks, but yeah, nothing's in the archive yet
<Laney> right, in archive is what I meant
<tumbleweed> foxx: well, of course, it's not something we'd do in a distro, but it doesn't sound so crazy
<tumbleweed> foxx: I would have preferred my company doing that rather than spending a year writing a new deployment system (but that was fun, too)
<foxx> heh
<foxx> yeah that was part of my thought process.. "why reinvent the wheel"
 * micahg is looking forward to lucid/oneiric desktop EOL
<foxx> Atlassian Bamboo release workflow combined with saltstack and some bash scripts for automating
<micahg> though less so than before
<ajmitch> micahg: lucid desktop goes EOL pretty soon, doesn't it?
<tumbleweed> having less supported releases is an obvious win
 * ajmitch should upgrade his desktop at work
<micahg> ajmitch: about the same time as hardy server
<ajmitch> good thing I don't have one of those :)
 * Laney 's server is squeeze
 * foxx uses squeeze everywhere
<tumbleweed> yeah, I must squeeze -> wheezy
<tumbleweed> (and should probably work on wheezy RC bugs too)
<foxx> i think we have some ancient routers still running etch too lol
 * jtaylor should also upgrade his work desktop, fedora 11 ...
 * foxx has a feeling hes the only person in here that uses windows as a desktop :/
<Laney> yeah this wheezy freeze feels like it's been dragging on
<jtaylor> my workplace uses fedora as its supported linux desktop, thats just brilliant,by the time IT verified the current release its EOL :(
<foxx> hah
<Laney> how long do fedora support their releases for?
<jtaylor> 1 or 1.5 years I think
<Laney> mm
<ajmitch> Laney: run for DPL & get wheezy released
<Laney> I doubt the DPL has much sway there :(
<Laney> file a GR about it
<ajmitch> argue about said GR for 6+ months
<micahg> ajmitch: almost anyone can get wheezy released, just fix all the RC bugs :)
<tumbleweed> DPL can spend money on the release team, and then things would get really interesting
<jbicha> Fedora does 13 months
<ajmitch> tumbleweed: like the suggestions in http://nthykier.wordpress.com/2013/02/28/wheezy-release-progress-february/ ?
<jbicha> I had an idea a while ago that Ubuntu regular releases should be just 12 months (EOL defined as the day before Release+2), that way we only obviously support upgrading to the next release without skipping releases, it reduces the SRU burden, and better reflects the reality of how developers & most users treat the releases
<tumbleweed> ajmitch: well, I was making a Dunk Tank joke
<jtaylor> I'd agree with 12 month, 18 is a little long
<ajmitch> tumbleweed: I know, just happened to be reading that page at the time :)
<Laney> hmm banshee is at least two rcbugs on that list (the same one)
 * Laney hunts down hyperair
<tumbleweed> (and my internet connection seems horrible tonight. UDS may be fun next week)
<ajmitch> Laney: and libmono-webbrowser2.0-cil
<foxx> hrm.. is there any particular reason init.d/skeleton has a space in the "#! /bin/sh" at the first line, and a colon (:) at the last line?
<Laney> yeah directhex is handling that one afaik
<foxx> never seen that before :X
<Laney> and a keepassx one
<Laney> oh no, s/x/2 is jtaylor's thingy
<foxx> ohh - nevermind - http://wellrounded.wordpress.com/2011/10/18/shell-scripting-shebang-binbash-followed-by-a-space-is-optional/
<ajmitch> Laney: wasn't RAOF looking at some of that banshee issue with dbus & threading?
<Laney> don't think so
<Laney> seems like the fix is known-ish
 * ajmitch is remembering things wrong then
<ajmitch> known-ish but not trivial
<maxb> foxx: The space is I believe simply an optional addition for readability, the colon would be the short form of the 'true' shell command, presumably to do something with the overall exit status
<tumbleweed> foxx: the : is equivalent to "true"
<RAOF> ajmitch: I was, but that should be fixed?
<foxx> oh nice, didnt know you could do that
<ajmitch> RAOF: was just reading through http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700585
<ubottu> Debian bug 700585 in banshee "needs to initialize dbus threading because of GConf" [Serious,Open]
<foxx> learnt so many new tips/tricks since learning about deb packaging.. how i didnt know some of this stuff is crazy
<Laney> we did the naughty fix (in GConf) in Ubuntu
<ajmitch> ah
<tumbleweed> foxx: the exit status of the script is the exit status of the last command executed
<foxx> tumbleweed: the colon is what forces that to happen?
<foxx> i.e. if you include a colon at the bottom, it will exit with the exit status of the last cmd?
 * ajmitch should go & find lunch
<tumbleweed> the colon forces the exit status to be zero, unless you expliticly exited the script earlier
<foxx> ahhh
<jtaylor> so its non readable magic for "exit 0"?
<tumbleweed> yeah, like a perl script that ends with 1;
<foxx> this is gonna sound really stupid but.. is there any benefit/reason not to use exit 0?
<tumbleweed> style? (an unusual style that I haven't seen before)
<foxx> lol got it
<jtaylor> having exit 0 at the end of rc.local prevented a rootkit from working on debian :)
<foxx> lmao
<tumbleweed> nice
<Laney> goodnight
<tumbleweed> yeah, should do that...
 * Laney hopes not to wake up to *too* many posts on -devel
<tumbleweed> it seems to have slowed
<jtaylor> ^^
<jtaylor> did the intial rolling post go to devel?
<jtaylor> I don't seem to have it, only replies
<foxx> well imma be idling here, if anyone has any python related problems/questions, feel free to ask.. would be nice to give something back
<jtaylor> foxx: fix some debian rc bugs :)
<tumbleweed> jtaylor: yes
<foxx> haha, i think it will be a long time before anything i do would be accepted by the core.. but it'd be worth a look.. could u point me to a bug url that might be easy?
<foxx> <-- is so new, he doesnt even know where deb bugs go lol
<jtaylor> http://bugs.debian.org/release-critical/
<foxx> ty
<tumbleweed> if those are all hard, fix an easy, non-RC bug in Ubuntu
<tumbleweed> (we used to have lists of those somewhere...)
<foxx> am i right in assuming that using pbuilder is the standard way of building/testing packages?
<foxx> or rather, the preferred way
<micahg> sbuild FTW
<jtaylor> yes, pbuilder or sbuild
 * foxx googles sbuild
<foxx> lol there are rc bugs in here dating back to 2010 :X
<jtaylor> even 2003: 197254
<jtaylor> the list also lists RC bugs for stable
<foxx> lol christ
<foxx> oh here's something weird..
<foxx> # Do NOT "set -e"
<foxx> every other example script ive seen does include it.. but skeleton says not to.. google doesnt seem to clarify either way
<jtaylor> foxx: see the set -e paragraph here: http://www.debian.org/doc/debian-policy/ch-opersys.html
<foxx> i found a couple of python related rc bugs i could prob help fix.. christ only knows how long it'll take me but it'll be good experience
<jtaylor> unfortunately most rc bugs right now a rather hard to fix
<foxx> ohhh
<foxx> okay set -e makes sense now
 * jtaylor offline
<foxx> jtaylor: tyvm
 * micahg debates starting a zopfli compression thread (http://lwn.net/Articles/540548/rss) on -devel for fun
 * ajmitch debates replying to the release thread to ask who's thinking of the poor app developers
<micahg> ajmitch: that point was addressed, current stuff targets latest LTS, next gen stuff rolls
<ajmitch> yeah, I'm not convinced that will work out well if the platform changes rapidly in a rolling release
<ajmitch> it'd be nice if the software center could not show packages that were no longer installable from extras.u.c or PPAs, due to changes in the rolling release
#ubuntu-motu 2013-03-01
<micahg> I thought the dev release didn't have extras.u.c, I guess it could be smarter when a dependency can't be satisfied
<ajmitch> the dev release doesn't, but a future rolling release scheme probably would
<ajmitch> otherwise people are waiting up to 2 years to get apps using the new shiny code, which completely defeats the purpose of the proposal
<achiang> why wouldn't apps get backported to LTS?
<maxb> Why *would* apps get backported to LTS?
<foxx> YEY - it works
<achiang> because that's where the users are?
<foxx> my first ever (clean?) debian package starts perfectly, installs perfectly, everything
<maxb> Depends which apps and which users.
<achiang> the idea of updating apps in lockstep with the underlying OS is a bit crazy.
<ogra_> well, we have the backports repo for that
<ogra_> though thats just an "if it builds its fine" effort
<achiang> updated apps on stable os shouldn't be a radical idea (or stuck in 2nd class citizenry of -backports)
<ogra_> its a manpower eating idea though ... if you want to do it with some quality ...
<achiang> it's a manpower eating idea because the OS developers package apps on behalf of app developers. :P
<RAOF> Well, not necesarily.
<ogra_> right, it wont matter on ubuntu touch
<ogra_> but thats designed radically different to the normal distro atm
<RAOF> And in the magical convergence world it won't matter on the 14.04 desktop, either!
<ogra_> well
<ogra_> for touch apps it wont
<ajmitch> apps can only get backported to an LTS if the underlying platform of the LTS has what they need
<ogra_> buildability ... as i said :)
<ajmitch> my concern earlier was with apps written against an old version of an API, which won't work any longer due to various changes (eg unity lenses)
<ajmitch> plenty of times that just building isn't enough :)
<RAOF> Yeah. We'll need to have a real honest-to-goodness _platform_, rather than the accidental aggregation of APIs we currently have.
<ogra_> well, if youre an app developer that targets ubuntu apps (as opposed to the general archive) you will surely have to make a choice for the ABI version
<ajmitch> currently there are at least 6-monthly releases to target
<ogra_> not different to android
<ajmitch> changing that to only every 2 years would be difficult
<ScottK> ogra_: The standard for backports is builds/installs/runs.  Amazingly, we've almost never had problems with backports that could do that.
<kurteknikk> Hi, is there anyone available ? i have a quick question.
<tumbleweed> !ask
<ubottu> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<kurteknikk> Basically i would like to know if there's somewhere to follow when new package updates for ubuntu are released.
<Laney> try the raring-changes mailing list http://lists.ubuntu.com/raring-changes
<kurteknikk> Thanks, basically there is a new mysql version which fixes a memory leak
<kurteknikk> so i think it's quiet important, can i submit a "request" on that mailing list ?
<lfaraone> ScottK: uploaded #1015925 to proposed. This is currently affecting most new Ubuntu installations at MIT, so I'm eager to see this fixed :)
<jtaylor> someone have a raring ppc and a little time?
<foxx> i might be opening a can of worms here but.. is there any particular reason Ubuntu are taking the same approach as Windows for thier default window manager? unity really isnt great for PCs, and feels just as wrong as metro on a PC
<foxx> on a tablet, sure it'd work great.. but surely PCs should have a different UI.. well obviously microsoft doesnt feel the same way, but does anyone know why ubuntu have taken the same approach?
<jtaylor> arg
<jtaylor> built scipy on ppc emulator
<jtaylor> and installd b-d via apt-getbuild dep which is missing python ...
<jtaylor> cython
<jtaylor> so restart the 3 hour build ._.
#ubuntu-motu 2013-03-02
<ScottK> lfaraone: How about I review your SRU and you get barry's NM process unstuck.
<ScottK> lfaraone: Accepted.  Now barry's NM.
<tumbleweed> micahg: I see blueman on rcbugs. You cherry-picked bits from 1.23-1 but seemed to have missed the gnome-icon-theme dependency, which does appear to be important
<tumbleweed> jtaylor: seen any big increase in linker failures? (generally you seem on top of these things)
<jtaylor> I saw a few new no-copy-dt-needed
<jtaylor> not sure wh
<jtaylor> in principle they should have appeared when it was first enabled
<tumbleweed> yeah, there seem to be lots of things with libm, pulse, or Xt
<tumbleweed> I tracked it down to binutils change, but not sure what was going on
<jtaylor> probably related to jwilks bug a while bug that it wasn'T working as expected
<jtaylor> let me see if I can find it
<jtaylor> hm no, but probably it was fixed recently
<tumbleweed> I'd also love any ideas for things to do with some new developers
<tumbleweed> build failures and rcbugs haven't resulted in any uploads yet :P
<jtaylor> http://lists.debian.org/debian-devel/2011/08/msg00445.html
<jtaylor> indeed his testcase now fails
<jtaylor> autopkgtests might be a place to work on
<tumbleweed> jtaylor: thanks!
<tumbleweed> (I'd forgotten all about that)
<jtaylor> tumbleweed: when is your jam? I have a very easy sru on my todo list I could leave for you
<tumbleweed> jtaylor: we're doing it :P
<tumbleweed> just got someone started on an autopkgtest for one of my packages :)
<jtaylor> oh, it would be bug: 1113356
<ubottu> bug 1113356 in simutrans (Ubuntu Quantal) "simutrans assert failure: *** invalid %N$ use detected ***" [Undecided,Triaged] https://launchpad.net/bugs/1113356
<tumbleweed> jtaylor: I handed that to ginggs, who knows, maybe you'll even sponsor it
<jtaylor> sure
<tumbleweed> thanks
<lfaraone> ScottK: sure, apologies.
 * lfaraone has been sort of afk from most FOSS recently :/
<cjohnston> The only help that I found on the wiki about syncing a package from debian is to file a bug if you don't have upload perms is to file a bug, and include the necessary info.. Is there any other way to assist/speed up the process?
<jtaylor> use requestsync
<jtaylor> aka, sync request done in 10 seconds
<cjohnston> jtaylor: I completed that... I am referring to actually helping to move the process along (I only did it last night, but if there is another way to assist with it is what I'm asking)
<jtaylor> bug number?
<cjohnston> bug #1139097  I have a couple more that I'm going to be doing in the next day or two as well...
<ubottu> bug 1139097 in dh-make (Ubuntu) "Sync dh-make 0.62 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1139097
<jtaylor> the bugs are added to a queue which is pretty large
<jtaylor> main is to a large part handled by canonical, so less work is done on the weekend
<cjohnston> right.. hense asking if there is any other help I could provide.. If there was something I could do to make it easier, (I honestly have no idea if there is, but I doubt it) then I'm willing to put forth the effort
<cjohnston> I understand the weekend part.. I feel like I'm the only one who works weekends alot of the time :-/
<jtaylor> for syncs there is not much you can do except testing it good
<cjohnston> I figured, but couldn't hurt to ask.
<Laney> cjohnston: yeah, not really - but they are usually sponsored pretty fast in my experience
<Laney> the same advice applies as for all sponsoring - ping if you don't hear anything in a reasonable period of time
<cjohnston> Laney: ack
<siretart> debfx: around? do you know if anyone is already working on a virtualbox 4.2 package?
<cjohnston> if syncing a package in raring will fix multiple CVE's is that better than patching the version in Ubuntu? If so, should I open a sync request for it and just comment in the security bug? (security bug is still valid for older releases, though I guess they could possibly be synced over as well, if that is better than doing a delta)
<notgary> Is there anyone here who can help me with this question? http://askubuntu.com/questions/263193/ibus-package-not-found-while-trying-to-build-gnome-settings-daemon
<Laney> notgary: you want libibus-1.0-dev
<Laney> http://packages.ubuntu.com/search?searchon=contents&keywords=ibus-1.0.pc&mode=exactfilename&suite=raring&arch=any
<notgary> Laney, thanks a lot :0
<notgary> :)
<jbicha> notgary: or you can build with --disable-ibus
<notgary> jbicha, Thanks a lot. That one is preferable.
<notgary> jbicha, how can I find out if the package I'm trying to build can be built without certain dependencies?
<jbicha> notgary: for GNOME stuff you can try reading the configure.ac
<jbicha> also, depending on what you're trying to do, you may find https://launchpad.net/~gnome3-team/+archive/gnome3-staging/+packages useful
<Laney> what are you trying to do?
<Laney> you might find building in some other way like jhbuild more pleasurable
<IDWMaster> I have experience with the Ubuntu packaging system and Launchpad and am looking into getting some of my packages into Ubuntu under the GPLv3 license, what do I need to do to get started?
<notgary> I want to build gnome-control-center so I can work on a bug. I trying to work on the latest source (Gtk+ 3.7.10-based) which is requiring me to go straight to Gnome for the latest sources. I can see that version of Gtk in Gnome3 staging. Is there a way I can upgrade my raring system to pull all of the in?
<notgary> and there's a lot of dependent packages I'm having to build too
<jbicha> notgary: one way is  to use ppa:gnome3-team/gnome3 and ppa:gnome3-team/gnome3-staging to update your system to GNOME 3.7.90, then run sudo apt-get build-dep gnome-control-center and install jhbuild, then run jhbuild buildone gnome-control-center
<IDWMaster> I'm looking to get appToolkit and crosslibs into the repositories from my PPA: https://launchpad.net/~webadm/+archive/idwpackages/+packages
<jbicha> the staging PPA has some regressions though...
<IDWMaster> Hmm
<IDWMaster> I should probably upload to Debian first though; but they're preparing a new release now so it may not be the best timing
<notgary> IDWMaster, Debian would be a good way to do it. I've never done it myself, but I think this doc is what you want http://www.debian.org/doc/manuals/developers-reference/pkgs.html
<notgary> jbicha, Thanks a lot for that. When I try to run jhbuild buildone gnome-control-center I get the error jhbuild: install prefix (/opt/gnome) can not be created
<jbicha> notgary: well you'll need to either create that directory or tell jhbuild where you want to install stuff instead
<jbicha> here's an excerpt from my ~/.config/jhbuildrc  http://paste.ubuntu.com/5580485/
<notgary> jbicha, Thanks a lot. I've just copied that paste and stuck it in my own file. It's building now and I'll let you know how it goes.
<notgary> jbicha, So is jhbuild just a tool for scripting the download and building of a packages and all its dependencies? Earlier tonight, as I was going through all these Gnome build, I was wondering if something just like this existed :)
<jbicha> notgary: you're probably have a few more problems actually since gnome-control-center needs newer versions of network-manager, modem-manager, colord than we currently have
<jbicha> you can use jhbuild buildone on those first and maybe you need repos['git.freedesktop.org'] = 'git://anongit.freedesktop.org/git/' for those
<Logan_> jbicha: Hey, regarding that multi arch Python bug, I just tried building virtualbox locally, and it still fails to find Python...
<jbicha> Logan_: do you have the buildlog? because I have things that failed to build with python in mid-January that build fine now
<notgary> jbicha, I'm getting a dependency issue on gnome-desktop3. It wants 3.7.5 but I only have 3.6.2 installed. I've checked the gnome3-staging page and 3.7.9 is in there and that repo is in my sources.list, but when I do 'apt-cache showpkg gnome-desktop3', it can't find it. Problem persists after updating and upgrading.
<debfx> siretart: I started working on it a bit. I can push the branches if you are interested.
<jbicha> notgary: I believe you need a dist-upgrade
<siretart> debfx: that would be great, thanks!
<ricotz> siretart, i have a ppa with 4.2.8
<Logan_> jbicha: http://paste.ubuntu.com/5580563/
<ricotz> Logan_, you need to patch configure.ac to use the pkg-config file python provides
<debfx> siretart: done, it's in the experimental branch. you also need a newer version of kbuild.
<neo31> We need a mentor to help ubuntu-tn introduce packaging to north africa. we have been working on scribus for long hours and we are stuck with some errors you can find on http://pastebin.com/M0Jmyf8Q
<ricotz> debfx, hi, http://paste.debian.net/plain/239413
<ricotz> debfx, would be nice to have that in so it can be synced
<siretart> ricotz: cool, does it work with raring?
<ricotz> siretart, yes
<ricotz> i mean i guess so, since 4.2.8 added support for 3.8
<jbicha> neo31: scribus is already packaged, it would be easier to start with the existing packaging if all you want is a newer version
<Logan_> ricotz: Oh, were you already working on fixing this?
<ricotz> Logan_, yes, https://launchpad.net/~ricotz/+archive/unstable/+packages
<neo31> scribus is available as 1.4.1 and we are intending to make a package for 1.4.2, could you please tell us the guide lines to follow jbicha ? thanks (we already downloaded the source from svn and installed the requirements)
<ricotz> siretart, ^
<Logan_> ricotz: Awesome - I'll leave you to it then. :P
<jbicha> neo31: I recommend you read through http://developer.ubuntu.com/packaging/html/ it's not complete but it has useful information
<siretart> ricotz: how comes that you didn't need a newer kbuild, as debfx mentioned?
<ricotz> siretart, idk
<IDWMaster> Setting up Debian build environment, seems like the best way to start
<IDWMaster> Still think it's odd that Ubuntu gets a lot of its packages directly from Debian
<siretart> neo31: try 'dh_auto_configure --buildsystem cmake'
<debfx> ricotz: it would be good to get a fix upstream for the python multiarch issue
<IDWMaster> So after I publish to Debian and request a sync, do future releases of my library just automatically get put in Ubuntu, or is there some kind of manual modifications that need to be done to the package when switching from Debian to Ubuntu archives?
<debfx> ricotz, siretart: virtualbox ships with a pre-built kbuild so it probably uses that
<ricotz> debfx, yeah, i am not stripping the tarball
<siretart> debfx: so what's wrong with that, what made you extracting it to a standalone package?
<neo31> yes, we have been following the document all day long. we tried to follow  the document for creating a new package for scribus 1.4.2 and test it with our own ppa jbicha :)
<siretart> neo31: if I'm interpreting the log correctly, then debhelper misdetects the build system and requires some help here
<notgary> IDWMaster, Ubuntu is a derivative of Debian, so it's not strange at all that we get our packages from them. As for updating your package in Ubuntu, you can do it both ways. You can either upload your updates to Debian and they'll eventually make their way into Ubuntu, or you can use a manual process to request a merge/sync which will speed up the process
<debfx> siretart: the problem is that it's not built from source
<debfx> since it has to move to contrib anyway that's not a huge problem anymore but still ...
<siretart> k
<notgary> jbicha, I've run into a dependency issue with colord like you said I would earlier. You also mentioned something about setting a repos dictionary in jhbuildrc that I don't understand. How can I get Freedesktop repos added to the build list without having to download and build each one manually?
<siretart> I'll try to have a look at it tomorrow or next weekend, i need to crash now.
<siretart> good night
<jbicha> notgary: you tried jhbuild buildone colord after adding that line to your jhbuildrc?
<notgary> jbicha, Doh, I thought it would a single command leading to a long chain of dependency builds :P
<jbicha> notgary: sure, you can do jhbuild build gnome-control-center if you want to try that
<notgary> jbicha, Cool. So what's the use case for buildone over build? Surely you would want to build dependencies.
<jbicha> notgary: I prefer the control of jhbuild buildone so that I can use system dependencies as much as possible
<notgary> jbicha, Ah, makes sense.
<jbicha> but I think most people just recommend jhbuild build which I think still uses system dependencies if they're already installed
<neo31> siretart, we are still trying to found our way around. please if you have any more hints we will really appreciate it. (FYI 'dh_auto_configure --buildsystem cmake' didn't resolve the problem)
<IDWMaster> Porting to Debian failed. What is the other way to get my package in Ubuntu when it cannot be ported to Debian?
<IDWMaster> It has dependencies that Debian Squeeze does not support
<IDWMaster> Specifically; it requires a newer version of g++ than is supported
<jtaylor> debian has 4.7 in unstable and 4.8 in experimental
<IDWMaster> OK, so do I just set pbuilder to unstable instead of squeeze than?
<jtaylor> yes
<IDWMaster> OK, thanks!
<neo31> we have put the option inside the rules file as a parameter of the dh command, it seems to compile now siretart
<chilicuil> hi there, I'm trying to fix a package.., however when Idownload it with bzr, it said it's "OUT-OF-DATE", how can I get the up to date version?, the full log: http://paste.ubuntu.com/5580712/
<notgary> jbicha, Hmm, something during this whole process has gone and hosed my system. Now when I boot all I have is a blank screen with a cursor floating around in it. I'm guessing this is something to do with the bleeding edge gnome code I installed. Does this sound familiar?
<jbicha> notgary: you know how to use ppa-purge, right?
<notgary> jbicha, I do now :P
<jbicha> notgary: knowing how to unbreak your computer is a prerequisite for that PPA, did you see the message at https://launchpad.net/~gnome3-team/+archive/gnome3-staging/ ?
<jbicha> there's also a #ubuntu-gnome channel if you want to discuss those ppas more
<notgary> jbicha, Actually I missed the message. I guess every day's a school day :P
<Logan_> james_w: Can you please perform requeue_package.py --full coreutils # ?
<xnox> Logan_: is that for package importer?
#ubuntu-motu 2013-03-03
 * xnox should be able to do that now, but i have not poked UDD yet.
<cjohnston> thanks bdrung
<Logan_> xnox: yup
<micahg> tumbleweed: I skipped it since it was seeded everywhere
<micahg> well, almost everywhere
<Logan_> If the only delta in Ubuntu is earlier symbols versions in the symbols control file (because Ubuntu provided new upstream releases of a package before Debian did), should the delta be dropped?
<Logan_> Or should the diff be forwarded to Debian?
<micahg> Logan_: I'd say that depends if there's still that older version in the archive, if yes, try to forward the diff IMHO
<Logan_> micahg: Thanks. :)
<james_w> Logan_: done
<Logan_> james_w: Thanks. :)
<Logan_> chilicuil: coreutils was dequeued, which should fix the problem you reported earlier
<Logan_> *requeued
<chilicuil> Logan_: ok, thanks!
#ubuntu-motu 2014-02-24
<dholbach> good morning
<Noskcaj> dholbach, Any chance you could sponsor https://code.launchpad.net/~noskcaj/ubuntu/trusty/clutter-1.0/1.16.4/+merge/207778 ?
<Noskcaj> woops, should have said that in -devel
<dholbach> Noskcaj, I'm a bit busy right now - can you try asking in -devel?
<Noskcaj> ok
<dholbach> thanks
<phanimahesh> Hey!
<phanimahesh> I'm trying to debug a FTBFS issue.
<phanimahesh> and I'm stuck.
<phanimahesh> Anyone has a few minutes to spare?
<Noskcaj> phanimahesh, yeah, sure
<phanimahesh> Noskcaj: Thanks. :)
<Noskcaj> what's the issue
<phanimahesh> I'm the developer of unity-tweak-tool
<phanimahesh> and we have a FTBFS only on trusty.
<phanimahesh> attempting to fix it somehow screwed up the build on all platforms, and I have reverted my "fixes"
<phanimahesh> allow me to fetch a failed log for you
<Noskcaj> ty
<phanimahesh> https://launchpad.net/~freyja-dev/+archive/unity-tweak-tool-daily/+build/5627836/+files/buildlog_ubuntu-trusty-i386.unity-tweak-tool_0.0.7-0%7E180%7Eubuntu14.04.1_FAILEDTOBUILD.txt.gz
<phanimahesh> That is the most recent attempt.
<phanimahesh> https://github.com/freyja-dev/unity-tweak-tool/blob/master/debian/rules
<phanimahesh> And that is our debian/rules file
<phanimahesh> The issue appears to be that the build system is trying to reference a non existant python version.
<Noskcaj> ubuntu currently build python3.4 and 3.3 i think
<phanimahesh> The logs show that python 3.3 is not found.
<phanimahesh> the build happened with python 3.4, and then somewhere in there, it tried to reference python 3.3
<phanimahesh> If I try removing the line
<phanimahesh> for python in $(shell py3versions -r); do
<phanimahesh> to not try all versions,
<Noskcaj> Could you try building with the rules files at http://paste.ubuntu.com/6985889/
<phanimahesh> then only the man page is getting bundled.
<phanimahesh> Sure, I'll queue up a build now.
<phanimahesh> sorry, i'm on a low bandwidth network and can not run a local pbuilder.
<phanimahesh> I'm pushing it to my playground ppa right now.
<Noskcaj> Since this is a python transition issue, maybe contact #ubuntu-devel or check the unity-tweak-tool ubuntu package (if there is one_
<phanimahesh> debuild -S itself fails with your debian/rules
<Noskcaj> error message plz
<phanimahesh> well, the package is there in the repos, and I am its developer.
<phanimahesh> dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2
<phanimahesh> Noskcaj: ^
<Noskcaj> that means something broke further up
<Noskcaj> Could you paste the build log
#ubuntu-motu 2014-02-25
<dholbach> good morning
<trijntje> Hi all, do I need to submit a feature freeze request for bug  1280332
<ubottu> bug 1280332 in Ubuntu "[needs-packaging] request for packaging: ubuntu-defaults-nl" [Wishlist,Fix committed] https://launchpad.net/bugs/1280332
<trijntje> to get the package into trusty
<trijntje> ping dholbach, you replied to my bug earlier, can you give me some advice on how to proceed?
<dholbach> hi trijntje - I'm a bit busy right now - I was sort of hoping that another reviewer (who's part of 'ubuntu-sponsors') could take care of it
<dholbach> can somebody help trijntje with bug 1280332?
<ubottu> bug 1280332 in Ubuntu "[needs-packaging] request for packaging: ubuntu-defaults-nl" [Wishlist,Fix committed] https://launchpad.net/bugs/1280332
<trijntje> dholbach: no problem, thanks for your time.
<trijntje> to everybody else: this is my first time going through this procedure, so please let me know if I made a mistake or need to take additional steps
<mitya57> trijntje: Yes, you need a FFe request as described in https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_new_packages
<trijntje> mitya57: an earlier version of the package is already in the repository
<trijntje> so I probably have to follow the steps for an exception for new upstream versions?
 * mitya57 looks
<mitya57> trijntje: Ah, I see. Then the bug shouldn't have [needs-packaging] in the subject, which is confusing.
<mitya57> trijntje: Do you have a diff between current and new versions somewhere?
<trijntje> mitya57: ill have to check the bzr of the project for that, hold on
<mitya57> Is it https://bazaar.launchpad.net/~ubuntu-defaults-nl-team/ubuntu-defaults-nl/ubuntu-defaults-nl/revision/12?remember=5&compare_revid=5 ?
<trijntje> yes
<trijntje> the main difference with the current version is that some of the dutch radiostations changed their stream url
<trijntje> current = currently in the repository
<mitya57> Then you don't need an FFe I think
<mitya57> Maybe I will sponsor it right now, even
<trijntje> that would be great, thanks for helping me out
<mitya57> trijntje: Can I use version number 6 instead of 12+6~ubuntu14.04.1 ?
<mitya57> Also, do you have a changelog entry somewhere, or should I write one for you?
<trijntje> mitya57: version number 6 is fine, the one in the repo now has 5
<trijntje> I'm afraid I haven't kept a changelog in the package
<trijntje> the main changes from the bzr log are
<mitya57> OK, so I'll build it myself :)
<trijntje>   Added COPYING file with GPL 3
<trijntje>   Removed empty background.jpg
<trijntje>   Updated changed urls for radiostations, added ClassicFM
<mitya57> trijntje: Oh, did you drop ubuntu-defaults-nl binary package?
<mitya57> Also launchers.txt was updated
<trijntje> mitya57: yes, defaults-nl was for compatibility with a ppa I had for 12.04, and it's no longer needed
<trijntje> and I also added a launcher for ubuntu-docs to the launchers.txt file
<mitya57> I'm afraid we still need to keep it, as a transitional package
<mitya57> I.e. it should be priority: extra and section: oldlibs
<mitya57> and depend on new package
<trijntje> for how long should it be kept?
<mitya57> You will be able to drop it after trusty release
<mitya57> I.e. for 2 months L)
<mitya57> That was ":)"
<trijntje> mitya57: ok, I'll add it back and commit it to launchpad
<mitya57> Don't worry, I will do that myself
<mitya57> trijntje: Wh are you overriding dh_install, instead of passing --with ubuntu_defaults to dh sequencer?
<mitya57> *Why
<trijntje> mitya57: I'm not sure, I think that was part of the boilerplate I used
<mitya57> Ah, ignore that, it doesn't have a .pm file so that won't work
<mitya57> trijntje: last question: why did you drop the -nl package and not -nl-nl? The name with one -nl looks much better to me...
<trijntje> it has to do with the way languae codes work, in theory someone else could create a similar package for belgium, which would be nl-be
<trijntje> (both countries have a duch speaking population)
<mitya57> OK
<trijntje> I agree it doesn't look very nice, but the main purpose of the package is to enable the creation of custom duch ubuntu images, so it will be rare for users to install the package manually
<mitya57> trijntje: One more question: you added some .desktop files to launchers list, but didn't add the relevant packages dependencies
<mitya57> That sounds like a bug
<trijntje> yeah, I should have removed 'gemeenschap', since adding custom launchers is not allowed
<trijntje> I did not add a dependency for yelp, since thats installed by default on ubuntu (thats the 'help' application)
<mitya57> Mmh, maybe
<trijntje> I do know it fails gracefully, since I completely forgot to remove the entry for gemeenchap after I removed the gemeenschap.desktop file
<trijntje> and I didn't end up with a 'missing icon' on the launcher or something like that, so the package still 'works' without yelp, maybe it should recommend it?
<mitya57> Not sure,  I think relying on default install is fine
<mitya57> trijntje: Uploaded!
<trijntje> mitya57: awesome, thanks a lot! Is there like an upload queue I can monitor to see when it will be available
<mitya57> trijntje: you'll get an email when it migrates, usually takes ~an hour
<trijntje> mitya57: ok, thanks again for helping me out, I'll be waiting for that email ;)
<mitya57> You are welcome :)
#ubuntu-motu 2014-02-26
<dholbach> good morning
<ngaio> Good morning! The Debian package of my program is out of date - what is the procedure to ask a MOTU to ensure Universe has an up to date version?
<geser> which package is it?
<Noskcaj> ngaio, what package?
<Noskcaj> dammit
<Noskcaj> lol
<Sonderblade> suppose you want to create an ubuntu package of an upstream source package, is it then enough to add the debian/ directory to your bzr on launchpad or do you need to clone all the upstream source code?
<ngaio> geser, Rapid Photo Downloader http://git.kirya.net/?p=debian/rapid-photo-downloader.git;a=summary
<ngaio> version in Universe is 0.4.7 http://packages.ubuntu.com/trusty/graphics/rapid-photo-downloader
<ngaio> most recent version is 0.4.10
<geser> ngaio: I see that Debian hasn't this new version yet either, so best to contact the Debian maintainer about it and once it's in Debian we could try to sync it (if it's not too late by then)
<ngaio> thanks geser. If the Debian maintainer cannot update it for some reason (he seems exceptionally busy), is there another option?
<geser> ngaio: you could try to update the package yourself (if you don't find someone to do it) (but we can help you when you have questions) and get it sponsored directly into Ubuntu (and you could also offer it to the Debian maintainer)
<geser> but be aware that we are part Feature Freeze (no new upstream versions) and you would need an exception to get it in
<geser> !ffe
<ubottu> Feature Freeze Exception. See https://wiki.ubuntu.com/FreezeExceptionProcess for the freeze exception process.
<ngaio> Thanks! I was aware of the feature freeze and I pushed out a critical bug fix in January, but unfortunately the Debian maintainer has not yet had the time to update the package. I'll see what he and I can do.
<geser> you can start from the existing package and if you are lucky just need to point it to the new upstream tarball (and add a changelog entry)
<ngaio> Yes it should be fairly simple like that. I'm heading to office now and I'll be back online later - thanks once again.
<Rhonda> Laney: is it intentional that xnox is listed below NOTB in the poll?
<Laney> the order is randomised
<Laney> for each ballot
<Rhonda> I found that slightly amusing. :)
<Laney> but that sounds about right to me ;-)
<Rhonda> heh
 * Laney snuggles xnox 
<xnox> i bet i'll come, one below threshold again.
<Rhonda> Well, for me too.  After all he got me killed for something totally unrelated.  *frowns*
<Rhonda> Shows his professional behavior.  >.>
#ubuntu-motu 2014-02-27
<dholbach> good morning
 * Logan_ waves to dholbach 
<dholbach> hi Logan_
<ockham> is ubuntu default changelog urgency still low, or has it changed to medium, as seems to have debian's?
<jtaylor> depends in which distribution you are packaging
<jtaylor> urgency it has no relevance in ubuntu
<fully_human> I'm asking this since I'm in the process of helping fix Quickly. Is Quickly a dead project?
<Logan_> fully_human: you'd probably want to ask about that in #ubuntu-app-devel
<Logan_> or #quickly for that matter
#ubuntu-motu 2014-02-28
<ockham1> i haven't done this in a while, so maybe someone can help me out: i've just finished preparing a package for gourmet 0.17.0 (-0ubuntu1, i.e.) -- now how can i get this FFE'd and sponsored?
<ockham1> ok, tomorrow
<dholbach> good morning
<Rhonda> Is #launchpad the proper channel to ask for a PPA size increase?
<Rhonda> My wesnoth-devel PPA hit its size limit, and given that the current release is the first beta for the next stable we would like to send out additional calls for testing. :)
<geser> Rhonda: the proper way is to open a question on launchpad asking about it
<Rhonda> geser: The amount of open questions there is a bit daunting
<Rhonda> oh, that was quick
<Rhonda> And a nice response, too: "The addition of new Wesnoth campaigns is something I can never complain about. Done."  xD
<jtaylor> hm why is wine 1.6 stuck in proposed :(
<Rhonda> wgrant: Thanks btw!
<geser> jtaylor: not fully sure, but might be related with https://launchpad.net/ubuntu/+source/wine1.4/1.4.1-0ubuntu9/+build/5588257
<jtaylor> hm upload failure
<jtaylor> weird
<jtaylor> I really like a newer wine, the last working wine we had in ubuntu was in precise :/
<jtaylor> all in between were broken in some way
<jtaylor> unfortunately I only need it but don't know a thing about it ;)
<jtaylor> I guess I can just retry these builds
<Laney> jtaylor: did you look at the upload log?
<jtaylor> oh
<jtaylor> didn't know that exists :(
<Laney> it's on that page geser linked
<jtaylor> I see now :)
<jtaylor> I had plenty upload failures and they were just spurious errors going away on a retry
<jtaylor> but do't worry I didnt retry yet
<jtaylor> YokoZar: are you still planning to fix this?
<ockham> could someone grant me an FFe, please? https://bugs.launchpad.net/ubuntu/+source/gourmet/+bug/1286073
<ubottu> Launchpad bug 1286073 in gourmet (Ubuntu) "[FFe] Please update gourmet to 0.17.0" [Undecided,New]
<wgrant> Rhonda: np :)
#ubuntu-motu 2014-03-01
<pranith__> Hi, can anyone give me a pointer on how to create a package?
<pranith__> I want to package the global package which is here: https://code.launchpad.net/~bobby-prani/gnuglobal/global-6.2
<YokoZar> jtaylor: Wine1.6 is stuck in proposed due to a problem with britney itself
<YokoZar> jtaylor: Wine is triggering spurious "uninstallable" errors because it has a cross-arch dependency
<miseria> "El Tiempo no agrada a todo el mundo, libre albedrio, quien seria yo si pudiera hacer lo que el tiempo no puede?" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
#ubuntu-motu 2015-02-23
<dholbach> good morning
<ESphynx> good morning dholbach
<ESphynx> dholbach: I realized my packages had bad stall work area files :S
<ESphynx> even in the previous Utopic version...
<dholbach> hi ESphynx
<dholbach> oh ok
<ESphynx> I reuploaded for 0.44.11  http://mentors.debian.net/package/ecere-sdk
<ESphynx> it should just be deleting these stall files
<ESphynx> we need to fix our 'make distclean' :P
<dholbach> I uploaded the last you had and uploaded to vivid
<dholbach> why don't you just sync it once it's in debian?
<ESphynx> dholbach: I'm not sure it will go in Debian because of the Jessie freeze :S
<dholbach> and uploading it to experimental?
<dholbach> I mean... if you want to get a patch into Ubuntu, you can still ask for a patch to be uploaded
<ESphynx> dholbach: well I did do a request for sponsor on mentors but I don't know...
<dholbach> ok
<ESphynx> I registered the unbuntu-sponsors too with a link to that package :P
<ESphynx> will I get better chances if I attach a debdiff
<dholbach> no, should be the same
<Brady4MVP> Hey there all hope that you are having a good day.,  I( have a repo that has reprepro installed to it and am wondering if anyone here is good with that ?  I would like to re-install all the debs that I have in my incoming dir but can not find anything in the man pages or help for reprepro
<Brady4MVP> how do I let dput use  UNRELEASED
<Brady4MVP> I added allowed_distributions   = (UNRELEASED|.*-security)  to my dput.cf
<Brady4MVP> NVM
<Brady4MVP> was a port issue
<Fantu> hi, cinnamon package in ubuntu need 2 small change from the debian one, for now I nobody do them in ubuntu official repository, if I'll do 2.2.16-5ubuntu1 with them signed with my launchpad key is possible send it for review and upload?
<Fantu> sry for my bad english
<Brady4MVP> How do I set up auto email in sbuilder ?  I have installed sendmail and configured it and also the email address in the conf's.  Maybe I am missing something ?
#ubuntu-motu 2015-02-24
<dholbach> good morning
<Unit193> Howdy.
<ESphynx> good morning :)
#ubuntu-motu 2015-02-25
<dholbach> good morning
<Unit193> Howdy.
<aeoril> Does anyone know why the diff for this merge proposal is so huge when I have only made minor changes to one file? https://code.launchpad.net/~aeoril/ubuntu/vivid/ubiquity/fix-for-1422113/+merge/250894
<aeoril> I had previously accidentally submitted a merge proposal with the same branch name that included the files from debuild -S, but have subsequently deleted that off of launchpad, re-pulled a clean branch, applied my simple one-file code changes, then re-pushed it up.  However, that did not clean up the merge proposal diff.
<aeoril> note that when I re-pulled the clean branch, I did so in a new directory on my computer
<Laney> aeoril: presumably you want to propose it against lp:ubiquity and not lp:ubuntu/ubiquity
<aeoril> Laney ok - I just found this:  https://bugs.launchpad.net/launchpad/+bug/483945
<ubottu> Launchpad bug 483945 in Launchpad itself "No way to ask Launchpad to refresh a stale diff" [Low,Triaged]
<Laney> It's not a stale diff
<aeoril> Laney why is it so big then?  Because I proposed it against the wrong thing?
<Laney> You just asked it to diff against a different thing
<aeoril> ok, thanks
<Laney> np!
<aeoril> Laney wow!  That worked great!  I submitted my first fix for merge!  Why did launchpad automatically fill in lp:ubuntu/ubiquity if it was wrong when I went to do the merge?
<Laney> aeoril: because of the branch you pushed to
<Laney> if you'd used lp:~/ubiquity/some_name it would have been right
<aeoril> I thought so - I was following a tutorial that said to do that
<aeoril> ok, now I know better Laney.  Thanks again!
<Laney> You used the scheme for packaging branches but this is an upstream one
<aeoril> Laney but upstream for Ubuntu, right?
<Laney> Yes, the distinction is a bit blurry in ubiquity's case :)
<aeoril> Laney ok, thanks!  I hope it is acceptable to the reviewer and works as it did for me in my tests!
<Laney> They have a channel #ubuntu-installer FWIW
<aeoril> oh, cool - I wish I had known that earlier!
<aeoril> I have been very nervous about doing this right - since it is my first fix ...
<aeoril> darkxst on #ubuntu-devel helped me do this whole thing, but he did not know what to do about the merge proposal problem
<aeoril> Laney I am certainly glad I came to #ubuntu-motu, though!
<Laney> heh
<Laney> well, thanks for your fix!
<aeoril> Laney I just hope it is all correct!  I did my best!
<aeoril> Laney do you have time to look it over?  It is very simple ...
<Laney> aeoril: Not me, but someone from the installer team should get to it v. soon
<aeoril> Laney ok, cool - thanks again!
<Laney> and if not, you know where to find them now
<aeoril> yes, I do
<aeoril> Laney it was an interesting "first fix" because I had to boot a LiveCD and then scp the .debs, install them, then manually run ubiquity to test
<aeoril> (all in a vm)
#ubuntu-motu 2015-02-26
<Logan> ari-tczew: in the future, I would prefer if you asked me before taking one of my merges
<ari-tczew> Logan: ok, I'll do
<Logan> I didn't realize you'd already done it until I uploaded myself (and got rejected) :P
<ari-tczew> Logan: due to CVE.. hope you're not angry
<Logan> no worries :)
<ari-tczew> Logan: sorry again
<dholbach> good morning
<ESphynx> dholbach: good morning :)
<dholbach> hi ESphynx
<ESphynx> dholbach: 4 days until we know whether we're accepted in GSoC :)
<dholbach> nice, good luck!
<ESphynx> I think it would give us a big push in terms of visibility :)
<ESphynx> thanks
<ESphynx> dholbach: we're planning a whole revamp of the graphics & GUI engine
#ubuntu-motu 2015-02-27
<dholbach> good morning
<ESphynx> good morning ;)
<ESphynx> dholbach: do I need to do anything to make sure this bug get fixed? :P https://bugs.launchpad.net/ubuntu/+source/ecere-sdk/+bug/1424418
<ubottu> Launchpad bug 1424418 in ecere-sdk (Ubuntu) "Work area files mistakenly included in orig tarball" [Undecided,New]
<dholbach> yep that should be fine
<dholbach> ESphynx, although........
<ESphynx> yeah?
<dholbach> ESphynx, it's a different upstream tarball?
<dholbach> with the same version number?
<dholbach> ah yes
<ESphynx> dholbach: I had mistakenly included work area files in the 'orig' build produced by debuild
<dholbach> that'll be hard to be fixed
<ESphynx> the source is the same
<dholbach> dpkg-source: error: file /home/daniel/ecere-sdk_0.44.11.orig.tar.bz2 has size 43373761 instead of expected 43492795
<ESphynx> the 'real' orig source did not change
<dholbach> right
<dholbach> but we now have 0.44.11-0ubuntu1 with the old tarball in the archive already
<dholbach> so we can't upload a changed tarball
<ESphynx> can't we nuke it
<dholbach> no
<ESphynx> it's kind of a privacy issue as well
<ESphynx> as those work area files should never have been uploaded
<ESphynx> (really need to fix our make distclean :S)
<dholbach> so, you could try to release 0.44.1.1 or something - that'd be the the clean way of going about it
<ESphynx> hmm couldn't we do a debian/ that takes out these extra files? I don't want to change the version number as it'  stall files from build loading projects that are in there , no change to the source...
<dholbach> hum
<dholbach> are these files installed onto the user's system at all?
<ESphynx> no they are not... they're just stall files there
<geser> ESphynx: that will only remove the files during the build but not the .orig.tar.gz
<dholbach> so they're just in the source
<dholbach> ?
<ESphynx> eys
<dholbach> right
<dholbach> in that case, there's no other way: we need a new tarball
<dholbach> I mean, it could be a fake "new tarball"
<dholbach> like 0.44.11+1 or some suc
<dholbach> such
<ESphynx> well the new tarball is @ http://mentors.debian.net/debian/pool/main/e/ecere-sdk/ecere-sdk_0.44.11.orig.tar.bz2 :P
<geser> ESphynx: 0.44.11+repack as "new" upstream version will do
<ESphynx> geser: ok. should I do anything about it?
<ESphynx> a new debuild with that new name?
<geser> the archive won't accept a 2nd file with the same name but different contents (neither in Ubuntu nor Debian for that matter)
<ESphynx> geser: well it never made it into Debian yet :P
<geser> is it in Ubuntu?
<ESphynx> yes it is
<geser> if you want to fix this in Ubuntu now, you need to use 0.44.11+repack or something like that and can keep 0.44.11 for Debian
<ESphynx> so I should redo a debuild and upload new .dsc / .orig and everything?
<geser> but you can't sync from Debian to Ubuntu until the next real new upstream or you also upload 0.44.11+repack to mentors (and then Debian)
<ESphynx> k
<geser> for Ubuntu: yes, new .dsc, new .orig, new upstream version string
#ubuntu-motu 2015-02-28
<Zhenech> will vivid be shipped with 3.18 or 3.19 kernel?
<Rhonda> linux | 3.19.0-7.7              | ubuntu/vivid-proposed            | source
<Rhonda> Ah, but in vivid itself there is 3.18.
<Rhonda> I didn't say anything. ;)
<Zhenech> Rhonda, :x
<ESphynx> geser: I imagine I will need a new changelog entry as well for 0.44.11+repack?
<ESphynx> ah or that should be 0.44.11-2 ?
<Fantu> hi, cinnamon package in ubuntu needs 2 small changes still missed, I prepared new build with it and uploaded in my launchpad for now: https://launchpadlibrarian.net/198985684/cinnamon_2.2.16-5_2.2.16-5ubuntu1.diff.gz
<Fantu> https://launchpad.net/~fantonifabio/+archive/ubuntu/ubuntu-fixes/+packages
<ESphynx> oh cinnamon is finally available from Ubuntu repos? :)
<Fantu> 2.2 seems works and I prepared also 2.4, maxy now will review it and upload to debian experimental
<Fantu> *works->good
<Fantu> I'm intering to give small help also with ubuntu cinnamon packages if possible
<Fantu> *interesting
<Fantu> the cinnamon build above can be good for ubuntu upload or other changes are needed?
<Fantu> thanks for any reply and sorry for my bad english
<ESphynx> geser: https://bugs.launchpad.net/ubuntu/+source/ecere-sdk/+bug/1424418 -- I uploaded the new tarball/dsc with +repack version
<ubottu> Launchpad bug 1424418 in ecere-sdk (Ubuntu) "Work area files mistakenly included in orig tarball" [Undecided,New]
<Fantu> sry for probably stupid question, even if I'm in uploader field of packages taken from debian I can't upload ubuntu specific build, is correct?
<Fantu> what I must do to make this build with ubuntu specific changes considered for upload?
<Fantu> https://launchpadlibrarian.net/198985684/cinnamon_2.2.16-5_2.2.16-5ubuntu1.diff.gz
<Fantu> https://launchpad.net/~fantonifabio/+archive/ubuntu/ubuntu-fixes/+packages
<tumbleweed> Fantu: debian developers / DMs can get upload rights in Ubuntu pretty easily, but until you get them, you need to use the sponsorship queue
<Fantu> thanks for reply, from a fast look seems that for it I must open a bug report for the package and attach the debdiff, is it correct?
<tumbleweed> yes, and subscribe the sponsors team
<Fantu> done: https://bugs.launchpad.net/ubuntu/+source/cinnamon/+bug/1426762
<ubottu> Launchpad bug 1426762 in cinnamon (Ubuntu) "Cinnamon package require 2 small ubuntu specific changes" [Undecided,New]
<Fantu> there a strange thing, the package built in launchpad some hours ago is still pending (https://launchpad.net/~fantonifabio/+archive/ubuntu/ubuntu-fixes/+packages) even if is not a problem since I have already tested the changes time ago
<teward> Fantu: you might poke #launchpad on that
<teward> (especially if its not publishing_
<Fantu> backports cinnamon and related software to trusty is possible (in trusty-backports)? I already did it in launchpad, tested the packages (installed also in notebook I use for works in latest months) and found needed important changes for trusty. if is possible what I must do?
<ScottK> !backports | Fantu
<ubottu> Fantu: 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
<Fantu> thanks for reply
<Fantu> !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
#ubuntu-motu 2015-03-01
<smallfoot-> Vivid packages IPython 2.3, however yesterday IPython 3.0 got released, can the package be updated?
<tumbleweed> smallfoot-: jtaylor maintains ipython in debian, and is a MOTU in Ubuntu. He knows the procedures here
<smallfoot-> oh cool
<jtaylor> unlikely for vivid
<smallfoot-> aww :(
<jtaylor> as we are past featurefreeze
<jtaylor> also it needs a slurry of other package updates first
<smallfoot-> I was hoping for it in Vivid, because IPython 3.0 seems like a very interesting release
<jtaylor> a backport may be possible
<smallfoot-> ah, I see
<jtaylor> you should be able to install it via pip quite easily
<smallfoot-> I am very excited for Vivid, it has GNOME 3.14, kernel 3.19, Wayland 1.7, it looks to be a very nice release, I just hope Xserver 1.17 hits too
<smallfoot-> Also, I am very excited for IPython 3.0 which seems to be very promising
<jtaylor> didn'T get to look at whats really new yet besides other language support
<jtaylor> did multi-user make it in?
<jtaylor> that would make packaging complicated :/
<smallfoot-> I am not sure, but now you can use IRuby, IJulia, I think. Support for multiple-kernels, all selected from the GUI from one server
<smallfoot-> http://ipython.org/ipython-doc/3/whatsnew/version3.html
<jtaylor> yes though those kernels all need separate packaging
<jtaylor> so it will take a little while
<smallfoot-> ah, I see
<smallfoot-> you can try it on https://tmpnb.org
#ubuntu-motu 2016-02-29
<dholbach> good morning
<teward> micahg: ping, if you aren't busy - can you poke at the sync request for the znc package and then follow up with the release team on an FFe?
<teward> hate to ask it to get included, but..
<teward> (wish it had been before FeatureFreeze)
<micahg> teward: unfortunately, my build env is broke at the moment, so I haven't been processing a lot of requests
<teward> micahg: ack.  i've got build environments I can loan to it, including my xenial-buildtests PPA and sbuild environments for amd64/i386, but I'm having headaches with regards to Internet speed right now, so those're slow
<teward> i'm planning on running PPA builds anyways, 'cause i provide those as a favor to ZNC upstream :p
 * teward is currently waiting on the Release Team to address an nginx FFe request for a new upstream version
<teward> so the znc sync request is my 'least concern' it's just a 'would like to have before final freezes'
<micahg> if it's in the sponsorship queue, I think people have been working to clear that more regularly now
<teward> micahg: ah, well, it should be `requestsync` did that
#ubuntu-motu 2016-03-01
<dholbach> good morning
#ubuntu-motu 2016-03-02
<mitya57> Unit193, remember the qsystemtrayicon bug you pinged me about? Can you please check if it's still the case with latest qtbase packages?
<mitya57> (Test without appmenu-qt5, obviously)
<Unit193> Of course, had to mess with it recently.  Can do, was about to run nightly updates on the affected system.
<mitya57> Thanks!
<Unit193> (kernel update is taking longer than it should.)
<Unit193> mitya57: So looks like no icon still.
<mitya57> :(
<mitya57> Unit193, if you have some time, can you please send me a log from dbus-monitor?
<mitya57> I.e. launch dbus-monitor, then start the app, and paste everything that dbus-monitor printed
<Unit193> wc -l dbus.holycrap                                                                                                .:2:38:25 on 16-03-02:.
<Unit193> 4523 dbus.holycrap
<mitya57> That's okay :)
<Unit193> Too long to look at things to redact, PM'd.
<dholbach> good morning
<Unit193> Howdy.
<mitya57> Hey dholbach!
<dholbach> hey hey :)
<mitya57> Unit193, one more thing: can you please run the application with QT_LOGGING_RULES="qt.qpa.tray=true;qt.qpa.menu=true" set and paste the applications output?
<Unit193> qt.core.logging: Ignoring malformed logging rule: 'qt.qpa.tray=true;qt.qpa.menu=true'
<mitya57> Hm
<mitya57> Ah, maybe multiple rules appeared only in Qt 5.6
<mitya57> Unit193, then please QT_LOGGING_RULES="qt.qpa.*=true"
<Unit193> https://paste.unit193.net/?ad6bd1ed27357b53#TmNpTmA6b1VGSEPFB4Ufu+XE3WLg+h5ZGzoC6UNImFM=
<mitya57> Thanks a lot
<Unit193> Of course.
<mitya57> Aaaaah
<mitya57> Unit193, look at this: https://github.com/andrew-bibb/cmst/blob/master/apps/cmstapp/code/control_box/controlbox.cpp#L2348
<mitya57> It registers/unregisters the icon 125 times until the geometry is "correct"
<mitya57> But the geometry only makes sense for classic XEmbed tray, for indicators there is no geometry
<mitya57> Unit193, now, your dbus log ends only on 55th attempt out of 125 :-)
<mitya57> I think you can just drop that horrible hack and everything will work
<Unit193> mitya57: That'd make sense only if I ran with --use-xfce or --use-mate though, I believe.
<Unit193> But yeah, it has had problems in the past with a tray icon.  May just force a tray icon for now (like with dropbox), or use appmenu.  Anywho, I'm out for the rest of the night.
<mitya57> Unit193, there are exactly 126 lines with 'unregistering "org.kde.StatusNotifierItem-20136-2"' in your log, so it is *that* code
<Unit193> Fun, shouldn't be doing that..
<mitya57> To sum up, I don't see any bugs on Qt side here. Also IIRC last time you told me the systray example from qtbase5-examples works correctly, which kindof confirms that :)
<mitya57> I can try to file a bug against cmst upstream if you want.
<Unit193> 'systray' being the one when you press the button for the alert?
<mitya57> Yes. Or did it not work?
 * mitya57 can't find the log
<Unit193> mitya57: Main icon didn't, but when you hit 'Show Message' they did, to sum up.
<mitya57> Ah, right
<Unit193> And confirmed, still the case.
<mitya57> Mirv, As you are going now, I won't bother you anymore, but next time logs from the official example can be also interesting to check.
<Unit193> Eg, don't test on crappy code. >_>
<mitya57> (sorry Mirv, that was for Unit193)
<Unit193> So, does that icon not showing up tell you more or less what you need?  (Granted, just not why.)
<Unit193> Right, 4am.. Tschau.
<mitya57> That doesn't tell me anything
<justin_time> Hi, I have a FFe approval for the tomahawk-player package (LP: #1487729) and I'm looking for a sponsor to get it uploaded. I would be really happy, if someone could help me! There are test builds for several architectures in this PPA: https://launchpad.net/~justin-time/+archive/ubuntu/tomahawk-player/+packages
<ubottu> Launchpad bug 1487729 in tomahawk (Ubuntu) "[FFe] Tomahawk 0.8.4 or newer [needs upgrade]" [Medium,In progress] https://launchpad.net/bugs/1487729
<justin_time> dholbach: Hey, sorry that I disturb you again, I got a FFe approval for the tomahawk package with the following message: "FFe approved, please work with a sponsor (dholbach?) to get it uploaded." Have you some time to sponsor me and my package? I also asked the maintainers of the old tomahawk package, but they do not have upload rights any longer for this package. I know you are very busy, but writing mails to the list
<justin_time> does not help me to find a sponsor.
<dholbach> I'm sorry, I'm in a call right now and quite busy
<dholbach> can somebody please help justin_time?
<dholbach> https://bugs.launchpad.net/ubuntu/+source/tomahawk/+bug/1487729
<ubottu> Launchpad bug 1487729 in tomahawk (Ubuntu) "[FFe] Tomahawk 0.8.4 or newer [needs upgrade]" [Medium,In progress]
<justin_time> dholbach, oh sorry for the disturbance.
<dholbach> no worries justin_time!
<Unit193> micahg: I don't suppose I could convince you to sync the newly uploaded irssi-scripts from Debian?  The one in Ubuntu has several of the scripts broken, for example screen-away is broken due to the newer version of screen.
#ubuntu-motu 2016-03-03
<micahg> Unit193: I'll see what I can do
<dholbach> good morning
<karstensrage> how do i install something with a makefile to /lib/i386-linux-gnu
<karstensrage> install -s foo.so /lib/<what here>/
<Rhonda> Can I test in a PPA somehow a test build for a package that would go into main?  I mean one that should *not* be built in an environment that can pull in packages from universe?
<Laney> Rhonda: PPAs have an option to configure that if the package is already in main
<Laney> don't know if you can do it for new packages
<Laney> or you can use pbuilder/sbuild and disable everything else :)
<Rhonda> Someone told me that a hack with alternative Build-Depends should work in the ubuntu build system (while it doesn't in Debian), and I want to have that checked.
<Laney> ah
<Rhonda> Package is irssi, and if that works I might be able to get rid of the ubuntu diff along that path (and be forever grateful to Unit193 for prodding me that way and figuring it out :))
<Rhonda> Btw., in which state is the release?  I just pushed 0.8.18 a day or two ago to Debian unstable and guess it would be nice to get that into the next ubuntu release, too. :)
<Laney> Rhonda: so "Edit PPA dependencies" -> "Use the same components used for each source in the Ubuntu primary archive."
<Laney> feature freeze
<Rhonda> Unit193, can you check for that merge until we have fixed that?
<mitya57> Unit193, the second part of my last comment in bug 1546328 may explain some issues with Qt tray icons. If my theory is right, then running apps with XDG_CURRENT_DESKTOP=Unity should make the icons show.
<ubottu> bug 1546328 in qjackctl (Ubuntu) "Systray option does not work." [Critical,Confirmed] https://launchpad.net/bugs/1546328
<Unit193> mitya57: That worked, yes.
<mitya57> Then we need to fix indicator-application :P
#ubuntu-motu 2016-03-04
<justin_time> Hi, I have a FFe approval for the tomahawk-player package (LP: #1487729) and I'm looking for a sponsor to get it uploaded. I would be really happy, if someone could help me!
<ubottu> Launchpad bug 1487729 in tomahawk (Ubuntu) "[FFe] Tomahawk 0.8.4 or newer [needs upgrade]" [Medium,In progress] https://launchpad.net/bugs/1487729
#ubuntu-motu 2016-03-05
<justin_time> Hi, I'm looking for a new sponsor for my tomahawk package (LP: #1487729). I have a approved FFe but unfortunately the sponsor who reviewed my package is busy. And so it would be really nice if someone could sponsor me!
<ubottu> Launchpad bug 1487729 in tomahawk (Ubuntu) "[FFe] Tomahawk 0.8.4 or newer [needs upgrade]" [Medium,In progress] https://launchpad.net/bugs/1487729
<hanno> Hi. I have only recently started packaging software in Debian and still stumble around with regards to the rules.
<hanno> Now I have four packages in Debian sid that have also come to Universe.
<hanno> I did read https://wiki.ubuntu.com/Ubuntu/ForDebianDevelopers but still have a bunch of questions.
<hanno> For one, here's my list of packages - https://qa.debian.org/developer.php?email=kontakt%40hanno.de
<hanno> I'd want to have all four of them synced now, as they are now imho in a stable state.
<hanno> I did read https://wiki.ubuntu.com/SyncRequestProcess but now I wonder...
<hanno> ...can this be done or does the DebianImportFreeze stop this?
<Unit193> Hello, I'm not a MOTU.  Since the packages are not seeded in any ISO and are fairly new, I'd think your request for a sync would indeed go pretty smooth.  If they are just bug fixes and no features added, extreamly easy.  DIF (Debian Import Freeze) affects only automatic sync, the one that'd be more worrysome is FeatureFreeze.
<hanno> Thanks for clarifying.
<mitya57> hanno, if you tell me your launchpad username I can sync ruby-wavefile for you right now â that one looks like a clear bugfix release.
<mitya57> The other ones may need feature freeze exception first..
<hanno> Thanks. I'm filing the bugs with requestsync right now.
<hanno> https://bugs.launchpad.net/ubuntu/+source/ruby-wavefile/+bug/1553583
<ubottu> Launchpad bug 1553583 in ruby-wavefile (Ubuntu) "Sync ruby-wavefile 0.6.0-2 (universe) from Debian unstable (main)" [Undecided,New]
<Unit193> mitya57: Oooh, core-dev?  I take it you'd tell me to FFe irssi too? :3
<mitya57> Unit193, that one is a merge rather than sync, right?
<Unit193> Da.
<Unit193> Yes.
<mitya57> The version number tells me it probably doesn't need an FFe
<hanno> I'd very much love to have Sonic Pi 2.9.0 in Xenial.
<Unit193> And FWIW, been working with Debian's maintainer to help reduce or eliminate the need for a merge.  dget https://sigma.unit193.net/source/irssi_0.8.18-1ubuntu1.dsc  (I'm not sure if it fits, but there it is.)
<mitya57> hanno, ruby-wavefile synced
<hanno> Thank you very much!
<mitya57> For Sonic Pi just file a FFe request and I'm sure it will get accepted
<mitya57> Unit193, uploaded :)
<Unit193> Wow, thanks a lot mitya57!
<mitya57> Yw!
 * mitya57 EOD, should really be sleeping by this time
<hanno> Oh, yow, for FFe I have to file a build log, too?
<mitya57> Yes
<mitya57> If it's difficult for you, a link to buildd.debian.org may work
<hanno> It's only difficult _right now_, as my xenial test vm system is at the office.
<hanno> but if link to buildd.d.o is ok, that's even better. Thanks.
<hanno> Ok, filed FFe for ruby-hamster, supercollider-sc3-plugins, sonic-pi (all new packages that shouldn't break anything else)
<hanno> When a ffe request is set to "wishlist" - is that a good sign or a bad sign?
#ubuntu-motu 2017-02-28
<Unit193> rbasak: Howdy.  Anything else I should fix, re: ruby-simplecov?
<rbasak> Unit193: context please?
<Unit193> rbasak: LP 1666988, wondered if there was anything else before I upload a new debdiff with the changelog fixes.
<ubottu> Launchpad bug 1666988 in ruby-simplecov (Ubuntu) "Incompatibilities with ruby-json =>2.0" [Undecided,New] https://launchpad.net/bugs/1666988
<rbasak> Unit193: are you planning to look after the package until it's in sync again please?
<rbasak> Unit193: but yeah, I don't see anything else I said not covered by a changelog fix then, thanks.
<Unit193> rbasak: I don't know ruby well, I'd expect it to get in sync next cycle again though.  But yeah, certainly.
<rbasak> Thanks :)
<Unit193> rbasak: You can take a look at ruby-trello for what I'm talking about regarding the issue, though.
<rbasak> Look at it how?
<Unit193> For example, try building it without this fix.
<rbasak> I'd rather believe what you say :)
<rbasak> I don't see a ruby-trello package in Ubuntu though?
<Unit193> It's not, https://launchpad.net/~unit193/+archive/ubuntu/test/+packages?field.name_filter=ruby&field.status_filter=published&field.series_filter=zesty
<Unit193> rbasak: Thanks for taking a look, updated the bug.
<rbasak> Unit193: I can take a look tomorrow (UTC working hours) for you. Ping me if I forget please.
<Unit193> Sure, thanks.
#ubuntu-motu 2017-03-01
<fossfreedom_> Please can anybody sponsor our (Ubuntu Budgie) bug-fix package?  Reason - would be useful to get some early confirmation testing.  TIA - https://bugs.launchpad.net/ubuntu/+source/budgie-desktop/+bug/1667144
<ubottu> Launchpad bug 1667144 in budgie-desktop (Ubuntu) "v10.2.9-3ubuntu3 bugfix release of budgie-desktop" [Low,In progress]
<rbasak> fossfreedom_: have you build tested it etc?
<fossfreedom_> rbasak: yes I have.
<fossfreedom_> rbasak: much appreciated.  Is the 64bit LP builders having a bit of a strange time?  the amd64 build has failed but there is no build log -  every single other build has passed.
<rbasak> I pressed the retry button.
<fossfreedom_> rbasak: thanks.  just monitoring the build - still no buildlog output - very weird - https://launchpad.net/ubuntu/+source/budgie-desktop/10.2.9-3ubuntu3/+build/12071397
<fossfreedom_> yay! buildlog output !
#ubuntu-motu 2017-03-02
<Unit193> rbasak: Ah crap, thought about pinging you but it was too early.  Now it's too late.
<Unit193> rbasak: Thanks!
#ubuntu-motu 2017-03-05
<Unit193> Hrm, thought I had upload rights to xfce4-equake-plugin due to xfce*.. https://sigma.unit193.net/source/xfce4-equake-plugin_1.3.8.1-0ubuntu1.dsc it's important due to: Debian: #856774
<ubottu> Debian bug 856774 in xfce4-equake-plugin "xfce4-equake-plugin: Fails to download data, needs to use https" [Important,Open] http://bugs.debian.org/856774
#ubuntu-motu 2018-02-27
<tsimonq2> handsome_feng: Hi there!
<tsimonq2> Did you plan on fixing up ukui-power-manager?
<handsome_feng> Yes, The developer of ukui-power-manager are still working for that
<tsimonq2> slangasek: ^
<tsimonq2> Thanks!
<tsimonq2> handsome_feng: This commit looks similar: https://github.com/ukui/ukui-power-manager/commit/137bac04731037ef91fa96141cb14700efd9f9ed
<tsimonq2> Could that be cherry picked or is there still more work to do?
<handsome_feng> It need to do some test
<tsimonq2> OK
<tsimonq2> Let me know
<handsome_feng> All right!
<handsome_feng> tsimonq2: Hi, I have uploaded the new ukui-power-manager to the PPA: https://launchpad.net/~ubuntukylin-members/+archive/ubuntu/newpackages/+packages
<tsimonq2> Aweomse
<tsimonq2> *Awesome,
<tsimonq2> I'll look shortly
<handsome_feng> Thanks! :)
<tsimonq2> 07:11:29 PM < handsome_feng> All right!
<tsimonq2> 09:43:31 PM < handsome_feng> tsimonq2: Hi, I have uploaded the new ukui-power-manager to the PPA: https://launchpad.net/~ubuntukylin-members/+archive/ubuntu/newpackages/+packages
<tsimonq2> 09:43:50 PM < tsimonq2> Aweomse
<tsimonq2> whoops
 * tsimonq2 was trying to select the URL :D
<tsimonq2> I really need to replace this cheap Dell mouse already...
<handsome_feng> haha
<tsimonq2> handsome_feng: Couple of quick packaging things that aren't a blocker at all but you should maybe look into for the next upload :)
<tsimonq2> You might want to look into using wrap-and-sort if you haven't already, it makes things a bit more organized.
<tsimonq2> You don't need this line in debian/rules because parallel is turned on by default in debhelper 10+:
<tsimonq2> DHFLAGS=--parallel
<tsimonq2> get-orig-source in debian/rules is a bit of a pkg-mateism (meaning, a bit of code that I have only seen used by the Debian MATE packaging team, or pkg-mate) and you should assess whether you use it or not
<handsome_feng> Thanks, I will pay attention next time!
<tsimonq2> Otherwise, it looks good to me :D
<tsimonq2> Ok, cool
<tsimonq2> Uploading now :D
<handsome_feng> \O/
#ubuntu-motu 2018-02-28
<handsome_feng> tsimonq2: Hi, Do you know why the ukwm be rejected?
<tsimonq2> handsome_feng: Yes, I just discussed with slangasek in #ubuntu-release :)
<tsimonq2> handsome_feng: The exact message is "debian/copyright incorrectly lists an 'or' license list for the work, implying the full work can be redistributed under any of the listed licenses, which is not true.  Stanzas need to be split by license, to not misrepresent the permissions."
<tsimonq2> handsome_feng: To be more specific:
<tsimonq2> slangasek> tsimonq2: 'Files: * License: GPL-2+ or LGPL-2+ or MIT~OldStyle+LegalDisclaimer or Expat or SGI-B-2.0' is incorrect, as this syntax claims that the work can be distributed under any of these licenses
<tsimonq2> slangasek> tsimonq2: I think the terms of the SGI-B-2.0 and Expat licenses also must be reproduced verbatim; best to do that by listing separate Files: stanzas for each license
<tsimonq2> slangasek: Am I missing anything? ;)
<handsome_feng> tsimonq2: oh, Thanks! I will fix that then
<tsimonq2> handsome_feng: Sure :)
<slangasek> tsimonq2: I think that covers it all
<tsimonq2> slangasek: OK, cool
<stkoch> Hi, my package usbauth-notifier needs an update before DebianImportFreeze... It's was updated more than 24h ago in Debian Unstable, but it has not synced until this hour. Any idea why? Thanks
<tsimonq2> (If you're reading the logs, the autosyncer just recently had to be fixed.)
<stkoch> tsimonq2: thanks
<tsimonq2> stno
<tsimonq2> grr
 * tsimonq2 's mobile keyboard sucks
<tsimonq2> np
#ubuntu-motu 2018-03-02
<handsome_feng> tsimonq2: Hi, May I ask you a question? I uploaded some ukui packages the day before yesterday, but only ukui-session-manager are still in proposed, Do you know how to find the cause? The url: https://launchpad.net/ubuntu/+source/ukui-session-manager
 * tsimonq2 will respond via email
#ubuntu-motu 2019-03-02
<CMooney> Hi, is there any mileage in me packaging pdftk-java (https://packages.ubuntu.com/cosmic/pdftk-java) to 18.04.02. I seems to be available to later versions of Ubuntu but not the LTS release. I've never packaged a deb before, but it seems simple. I just downloaded the Cosmic deb and installed but had to install some extra packages that apt required.
<Eickmeyer> Hey everyone! I messaged the Release mailing list, and the MOTU mailing list, but we're in desperate need for some packages to get uploaded and updated. I thought this would get done before Feature Freeze, but that hasn't happened. Please see bugs 1816673, 1818372, 1818368, 1818369, 1818370, 1818366, 1809024, 1818373.
<ubottu> bug 1818370 in ubuntustudio-look "[needs packaging] Update for Disco" [Critical,New] https://launchpad.net/bugs/1818370
<ubottu> bug 1818368 in ubuntustudio-default-settings "[needs packaging] Update for Disco" [Critical,New] https://launchpad.net/bugs/1818368
<ubottu> bug 1818369 in ubuntustudio-menu (Ubuntu) "[needs packaging] Update for Disco" [Undecided,New] https://launchpad.net/bugs/1818369
<ubottu> bug 1816673 in ubuntustudio-installer "[needs packaging] GUI dances while installing" [Critical,Fix committed] https://launchpad.net/bugs/1816673
<ubottu> bug 1818372 in ubuntustudio-icon-theme "[needs packaging] Update for Disco" [Critical,New] https://launchpad.net/bugs/1818372
<fossfreedom> Eickmeyer, as mentioned previously none of those bug reports has details of what you want sponsoring.  Details of the package - a ppa upload, lintian checks, check-all-the-things run etc need all to be in the bug description
<Eickmeyer> fossfreedom: Does it matter that only two of those should require that since the others are already in the repo?
 * Eickmeyer obviously has no idea what he's doing.
<fossfreedom> I can only go with my experience - everytime I uploaded a package - even if it was just an update - I had to include all those details in the bug description
<fossfreedom> once you have package upload rights - then obviously you don't need to file a bug report ... but you get into the routine of running the usual lintian, check-all-the-things, building on proposed repo via sbuild etc
#ubuntu-motu 2019-03-03
<Eickmeyer> fossfreedom: I think I just finished all of that.
#ubuntu-motu 2020-02-25
<ryanakca> Who should I prod about rather critical security vulnerabilities in universe packages?
<ryanakca> I reported https://bugs.launchpad.net/debian/+source/opensmtpd/+bug/1861242 over a month ago and even commented with which commits to cherry-pick from Debian, but the bugs are still open.
<ubottu> Launchpad bug 1861242 in opensmtpd (Ubuntu Eoan) "Major vulnerabilities in opensmtpd resulting in RCE and DOS" [Critical,Confirmed]
<ryanakca> https://bugs.launchpad.net/debian/+source/opensmtpd/+bug/1864707 was fixed by your most recent sync, but also affects past supported Ubuntu releases. I'll comment when fixes make it to buster-security and stretch-security (you should then be able to sync for bionic and eoan).
<ubottu> Launchpad bug 1864707 in opensmtpd (Ubuntu Eoan) "arbitrary command execution vulnerability" [Critical,Confirmed]
<rbasak> ryanakca: thank you for getting in touch! The security team can sponsor security updates to universe - ask in #ubuntu-hardened please. There's some documentation on what they expect: https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures
<rbasak> ryanakca: also https://wiki.ubuntu.com/SponsorshipProcess
<mdeslaur> ryanakca: FYI, CVE-2020-7247 got fixed on 2020-02-05
<ubottu> smtp_mailaddr in smtp_session.c in OpenSMTPD 6.6, as used in OpenBSD 6.6 and other products, allows remote attackers to execute arbitrary commands as root via a crafted SMTP session, as demonstrated by shell metacharacters in a MAIL FROM field. This affects the "uncommented" default configuration. The issue exists because of an incorrect return value upon failure of input valid... (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7247)
<mdeslaur> ryanakca: someone is currently working on the more recent issues
<ryanakca> mdeslaur: Thanks. If that someone would like, here are the debdiffs for the my uploads to buster- and stretch-security. https://people.debian.org/~rak/opensmtpd/buster.debdiff https://people.debian.org/~rak/opensmtpd/stretch.debdiff . Upstream's patches did not apply cleanly and required backporting to those versions.
<mdeslaur> thanks ryanakca, I'll pass those along to msalvatore (who doesn't appear to be in this channel)
<JackFrost> Now he does.
<mdeslaur> hi msalvatore
<mdeslaur> msalvatore: ryanakca filed https://bugs.launchpad.net/debian/+source/opensmtpd/+bug/1864707
<ubottu> Launchpad bug 1864707 in opensmtpd (Ubuntu Eoan) "arbitrary command execution vulnerability" [Critical,Confirmed]
<msalvatore> thanks mdeslaur, ryanakca
<ryanakca> msalvatore: here are the debdiffs for the my uploads to buster- and stretch-security if you want them: https://people.debian.org/~rak/opensmtpd/buster.debdiff https://people.debian.org/~rak/opensmtpd/stretch.debdiff
<msalvatore> ryanakca: thanks. the xenial and trusty backports may present some difficulty. We'll see :)
<ryanakca> msalvatore: I don't think trusty is affected. It has 5.4.1p1 from 2014. The LPE/RCE vulnerabilities only affect versions since December 2015: https://www.openwall.com/lists/oss-security/2020/02/24/5
<msalvatore> ryanakca: that seems correct.
#ubuntu-motu 2020-02-26
<msalvatore> ryanakca: Hey. I'm looking over the debdiff for opensmtpd. Why did you pull in changes from this commit? 555d2121736acdd70453b24b94c8c2996d9ab5f9
<ryanakca> msalvatore: for stretch? I preferred not to introduce any code that was not already in an opensmtpd release. The upstream patch for smtpctl.c does not apply cleanly because the type of makemap changed. makemap from makemap.c used to take 2 arguments and determine how it was being called by examining __progname and then set the mode to either P_MAKEMAP or P_NEWALIASES. Recent releases instead pass
<ryanakca> makemap the mode directly. In particular, ...
<ryanakca> ... upstream's patch for smtpctl.c passes makemap the mode P_SENDMAIL. I could alternatively have backported the patch by adding P_SENDMAIL to the enum 'mode', setting __progname to "sendmail" in smtpctl.c, and extending the logic in makemap.c to account for this third possibility.
<ryanakca> (I think, I didn't test.) It would have resulted a smaller patch, but it would also have meant diverging from code that opensmtpd has already released.
<msalvatore> ryanakca: gotcha. thanks.
#ubuntu-motu 2020-02-27
<msalvatore> ryanakca: were you able to get the proof of concept to run?
<ryanakca> msalvatore: Proof of concept to reproduce the vulnerability? No, it was only published after we uploaded.
<msalvatore> ok. It doesn't seem to be working for me. I haven't gotten a chance to dig down yet and see what's going on.
<ryanakca> I'll give it a try after work to make sure my backported patches actually work.
<msalvatore> ryanakca: cool. let me know how you fare.
<ryanakca> also, I think the autosync fixing focal got blocked by the debian import freeze.
<msalvatore> ryanakca: I'll see what I can do.
<msalvatore> ryanakca: I was able to test the buster patch with the poc. it seems to resolve the issue.
